Re: [nfsv4] Review of 3530bis "Multi-Server Namespace" Chapter

James Lentini <jlentini@netapp.com> Thu, 21 October 2010 19:05 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 659BD3A681F for <nfsv4@core3.amsl.com>; Thu, 21 Oct 2010 12:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.736
X-Spam-Level:
X-Spam-Status: No, score=-7.736 tagged_above=-999 required=5 tests=[AWL=2.863, 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 673bDCc-VBid for <nfsv4@core3.amsl.com>; Thu, 21 Oct 2010 12:05:50 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 814733A689B for <nfsv4@ietf.org>; Thu, 21 Oct 2010 12:05:50 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.58,218,1286175600"; d="scan'208";a="471102823"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 21 Oct 2010 12:07:24 -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 o9LJ7NCh021973; Thu, 21 Oct 2010 12:07:23 -0700 (PDT)
Date: Thu, 21 Oct 2010 15:07:22 -0400
From: James Lentini <jlentini@netapp.com>
X-X-Sender: jlentini@jlentini-linux.nane.netapp.com
To: Thomas Haynes <thomas@netapp.com>
In-Reply-To: <9F6B463A-0CA8-4C34-A7C2-0BF108745B94@netapp.com>
Message-ID: <alpine.LFD.2.00.1010211446060.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>
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: Thu, 21 Oct 2010 19:05:51 -0000

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?