Re: mount.nfs timeout of 9999ms (was Re: Listen backlog set to 64)

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

On Dec 8, 2010, at 1:37 PM, J. Bruce Fields wrote:

> On Wed, Dec 08, 2010 at 01:28:06PM -0500, Chuck Lever wrote:
>> From what I have read, the server's configuration is the immediate problem here: namely that the disk that /var is on is slow, or there are bugs (or not-very-useful behavior) in the file system implementation used on /var, or that rpm should not cause such latency for other applications, or that the multi-threading architecture of mountd is incorrect.  Or some combination of these.
>> 
>> A ten second latency for file system operations is the real issue.
>> 
>>>> IMO adding another mount option would be mistaken.  It adds clutter to 
>>>> the mount user interface to work around what is clearly a problem on the 
>>>> server.
>>> 
>>> I agree that new options can be cluttered.
>>> 
>>> But I think the problem needs attention at both the client and sever side.
>> 
>> It seems reasonable to relax mount.nfs's timeout settings used when performing mount and rpcbind requests.  The question I have is what would be reasonable values to use instead of what we have?  (That question is directed to everyone who is still reading).
> 
> What's the behavior you want when the server is just off or unreachable?
> 
> I'd've thought that there are cases where you just want the mount to
> hang till it's interrupted or the problem is fixed.  (Autofs possibly
> being one of them.)

Be it noted however that autofs usually wants a quick yes or no answer in these cases.  Auto mounts that take a long time to succeed usually drive users crazy, especially if the automounter is single-threaded.  That's why this timeout is kept short.

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