Re: [nfsv4] Review of 3530bis "Multi-Server Namespace" Chapter
James Lentini <jlentini@netapp.com> Fri, 22 October 2010 02:09 UTC
Return-Path: <jlentini@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 C711E3A67DB for <nfsv4@core3.amsl.com>; Thu, 21 Oct 2010 19:09:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.858
X-Spam-Level:
X-Spam-Status: No, score=-7.858 tagged_above=-999 required=5 tests=[AWL=2.741, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 G+X0MrtOJ8iB for <nfsv4@core3.amsl.com>; Thu, 21 Oct 2010 19:09:17 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id B1DF73A6359 for <nfsv4@ietf.org>; Thu, 21 Oct 2010 19:09:17 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.58,221,1286175600"; d="scan'208";a="471249322"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 21 Oct 2010 19:10:54 -0700
Received: from jlentini-linux.hq.netapp.com (jlentini-linux.hq.netapp.com [10.97.16.21]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o9M2ArEV016045; Thu, 21 Oct 2010 19:10:53 -0700 (PDT)
Date: Thu, 21 Oct 2010 22:10:52 -0400
From: James Lentini <jlentini@netapp.com>
X-X-Sender: jlentini@jlentini-linux.nane.netapp.com
To: david.noveck@emc.com
In-Reply-To: <BF3BB6D12298F54B89C8DCC1E4073D80028C7166@CORPUSMX50A.corp.emc.com>
Message-ID: <alpine.LFD.2.00.1010212156150.4707@jlentini-linux.nane.netapp.com>
References: <alpine.LFD.2.00.1009221101060.21841@jlentini-linux.nane.netapp.com> <9F6B463A-0CA8-4C34-A7C2-0BF108745B94@netapp.com> <alpine.LFD.2.00.1010211446060.4707@jlentini-linux.nane.netapp.com> <BF3BB6D12298F54B89C8DCC1E4073D80028C7166@CORPUSMX50A.corp.emc.com>
User-Agent: Alpine 2.00 (LFD 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: Robert Thurlow <Robert.Thurlow@oracle.com>, nfsv4@ietf.org
Subject: Re: [nfsv4] Review of 3530bis "Multi-Server Namespace" Chapter
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: Fri, 22 Oct 2010 02:09:18 -0000
On Thu, 21 Oct 2010, david.noveck@emc.com wrote: > I'm using the term "referral" to indicate a situation in which the > client does not have any state within the target filesystem. If he > doesn't have an open file, how is he writing? I don't think the > write-verifier case can arise in a referral. > > Am I missing something here? I must not have been clear, because I think I'm saying the same thing as you and Trond. My observation was that for the other equivalence classes (e.g., handle class) the specification gives rules for all three cases (replication, migration, and referrals), but for the write-verifier only rules for the replication and migration cases are given. The question was if specification should explicitly state that the referral case doesn't apply to the write-verifier class. I don't have an opinion on this. When I was reviewing this chapter, I wondered if this was intentional. > -----Original Message----- > From: James Lentini [mailto:jlentini@netapp.com] > Sent: Thursday, October 21, 2010 3:07 PM > To: Thomas Haynes > Cc: Robert Thurlow; Noveck, David; nfsv4@ietf.org > Subject: Re: Review of 3530bis "Multi-Server Namespace" Chapter > > > > On Wed, 13 Oct 2010, Thomas Haynes wrote: > > > Rob and Dave, > > > > There is a question for each of you below. > > > > > > On Sep 22, 2010, at 6:31 PM, James Lentini wrote: > > > <snip> > > > > For the write-verifier class in Section 7.7.7, Section 7.9.1 > > recommends assuming file system instances are of a different > > class in the case of a failover. Is there a recommendation for > > the NFS4ERR_MOVED case? I realize that the recommendations in > ^^^^^^^^^^^^^ > referral > > > To clarify my question: Is there a recommendation for the > write-verifier class in the referral case? > > The "general" rules for the handle class, fileid class, and change > class cover the replication, migration, and referral cases. Since > those rules immediately precede the write-verifier rules, the omission > of a referral case jumped out at me. > > I expect the recommendation would be for the client to treat the > referral source and referral target as being in different > write-verifier classes given that the write-verifier class doesn't > apply to the referral case, but the text doesn't say that. > > > > > 7.9.1 are taken almost verbatim from RFC 5661, but it seems > > that there is a case missing here. > > > > Rob, any comment here? > >
- [nfsv4] Review of 3530bis "Multi-Server Namespace… James Lentini
- Re: [nfsv4] Review of 3530bis "Multi-Server Names… Thomas Haynes
- Re: [nfsv4] Review of 3530bis "Multi-Server Names… James Lentini
- Re: [nfsv4] Review of 3530bis "Multi-Server Names… Thomas Haynes
- Re: [nfsv4] Review of 3530bis "Multi-Server Names… James Lentini
- Re: [nfsv4] Review of 3530bis "Multi-Server Names… Trond Myklebust
- Re: [nfsv4] Review of 3530bis "Multi-Server Names… Spencer Shepler
- Re: [nfsv4] Review of 3530bis "Multi-Server Names… Trond Myklebust
- Re: [nfsv4] Review of 3530bis "Multi-Server Names… david.noveck
- Re: [nfsv4] Review of 3530bis "Multi-Server Names… James Lentini
- Re: [nfsv4] Review of 3530bis "Multi-Server Names… david.noveck
- Re: [nfsv4] Review of 3530bis "Multi-Server Names… Robert Thurlow