Subject: RE: [nfsv4] Setattr stateid

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 5 Aug 2003 12:43:59 -0700

My thinking was that if you have a delegation, you
don't have to do an over-the-wire GETATTR to get the 
attributes, since you know they can't change.  If that's
the case, then you have to recall a delegation when they
change.

It might be possible to try to distinguish changes of 
writable attributes between those that affect possible
opens made under the delegation and those that don't,
but if you look at the writable attributes in v4 and
you exclude size, change, mode, owner, owner_group,
and ACL, then there is not all that much left.  It
just seems simpler to have the delegation envelope
include the attributes as well.  

The spec lists "SETATTR issued by another client" as 
necessitating recall of a delegation so why wouldn't
the server just do the recall?  I suppose the "by 
another client" adds confusion since, as Rick points
out, in many cases, you don't have the stateid to make
a definitive determination.  Making allowances for that,
why not just err on the side of safety, and recall all
the delegations?  If we are talking about read delegations,
I don't see many situations where a SETATTR will be done
on one delegated client and you don't want to recall the
delegations.  In the case of a write delegation, the client
knows he is the only one, so if we doesn't want the 
delegation recalled he just has to defer the over-the-wire
SETATTR, so the fact that the server will recall the delegation
if the SETATTR is done is not very confining. 

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Friday, August 01, 2003 5:36 PM
To: [email-masked]
Subject: Re: [nfsv4] Setattr stateid

On Fri, [email-masked] wrote:
> In Section 14.2.32, it basically says that the stateid should be all 0s
> iff the size is not being changed.
> 
> In Section 9.4.4 is says:
> 
> "SETATTR issued by another client"
> 
> as a case where open delegations should be recalled. Does this recall only
> apply if the size is being set? (If not and the stateid is all 0s, do you
> just recall all delegations?)

My interpretation has been that the delegation covers the data of the
file, the size and change attribute.  Therefore, if another client
does a setattr of the mode attribute, the stateid should be all-zeroes
and the server would not recall the delegation on the file.  If a
client is changing the size and or time on the file then the
delegation stateid should be supplied so that the server knows not to
recall the delegation prior to servicing the setattr.  Of course, the
client should supply the open/lock stateid if it doesn't hold a
delegation to enable the server to check the appropriate state the
client holds with the requested in the setattr (when it comes to
size/time).

Spencer

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

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