Subject: Re: [nfsv4] EXCHGID4_FLAG_SUPP_FENCE_OPS

From: "Mike Eisler" <[email-masked]>
Date: Fri, 1 Jun 2012 11:01:44 -0700

Bruce,

You raise a good point. Inline ...

On Tue, May 29, 2012 12:57 pm, J. Bruce Fields wrote:
> 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.

I think was in error. I think we should leave DESTROY_CLIENTID alone.

Note however, that an EXCHANGE_ID with the same client owner but a new
verifier needs to have the effect of waiting for or aborting pending
operations before blowing away stated when EXCHGID4_FLAG_SUPP_FENCE_OPS is
in force.

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

Yes, I agree. The client can request it (or not), and the server can
accept it or not, or impose it or not.

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

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 1 Jun 2012 16:20:55 -0400

> I think was in error. I think we should leave DESTROY_CLIENTID alone.

OK, that makes more sense to me.

The change here would also have made DESTROY_CLIENTID redundant, I
think, as it would become equivalent to the client-reboot case of
EXCHANGE_ID.

> operations before blowing away stated when EXCHGID4_FLAG_SUPP_FENCE_OPS is

Yes, understood.  That case is already covered by the previous
paragraph, so I think all we need to do is remove the reference to
DESTROY_CLIENTID.

> accept it or not, or impose it or not.

Got it, thanks.  So, maybe something like the following is all we need.

--b.

diff --git a/nfsv42_middle_op_exchange_id.xml b/nfsv42_middle_op_exchange_id.xml
index 1030ddd..c752f50 100644
--- a/nfsv42_middle_op_exchange_id.xml
+++ b/nfsv42_middle_op_exchange_id.xml
@@ -38,8 +38,8 @@
        A client SHOULD request the EXCHGID4_FLAG_SUPP_FENCE_OPS capability
        when it sends an EXCHANGE_ID operation.  The server SHOULD set this
        capability in the EXCHANGE_ID reply whether the client requests it or
-       not.  If the client ID is created with this capability then the
-       following will occur:
+       not.  It is the server's return that determines whether this capability
+       is in effect.  When it is in effect, the following will occur:
     </t>
 
     <t>
@@ -56,15 +56,6 @@
         </t>
 
         <t>
-          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  <xref target="ref:RFC5661" />) 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.
-        </t>
-
-        <t>
           The NFS server SHOULD support client ID trunking, and if it does
           and the EXCHGID4_FLAG_SUPP_FENCE_OPS capability is enabled, then a
           session ID created on one node of the storage cluster MUST be

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 6 Jun 2012 22:05:34 +0000

I've pulled in the following change, thanks Bruce!