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

From: Peter Varga <[email-masked]>
Date: Wed, 8 Mar 2006 15:10:24 -0500

I would say that's a badly behaving client since all opens are supposed to
be handled locally while a client has write delegation, and the client is
the one who should pay the price for the bad behaviour.

Besides, you as a server have no idea what OPENs and CLOSEs, if any, have
actually been handled locally by the client, so you don't know if this bad
OPEN you received should be successful or not as it may violate sharing
modes for OPENs that HAVE been handled by the client locally.

So, how about another option... recall the original delegation you gave the
client, and don't give it any new delegations (at least until it renews with
another SETCLIENTID)?

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 08, 2006 11:35 AM
To: [email-masked]
Subject: [nfsv4] Open while client has a Delegation

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

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

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 08 Mar 2006 18:00:45 -0500

> the one who should pay the price for the bad behaviour.

It is not a "badly behaving client". The only way to guarantee that the
client never sends an OPEN for a file for which the server has granted
it a write delegation would be to require that it must serialise _all_
OPEN calls to any given file until it obtains a delegation.

Where in the RFC does it say that you have to do that?

Cheers
  Trond