Re: [nfsv4] persistent sessions and compound atomicity

[Trond Myklebust <[e-mail]>]

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?


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