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

From: [email-masked]
Date: Thu, 24 Mar 2005 17:32:04 -0500 (EST)

[Dave wrote]
> It also says:
> 
>    When a client has a write open delegation,
>    it may modify the file data since no other client will be accessing
>    the file's data.  The client holding a write delegation may only
>    affect file attributes which are intimately connected with the file
>    data:  size, time_modify, change.
Would replacing the last sentence with something like:
     The client holding a write delegation may only locally modify file
     attributes which are intimately connected with the file data:
     size, time_modify , change. The client must immediately do a
     Setattr Op to change any other attributes for the write delegated file.
be sufficient, as a clarification of what you meant?
[stuff snipped]
[Trond wrote]
>      7) When a SETATTR is done and a write delegation is held, the
> server
>      must recall if and only if the stateid passed is not that of the
>      write delegation.  When it is not, the write delegation must be
>      recalled and the attribute change must not proceed until the
>      delegation is returned or recalled.
> 
> If I have OPENed the file for writing, why shouldn't I be able to use
> the resulting open_owner stateid? After all, I can do that for ordinary
> writes without having the write delegation recalled.

Unless the RFC is re-written, it would seem that an open stateid should be
sufficient. In other words, the server should be able to discern that the
client with that open stateid also holds a write delegation for the same
file. If not, the server is forced to recall the delegation?

> You're also in major conflict with the main paragraph describing
> SETATTR:
> 
>    The stateid argument for SETATTR is used to provide file locking
>    context that is necessary for SETATTR requests that set the size
>    attribute.
>    ..... When the file size attribute is not set, the special
>    stateid consisting of all bits zero should be passed.

I do feel this is "errata" that needs to be changed. I think the stateid
of all 0s should only be used when the client doesn't have a write
delegation.

Maybe change the last sentence to something like:
    ... all bits zero should be passed, unless the client has a write
    delegation. For that case, the write delegation stateid should be
    used.
Just my thoughts, rick

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

---

From: Craig Everhart <[email-masked]>
Date: Fri, 25 Mar 2005 07:40:25 -0500

> be sufficient, as a clarification of what you meant?

Just a nit: instead of "may only locally modify file attributes which are",
how about "may locally modify only those file attributes which are".

That is, I can choose to push through time_modify; I don't have to
"only locally modify" it.

            Craig

Craig Everhart
+1 919 543 2169 (tie 441 2169)