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

["J. Bruce Fields" <bfields@fieldses.org>]

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.)

--b.