Subject: [nfsv4] EXCHGID4_FLAG_SUPP_FENCE_OPS

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 29 May 2012 15:57:26 -0400

Is this language in 4.2:

	When DESTROY_CLIENTID is invoked, if there are sessions (both
	idle and non-idle), opens, locks, delegations, layouts, and/or
	wants (Section 18.49 of [2]) associated with the client ID are
	removed.  Pending operations will be completed or aborted before
	the sessions, opens, locks, delegations, layouts, and/or wants
	are deleted.

meant to override this language describing DESTROY_CLIENTID in 5661:

	If there are sessions (both idle and non-idle), opens, locks,
	delegations, layouts, and/or wants (Section 18.49) associated
	with the unexpired lease of the client ID, the server MUST
	return NFS4ERR_CLIENTID_BUSY.

?

In the original discussions I thought we were just providing the server
a way to state that it was providing guarantees that it could have
already provided over 4.0/4.1, but this goes a bit beyond that.

Also, the server can set this unilaterally, and then the client might
need to be more careful about when it calls DESTROY_CLIENTID.  Does this
violate the expectation that developers will be able to ignore features
they don't care about when first adding 4.2 support?  (In practice I
don't know whether any sane client would mind the new behavior, so maybe
there's no issue.)

In any case a little clarification might help.  (E.g. "Note that if this
flag is *not* set in the server's reply then the server is required to
return NFS4ERR_CLID_INUSE whenever such state exists.")

Also, another clarification: I'm assuming in the above that the new
behavior is in force whenever the server replies with
EXCHGID4_FLAG_SUPP_FENCE_OPS set.  Is that's what intended?  Or is it
intended to be in force only when it was set in *both* EXCHANGE_ID
arguments and reply?  Assuming the former, perhaps "if the client ID is
created with this capability" should read "if a client ID is created
with an EXCHANGE_ID with this capability set in the reply".

(Also: nit for Tom: "if there are sessions" in the first quote above
should be "any sessions".)

--b.

---

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 29 May 2012 20:06:16 +0000

>already provided over 4.0/4.1, but this goes a bit beyond that.

If "it could have already provided", then could we have added this as an
errata to RFC 5661?

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 29 May 2012 16:19:57 -0400

> If "it could have already provided", then could we have added this as an

Right, the slides Mike previously quoted say

	http://www.ietf.org/proceedings/79/slides/nfsv4-10.pdf

	"Is the EXCHGID4_FLAG_SUPP_FENCE_OPS capability necessary or is
	this just RFC5661 errata

	*  Unfortunately, few NFSv4.1 servers deal with dangling ops
	of killed sessions and client IDs"

So they wanted some way to distinguish servers that do this "right" from
those that don't.

So like I say, I understood this to be just providing the way for the
server to signal that it was providing semantics that were previously
allowed but not mandatory.  So I was a little surprised to notice the
DESTROY_CLIENTID change.

--b.