Bug 166750 - nfs clients mount wrong volume after server reboot
nfs clients mount wrong volume after server reboot
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lvm2 (Show other bugs)
4.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Alasdair Kergon
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-25 05:19 EDT by Olle Liljenzin
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-30 12:19:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Olle Liljenzin 2005-08-25 05:19:52 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050719 Red Hat/1.7.10-1.1.3.1

Description of problem:
Device number for lvm volumes are generated dynamically. In case the set of devices are changed, e.g. because of a snapshot volume has been created for backup, device number will be shifted at reboot.

nfs clients that mounted a filesystem before the server reboot, will access the wrong device after the reboot if the device number has changed on the server. In many cases this will result in "Stale NFS file handle", but under some circumstances the client will be operating but on a different filesystem after the server reboot. The latter case is very dangerous since running applications could update or delete files in the wrong filesystem.

'df' on the client will still report the original filesystem even if it has changed after a server reboot.

Version-Release number of selected component (if applicable):
lvm2-2.01.08-1.0.RHEL4

How reproducible:
Always

Steps to Reproduce:
1. Create and export a volume:
lvcreate -L 128M -n foo /dev/VGSYS
mkfs.ext3 /dev/VGSYS/foo
mkdir /mnt/foo
mount /dev/VGSYS/foo /mnt/foo
echo "/mnt/foo *" > /mnt/exports
service nfs start

2. Create a snapshot (to be used for making a backup)
lvcreate -L 32M -s -n foo_snap /dev/VGSYS/foo

3. Mount the filesystem on a client
mkdir /mnt/foo
mount lille:/mnt/foo /mnt/foo

4. Reboot the server or run the following commands
service nfs stop
umount /mnt/foo
lvchange -a n /dev/VGSYS/foo
#
lvchange -a y /dev/VGSYS/foo
mount /mnt/foo
service nfs start

5. Access the mounted filesystem from the client
ls -l /mnt/foo

Actual Results:  Stale NFS file handle

Expected Results:  The content of the directory should be listed

Additional info:
Comment 1 David Juran 2005-08-25 05:34:45 EDT
The Red Hat Service ticket, number 550270, has also been opened about this issue.
Comment 2 Alasdair Kergon 2005-08-30 12:19:59 EDT
  (1) If you need to mix persistent and dynamic device numbers, choose larger
minor numbers for the persistent ones so that the lower dynamic ones won't
conflict.  As you've discovered, dynamic assignment takes the lowest unused
minor number.

  (2) See 'man exports' fsid=num for how to avoid any nfs dependency on the
device-number.
Comment 3 Olle Liljenzin 2005-08-30 12:46:03 EDT
Thanks!

I will give (2) a try. The fsid option was new to me.

It would be great if a warning was printed when a dynamic device minor number
was used as fsid for an exported volume, but that is a different issue of course.
Comment 4 Damian Menscher 2005-10-19 19:29:34 EDT
If the major/minor number of the block device is not a stable identifier of a
filesystem, then a different stable identifier should be used.  The filesystem
UUID seems ideally suited for this task.  Please let me know if I should open
this as a separate bug report, or if I should just take it upstream (to who?).

Note You need to log in before you can comment on or make changes to this bug.