Jeff, Jim, Trond - Thanks for all the comments. I'm looking again at the code and will incorporate your suggestions and do some more testing. Should have results and a modified patch set tomorrow. -->Andy On Sep 10, 2012, at 4:14 PM, Myklebust, Trond wrote: > On Mon, 2012-09-10 at 15:56 -0400, Jim Rees wrote: >> Jeff Layton wrote: >> >> My only concern is this behavior described in the last patch: >> >> "If the buffered WRITE is using a credential key that will expire >> within low watermark seconds, fail the WRITE in nfs_write_begin >> _before_ the WRITE is buffered and return -EACCES to the application." >> >> Shouldn't rejecting the write attempt be the purview of the server? >> >> It seems to me that we'd be best off just switching to synchronous >> writes when we start approaching credential expiration, and letting the >> server handle the case where the credential expires. >> >> It seems to me that the client should just be in the business of >> recognizing when the credential might be about to expire and attempt to >> ensure that we don't end up with a bunch of buffered data in that case. >> >> I don't like it. It's easy to understand why writes might fail if the creds >> are getting stale. It's not so easy to understand why client behavior >> changes in a subtle way, with performance implications. > > We don't know that the creds are stale. We just know that the GSS > session is about to expire. > > -- > 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
