Re: [nfsv4] persistent sessions and compound atomicity

["J. Bruce Fields" <[e-mail]>]

On Fri, Dec 11, 2020 at 12:36:29PM -0500, Trond Myklebust wrote:
> On Fri, 2020-12-11 at 06:12 -0500, David Noveck wrote:
> > 
> > 
> > On Thu, Dec 10, 2020, 9:23 PM Trond Myklebust <[e-mail]>
> > wrote:
> > 
> > 
> > > 
> > > in Section 2.10.6.5 of RFC5661, there is the following snippet:
> > 
> > Deleted snippet about making the execution of a COMPOUND a
> > transaction.
> 
> The thing in the spec was talking about a COMPOUND, but I believe it is
> easier to implement as a per-op transaction. I believe that still
> satisfies the language in the rest of the spec.
> 
> > > 
> > > 
> > > Why shouldn't a client implementer reading the above be able to
> > > conclude that a NFS4ERR_DEADSESSION error implies that the
> > > operation failed with no side-effects?
> > 
> > No reason at all.  The problem is that requiring the server to
> > implement COMPOUNDs as atomic transactions if it implements
> > persistent sessions has no real justification and probably cannot be
> > implemented.
> > 
> 
> The fact that it hasn't been implemented yet means that we still the
> option of throwing it out of the current spec.
> 
> Hammerspace could probably implement this spec as it is defined today,
> but it would very likely cause a performance penalty that I don't see
> us being willing to take. Is anyone else planning on doing so?

Now that I've reread it all, I really think the spec is fine, the *only*
part that bugs me is that language in 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....

	One way to view the problem is as a single transaction
	consisting of each operation in the COMPOUND followed by storing
	the result in persistent storage....

	While the description of the implementation for atomic execution
	of the request and caching of the reply....

>From the rest of the spec I think it's clear this is just clumsily
worded; maybe it would be clearer like:

	The execution of an operation and placement of its results in
	the persistent cache MUST be atomic....

	One way to implement this is as series of transactions, one for
	each operation in a compound, with each transaction consisting
	of executing that operation and storing its result in persistent
	storage....

	While the description of the implementation for atomic execution
	of an operation and caching of its result....

--b.

> 
> 
> > Also I don't think it is right for the sever to send DEADSESSION
> > since the persistent session is not dead.  I still like DELAY which
> > Tom thinks is the spawn of the devil, but feel that if the server
> > reboots, SERVERFAULT is justified for ops abandoned because of that.
> > 
> > Maybe we need an nfsv4 error with error code 666, even if DELAY is
> > not it.  Could be a subject for an I-D to be submitted 4/1/2021😊
> > 
> 
> Make it an op:
> 
>    OP_SPAWN_DELAY  = 666,
> 
> 
> -- 
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> [e-mail]
> 
>