Re: whither NFS umount?

[Steve Dickson <SteveD@redhat.com>]

Good Morning,

On 10/14/2010 06:22 PM, Chuck Lever wrote:
> 
> On Oct 14, 2010, at 5:24 PM, Steve Dickson wrote:
>
>>> The mount protocol information in /proc/mounts can be very very stale
>> Well the mount(8) man page seems to disagrees with you:
>>
>>    When  the  proc  filesystem is mounted (say at /proc), the files
>>    /etc/mtab and /proc/mounts have very similar contents. The  former  
>>    has  somewhat  more  information, such as the mount options used, but is not    
>>    necessarily  up-to-date  (cf.  the  -n  option below).  It is possible to replace  
>>    /etc/mtab by a symbolic link to /proc/mounts, and especially when you have
>>    very large number of mounts things will be much faster with that symlink,
>>    but some information is lost that way, and in particular using the "user"
>>    option will fail.
>>
>> They are basically say you should replace /etc/mtab with /proc/mounts.
> 
> Right, that text is not written with NFS in mind, unfortunately. 
> I thought it was common knowledge that replacing /etc/mtab with a link
> was bad for NFS.
> 
> Notice they call out support for the "user" mount option explicitly here.
> That seems to be an important feature for network file systems.
My point is staleness.... BOTH /etc/mtab and /proc/mounts "can be very very stale"

>> . 
>>> If the mount point is very long lived, as it is for static mount points on 
>>> server-class systems, the client may have been up for months, while the 
>>> NFS servers can have rebooted multiple times during that time span.  
>>> Each server reboot can result in the mount port changing, for example.
>>> /proc/mounts has the specific set of options that were the result of 
>>> negotiation during the mount process.  Those will work sometimes, but I 
>>> think those actually have a good chance of not working in some cases.
>>>
>>> If umount.nfs starts with /proc/mounts, how can it know which of "vers=" 
>>> and "proto=" and "port=" and "mountport=" were specified on the original 
>>> command line (and thus are required to make the mount work) and those which
>>> were negotiated by mount.nfs (and thus may have changed since the original mount)?
>> Well I don't believe either the proto= or vers= will change
>> over a server reboot since the values in /proc/mounts are the
>> were negotiated to...  I do agree both the "port=" and 
>> "mountport=" can go stale... So many be should just never use them... 
> 
> Vers= won't change, which is why we can trust /proc/mounts to tell us what 
> NFS version to use for the umount.
proto= will not go stale either... 

> 
> mountvers= may go stale, 
> mountproto= can go stale, 
I think these going stale would be highly unlikely, but recoverable... 

> mountport= can also go stale.  For umount, we don't care about port=.  
True any port value can easily go stale... 

> The problem is we can't tell whether mountproto and mountport in /proc/mounts
< was specified on the command line (say, to punch through a firewall) or 
< was negotiated by user space (and is thus safe to ignore and renegotiate).
We shouldn't care whether those options were specified or negotiated.
The values in /proc/mounts are the ones that worked! So at one point 
in time we know all the values in /proc/mounts were valid (since the
entry exists). This is something that cannot be said about options
specified on the command line.

> 
> The relationship between mounthost and mountaddr can also change over time.
> /proc/mounts has mountaddr.  We really want to look up mounthost again to be reliable.
Fine... Add that to the list that needs to be updated once the first call fails... 

> 
>>> So, preserving the original mount options somewhere and using that as the
>>> starting point for negotiation during the umount is the best way to ensure
>>> that a UMNT request will get to the server, in my opinion, not the least 
>>> because that's the intent of the code we have now.
>>>
>>> I think there are more cases when using /proc/mounts will be worse than 
>>> using /etc/mtab, and thus we'll get worse behavior on UMNT than we have
>>> today in some cases.  If this weren't true, I think we would have 
>>> embraced /proc/mounts already.  I consider a change to use /proc/mounts 
>>> as risky as a change to not send UMNT at all.
>> Can you outline these cases? The only thing I think can go stale
>> is the port numbers... Everything else should stay relatively 
>> valid... as I just stated... 
> 
> See above.  The options we care about for doing an umount reliably can go 
> stale, and there's no way to tell if the information in /proc/mounts 
> was specified on purpose or negotiated automatically.
My point is it really does not matter... the values in /proc/mounts
allowed the mount to succeed at one point and that's not a bad place
to start from... IMHO... 

> 
>>> So, I'm OK with keeping umount.nfs around for the time being, but
>>> maybe I have to put my foot down and say we mustn't use /proc/mounts
>>> for anything but deciding whether the mount point is an NFSv4 mount.  
>>> I'm happy to volunteer code, and also happy to collaborate with you on a fix.
>>> I've already spent a lot of time poking at this and coding prototypes, 
>>> so I'm "invested."
>> Well talking with the upstream maintainer of the mount command
>> as soon as the new libmount makes an appearance, there is 
>> a very really possibility /etc/mtab will be going away... He
>> says it will be replace with something like /var/run/mount/something
>>
>> So maybe we start looking into how to make /proc/mounts work.
> 
> I agree that we should work towards unlinking our mount subcommands from 
> relying on /etc/mtab.  I don't think the impending presence of 
> libmount mandates the use of /proc/mounts, though.
True... All I'm trying to point out is the information in /proc/mounts and 
/etc/mtab can be equally as good and equally as bad at any point
in time. 
 
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... 

> 
>>> To summarize: instead of relying on /etc/mtab, also use an NFS-specific 
>>> place to record the same information.  umount.nfs can use that 
>>> instead of /etc/mtab.  And by the way, we don't touch this information
>>> during a remount... heh.  That guarantees that we preserve existing 
>>> good behaviors of umount.nfs, continue to update /etc/mtab as documented,
>>> until maybe it goes away, but eliminate our functional dependence on it.
>>>
>> If the info in /etc/mntab is not updated on remounts, then what is 
>> the issue we are talking about? Just curious, will the info in /proc/mounts
>> be updated on remounts?
> 
> /etc/mtab would still be updated on remounts, and would still have the 
> bug where "remount" would wipe the options.  But we would no longer depend
> on that destroyed information to perform the umount reliably.
The remount would wipe out the *original* options, basically overriding
them with the updated options... As long as we have a mechanism to
retry the UMNT if the first call fails, I don't see this a being a 
problem... 
 
> 
> This new stash of information I'm proposing would not be altered by a
> remount.  It sounds like we would need to store only the MNT protocol 
> related options, described above.
> 
> In /proc/mounts, the NFS-specific mount options aren't supposed to 
> change at all on a remount.  Only the generic mount options 
> ("sync", "ro", etc) should change.
Could you please point me to where the above rule is mandated...
I had know idea there were rules of what can and cannot be
changed in /proc/mounts... tia...

steved.