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

<david.noveck@emc.com> Fri, 22 October 2010 01:44 UTC

Return-Path: <david.noveck@emc.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 947C43A67FA for <nfsv4@core3.amsl.com>; Thu, 21 Oct 2010 18:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.671
X-Spam-Level:
X-Spam-Status: No, score=-6.671 tagged_above=-999 required=5 tests=[AWL=-0.072, 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 YjmzMoouvi01 for <nfsv4@core3.amsl.com>; Thu, 21 Oct 2010 18:44:50 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 484CD3A6359 for <nfsv4@ietf.org>; Thu, 21 Oct 2010 18:44:49 -0700 (PDT)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9M1kQ12023889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2010 21:46:26 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 21 Oct 2010 21:46:20 -0400
Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9M1jOej032319; Thu, 21 Oct 2010 21:45:24 -0400
Received: from CORPUSMX50A.corp.emc.com ([128.221.62.45]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Oct 2010 21:45:24 -0400
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: Thu, 21 Oct 2010 21:45:23 -0400
Message-ID: <BF3BB6D12298F54B89C8DCC1E4073D80028C7166@CORPUSMX50A.corp.emc.com>
In-Reply-To: <alpine.LFD.2.00.1010211446060.4707@jlentini-linux.nane.netapp.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review of 3530bis "Multi-Server Namespace" Chapter
Thread-Index: ActxU2kMSiDimbvJT66RfzUtYy8NigANvxlg
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>
From: david.noveck@emc.com
To: jlentini@netapp.com, thomas@netapp.com
X-OriginalArrivalTime: 22 Oct 2010 01:45:24.0247 (UTC) FILETIME=[CB6C0270:01CB718A]
X-EMM-MHVC: 1
Cc: 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 01:44:52 -0000

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?

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