Subject: [nfsv4] Recalling write delegations on setattr

From: "Khan, Saadia" <[email-masked]>
Date: Tue, 8 Mar 2005 18:41:53 -0800

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? 

I think this is something that should be clarified in the spec. 

Saadia

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

---

From: eric kustarz <[email-masked]>
Date: Fri, 18 Mar 2005 12:04:15 -0800

> 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).

eric

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 18 Mar 2005 18:34:11 -0800

> 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.

Spencer