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

From: [email-masked]
Date: Thu, 9 Mar 2006 12:43:19 -0500 (EST)

>[Peter wrote]
>> If a client can "do what it wants" with OPENs while it has write delegation,
>> how is the server supposed to know if it should allow or deny the open? A
>> subset of OPENs/CLOSEs handled locally by the client could have created
>> conflicting share/access modes that the server is not even aware of! We
>> can't allow this kind of mix where half the OPENs are handled locally, and
>> the other half go to the server. The way I see it is that if a client
>> doesn't want to handle OPENs locally, then fine, it doesn't need write
>> delegation, and the delegation can be recalled.
>[Trond responds]
>If the client has set up conflicting shares on delegated OPENs then it
>has screwed itself over. Why should the server care at that point?
I think a slightly more diplomatic way of putting this would be to say
that, since the client allowed a local open with a share/deny based on
the write delegation, then it is the client's responsibilty to check for
the validity of other opens before doing them at the server.

If, on the other hand, the client does not realize it has the delegation
(hasn't processed the appropriate Open reply or...), then it won't have
done any opens locally on the client->no local share/denies.

For the original example, I didn't specify whether or not the Opens used
the same open_owner. If they are the same open_owner, I am still hesitant
to follow Peter's suggestion for the following reason.
  - As I believe Spencer alluded to, I don't see anything in the RFC that
    requires the client to use CLAIM_DELEGATE_CUR for another Open on the
    same open_owner when the client has a write delegation for the file.

Given that, I believe the server should be as liberal as is practicable,
in an effort to improve interoperability.

Fun discussion though. More to come. I'll fill in the rest of the scenario
in a few minutes, rick.

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

---

From: Peter Varga <[email-masked]>
Date: Thu, 9 Mar 2006 16:05:45 -0500

It has to be recalled because any hard link to the file can be removed, and
the server is not keeping track of names, only file objects (as just
agreed).

Consider two hard links:
File1.txt
File2.txt

1. Client A gets a write delegation when it opens File1.txt
2. Client B does REMOVE on File1.txt (but File2.txt still exists)

The server must recall the delegation in order to determine if the file is
still opened on the client, and if it is, it must refuse the REMOVE. If it
is no longer opened on the client, it can allow the remove.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 09, 2006 4:03 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] Open while client has a Delegation

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

---

From: [email-masked]
Date: Thu, 9 Mar 2006 16:34:33 -0500 (EST)

>> Put another way, if the Delegation
>Doesn't an unlink affect the change attribute?
As I understand it, change is affected by any metadata change
(except change itself:-). However, Sec. 9.3.4 doesn't say that the delegation
must be recalled when change changes (I've been dying to say that:-),
it just explains how CBGetattr is used to maintain the attributes on
the server and what to reply to clients doing Getattr Ops.

If the server wasn't going to be changing change while the client has
the Write delegation, why would it need to cache a copy of the change
attribute when it issues the delegation? (Second last bullet point
on Page 107) Admittedly, it doesn't address change being changed by
other clients. (It also always refers to Getattr Ops by other clients,
although Getattr doesn't have a clientid argument, as well.)

rick

---

From: [email-masked]
Date: Thu, 9 Mar 2006 18:08:45 -0500 (EST)

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

Ah yes, good point. Since the CLAIM_DELEGATE_CUR uses a name, a removal
of any name could affect the client's ability to Delegreturn.

So, a removal of any name (any hard link) requires that the Delegation
be recalled before the name is removed (and the Recall must be done before
checking for Open/Share conflicts).

Thanks for the clarification. I'm convinced, rick
ps: I just looked at my server code and it does do the Recall for all
	removes. However, I check for Open/Share conflicts before
	Recalling the Delegation. Oops, buggy wuggy fixin' time.
	Fortunately, the fix is straightforward. Boy, that would have
	been a hard one to find later:-)

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 10 Mar 2006 09:42:06 -0500

While we're thinking about the v4.1 spec, we should probably make
it explicit that operations other than SETATTR that have such an
effect are also included.

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]]
Sent: Thursday, March 09, 2006 3:10 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] Open while client has a Delegation

Cheers,
  Trond