Re: [nfsv4] Draft is updated following your comments, Thanks//答复: draft-mzhang-nfsv4-sequence-id-calibration-01

[Rick Macklem <[e-mail]>]

On Mon, Apr 10, 2023 at 1:58 PM Rick Macklem <[e-mail]> wrote:
>
> On Mon, Apr 10, 2023 at 1:15 PM Rick Macklem <[e-mail]> wrote:
> >
> > On Sun, Apr 9, 2023 at 11:39 PM yangjing (U)
> > <yangjing8=[e-mail]> wrote:
> > >
> > > The draft is updated as https://www.ietf.org/archive/id/draft-mzhang-nfsv4-sequence-id-calibration-02.txt
> > Here are a few generic comments about the draft (I know nothing about
> > detailed formatting, etc).
> >
> > 1 - It is my understanding that new operations can only be added to
> > minor version 2 and not
> >      minor version 1.
> > 2 - I largely agree with what Tom Talpey said in his comments. I think
> > you need to figure out
> >      how/when the sequenceid is getting messed up.
> >      Note that it is my understanding that the main purpose of
> > sessions is to achieve
> >      "exactly once RPC semantics" (the fact that the reply cache is
> > bounded in size is a nice
> >      added feature, but not the principal purpose).
> >      As such, a sequenceid being misordered implies that "exactly
> > once" semantics could
> >      already have been broken by a software bug in the client.
> >
> >      You note that the misordered sequenceid could be caused by
> > "network partitioning".
> >      In a correct implementation that should not be the case. After a
> > network partition heals,
> >      the client should re-send all outstanding RPCs with the same
> > Session/slot/sequenceid
> >      as was used in the original RPC request message. These should
> > succeed (no misordered
> >      error reply) using cached replies, as required.
> >      --> If a client's recovery from network partitioning is not doing
> > this, then it needs to be
> >            fixed.
> >      --> As above, if a misordered sequenceid error reply is due to a
> > client bug, then that
> >            must be fixed, since "exactly once" semantics may already be broken.
> > The common client bug that results in a misordered sequenceid error
> > reply happens when
> > an in-progress RPC gets interrupted before the RPC reply is processed.
> > This is not a case
> > where your suggested extension should be used, since the in-progress
> > RPC may still be
> > "in-progress". Although I am not sure there is a 100% correct way for
> > a client to handle
> > the need to interrupt an in-progress RPC, marking the session slot as
> > broken and no
> > longer using it is the best approach I am aware of. (I suspect you
> > might be referring to
> > the Linux client and I cannot comment on how it handles interruption
> > via signals or
> > timeouts for session slots, since I am not a Linux client implementor.)
> >
> > It sounds like migration might be an exception to the above, but it
> > should be addressed
> > specifically (as Tom Talpey notes).
> >
> > 3 - If your extension were used by a client, how would the client know
> > whether or not
> >      there are still RPC(s) in-progress that have been assigned that
> > session/slot/sequenceid?
> An additional comment:
> - If the client knows that the outstanding RPC request on the
>   session/slot/sequenceid that got a misordered error reply
>   is one where "exactly once" semantics is not required,
>   then I can see that the client implementor might be able to
>    safely resynchronize the sequenceid.
>   To do this, I do not think your extensions are needed.
>    If the client issues an RPC that consists of only the
>    Sequence operation repeatedly, with the sequenceid incremented
>    by one each attempt after waiting for a reply to the previous
>    attempt, it should get NFS_OK within a few attempts.
>    Then the correct sequenceid to be used for the session/slot is known.
Oops, "known" is probably too strong a word here. Since the cause of
the misordered sequenceid is not known, I think there is a very low
probability that an RPC using the session/slot is still in flight and will
change the sequenceid when processed on the server, causing another
misordered sequenceid error reply.

rick

>
> rick
>
> >
> > rick
> >
> > > _______________________________________________
> > > nfsv4 mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/nfsv4