Red Hat Bugzilla – Bug 166750
nfs clients mount wrong volume after server reboot
Last modified: 2007-11-30 17:07:19 EST
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-188.8.131.52
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):
Steps to Reproduce:
1. Create and export a volume:
lvcreate -L 128M -n foo /dev/VGSYS
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
mount lille:/mnt/foo /mnt/foo
4. Reboot the server or run the following commands
service nfs stop
lvchange -a n /dev/VGSYS/foo
lvchange -a y /dev/VGSYS/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
The Red Hat Service ticket, number 550270, has also been opened about this issue.
(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
(2) See 'man exports' fsid=num for how to avoid any nfs dependency on the
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.
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?).