[nfsv4] persistent sessions and compound atomicity

[[e-mail]]

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?

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

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.