[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
- [nfsv4] When to RECLAIM_COMPLETE? Labiaga, Ricardo
- Re: [nfsv4] When to RECLAIM_COMPLETE? Noveck, Dave
- Re: [nfsv4] When to RECLAIM_COMPLETE? Labiaga, Ricardo