Re: [nfsv4] persistent sessions and compound atomicity

[Tom Talpey <[e-mail]>]

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.

Tom.

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