Re: Status of mount.nfs

[Steve Dickson <SteveD@redhat.com>]

Chuck Lever wrote:
> 
> And umount.nfs always uses TCP for the mountd request.  I have a patch 
> that fixes that to behave more like mount.nfs does, which I will forward 
> in the next day or two.
thats a bug... umount should use the protocol the mount did...
I thought I had fixed that... :-\

> 
> I notice some problems if a share is mounted with TCP, but the server 
> later disables TCP -- umount.nfs hiccups on that when it tries to umount 
> using the same protocol as listed in /etc/mtab.  Perhaps relying on 
> /etc/mtab for setting the umount protocol is unnecessary.
I think I was using /proc/mounts...

> 
> We have three requests that need to be made:
> 
> 1.  GETPORT -- I think this should UDP all the time unless proto=tcp is 
> explicitly specified;
Some people have asked that we first try UDP all the time... which
I have resisted but it might make sense...

> 
> 2.  MNT -- likewise, UDP unless proto=tcp is specified or GETPORT says 
> UDP is not supported;
> 
> 3.  NFS -- this should be TCP all the time unless proto=udp is specified 
> or GETPORT says TCP is not supported.
What about rollbacks... meaning if tcp is not supported do we try udp?
if v4 is not supported to we try v3 and the v2 or just fail the mount?

> 
> Even better would be to use RPCB_DUMP instead of RPCB_GETPORT.  That way 
> we only need a single rpcbind call for both protocols, and can get 
> transport protocol information as well, and make an "informed" choice.
Good point... but note, a while back I got a request to use GETPORT
instead of DUMP because some Cisco router actually use the GETPORTs
to punch wholes in their firewalls.
> 
> Also, can we get rid of the clnt_ping()?  If not, can we document why it 
> is there?  It adds two extra round trips to the whole process.  If error 
> reporting is the problem, maybe we can try the pings only if the kernel 
> part of the mount process fails?
How do we avoid hang down deep in RPC land (governed by
uncontrollable timeout) when either mountd or nfsd  are not up?

That was the main reason for the ping. Since neither portmapper or
rpcbind ping their services before they hand out the ports, there
is really no way of telling where the server is up? So to avoid
the hang, we ping them... Sure its costly network wise, but
hanging during a boot because a server is not responding is
a bit more costly... imho...

steved.


-------------------------------------------------------------------------
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/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs