Re: [nfsv4] persistent sessions and compound atomicity

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.

> 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.

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
> 