Re: [nfsv4] persistent sessions and compound atomicity

On Tue, Dec 8, 2020, 7:26 PM J. Bruce Fields <bfields@fieldses.org> wrote:

> I hadn't given much thought to this language in RFC 5661, and now that I
> do, it surprises me.  If you have any pointers to discussion I forgot or
> overlooked, I'd be interested:
>

I don't know of any but. I have comments that might be helpful.

>         https://tools.ietf.org/html/rfc5661#section-2.10.6.5
>
>         The execution of the sequence of operations (starting with
>         SEQUENCE) and placement of its results in the persistent cache
>         MUST be atomic.

Although this is ambiguous, I don't think the intention here is to say the
execution of the Compound needs to be a atomic.  The text is citing two
things that must be atomic.  It would normally be reasonable to infer that
each of them must be atomic.  However, the difficulties of doing that,
given that most individual ops don't need to be atomic. means I think it is
not intended meaning.  An alternative interpretation is that the transition
between an existing Compound and a completed compound must be atomic.

If a client retries a sequence of operations
>         that was previously executed on the server, the only acceptable
>         outcomes are either the original cached reply or an indication
>         that the client ID or session has been lost (indicating a
>         catastrophic loss of the reply cache or a session that has been
>         deleted because the client failed to use the session for an
>         extended period of time).
>

In my view, the atomic transition is between encountering an executing
compound and getting the cached reply for a completed compound.

>
>         A server could fail and restart in the middle of a COMPOUND
>         procedure that contains one or more non-idempotent or
>         idempotent-but-modifying operations. This creates an even higher
>         challenge for atomic execution and placement of results in the
>         reply cache...
>

As I read that,it seems an option and not a requirement.

>
> And I don't see why that MUST is necessary.  Why can't the server, on
> encountering a nonidempotent operation, store partial compound results
> in its reply cache together with whatever compound state (current
> filehandles, etc.) it needs to resume processing on restart?
>

I don't see any indication the server can't do that.

>
> Or, why not allow it to return the result so far and then DEADSESSION on
> any following operation

> I don't think DEAD SESSION is right for a persistent session. I think you
> can and should return DELAY. Server restart is not quick.

> One problem is that a create operation followed by a GETATTR really
> shouldn't fail in between the two--that'd make it hard to implement
> O_CREAT, for example.
>

It shouldn't but I don't see raising that to a MUST NOT or SHOULD NOT.

>
> But it seems like a server should be able to avoid that without making
> every sa_cachethis operation completely atomic.
>

Yes and if that choice were made, the spec would have to a whole lot more
explicit about the matter.

> Am I missing some reason for that MUST?
>
> --b.
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>