On Wed, 2008-04-23 at 14:19 -0400, J. Bruce Fields wrote: > On Wed, Apr 23, 2008 at 10:20:43AM -0400, Trond Myklebust wrote: > > > > On Tue, 2008-04-22 at 11:11 -0400, Trond Myklebust wrote: > > > On Tue, 2008-04-22 at 09:38 -0400, Chuck Lever wrote: > > > > > RFC-2203 states that servers are supposed to silently discard requests > > > > > that they don't recognise (see section 5.3.3.1 - Context > > > > > Management), so > > > > > it is correct server behaviour. > > > > > > > > > > > > Dropping the request to destroy a context is fine. Temporarily > > > > fencing the client is what I was concerned about. > > > > > > I'd agree that is somewhat drastic, and have passed the information on > > > to the server vendor, however that doesn't change the fact that we have > > > a client bug too: we should not be using expired creds. > > > > > > The client side performance problem was compounded by the fact that the > > > RPCSEC_GSS destruction call was sent as a hard RPC call, and the fact > > > that we impose the NFSv4 rule that we need to drop the connection before > > > resending a request. > > > > Having thought a bit more about the consequences of this RFC, I think we > > also need to drop the credential on (major) timeouts, since we need to > > assume that the timeout may be due to the credential being out of > > sequence. > > I'm a little confused. Each resend is done with a new gss sequence > number. The point is that if the _server_ gets confused, then it may not tell us that our context is invalid: it will just start dropping all the requests that we send it. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.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
