Re: Status of mount.nfs

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

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

Steve Dickson wrote:
>>>> I can't see why we need to refer back to either file to determine 
>>>> the transport protocol for a umount request.  Whatever transport 
>>>> mountd is advertising at the moment is what should be used, right?
>>> Well for firewall reasons you generally want to use the protocol
>>> that the mount used...
>>
>> That could have been a very long time ago, even months, and the server 
>> settings may have changed.  Thus sending what mount used seems 
>> inherently unreliable.  The race window is enormous!

> hmm... I must be missing something... Why is umount-ing with the
> same network protocol that mount used unreliable and racy?

Well, I exaggerated a bit, but technically speaking it is a race window 
because the client is caching information about the server.  When a 
mount succeeds, the client remembers the transport protocol it used for 
the mount in /etc/mtab.

A long time later, it uses that cached information to set the transport 
protocol for the umount request.

During the time the share is mounted (ie the window), some system 
administrator can change the server's settings -- for example, by 
disabling the TCP mountd service, or by changing the iptables on the 
server.  At that point, the information in the client's /etc/mtab 
becomes stale, and, in fact, useless as a hint.

I'm simply arguing that /etc/mtab should be ignored by umount entirely 
when it comes to determining what transport protocol to use because that 
cached information in not reliable.  Just do a fresh GETPORT before the 
umount, and you will be all set.

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 315 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
email;internet:chuck dot lever at nospam oracle dot com
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs