Subject: [nfsv4] Re: deleg reclaim on SETATTR

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 28 Jul 2005 10:44:17 -0400

On Thu, Jul 28, 2005 at 02:46:25AM -0500, Spencer Shepler wrote:
> On Wed, Trond Myklebust wrote:
> > on den 27.07.2005 Klokka 23:14 (-0400) skreiv Chuck Lever:
> > > in this case, the client is using the zero stateid for the SETATTR 
> > > operations.
> > 
> > That is allowed, as long as we're not talking about changing the file
> > size (which is to be considered as equivalent to a WRITE according to
> > the RFC).
> > 
> > In fact, a strict reading of RFC3530 would appear to state that you
> > should always use the zero stateid unless changing the file size.
> 
> Yes, that is the strict read of the RFC and I believe we had
> some discussion (can't remember if it was on the WG alias or off-list)
> about recall on a SETATTR of mode/acl.
> 
> Essentially, if the mode/acl is changing at the server and 
> a special stateid is being used for the SETATTR, then the server
> will recall the delegation.  The main reason for this is that
> cached results from ACCESS calls are potentially invalid.  The server
> is recalling to have the client OPEN or call ACCESS in the future
> if another delegation is obtained.

But the server could still choose not to recall the delegation, right?
For example, suppose the ACE returned in the original delegation didn't
allow the client to skip any ACCESS calls.  Do you see any problem with
keeping the delegation in that case?

> If the client were to use a delegation stateid for the SETATTR
> of mode/acl, then the server does not need to recall but the client
> should flush any cached ACCESS results for that file.

OK.

--b.

PS Complete thread for those just joining in:
http://linux-nfs.org/pipermail/nfsv4/2005-July/002300.html

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4