On Wed, Feb 03, 2010 at 05:20:10PM -0500, Trond Myklebust wrote: > On Thu, 2010-02-04 at 08:23 +1100, Neil Brown wrote: > > On Wed, 03 Feb 2010 10:43:04 -0500 > > Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > > > > > I don't think dropping the connection will cause the client to > > > retransmit sooner. Clients I have encountered will reconnect and > > > retransmit only after their retransmit timeout fires, never sooner. > > > > > > > I thought I had noticed the Linux client resending immediately, but it would > > have been a while ago, and I could easily be remembering wrongly. > > It depends on who closes the connection. > > The client assumes that if the _server_ closes the connection, then it > may be having resource congestion issues. In order to give the server > time to recover, the client will delay reconnecting for 3 seconds (with > an exponential back off). > > If, on the other hand, the client was the one that initiated the > connection closure, then it will try to reconnect immediately. So, if I understand Neil's patches right: - First we try waiting at least one second for the upcall. - Then we try to return JUKEBOX/DELAY. (But if we're still processing the rpc header we may not have the option.) - Then we give up and drop the request. Upcalls shouldn't normally take a second; so something's broken or congested, whether it's us or our kerberos server. So telling the client we're congested sounds right, as does the client response Trond describes. --b. -- 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
