Re: [nfsv4] possible minor corrections of federated-fs-admin-05

James Lentini <jlentini@netapp.com> Thu, 23 September 2010 14:06 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 CA98A3A6968 for <nfsv4@core3.amsl.com>; Thu, 23 Sep 2010 07:06:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.934
X-Spam-Level:
X-Spam-Status: No, score=-5.934 tagged_above=-999 required=5 tests=[AWL=0.665, 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 rVjKXvq9ySY1 for <nfsv4@core3.amsl.com>; Thu, 23 Sep 2010 07:05:59 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id BEE3F3A695A for <nfsv4@ietf.org>; Thu, 23 Sep 2010 07:05:57 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.57,223,1283756400"; d="scan'208";a="456638757"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 23 Sep 2010 07:06:27 -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 o8NE6Qxk024842; Thu, 23 Sep 2010 07:06:27 -0700 (PDT)
Date: Thu, 23 Sep 2010 10:06:26 -0400
From: James Lentini <jlentini@netapp.com>
X-X-Sender: jlentini@jlentini-linux.nane.netapp.com
To: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <18218677-5DBE-4ABB-9FF9-E737AC458533@oracle.com>
Message-ID: <alpine.LFD.2.00.1009230935110.21841@jlentini-linux.nane.netapp.com>
References: <18218677-5DBE-4ABB-9FF9-E737AC458533@oracle.com>
User-Agent: Alpine 2.00 (LFD 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: NFSv4 Working Group <nfsv4@ietf.org>
Subject: Re: [nfsv4] possible minor corrections of federated-fs-admin-05
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, 23 Sep 2010 14:06:07 -0000

On Wed, 22 Sep 2010, Chuck Lever wrote:

> Hi James-
> 
> The last paragraph of Chapter 5 section 3 says:
> 
> > If the junction is resolved, the fileserver will indicate the type of resolution that was performed using the FedFsResolveRes's resolve value and include a list of UUIDs for the FSN's FSLs in the FedFsResolveRes's fslUuid array.
> 
> 
> I think that language needs to be updated to reflect what is now 
> returned in the result of FEDFS_LOOKUP_JUNCTION.  Most important is 
> that an array of FedFsFsl structures is returned, not an array of 
> fslUuids.  I don't recall seeing this change in the most recent set 
> of diffs, but my memory could be foggy.

Good catch. I will correct that.
 
> Also, we had previously discussed adding a unique error code to the 
> protocol for "procedure not implemented".  Can that be added in the 
> next draft update?

Yes, I can add a FEDFS_ERR_NOTSUPP.

At the start of Section 5, the specification requires fileservers with 
junctions (internal nodes) to implement all of the procedures. The 
procedures are only optional for fileservers that don't support 
junctions (leaf nodes), so only leaf nodes would be allowed to return 
FEDFS_ERR_NOTSUPP.

Which procedures should be allowed to return FEDFS_ERR_NOTSUPP? All of 
the procedures except FEDFS_NULL?

-james