Subject: RE: guard on SETATTR

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 18 Jun 2001 14:24:42 -0700

Spencer Shepler wrote: 
> On Mon, Peter Staubach wrote:
> > 
> > > 
> > > Does anybody know what happened to the guard
> > > mechanism for SETATTR that was in V3?  It isn't
> > > in V4 and I'm wondering why.
> > > 
> > > Is it the case that it has turned out to be
> > > useless (i.e. that no clients use it)?  It doesn't
> > > appear that it would be difficult for a server to 
> > > implement so even if it were used only by a few people, 
> > > it doesn't seem as though there would be a need to 
> > > remove it from NFS.
> > > 
> > > Anybody remember the history here?
> > 
> > The guard mechanism for SETATTR in NFS Version 3 is extremely useful.
> > It is used by most clients, at least, to protect requests which change
> > the size of the file.  These requests can cause data loss if a
> > retransmitted request is not caught properly and is reexecuted.

> Yes.  It is a useful feature.  Since RFC 1813 doesn't mention any
> atomic requirements for use of the guard on SETATTR, the NFS version 4
> protocol provides for the same functionality by the use of COMPOUND.
> Using VERIFY/NVERIFY in combination with SETATTR should provide the
> equivalent functionality.  

It doesn't mention atomicity requirements explicitly, but it sure gives
the impression that these should be atomic.

      The guard.check mechanism allows the client to avoid
      changing the attributes of an object on the basis of stale
      attributes. 

If it weren't atomic it would not allow the client to avoid doing the
wrong thing.

And when it says:

      A client may request that the server check that the object
      is in an expected state before performing the SETATTR
      operation. To do this, it sets the argument guard.check to
      TRUE and the client passes a time value in guard.obj_ctime.
      If guard.check is TRUE, the server must compare the value of
      guard.obj_ctime to the current ctime of the object. If the
      values are different, the server must preserve the object
      attributes and must return a status of NFS3ERR_NOT_SYNC.
      If guard.check is FALSE, the server will not perform this
      check.

It gives me the impression that making the check, going out for 
coffee, and then doing the setattr, would be a Bad Idea, even 
though there is no specific prohibition.

Compare this to COMPOUND.  In that case it is not that atomicity
is not mentioned.  It is mentioned in order for it to be stated that
it is not atomic.  The client should not depend on atomicity.

> In fact, the client is able to specify more
> than just the "time_metadata/ctime" attribute for the check condition.

That very flexibility is the problem for the server.  Providing 
atomicity for the specific case of SETATTR guard is easy while
providing it in more general settings is difficult to impossible.

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 18 Jun 2001 17:54:21 -0500

>       changing the attributes of an object on the basis of stale

Ahh, the beauty of an information RFC that hasn't had the benefit of
feedback from implementation experience. :-)

That is your interpretation and I am sure there are others.

> If it weren't atomic it would not allow the client to avoid doing the

Does it?  In the example that Peter provided (protecting from a blown
duplicate request cache) it would seem to work just fine.

> providing it in more general settings is difficult to impossible.

Is it easy?  Seems to me that not all operating environments will
provide for atomicity.  And at what level?  Is this just for the NFSv4
server or interaction with local access?  

Looks like we need additional input from other environments and client
usage before making any changes on this one.

-- 

- Spencer -