Subject: Re: [nfsv4] Open while client has a Delegation

From: [email-masked]
Date: Thu, 9 Mar 2006 14:57:37 -0500 (EST)

> REMOVE("/bar") will change the numlinks field, time_metadata and the
> change attribute on the file, all of which may be cached by holders of
> delegations. The server is required to recall the delegation in those
> circumstances.

Why does the delegation have to recalled? Neither numlinks, time_metadata
nor change will affect the ability for the file to be Opened. (The handling
of time_metadata and change are discussed in Sec. 9.4.3. Since CBGetattr
only handles Change and Size, I don't see any reason why caching of other
attributes would be any different when there is a write delegation than no
delegation. In other words, up to the client to do a Getattr when it
feels it needs up to date ones.

I will agree that the RFC uses the term "file" and I can see where this
can be interpreted as "name" vs "object", but the case of CLAIM_PREVIOUS
seems to clarify that the delegation refers to the "object".

rick

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

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 09 Mar 2006 15:10:12 -0500

On Thu, 2006-03-09 at 14:57 -0500, [email-masked] wrote:
> nor change will affect the ability for the file to be Opened.

Bruce's question was about a REMOVE request from another client that is
not the client that holds the delegation. You could classify this under
the "SETATTR issued by another client" category in section 9.4.4, I
suppose.

Cheers,
  Trond