Subject: RE: guard on SETATTR

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 19 Jun 2001 08:31:42 -0700

Spencer Shepler wrote:
> > > 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.
> 
> 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? 

OK.  "easy"  --> "relatively easy".  Some operating environments make 
make lots of things difficult.

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

The question here is whether clients want to retain whatever encouragements
for server atomicity that are defined for the V3 guard mechanism, as opposed
to leaving this to COMPOUND.  We could do this simply by adding the guard 
mechanism to SETATTR and using similar language to RFC1813 to characterize
its purpose and handling, which would allow operating environments that
had provided atomicity for the v3 SETATTR guard to retain it for v4
easily.  Another approach is to use the VERIFY-SETATTR emulation but 
call out this case for special handling.  Something like this:

      Use of a COMPOUND containing a VERIFY operation specifying only
      the TIME_METADATA attribute, immediately followed by a SETATTR, 
      provides a means whereby a V4 client may specify a request that 
      emulates the functionality of the SETATTR guard mechanism of NFS-v3.  
      Since the function of the guard mechanism is to avoid changes to 
      the file attributes based on stale information, delays between
      checking of the guard condition and the setting of the attributes
      have the potential to compromise this function, as would the 
      corresponding delay in the NFS-v4 emulation.  Therefore, NFS-v4
      servers should take care to avoid such delays, to the degree
      possible, when executing such a request.

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 19 Jun 2001 10:39:39 -0500

> to leaving this to COMPOUND.  We could do this simply by adding the guard 

Well, I know of two server implementations that currently do not meat
your interpretation of the NFSv3 RFC (Solaris and AIX).  Has this been
a problem for clients?  At least in my experience, I have not seen
this as a problem.  It would be interesting to hear what other server
implementations have done in this particular case.

> easily.  Another approach is to use the VERIFY-SETATTR emulation but 

And if it is not clearly stated and written as a MUST, clients can not
depend on the functionality.  Again, based on my limited knowledge and
experience, I don't think the existing v3 clients are dependant on it
today.  I don't have a strong opinion about whether we should add a
guard to SETATTR but if we do then we should remove all ambiguity
about the atomicity requirements.  

>       possible, when executing such a request.

This wording is reasonable and would be my preference over adding a
guard to SETATTR.

-- 

- Spencer -