Re: whither NFS umount?

[Chuck Lever <chuck.lever@oracle.com>]

Happy Monday...

On Oct 15, 2010, at 4:08 PM, Steve Dickson wrote:

> On 10/15/2010 12:00 PM, Chuck Lever wrote:
>> On Oct 15, 2010, at 9:11 AM, Steve Dickson wrote:
>> The options in /proc/mounts worked at one point in time, but /etc/mtab 
>> has the options that are probably used every time you do the mount.  
>> They are basically copied from /etc/fstab or the command line.  So we know
>> that, no matter what the server does, the /etc/mtab options are tested and
>> known to allow the client to negotiate the correct settings.
>> 
>>> Now that there is a real possibly that /etc/mtab could deprecated,
>>> I think we should start looking into making the info in /proc/mounts 
>>> work, since /proc/mounts not going anywhere... 
>> 
>> Again, I agree /etc/mtab should be deprecated, but we must not use 
>> /proc/mounts for this purpose.  Save the original mount options and 
>> use them for the umount.  That way the negotiation behavior of the MNT 
>> and the behavior of the UMNT follow exactly the same rules.
> As I've said, we already do use /proc/mounts which is fine.. IMHO.. 

The "fallback to /proc/mounts case" breaks UMNT in exactly the ways I've described.

umount.nfs will use /proc/mounts as a fallback because, without /etc/mtab, that's the only way it can match a mount point directory on the client with the file server name and export information.  However, the mount options can still be incorrect, just as I have described.  Thus this fallback is weak to worthless for sending UMNT (it will get the local umount(2) call right, but that's all that truly matters for the client, anyway).

Using /proc/mounts as a substitute for /etc/mtab works fine for a vast majority of Linux file systems, because during an unmount, they don't care what the mount options were.  They just need to know what device is associated with the mount point being unmounted.

Unfortunately for us, NFS does care about those mount options, and uses /etc/mtab in a way that most other file systems do not.  Yet another reason why no-one else but us chickens cares that a remount can rewrite mount options in /etc/mtab at whim.

>> Let's just write these options to another place besides /etc/mtab, 
>> and read them from that place during unmount.  The only change I'm 
>> talking about is putting a second copy of these options on disk somewhere.
>> 
> I don't think I'm a fan of creating yet another non-scalable
> list we need to maintain.. but that's for another day.. if/when
> /etc/mtab goes away.. 
> 
> For now, I agree with you, lets keep using /etc/mtab to 
> maintain the original options...  

We have to do something now to address this remount bug.  I'm going to code up a patch that stores the mount command line somewhere under /var/run.

Plus, as you have said, /etc/mtab is destined to be removed; has been for some time.  We will have to do this at some point anyway.

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