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-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:
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 minor number. (2) See 'man exports' fsid=num for how to avoid any nfs dependency on the device-number.
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.
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?).