Subject: Re: [nfsv4] disposition of inflight NFSv4.1 operations when a session or client ID is destroyed

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 4 Nov 2010 13:46:57 -0400

On Thu, Oct 14, 2010 at 06:41:52AM -0400, [email-masked] wrote:
> This issue has been vaguely alluded to before but there is no previous
> that actually tackles it.  Your message is not a dup.
> 
> I don't see how a client can go on without the assurance that operations
> started under a previous session or clientid, cannot just start up again
> and screw up any assumptions you are making.  The protocol is designed
> so that if such messages were stuck in the network, they would be
> discarded.  To me, the fact that this issue is not mentioned for
> operations in-process on the server is just a plain oversight.  I'd fix
> it via the errata mechanism.
> 
> This oversight is clearly either your fault or my fault or Spencer's
> fault.  We could have a big finger-pointing session in Beijing :-).  Or
> we could go have a drink and celebrate the fact that instances of this
> sort of oversight have been pretty small given the size and complexity
> of the spec.  I vote for the latter. 
> 
> If this is judged too big/substantive for the errata mechanism, then I
> would favor the capability as second best.  But the question is what do
> you say about clients and servers that don't provide this.   The
> following is what I would want to, but couldn't, say:
> 
>      "Those writing clients that do not set this bit or 
>       that are allowed to interact with servers that don't 
>       set it, should immediately contact a mental health
>       professional." 
> 
> 
> > Another question is, even if you think the server MUST 
> > abort/wait for in-flight requests, does your NFSv4.1 server 
> > do that?
> 
> I don't know.  I intend to find out.
> 
> The fact that this is not mentioned in RFC5661 does raise the chances
> that implementations did not address this.  While, once you raise the
> question, the answer should be clear, someone asked to implement the
> spec might very well not think of this issue.

Right, so apologies for the slow response, the Linux server does fall
into that category.  On the other hand, it's not done, and this can be
added to the list of things to do before we declare it done (and
encourage distributors to have it on by default).

I'm a little confused about the cases when a clientid is destroyed: I
would have thought those correspond to unmounts, at which point the
client no longer cares.

--b.

> 
> So this gives rise to another reason for the capability bit.  It creates
> the occasion for someone to really look at the implementation and decide
> to say "we have this Halloween server and if you dig being afraid of
> weird protocol interactions with dead sessions or server instances, this
> is for you."  or "we've looked at this and you can relax.  No need to
> take anxiolytic drugs.", presumably making whatever fixes are necessary
> to be able to make the second choice.
>   
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mike Eisler
> Sent: Wednesday, October 13, 2010 6:41 PM
> To: [email-masked]
> Subject: [nfsv4] disposition of inflight NFSv4.1 operations when a
> session or client ID is destroyed
> 
> Apologies if this is a dup.
> 
> What do people think should happen to operations that are in flight when
> DESTROY_SESSION kills a session or EXCHANGE_ID/CREATE_SESSION
> causes an existing client ID to be destroyed (thus destroying
> the sessions of s previous client instance)?
> 
> - Undefined, or
> - Server MUST abort or wait for in flight operations to complete
> 
> The internet-draft Margaret Susairaj and I wrote proposes a new
> capability to EXCHANGE_ID to ensure that the latter happens. See
> http://www.ietf.org/id/draft-eisler-nfsv4-enterprise-apps-00.txt .
> 
> Excerpt from the I-D:
> 
>    A client MAY request the EXCHGID4_FLAG_SUPP_FENCE_OPS capability when
>    it sends an EXCHANGE_ID operation.  The server MAY set this
>    capability in the EXCHANGE_ID request whether the client requests it
>    or not.  If the client ID is created with this capability then the
>    following will occur:
> 
>    o  The server will not reply to DESTROY_SESSION until all operations
>       in progress are completed or aborted.
> 
>    o  The server will not reply to subsequent EXCHANGE_ID invoked on the
>       same Client Owner with a new verifier until all operations in
>       progress on the Client ID's session are completed or aborted.
> 
>    o  When DESTROY_CLIENTID is invoked, if there are sessions (both idle
>       and non-idle), opens, locks, delegations, layouts, and/or wants
>       (Section 18.49) 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.
> 
>    o  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
>       destroyable via DESTROY_SESSION.  In addition, DESTROY_CLIENTID
>       and an EXCHANGE_ID with a new verifier affects all sessions
>       regardless what node the sessions were created on.
> 
> =======================================================
> 
> But it raises the question if this is necessary.
> 
> Another question is, even if you think the server MUST abort/wait for
> inflight requests, does your NFSv4.1 server do that?
> 
> --
> Mike Eisler, Senior Technical Director, CR & NFS
> +1 719 599 9026 - blogs.netapp.com/eislers_nfs_blog/
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4