Subject: Re: [nfsv4] draft-fan-nfsv4-global-namespace-problem-statement-00.txt

From: Manuel Pereira <[email-masked]>
Date: Fri, 1 Apr 2005 17:12:24 -0800

Craig Everhart wrote:
> (b) In 3, your second requirement for Uniformity of View. Yes, there
> should be an agreed-on view and an agreed-on authoritative procedure for
> determining the global name space. But I think it's misleading and
> constraining to say that the authoritative data for the namespace needs
> to be in a table. It could just as easily, or perhaps better, be in the
> "smart server" model, where it doesn't really matter where the smart
> server gets its information. I'm all for the agreed-on root server--but
> actually that root server should really be multiple. See (d) below...

We agree with the notion of a “smart server”, as you have stated “where it
doesn’t really matter where the smart server gets its information”, so long
as the information obtained is from an authoritative repository.  We also
believe that the essential namespace semantics need to be defined, perhaps
in the form of a standard specification.

Craig Everhart wrote:
>> (c) In 5, what "namespace mappings"? I guess I don't understand what
>> kind of schema you have in mind. Does it duplicate paths that are also
>> in file systems? (Why?)
>
> Charles Fan wrote:
> The namespace mappings are referred to the abstraction between the
> logical namespace and physical locations.  We call for a standard schema
> to capture these mappings.

This is a good description of namespace mappings.

With respect to the “why” question, it is certainly necessary to maintain a
“mapping” that resolves a logical representation to a physical location.
Such a mapping provides a necessary level of indirection, thereby enabling
a certain degree of virtualization allowing target locations to freely move
and change without impacting junctions/mount points stored in the
filesystem (changes to target locations are handled in the namespace
mappings).

We believe this substantiates the need to standardize an object schema and
access method to a resolution service responsible for handling logical to
physical mappings.  Standardization is key for this particular service to
ensure interoperability between various namespace service implementations
and logical-to-physical resolution services.

Charles Fan wrote:
> I agree that the name can correspond to multiple addresses.

We too agree that the capability of a one-to-many mapping must be offered.

Regards,
Manuel Pereira
===============================
IBM Almaden Research Center
===============================
650 Harry Road, San Jose, CA 95120
1-408-927-1935  [T/L 457]
Pager: 800-946-4646 1492425
http://mvp3.almaden.ibm.com
[email-masked]

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Ted Anderson <[email-masked]>
Date: Mon, 04 Apr 2005 16:22:41 -0400

Charles Fan, Dave Noveck, Mario Wurzl, March 2005, "NFSv4 Global
Namespace Problem Statement",
draft-fan-nfsv4-global-namespace-problem-statement-00.txt.

 > Multiple data replicas can be created, and the global namespace will
 > be able to transparently guide clients to the appropriate replica
 > based on load, distance, and access requirement (read or write).

I agree with Craig Everhart that the intention of the client to read or
write data cannot be used to select an appropriate replica.

 > - Granularity of namespace mapping: Whether the namespace mapping can
 >   happen at the file system granularity, or directory granularity, or
 >   file granularity, or sub-file granularity?

The easiest and most important reduction in granularity from that of
whole filesystems, is to a granularity of a directory subtree.  This is
larger and usually more convenient that a single directory and certainly
much easier to accommodate than the level of files or subfiles.  Perhaps
this meaning was intended by "directory granularity", but if so a
clarification would be good.

 > - Variable Support: Depending on variables such as client OS, client
 >   geographical location, or time-of-day, can the namespace mapping be
 >   different?  This is highly desired in many customer environments.

Variable support can be a valuable addition to a file system namespace.
In the same way that a pathname is a vehicle for communicating the
applications desire for a particular object to the file system, the
variable mechanism expands that communication path to include contextual
information that can be valuable such as platform or other factors.  In
fact, the read or write intention (the first point above) is usually
better communicated explicitly via the namespace by having a different
path for a read-only replica compared to that used to access the
writable primary from which it is created.

Conventions for these elaborations of the namespace will improve
interoperability and uniformity.

 > - Manageability.  Can the namespace be accessed and modified real-time
 >   by administrators? by applications? by user groups? How fast does a
 >   namespace mapping change propagate to all clients?

This raises the question of what the management interface for the
namespace should look like.  This is an important question to consider,
even though its specification may be out of scope for the NFSv4 RFC
process itself.  It is very likely that consideration of the management
interface would have some impact on the NFSv4 client/server protocol
that is the focus of the working group.

 > - Multi-protocol Interoperability.  Will NFSv2 and v3 clients be able
 >   to use this same namespace?  Will this namespace be synchronized
 >   with the CIFS namespace?

Supporting utilization of the namespace by CIFS clients would be highly
desirable.  Not the least point is that broadening the scope of the
namespace to include CIFS will likely provide a wider perspective that
will improve the longevity and acceptability of the resulting
specification.

 > - A viable global namespace solution will need to be location
 >   independent, unified, transparent and secure.  We should also
 >   consider additional user requirements to make sure we have a
 >   solution that addresses the needs of enterprise storage
 >   administrators.

Administrative tools are another type of client to consider.  While
these could use any type of protocol (including NFSv4), their concerns
would likely be somewhat different from that of the file system client.
In particular, the admin client would be interested in the structure of
the namespace rather than the contents of the file system.  It would
probably be easy to define aspects of the protocol to provide structural
information giving the relationships between constituents of the
"global" file system in addition to the file server addresses needed by
file system clients.  In other words, should we augment the NFSv4
protocol to expose the junctions/referrals themselves to cognizant
clients?

 > First, we could choose a central repository, such as LDAP, for the
 > namespace mappings.  We can work to define a standard schema for the
 > NFS namespace mappings.  This work is not part of the NFSv4 protocol
 > itself, but it is reasonable for us to address it for the specific
 > case of NFS namespace.  We should define well how servers and clients
 > can access this central repository, and how it should support not only
 > NFSv4, but v3 and v2 clients as well.

 > Second, we need to clarify the client-server interactions based on RFC
 > 3530.  This work is already under way, with both implementation and
 > suggestions for errata for RFC 3530.  Both the migration case and the
 > pure referral case need to be fully considered. [Noveck] The security
 > issues should also be considered that the proposed scheme doesn't
 > compromise existing level of security.  The hope is that this
 > challenge will be overcome, and we'll be able to have the first
 > client, server and namespace server reference implementation of the
 > basic use of the NFS4ERR_MOVED and fs_location.

Currently FS_LOCATIONS includes a list of physical addresses of file
servers.  In tackling the second item we could address the needs of the
first, in the following way.  Extend the semantics of the entries in the
list to include logical names for the objects being addressed.  This
would effectively be the input the file server uses when looking up the
physical addresses it also returns.  In addition (or instead) it could
return a representation of the (LDAP) schema used to describe the
namespace mappings (perhaps serialized in using LDIF?).  This extension
could be the vehicle for support read-only administrative access to the
namespace via the NFSv4 file system protocol.  Could this be extended to
read-write access by allowing FS_LOCATIONS to be written via setattr()?

On 3/30/2005 18:04, Nicolas Williams wrote:
 > On Wed, Mar 30, 2005 at 02:19:01PM -0800, Craig Everhart wrote:
 >>(d) In 5, "Third," yes, "nfsroot" is an OK idea.  But I'm partial to
 >>the RFC 1183 idea of building on an "AFSDB" subtype, so that multiple
 >>servers can naturally be returned as the root for the filesystem for a
 >>given organization. ...
 >
 > I think we should use SRV RRs.  There is precedent for this; for
 > example, Kerberos V KDCs can be found through SRC RRs.

I'm also partial to AFSDB records, but it seems that the SRV are as
capable as AFSDB records for this purpose, so it doesn't seem to make
any technical difference.

Ted Anderson