Re: [nfsv4] persistent sessions and compound atomicity

[Rick Macklem <[e-mail]>]

David Noveck wrote:
>On Wed, Dec 09, 2020 at 04:43:59PM +0000, Rick Macklem wrote:
>> I would say that the ATOMIC refers to the individual operations of the
>> compound. In other words, it must cache the reply to each operation
>> when it is completed, in the persistent cache.
>>
>> Then, if a retry of the compound is received after a server reboot,
>> the reply for the first K operations that were completed prior to the
>> reboot are generated from the cache and the remaining N-K are
>> performed on the file system to complete the reply. (At least for the
>> non-idempotent operations in the compound.)
>>
>> For this to all work correctly, I think the server file system would
>> need to perform each non-idempotent operation ATOMICALLY as well, such
>> that after the reboot the file system is in either the pre-operation
>> or post-operation state.
[stuff snipped]
>I don't see the need for individual ops to be atomic especially since they (e.g. >writes) are not defined as atomic in general.
Well, I'd actually say that "write" is not a non-idempotent operation for this
case. Long ago, Chet Juszczak defined it as one in his original paper on the
DRC he had invented, because interactions between "write" retries and other
non-idempotent RPCs could result in inconsistent results. (He also coined
the (mis)use of the term in his paper to refer tp RPCs that could result in
inconsistent outcomes due to retries.)

However, since sessions allow a client to serialize RPCs (same session  slot)
and operations within a compound are assumed to be serialized,
I think allowing retries of partially completed writes will be ok for 4.1/4.2.

However, if the operation is an exclusive open create, I think the server
will need to either complete the operation and capture the reply for the
persistent session or roll the file system back to the pre-exclusive create open
state to get things completely correct.

rick

I don't think we have total agreement but we are moving in the same direction.  No reason to be anything but calm.
.

> rick, who has no intention of ever trying to implement a persistent
> session cache.

Your input is still valuable.


I can't decide.  It looks like kind of a pain.  It'll require some
cooperation with the filesystem folks--I think it needs to be integrated
with filesystem journaling somehow.

That makes sense.


But I'm not looking forward to someone running into this, and having to
say, "oh yeah, we've known about that bug for decades; just give me
another few months or a year, and I'll fix it right up for you...."

I have a revised version of this section in draft-dnoveck-rfc5661bis-00.  (Will be out before next year).  I hope we will discuss that and get to a text that everybody does agree on, and might even be implementable :-)

--b.

_______________________________________________
nfsv4 mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/nfsv4