Re: pynfs replay cache test SEQ9f

["bfields@fieldses.org" <bfields@fieldses.org>]

On Fri, Oct 13, 2017 at 03:26:51PM +0000, Trond Myklebust wrote:
> On Fri, 2017-10-13 at 11:00 -0400, bfields@fieldses.org 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.