Re: [nfsv4] persistent sessions and compound atomicity

On Wed, Dec 09, 2020 at 08:55:03AM -0500, Tom Talpey wrote:
> On 12/8/2020 7:26 PM, J. Bruce Fields 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:
> >
> >	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.  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).
> >
> >	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....
> >
> >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 think the atomicity is referring to the building of the response,
> not the execution of the COMPOUND itself (which would be impossible,
> generally).
> 
> The main issue it's protecting is the server's response never changing.
> The operation must always have one result. If the client were to replay
> a request while the server is still executing the compound, and get a
> partial answer, followed by the final answer, that would be very bad
> indeed.

Got it, thanks.

> >Or, why not allow it to return the result so far and then DEADSESSION on
> >any following operation?
> 
> "So far"? That only makes sense if the compound were totally complete.
> At which point, there is one and only one result.

Hm, I'm not sure what you mean.  The server comes up from a crash and
determines that it was in the middle of processing a compound, and that
the last thing it does was succesfully execute a nonidempotent op in the
middle of the compound.  it has to decide what it's going to use as the
final reply for that compound.

--b.

> 
> Tom.
> 
> >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.
> >
> >But it seems like a server should be able to avoid that without making
> >every sa_cachethis operation completely atomic.
> >
> >Am I missing some reason for that MUST?
> >
> >--b.
> >
> >_______________________________________________
> >nfsv4 mailing list
> >nfsv4@ietf.org
> >https://www.ietf.org/mailman/listinfo/nfsv4
> >
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4