Re: [nfsv4] When to RECLAIM_COMPLETE?

"Noveck, Dave" <Dave.Noveck@netapp.com> Mon, 07 December 2009 21:47 UTC

Return-Path: <Dave.Noveck@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 2C2613A694E for <nfsv4@core3.amsl.com>; Mon, 7 Dec 2009 13:47: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 4jmipqT7eUwg for <nfsv4@core3.amsl.com>; Mon, 7 Dec 2009 13:47:13 -0800 (PST)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 584163A672E for <nfsv4@ietf.org>; Mon, 7 Dec 2009 13:47:13 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.47,357,1257148800"; d="scan'208";a="284953393"
Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 07 Dec 2009 13:47:03 -0800
Received: from sacrsexc1-prd.hq.netapp.com (sacrsexc1-prd.hq.netapp.com [10.99.115.27]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id nB7Ll3AV019679 for <nfsv4@ietf.org>; Mon, 7 Dec 2009 13:47:03 -0800 (PST)
Received: from rtprsexc2-prd.hq.netapp.com ([10.100.161.115]) by sacrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 13:47:03 -0800
Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.111]) by rtprsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 16:47:01 -0500
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 16:47:01 -0500
Message-ID: <6AD91E4EBDFF734B9035AA1DCD0965E5066FD5C0@RTPMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <273FE88A07F5D445824060902F70034408A1A7F7@SACMVEXC1-PRD.hq.netapp.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [nfsv4] When to RECLAIM_COMPLETE?
Thread-Index: Acp3hepCsBwi9vcqRiqABV/OAviwegAAJF6w
From: "Noveck, Dave" <Dave.Noveck@netapp.com>
To: "Labiaga, Ricardo" <Ricardo.Labiaga@netapp.com>, nfsv4@ietf.org
X-OriginalArrivalTime: 07 Dec 2009 21:47:01.0785 (UTC) FILETIME=[CF210090:01CA7786]
Subject: Re: [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:47:14 -0000

That's how I read it.

I'm pretty sure that not following that path leads into difficulties for
the reasons you indicate, but even if you somehow could avoid those
difficulties, the spec is pretty direct.  It says "MUST"

-----Original Message-----
From: Labiaga, Ricardo 
Sent: Monday, December 07, 2009 4:41 PM
To: nfsv4@ietf.org
Subject: [nfsv4] When to RECLAIM_COMPLETE?


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
_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4