Subject: RE: [nfsv4] Recalling write delegations on setattr

From: "Khan, Saadia" <[email-masked]>
Date: Mon, 21 Mar 2005 14:21:45 -0800

> -----Original Message-----
> From: Spencer Shepler [mailto:[email-masked]] 
> Sent: Friday, March 18, 2005 6:34 PM
> To: eric kustarz
> Cc: Khan, Saadia; [email-masked]
> Subject: Re: [nfsv4] Recalling write delegations on setattr
> 
> 
> On Fri, eric kustarz wrote:
> > Khan, Saadia wrote:
> > >The spec states that the server should recall a delegation if a 
> > >setattr is coming in from another client. It also states that an 
> > >open/delegation stateid is required when changing the size 
> attribute. 
> > >However it does not say anything about an open/delegation stateid 
> > >being required for any operations other than changing the 
> size of a 
> > >delegated file. So in the case of changing any attributes 
> other than 
> > >size, a client can use a special stateid of all zeroes and 
> then the 
> > >server would have no way of knowing that this request is 
> coming from 
> > >the client holding the delegation. This would result in the server 
> > >recalling the delegation even if the setattr came from the client 
> > >holding the delegation, therefore causing a performance hit.
> > >
> > >Do clients currently use the open/delegation stateid in 
> all setattr 
> > >operations for delegated files?
> > 
> > The solaris client -currently- uses the special stateid.
> > 
> > >
> > >I think this is something that should be clarified in the spec.
> > 
> > agreed.
> > 
> > And since jeff is looking to fix this for us... i would 
> mention that 
> > it
> > seems the proper behavior is for the client to actually return the 
> > delegation before doing the setattr (for things like mode).
> > 
> > The complications come in when the client is internally 
> keeping track 
> > of
> > an open that never went OTW (since it had a delegation), 
> and the setattr 
> > would change it such that a future recovery reopen OTW would fail. 
> > Forcing the internal open OTW, then doing the setattr will prevent 
> > possible breakage.
> > 
> > So from the server's point of view, it should issue a CB_RECALL for
> > setattrs on mode (regardless if the stateid is special or 
> delegation).
> 
> The reclaim issues still exist without delegations being present in 
> that the client will attempt to reopen a file that has 
> potentially had a acl/mode change that would now disallow the 
> OPEN from succeeding.
> 
> I think the more salient point is that the delegation allows 
> the client to use ACCESS to determine if an OPEN would pass 
> the ACCESS test at the server and then proceed.  The client 
> is able to cache the ACCESS results and use them in the 
> future while it has the delegation. If the server is 
> processing a acl/mode change, it should recall the delegation 
> as a means to "flush" the ACCESS cache at the client and 
> force it to OPEN to the server for existing and future OPENs. 
> Once the acl/mode change is complete, then the server can 
> provide a delegation and the client can go back to using 
> ACCESS to determine appropriate OPEN processing under that 
> delegation, etc.
> 

What about changes to owner/group then? Those should also cause a
recall. So is it safe to say that setattr operations other than the ones
that change the owner/group/mode/acl should not cause a delegation to be
recalled?

Saadia

> Spencer

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

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 21 Mar 2005 14:30:12 -0800

> that change the owner/group/mode/acl should not cause a delegation to be

Yes, owner and owner_group fall into the same category as mode/acl.

It is my opinion that setattr of attributes other than 
owner/owner_group/mode/acl do not require a recall of the delegation.

Spencer