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

"Mike Eisler" <mre-ietf@eisler.com> Wed, 13 October 2010 22:40 UTC

Return-Path: <mre-ietf@eisler.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF0D3A699A for <nfsv4@core3.amsl.com>; Wed, 13 Oct 2010 15:40:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvkqvcBtUwSF for <nfsv4@core3.amsl.com>; Wed, 13 Oct 2010 15:40:11 -0700 (PDT)
Received: from postalmail-a8.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 045D03A69C1 for <nfsv4@ietf.org>; Wed, 13 Oct 2010 15:40:11 -0700 (PDT)
Received: from webmail.eisler.com (ahfbbjcaiaae.dreamhost.com [75.119.208.4]) by postalmail-a8.g.dreamhost.com (Postfix) with ESMTP id A48C1AABBD for <nfsv4@ietf.org>; Wed, 13 Oct 2010 15:41:28 -0700 (PDT)
Received: from 198.95.226.230 (proxying for 198.95.226.230) (SquirrelMail authenticated user mre-ietf@eisler.com) by webmail.eisler.com with HTTP; Wed, 13 Oct 2010 15:41:28 -0700
Message-ID: <9a0c3fae91b577f987b0209ac1b91753.squirrel@webmail.eisler.com>
Date: Wed, 13 Oct 2010 15:41:28 -0700
From: "Mike Eisler" <mre-ietf@eisler.com>
To: nfsv4@ietf.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: [nfsv4] disposition of inflight NFSv4.1 operations when a session or client ID is destroyed
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Oct 2010 22:40:12 -0000

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/