Re: [nfsv4] Global Namespace in NFSv4

[Chenggong Charles Fan <[e-mail]>]

Hi,

I've formated my previous email on global namespace into a short I-D 
(attached).  Comments welcome.

Charles

Ted Anderson wrote:

> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/nfsv4