Re: [nfsv4] persistent sessions and compound atomicity

[Trond Myklebust <[e-mail]>]

On Thu, 2020-12-10 at 17:07 -0500, David Noveck wrote:
> 
> 
> On Wed, Dec 9, 2020, 5:59 PM J. Bruce Fields <[e-mail]>
> 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.
> > 
> > Great, sounds like everyone agrees, I'll calm down.
> 
> 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.
> 
> I don't think we have total agreement but we are moving in the same
> direction.  No reason to be anything but calm.

in Section 2.10.6.5 of RFC5661, there is the following snippet:

   One way to
   view the problem is as a single transaction consisting of each
   operation in the COMPOUND followed by storing the result in
   persistent storage, then finally a transaction commit.  If there is a
   failure before the transaction is committed, then the server rolls
   back the transaction.  If the server itself fails, then when it
   restarts, its recovery logic could roll back the transaction before
   starting the NFSv4.1 server.

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?


> . 
> > 
> > > 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]
> > https://www.ietf.org/mailman/listinfo/nfsv4
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
[e-mail]