Re: [nfsv4] Global Namespace in NFSv4

Ted Anderson <> Mon, 11 October 2004 17:04 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id NAA22519 for <>; Mon, 11 Oct 2004 13:04:59 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1CH3mA-0003TW-Fw for; Mon, 11 Oct 2004 13:15:58 -0400
Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1CH3WJ-0004BF-Em; Mon, 11 Oct 2004 12:59:35 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1CH3UD-0003Ht-DI for; Mon, 11 Oct 2004 12:57:25 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id MAA21717 for <>; Mon, 11 Oct 2004 12:57:22 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.33) id 1CH3ej-0003IY-7A for; Mon, 11 Oct 2004 13:08:20 -0400
Received: from ([] helo=[]) by with asmtp (Exim 4.34) id 1CH3Ta-0003HR-OL; Mon, 11 Oct 2004 09:56:47 -0700
Message-ID: <>
Date: Mon, 11 Oct 2004 12:56:45 -0400
From: Ted Anderson <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Chenggong Fan <>
Subject: Re: [nfsv4] Global Namespace in NFSv4
References: <>
In-Reply-To: <>
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 6696b53a3b08fac26c0bff688557057c416dc04816f3191c022fe0290e38db9d4ae81bb1a93af5658a4f69e59f414d0d350badd9bab72f9c350badd9bab72f9c
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: 7bit

On 10/9/2004 16:55, Chenggong Fan wrote:
 > My name is Charles Fan and I am relatively new to this workgroup.  I
 > work for Rainfinity and we make file virtualization products.  I am
 > interested in topics in NFSv4 related to namespace, migration, referrals
 > and volatile file handles.

Interesting topics all!

 > I have read the mailing list threads around last Christmas discussing
 > these topics and the I-Ds written by Rob Thurlow and Dave Noveck.  I
 > enjoyed reading them.  There were repeated calls for more volunteers to
 > work on these issues on the mailing list.  I'd like to raise my hand and
 > try to make useful contributions.
 > Attached is a summary of what I learned from the discussion threads and
 > a proposal.  Please correct me if I made any mistakes, and all comments
 > welcome.

This summary really seems like a good one and should be a very useful
starting point for others joining into this discussion.

 > 3. World-wide namesapce.  This makes possible the "world-wide NFS",
 >    with a global URL to each file.  I believe if we are successful in
 >    defining an enterprise-wide namespace, it is possible to extend it
 >    to the global scale, perhaps by leveraging IP DNS resolutions.  But
 >    the enterprise-wide namespace seems to be of higher priority for us
 >    to work on the first.

I agree with this.

 > So why do some NFS enterprise users still ask for a "global
 > namespace"?  What is it lacking in an automounter-based solution?
 > Here is what I've heard from NFS administrators.  First the update of
 > the automounter map is not completely transparent.  Clients which have
 > applications running and keeping the old mount active will not let go
 > the old mount.  For some versions of some OS, even after the mount
 > become inactive, the old mount still won't be released, even with "-f"
 > option.  Dealing with the multitude of client OS's and versions, this
 > is a difficult problem.  (Reflected in Mike Eisler's comment about
 > category #1).

I also would like to understand this question better.  I assume that
part of the problem is that there are no widely accepted standards for
building and managing such automounter namespaces.  Apparently, there
are lots of ad hoc solutions but no very good knowledge base for how to
deal with platform specific problems, cross vendor interoperability
issues, or multi-protocol support.  This is an area where even an
NFSv4-oriented I-Ds would help by providing a nucleus for future
standardization, formal or otherwise.

A colateral benefit of targetting a world-wide namesapce is that it
would encourage real standardization.  Pushing for heterogeneous and
multi-protocol support will also help the drive to uniform mechanisms.
This suggests that the "problem" with the automounter solutions to date
is that they don't provide quite enough incentive (benefit) to adopt it
widely and expand its reach into other domains.  Sort of a
network-effect issue.

 > If this is a workable architecture, we have the following work items?
 > 1. NFSv4 Global Namespace Problem Statement
 > 2. Clarification on NFSv4 client-server ops involving NFS4ERR_MOVED
 >    and fs_location.
 > 3. Best Practice in configuring NFSv4 enterprise namespace, including
 >    nfsroot schemes.
 > 4. Proposal for NFSv4 minor version enhancements
 > 5. Proposal for database schema for NFS namespace
 > 6. Prototype implementation of the client, server and namespace
 >    server.
 > With the feedback from the group, I volunteer to start immediately to
 > work on item 1, perhaps co-authoring with some of you?  I also
 > volunteer to join Dave and Rob on the work on item #2, and collaborate
 > on some initial prototyping.  I hava some questions and comments on
 > item #2 regarding detailed ops and I'll send them in a separate email.

We are working on #5, an LDAP schema, and will hopefully have something
to share before long.

Ted Anderson

nfsv4 mailing list