Re: [nfsv4] Last call for NSDB Protocol for Federated Filesystems (Oct 4 - Oct 22nd)

James Lentini <> Thu, 04 November 2010 18:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BC6628C100 for <>; Thu, 4 Nov 2010 11:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CGOFmtPFGPXm for <>; Thu, 4 Nov 2010 11:25:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3673728C0DB for <>; Thu, 4 Nov 2010 11:25:48 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.58,297,1286175600"; d="scan'208";a="477597436"
Received: from ([]) by with ESMTP; 04 Nov 2010 11:25:58 -0700
Received: from ( []) by (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oA4IPvLu015466; Thu, 4 Nov 2010 11:25:57 -0700 (PDT)
Date: Thu, 04 Nov 2010 14:25:57 -0400
From: James Lentini <>
To: Robert Thurlow <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <>
User-Agent: Alpine 2.00 (LFD 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: "" <>
Subject: Re: [nfsv4] Last call for NSDB Protocol for Federated Filesystems (Oct 4 - Oct 22nd)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Nov 2010 18:25:49 -0000

On Wed, 3 Nov 2010, Robert Thurlow wrote:

> James Lentini wrote:
> > There has been some discussion regarding the fedfsAnnotation LDAP attribute
> > defined in Section that I wanted to record as part of this thread.
> > 
> > Chuck Lever discovered some ambiguities in the description of this
> > attribute's format. We discussed those issues during the FedFS concall on
> > 10/14. A revised description that attempts to eliminate those ambiguities is
> > included below.
> I like the revised text without reservation.
> > In the process of reviewing the revised text, Chuck, my co-authors, and I
> > have have been considering the utility of including this annotation
> > mechanism. Before LDAP was chosen for the NSDB protocol, this attribute was
> > created to allow private schema extensions. Given our use of LDAP, this
> > attribute may be obsolete.
> > 
> > Using LDAP there are other, arguably more natural, ways to allow for schema
> > extensions. For example, LDAP allows an entry's schema definition to be
> > extended by adding additional object types to the entry. In this approach,
> > the KEYs and VALUEs defined in Section map to LDAP attribute types
> > and values respectively. This approach would allow implementers to define
> > their own annotation attributes, and would allow for standardizing such
> > attributes if there was interest.
> > 
> > Are there objections to removing the fedfsAnnotation attribute from the
> > schema and recommending that schema extensions be handled as described
> > above?
> I wish to create a management application which uses the
> annotations fields as described in the current NSDB schema,
> and I think the use case really requires the current form
> of the specification, and not schema extensions.
> The interesting-to-me use case is a kind of a back pointer -
> a way to track back from an FSL and/or FSN to the place in
> the namespace where this item is referenced.  I don't think
> this can every be truly reliable, but if you're taking a
> disk array down for planned maintenance and can send an
> outage warning saying that "the following filesystem paths
> are known to be affected", that could be useful at times.
> The unreliability is why this is not something I have tried
> to make a core part of the NSDB protocol.
> So the goal is something like a "mountpath=/nfs4/my/path"
> piece of data.  The NSDB protocol as currently specified
> will let me just write this attribute whenever I manage a
> junction.
> If I need to do this with LDAP schema extensions, someone
> must go through the non-standard LDAP management interface
> to get these bits added to the schema before I do my first
> bit of work in my management application.  That might be me,
> the vendor, trying to script something for all known LDAP
> implementations, or it might be my customer trying to read
> the fine manuals and do what I conceptually guide him to do.
> How many of us would ever do that as a vendor or a customer?
> Even if my environment is homogeneous, I may have to touch
> every LDAP server I use for FedFS, depending on what any
> replication solution supports.
> In summary, I think I have something I would really like to
> implement which cannot be done properly without annotations
> as currently specified, so I would like them kept.

Clearly there is a use for this attribute. The next revision of 
draft-ietf-nfsv4-federated-fs-protocol will include this attribute 
with the revised definition of its format.