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

[<[e-mail]>]

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.

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: [e-mail] [mailto:[e-mail]] On Behalf
Of Mike Eisler
Sent: Wednesday, October 13, 2010 6:41 PM
To: [e-mail]
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
[phone] - blogs.netapp.com/eislers_nfs_blog/


_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4