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.) Perhaps we should retry in this case until the mount succeeds or the retry= timeout expires. Then the value of NFSRPC_TIMEOUT_TCP would be inconsequential. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
