Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 4 product line. The current stable release is 4.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 166750

Summary: nfs clients mount wrong volume after server reboot
Product: Red Hat Enterprise Linux 4 Reporter: Olle Liljenzin <olle>
Component: lvm2Assignee: Alasdair Kergon <agk>
Status: CLOSED NOTABUG QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 4.0CC: djuran, goeran, menscher
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-08-30 16:19:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Olle Liljenzin 2005-08-25 09:19:52 UTC 
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 09:34:45 UTC 
The Red Hat Service ticket, number 550270, has also been opened about this issue.
Comment 2 Alasdair Kergon 2005-08-30 16:19:59 UTC 
  (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 16:46:03 UTC 
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 23:29:34 UTC 
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?).