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

From: [email-masked]
Date: Thu, 9 Mar 2006 16:02:49 -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.
>
>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.

Since remove doesn't have a stateid argument, the server doesn't know
if it a different client, so different client has to be assumed.

Bruce mentioned that the Open delegation applies to the metadata as well.
I don't see that stated in the RFC. Put another way, if the Delegation
applies to metadata other than Size and Change, why is it that CBGetattr
is only expected to support those two attributes?

As for "Setattr by another client", I thought it had been agreed that
this was only necessary for attributes that affect the ability to Open
the file (owner, owner_group, mode, acls) or size, which affects size
and change. (None of these attributes are affected by a removal of other than
the last link.)

I'm curious to hear what others have to say, rick

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 9 Mar 2006 16:08:59 -0500

> if it a different client, so different client has to be assumed.

Yeah.

I wonder whether it'd be reasonable for the server to assume it didn't
need to recall if it had some other information in the compound to tell
it the client.  (Probably only likely to happen after sessions.)

(Is it legal for two clients to multiplex operations in the same
compounds?  Aie.)

> I don't see that stated in the RFC.

I think it's probably what was intended to be implied by e.g. the
SETATTR language.

> Put another way, if the Delegation

Doesn't an unlink affect the change attribute?

--b.

---

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

> is only expected to support those two attributes?

Which other mandatory attributes is the client able to change
asynchronously?

> and change. (None of these attributes are affected by a removal of other than

The attributes might not be affected, but your ability to open the file
might be hampered if the directory you were using suddenly holds no
entries for that particular file.
How do you propose to recover if the server recalls the delegation?
Recall that CLAIM_DELEGATE_CUR takes a filename argument.

Cheers,
  Trond

---

From: Mike Eisler <[email-masked]>
Date: Thu, 9 Mar 2006 18:09:26 -0800 (PST)

> I don't see that stated in the RFC. Put another way, if the Delegation

You are correct that it is not there. It is implied by the fact that
SETATTR takes a stateid and the text that says that the server will
recall delegations when there is a SETATTR.

> is only expected to support those two attributes?

The client isn't allowed to change say the mode bits or the ACL. This
is implied by the part of the spec that discusses the delegation ACE.
If the client changed the ACL it has no way to know that it still has
access to the file. It also doesn't know that is has the rights to
change ACL.

---

From: "Talpey, Thomas" <[email-masked]>
Date: Fri, 10 Mar 2006 09:44:17 -0500

>(Is it legal for two clients to multiplex operations in the same

Yes, it is. But in my view a client implementation would be insane to do so.
That would make one clientid's operation dependent on the success of
another's (by the COMPOUNDing rules).

Sessions fixes this by requiring that all operations in a COMPOUND are
owned by the session (and therefore clientid) present in the SEQUENCE
op which accompanies them.

Tom.