Subject: RE: [nfsv4] Open/CBGetattr scenario

From: Peter Varga <[email-masked]>
Date: Fri, 10 Mar 2006 10:33:14 -0500

On second thought... yea you guys are all right about this. My appologies.

I was making the assumption this whole time that I need the caller to
present a _delegation_ stateid in order to prevent a recall, when really
just having a clientid that matches the clientid of the delegation owner is
sufficient to prevent the recall. So, I'm fairly convinced that a server
doesn't need to recall on OPEN(CLAIM_NULL) from the same client that has a
write delegation on the file.

That said, why do we need CLAIM_DELEG_CUR on OPEN?

Peter

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Friday, March 10, 2006 10:24 AM
To: [email-masked]
Subject: RE: [nfsv4] Open/CBGetattr scenario

--- Peter Varga <[email-masked]> wrote:

> Although sending of CB_GETATTR is causing problems in Rick's scenario, I
> don't think it is the root of the problem: the second OPEN from the client
> that has the write delegation has the create flag set! Such an OPEN, if
> successful (and it is in this case), must change the value of the 'change'
> attribute, thereby necessitating a delegation recall in this case.

The presence of the create flag is set 
to open and create an existing
file does not alter the change attribute.

However, the presence of the attributes 
in the OPEN operation that set the
file size to zero bytes does result 
in the value of 'change' changing.

Regardless, this does not require a recall. 
For one thing, this OPEN for create/truncate
might very well be one that the client did 
ages ago in its own cache, and it is
now flushing it to the server for whatever 
reason. For another thing, the server might have 
already recalled the delegation, and the client is
flushing for that reason.

Clients that hold delegations are free 
to send OPENs, LOCKs, SETATTRs, WRITEs etc. whenever
they want. That's why these operations include stateids. 

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

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

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 10 Mar 2006 10:49:03 -0500

> That said, why do we need CLAIM_DELEG_CUR on OPEN?

OPEN(CLAIM_DELEGATE_CUR) has the useful property that it can only
succeed while the delegation is held by the client.

A client that uses DENY modes, for instance, needs to know that its OPEN
was done under the protection of the delegation. If the delegation lease
expired while it was still trying to recover its share reservations,
then it may need to send an error to the application.

Cheers,
  Trond