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

From: Peter Varga <[email-masked]>
Date: Thu, 9 Mar 2006 13:11:29 -0500

Again, if the client has already done the checks locally, why does it have
to send the OPEN to the server?

An OPEN on the same file with same open_owner is basically an "OPEN_UPGRADE"
operation, and it doesn't matter if the client has a delegation or not.
However in this case as well, there's no reason for the client do this if it
is checking opens locally.

I still maintain the major point is that although the protocol allows a
client to send OPEN with CLAIM_NULL while it has a write delegation, such a
client is not taking advantage of the delegation, and therefore does not
need it.

Peter

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

>[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: Spencer Shepler <[email-masked]>
Date: Thu, 9 Mar 2006 12:36:46 -0600

> client is not taking advantage of the delegation, and therefore does not

Sure. I don't see anyone disagreeing with this.  The protocol allows it.
The server shouldn't return an error.  THe client should avoid it if
possible.  Is it required to?  No.

Spencer