On Fri, Oct 13, 2017 at 03:26:51PM +0000, Trond Myklebust wrote: > On Fri, 2017-10-13 at 11:00 -0400, bfields@xxxxxxxxxxxx wrote: > > OK, OK, I'll look into fixing the server (I'm pretty sure we get this > > wrong). > > > > You've explained the ctrl-C case before and I don't think I > > understood > > it. I guess otherwise the only way for the client to sort out the > > situation would be to retry the original request. And that requires > > keeping the arguments and credentials around to handle potential > > retries. And that's impractical if the process is going away? OK. > > > > Right, we're not going to do that just for data that is just going to > be tossed away anyway. We already guarantee that non-idempotent > operations (the ones that we actually do ask the server to cache) are > guaranteed to complete whether or not the user presses ^C, so this is > mainly about what happens when somebody interrupts an operation that we > did not want the server to cache. > > I have a patch out there that just replays a SEQUENCE op if we detect > that an RPC call was interrupted. That should be sufficient to deal > with servers that cache everything (whether or not the client sets > sa_cachethis), but don't want to do NFS4ERR_SEQ_FALSE_RETRY. That > particular combination has been seen to be extremely toxic to the > current client, because it can get replayed LOOKUP or GETATTR requests > after someone presses ^C. Those all involve uncached compounds with more than one op. My reading of knfsd code is that it will return RETRY_UNCACHED_REP in this case, and I think (I might be misunderstanding) that the client will bump the slot seqid and retry in that case. So I *think* you shouldn't be seeing that problem with knfsd? --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
