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

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

In Rick's scenario the client has done write,commit,close before sending the
second open, so it is clearly aware, or rather it should be, that it has a
write delegation.

In Trond's scenario, two different open_owners are opening the same file at
the same time from the same client... I believe this is quite rare, so I'm
not sure how much of a concern this really is.

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.

As for hard links, well, one could argue that a client accessing data from
two different file names is similar to two clients accessing the data from
the same filename: the NFS client doesn't know which two files are hard
linked (since fileid is an optional attribute), so it has separate data
caches for each. In this case, returning it the same delegation will be
disastrous when it returns the delegation for the first one, then failing to
return the delegation for the second one. If I'm correct about this, it's
clear this client should not have write delegation on any of the file's hard
links.

Also, if I'm wrong above, and I may very well be :) , if we _are_ going to
allow OPENs while a write-delegation is in effect, then there's no need for
CLAIM_DELEG_CUR since the end result will be the same as using CLAIM_NULL
(IF CLAIM_NULL doesn't return the same delegation again). Also in this case,
the server will be forced to scan for existing delegations on every
CLAIM_NULL... which would adversely affect its performance.

Seems to me like we're trying to write a tons of code just to handle corner
cases, thereby slowing down and complicating the most common cases.

Peter

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Thursday, March 09, 2006 2:31 AM
To: [email-masked]
Subject: Re: [nfsv4] Open while client has a Delegation

On Wed, [email-masked] wrote:
> Here's another one that cropped up at Connectathon06:
> 	a) Client Opens "foo" with CLAIM_NULL and gets a Write delegation
for
> 		it, followed by Write,...,Write, Commit, Close
> 	b) Client Opens "foo" again, with CLAIM_NULL, before having returned
> 		the delegation
> 
> Now, what is the correct server response for b)?
> 1 - Return an error, since the client should have used CLAIM_DELEGATE_CUR
> 	(and if so, what error seems appropriate)?
> 2 - Do the Open and return a new OpenStateID, but no Delegation
(Delegation
> 	type == NONE)?
> 3 - Same as #2, but include the same Delegation info already sent to the
client
> 	in the response to a)?
> 
> Currently, my server does #2. (I was concerned that returning the
Delegation
> 	info again might confuse the client, thinking it was a
> 	"new delegation". I also couldn't decide whether or not the
> 	delegation_stateid.seqid should be incremented, if I chose to return
it
> 	again. I think the answer to this is "No, since the Delegation
> 	state hasn't changed", but I'm not sure.)
> 
> So, is it door #1, #2, #3 or ...?

The server can choose to do either #2 or #3.  The client should
not read anything into #2 however if it figures out, upon receipt of 
the response, that there is a delegation already held.

I would prefer #3 but that is a personal preference not a protocol
interpretation preference.

With respect to a client sending an OPEN(CLAIM_NULL) for a file
that already has a delegation for it, Trond is right, there is
nothing in the protocl that makes a MUST that the client avoid
such behavior.  The client can do what it wants with OPENs for
files for which it holds a delegation.  Just as it can with 
file locks.

The one scenario where a client would do a OPEN(CLAIM_NULL)
because it doesn't know is our beloved case of hard links.

Spencer

_______________________________________________
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: Thu, 09 Mar 2006 12:03:06 -0500

> delegation, and the delegation can be recalled.

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?

> clear this client should not have write delegation on any of the file's hard

Whole swarthes of POSIX programs would break if we didn't guarantee
cache consistency between hard linked files.

Even in the case where fileids are not supported, NFS allows clients to
assume that files are hard linked if and when their filehandles are
identical. For that reason, all sane servers that support hard links
take great pains to ensure that hard linked files have identical
filehandles.

> CLAIM_NULL... which would adversely affect its performance.

Yes. Performance is an issue there, so clients should definitely _try_
to avoid CLAIM_NULL when they hold a delegation, but servers should also
be prepared to tolerate the odd race. The cost of revoking a delegation
is much higher than dealing with the race.

Cheers,
  Trond