NFS remount bug

NFS remount bug

[Chuck Lever]

Hi-

I'm working on the NFS submount commands.  These are found in the nfs-utils package, but they inherited a bunch of code from utils-linux to read fstab and manage mtab.

We've got a little problem with "-o remount".

At mount time, mount.nfs can negotiate with the target NFS server to determine how to contact it to send the MNT request and set up the communication parameters for the NFS protocol.  If the mount process succeeds, mount.nfs puts the command line options in /etc/mtab.

At umount time, umount.nfs reads these options back from /etc/mtab so that it can figure out how to send a UMNT request.  There are some problem cases, though.

If /etc/mtab is a link to /proc/mounts, the final fixed negotiated options appear there, not necessarily what was on the command line.  If the server reboots, some of those options might become stale.

If a remount is done, the options in /etc/mtab are wiped, so umount.nfs has no way to know how to contact the server.

We also know that everyone wants to toss /etc/mtab.

So: what future-proof mechanism do we use to preserve the mount command line so umount.nfs has a chance of working reliably?

In the meantime, is there a straightforward way to merge the old and new mount options during a remount?

-- 
chuck[dot]lever[at]oracle[dot]com

Re: NFS remount bug

[Chuck Lever]

On Oct 19, 2010, at 1:32 PM, Chuck Lever wrote:

> Hi-
> 
> I'm working on the NFS submount commands.  These are found in the nfs-utils package, but they inherited a bunch of code from utils-linux to read fstab and manage mtab.
> 
> We've got a little problem with "-o remount".
> 
> At mount time, mount.nfs can negotiate with the target NFS server to determine how to contact it to send the MNT request and set up the communication parameters for the NFS protocol.  If the mount process succeeds, mount.nfs puts the command line options in /etc/mtab.
> 
> At umount time, umount.nfs reads these options back from /etc/mtab so that it can figure out how to send a UMNT request.  There are some problem cases, though.
> 
> If /etc/mtab is a link to /proc/mounts, the final fixed negotiated options appear there, not necessarily what was on the command line.  If the server reboots, some of those options might become stale.
> 
> If a remount is done, the options in /etc/mtab are wiped, so umount.nfs has no way to know how to contact the server.
> 
> We also know that everyone wants to toss /etc/mtab.
> 
> So: what future-proof mechanism do we use to preserve the mount command line so umount.nfs has a chance of working reliably?
> 
> In the meantime, is there a straightforward way to merge the old and new mount options during a remount?

This is documented in

  https://bugzilla.linux-nfs.org/show_bug.cgi?id=188

There are some interesting test results posted there.

This looks like behavior that is totally controlled by mount(8), since mount(8) passes the correct options to mount.nfs in some cases, and sometimes it doesn't.

If the mount point is not already in /etc/fstab, and the remount command line does not include the "device" (it looks like "mount -o remount,foo /mntdir") then it gets it right (that is, it adds the correct set of mount options back to /etc/mtab).  Other combinations don't get it right.

Is there a reason why the set of mount options that appear in /etc/mtab should be different depending on how the remount command is specified and whether the mount point appears in /etc/fstab?  Any chance this can be made to work consistently in each of these cases?

Thanks for any advice, or history lessons.

-- 
chuck[dot]lever[at]oracle[dot]com

Re: NFS remount bug

[Karel Zak]

On Fri, Oct 22, 2010 at 04:14:53PM -0400, Chuck Lever wrote:
 
> This is documented in
> 
>   https://bugzilla.linux-nfs.org/show_bug.cgi?id=188
> 
> There are some interesting test results posted there.
> 
> This looks like behavior that is totally controlled by mount(8),
> since mount(8) passes the correct options to mount.nfs in some
> cases, and sometimes it doesn't.

 Yes (but it does not mean that you cannot read the original options
 from mtab in mount.nfs).

> If the mount point is not already in /etc/fstab, and the remount
> command line does not include the "device" (it looks like "mount -o
> remount,foo /mntdir") then it gets it right (that is, it adds the
> correct set of mount options back to /etc/mtab).  Other combinations
> don't get it right.
> 
> Is there a reason why the set of mount options that appear in
> /etc/mtab should be different depending on how the remount command
> is specified and whether the mount point appears in /etc/fstab?  Any
> chance this can be made to work consistently in each of these cases?
> 
> Thanks for any advice, or history lessons.

This is old and documented behaviour. There is not a difference
between remount and normal mount.

    # mount <source> <target>

means that you want to bypass fstab (mount(8) has all necessary
information on command line), but

    # mount <source> | <target>

means that you have to use fstab (command line does not contain all
information). 

If fstab does not contain <source> or <target> then it lookups mtab,
it's was probably added because

    # mount /dev/sda1 /mnt 
    # mount -o remount,ro /mnt

is expected to work independently on fstab.

I see only one problem -- many many years ago there probably wasn't
difference between mount options in fstab and mtab, so it was correct
to lookup fstab before mtab on remount. This is problem now.

IMHO mount(8) should be fixed to read mount options only from mtab
on remount. The fstab file should be ignore at all.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com