Re: [nfsv4] persistent sessions and compound atomicity

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

On Wed, Dec 09, 2020 at 10:29:23AM -0500, Tom Talpey wrote:
> On 12/9/2020 9:49 AM, J. Bruce Fields wrote:
> >On Wed, Dec 09, 2020 at 08:55:03AM -0500, Tom Talpey wrote:
> >>On 12/8/2020 7:26 PM, J. Bruce Fields wrote:
> >>>Or, why not allow it to return the result so far and then DEADSESSION on
> >>>any following operation?

Hm, maybe allowing DEADSESSION for operations other than SEQUENCE is
just too weird, and DELAY would work just as well.

> >>"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.
> 
> In the persistent restarted server case, I agree with you. I thought
> you were somehow arguing that the server could provide a reply from
> cache, for an in-progress operation.
> 
> In the persistence case, I guess this means the server will build the
> compound response in-progress, and keep it "secret" as long as it's
> partial. On restart, it will need to sweep the cache, add any
> necessary error for the compounds that didn't get executed, and mark
> it complete and ready for responding whne the client replays.

Yeah.  I think the server should at least execute any immediately
following GETFH.

It could just go on executing the rest of the compound, but I wonder
whether the results could be weirder than a client is prepared to deal
with.  I don't have a good example, though.  (PUTHF+OPEN+WRITE where the
OPEN succeeds with the old state and then the WRITE returns a new
verifier?  A compound with two LOCKs where the first succeeds and the
second returns GRACE?)

> That seems like a lot of fiddly stuff, but I guess it's important
> for any non-idempotent operations. I bet there's more language that
> needs tightening up.

Probably.

--b.