Bug 166750 - nfs clients mount wrong volume after server reboot
Summary: nfs clients mount wrong volume after server reboot
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lvm2
Version: 4.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: Alasdair Kergon
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-08-25 09:19 UTC by Olle Liljenzin
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-08-30 16:19:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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?).


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