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?
> 
>