[nfsv4] When to RECLAIM_COMPLETE?

"Labiaga, Ricardo" <Ricardo.Labiaga@netapp.com> Mon, 07 December 2009 21:40 UTC

Return-Path: <Ricardo.Labiaga@netapp.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 EC1EC28C1D5 for <nfsv4@core3.amsl.com>; Mon, 7 Dec 2009 13:40:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 XhzzOd39MEdq for <nfsv4@core3.amsl.com>; Mon, 7 Dec 2009 13:40:14 -0800 (PST)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 4026E28C0E9 for <nfsv4@ietf.org>; Mon, 7 Dec 2009 13:40:14 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.47,357,1257148800"; d="scan'208";a="284950534"
Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 07 Dec 2009 13:40:04 -0800
Received: from svlrsexc2-prd.hq.netapp.com (svlrsexc2-prd.hq.netapp.com [10.57.115.31]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id nB7Le3x5016037 for <nfsv4@ietf.org>; Mon, 7 Dec 2009 13:40:04 -0800 (PST)
Received: from SACMVEXC1-PRD.hq.netapp.com ([10.99.115.13]) by svlrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 13:40:03 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 07 Dec 2009 13:40:37 -0800
Message-ID: <273FE88A07F5D445824060902F70034408A1A7F7@SACMVEXC1-PRD.hq.netapp.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: When to RECLAIM_COMPLETE?
Thread-Index: Acp3hepCsBwi9vcqRiqABV/OAviweg==
From: "Labiaga, Ricardo" <Ricardo.Labiaga@netapp.com>
To: nfsv4@ietf.org
X-OriginalArrivalTime: 07 Dec 2009 21:40:03.0458 (UTC) FILETIME=[D5C95E20:01CA7785]
Subject: [nfsv4] When to RECLAIM_COMPLETE?
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: Mon, 07 Dec 2009 21:40:15 -0000

Section 18.51.3 states:

   "Whenever a client establishes a new client ID and before it does the
   first non-reclaim operation that obtains a lock, it MUST send a
   RECLAIM_COMPLETE with rca_one_fs set to FALSE, even if there are no
   locks to reclaim.  If non-reclaim locking operations are done before
   the RECLAIM_COMPLETE, an NFS4ERR_GRACE error will be returned."

I interpret this as requiring the client to send a RECLAIM_COMPLETE
after every new client id.  Contrary to only sending it after new client
ids that resulted from detecting the server restarted.  Since the client
doesn't always know if the server has rebooted, send a RECLAIM_COMPLETE
after the initial EXCHANGE_ID/ CREATE_SESSION as well, and both sides
will be happy.

Is this an accurate interpretation?  The question recently came up in
the Linux list while working on the feature implementation.

Thanks,

- ricardo