Subject: [nfsv4] Open while client has a Delegation

From: [email-masked]
Date: Wed, 8 Mar 2006 11:35:18 -0500 (EST)

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

Thanks in advance for any info, rick

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

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 9 Mar 2006 01:31:10 -0600

> 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

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 09 Mar 2006 11:38:02 -0500

> because it doesn't know is our beloved case of hard links.

That is not a unique scenario. Another is the race I described, where
two OPEN(CLAIM_NULL) calls with different open_owners are put on the
wire together and the server ends up giving out a delegation to the
first request that it processes.

Cheers,
  Trond