RE: [nfsv4] pynfs replay cache test SEQ9f

["Frank Filz" <ffilzlnx@mindspring.com>]

> On Fri, 2017-10-13 at 11:00 -0400, bfields@fieldses.org wrote:
> > On Fri, Oct 13, 2017 at 01:34:28PM +0000, Trond Myklebust wrote:
> > > On Thu, 2017-10-12 at 21:52 -0400, J. Bruce Fields wrote:
> > > > On Thu, Oct 12, 2017 at 03:00:51PM -0700, Tom Haynes wrote:
> > > > > On Thu, Oct 12, 2017 at 05:44:54PM -0400, J. Bruce Fields
> > > > > wrote:
> > > > > > Your mailer's not quoting right, it's a little hard for me to
> > > > > > find your replies.  Wading in:
> > > > > >
> > > > > > On Thu, Oct 12, 2017 at 09:39:04PM +0000, Thomas Haynes
> > > > > > wrote:
> > > > > > > On Oct 12, 2017, at 12:49 PM, J. Bruce Fields <bfields@fiel
> > > > > > > dses .org<mailto:bfields@fieldses.org>> wrote:
> > > > > > > > So I *think* the only correct options OK or FALSE_RETRY?
> > > > > > >
> > > > > > > It can=E2=80=99t be OK if the parameters to SEQUENCE differ.
> > > > > >
> > > > > > I'm getting that from: "When the replier detects a false
> > > > > > retry, it is permitted (but not always obligated) to return
> > > > > > NFS4ERR_FALSE_RETRY in response to the Sequence operation
> when
> > > > > > it detects a false retry."
> > > > >
> > > > > I think you are agreeing with me that OK is not appropriate
> > > > > here?
> > > >
> > > > No, I think OK is OK:
> > > >
> > > > > > If i understand the following language, we're required to
> > > > > > return FALSE_RETRY in the case the rpc credentials of the
> > > > > > caller map to different principals, but not otherwise.
> > > > >
> > > > > This one drove me crazy:
> > > > >
> > > > >    If a requester sent a Sequence operation with a slot ID and
> > > > > sequence
> > > > >    ID that are in the reply cache but the replier detected that
> > > > > the
> > > > >    retried request is not the same as the original request,
> > > > > including a
> > > > >    retry that has different operations or different arguments in
> > > > > the
> > > > >    operations from the original
> > > > >
> > > > > SEQUENCE is not special - both the compounds in this example
> > > > > only have the SEQUENCE op and they differ only in that in the
> > > > > first sa_cachethis is False and in the second it is True.
> > > > >
> > > > > So we have to return FALSE_SEQ_RETRY here...
> > > >
> > > > It says "if the replier detected" a difference, not "if there is"
> > > > a
> > > > difference.  So the replier is not required to do such detection.
> > > > This agrees with the "not always obligated" above.
> > > >
> > > > So I think it's allowed for the server to just return an old
> > > > cached response here (with the cached OK).  And I can't see any
> > > > practical problem that would create--a client shouldn't be sending
> > > > a different request with the same (slot, sequence) anyway.  The
> > > > only potential risk is the malicious client trying to snoop
> > > > somebody else's reply cache, hence the requirement in the case
> > > > principals differ.
> > >
> > > Clients may indeed send a different request with the same slot and
> > > sequence if they don't know that the server received the last
> > > request.
> > > This is tbe "user pressed ^C" scenario...
> > >
> > > Servers MAY ignore that fact, but they'd be really stupid to do
> > > so...
> >
> > 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 compl=
ete
> 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 tha=
t 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.

I'm wondering if Ganesha does this right...

Bruce, if there's something not covered by the pynfs tests, can we make sur=
e to add one?

Frank


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus