Re: [nfsv4] persistent sessions and compound atomicity

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

On Wed, Dec 09, 2020 at 04:22:24PM -0500, Tom Talpey wrote:
> On 12/9/2020 4:03 PM, J. Bruce Fields wrote:
> >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.
> 
> That's an interesting idea! DELAY basically says "busy, try again" and
> means the client's retry will pick up where the client chooses to.
> 
> On the other hand, returning DELAY in the middle of the compound is
> kind of awkward, it hands the mess back. But I guess that can happen
> in the protocol. I will resist repeating my rant that DELAY is the
> spawn of the devil and should never have gone into NFSv3, much less
> survived until today.
> 
> >>>>"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 idea occurred to me too. It's arguably the most transparent and
> correct thing the server could do for the client. But it would also
> delay server availability - it can't begin serving until all such
> operations were complete.
> 
> I don't see how the last example should be possible. The GRACE timer
> is determined by the server. Calling it in the middle of a compound,
> where the server shouldn't even have been running the grace timer,
> is beyond the pale.

So the server could come up, do its journal replay and reload its DRC or
whatever, and finish any in-progress compounds as part of that process.
And then only after its done all that, start the grace timer and start
accepting new RPCs.  OK, that probably makes sense.

Well, this is still all a little theoretical for now.

--b.