Subject: [nfsv4] Global Namespace - Location Resolution

From: Manuel Pereira <[email-masked]>
Date: Fri, 8 Apr 2005 15:04:53 -0700

We have been working on a global namespace for generalized resources over
the course of the past couple of years within the Global Grid Forum (GGF)
and are interested in contributing to the more specialized description of a
global namespace for NFSv4. This is our first try in this particular forum
and we are interested in your feedback.

Please see the write-up included below.  This work reflects a joint effort
by Leo Luan, Ted Anderson, and Manuel Pereira.

Regards,
Manuel Pereira
IBM Almaden Research Center
408-927-1935 [T/L 457]

-------------------

As NFSv4 continues to take form, the strong demand for a global namespace
for files is emerging as a common requirement. The significance and
challenges associated with a global namespace for NFSv4 have been discussed
at some length, both on the mailing list and in several internet-drafts,
most recently [Fan, Noveck, Wurlz]. Although there appears to be distinct
perspectives regarding how certain aspects of such a global namespace
should be addressed, there is a general consensus with respect to the
fundamental necessity and essential features. For this reason, it is our
intent to focus on a specific feature of the global namespace here,
presupposing the necessity and importance of such a namespace.

There appears to be general agreement that a global namespace should
provide a unified view of files which is uniform and independent of
physical location, transparent to physical data movement, hierarchical in
arrangement, and vendor neutral. This suggests that the namespace maintain
mappings between the names, identified by paths within the hierarchy, and
corresponding physical locations. Location independent path names enable
uninterrupted access to data even when the physical location of data
changes. This type of data virtualization and transparency is an important
characteristic of the global namespace.

A key concept in the global namespace discussion for file systems is the
notion of a fileset [1], which is basically a unit of namespace management
defined in NFSv4 by the set of objects that have the same fsid. Another
essential component of a global namespace is a namespace junction [2],
which is effectively the attachment point of one fileset, to the root of
another fileset. These terms will be used throughout the remainder of this
document.

A fundamental requirement of a namespace architecture that facilitates the
said characteristics of transparency and virtualization is a layer of
indirection. A namespace architecture that incorporates a layer of
indirection for this purpose is considered a three-tiered naming
architecture, where names in the first tier ultimately resolve to values in
the third tier with the second tier providing indirection. The first tier
name is the expression of a junction that appears as a directory in a list
operation, in other words the first tier is a path name. This view of a
junction may be considered similar to a special symbolic link that is
visible to users and applications and may appear together with normal files
and directories. The second tier is described by the unique logical name or
identifier, like a UUID, used in a junction, to logically correspond to one
or more physical locations of a fileset or fileset replica(s). The second
tier is necessary for indirection, since address information stored within
an object in the file system would inhibit the desired characteristics of
transparency, data virtualization, resiliency, etc. Updates to replica
location information, physical address changes of replica hosts,
registration of new replicas, and other related operations would, in this
example, presents a significant consistency problem throughout the
namespace. The third tier embodies the values of physical locations, also
referred to as addresses, of filesets. An example of the three tiers
follows:

Junction: /foo/bar => url1, url2, url3
-------------------------------------------------------------------
 [Tier 1 - visible path name   ] /foo/bar
-------------------------------------------------------------------
 [Tier 2 - logical name        ] /foo/bar => fset-01234567
-------------------------------------------------------------------
 [Tier 3 - physical location(s)] fset-01234567 => url1, url2, url3
-------------------------------------------------------------------

Where "/foo/bar" is the visible path name of the junction that contains the
logical name "fset-01234567", which maps to three different physical
locations "url1", "url2", and "url3" each hosting a replica of the fileset
logically represented by "fset-01234567".

A standardized approach for the use of logical names and associated
resolution scheme between these names and their corresponding physical
addresses can facilitate interoperability between vendor products. For
example, such a standardized approach can facilitate interoperability of
fileset replication management across a multi-vendor network of NFSv4
servers. Replica copies of a given fileset generated and hosted by
different vendor products may all benefit from the standard ability to
update the mapping between the logical name of a fileset and the number and
location of each of its replicas. In addition to the physical addresses,
attributes of the physical fileset can be defined and included in the
mapping results, such as read-only, timestamp, cache-copy, server-type,
etc. (a preliminary proposal for such attributes is listed below).

The focus here is to propose a standard approach to the operation of
resolving logical names to physical addresses. There are a number of
specifics that will not be addressed, primarily identification of a root
namespace server address, client-server interaction, representation of
namespace junctions within a fileset, replica selection mechanisms, and
where and how junction information is stored. We do not propose to mandate
the format of logical names, but rather describe them as strings that must
be unique within the contextual scope of the namespace; meaning if the
scope of the namespace is world-wide then the logical name must be unique
in a world-wide context. Logical names can therefore embody UUIDs or any
scheme or convention that maintains uniqueness within the space and time of
the scoped context. Comparisons of strings that symbolize logical names are
only meaningful in terms of equality. Finally, we propose a fully qualified
URL string serve as the representation of a physical address. The URL
syntax must comply with RFC 1738, being in the form: <file system
protocol>://<hostname>[:<port>]/<path to data> (where port is optional).

For this reason, we propose a standard location resolution scheme that
offers a mapping repository for logical to physical resolution. This
approach does not have to be complicated and should strive to minimize
operational dependencies. With a clearly defined, standard and efficient
mechanism for resolving logical names to physical addresses, we hope to
encourage global namespace interoperability among various NFSv4 vendors.
The type of repository required for this function must be capable of
efficiently maintaining large flat indices of strings that map to one or
more records, which may contain more than one field. Access to the
repository must be light-weight with satisfactory performance. A decisive
factor in choosing a repository access protocol is that it be a
well-established standard. One potential candidate for such a repository
access protocol is the Lightweight Directory Access Protocol (LDAP), which
offers a number of key features that fit nicely with the essential
requirements.

In addition to mapping a logical name to a physical address, a location
resolution scheme offers the added value of facilitating extended
attributes within a physical address record. The following list offers an
example set of basic attributes that may be included in a location
resolution schema:
-   Address - The physical address of the target data (URL)
-   CacheCopy - Is this data represented by this replica a cached copy of
data.
                          This attribute may be used to differentiate
between an original
                          source and a replica copy that is cached.
-   Checksum - A string field containing the value of a checksum
-   ChecksumType - A string identification of the checksum type used (i.e.
MD5)
-   Complete - Is the replica "complete"
-   ReadOnly - Is this a read-only replica
-   Timestamp - Timestamp indicating when replica was made
-   Version - A string field containing version information of the replica

-------------------

[1] fileset - a unit of namespace management. A fileset is like an NFSv4
filesystem, with a single root and leaves that are either files,
directories or other filesets.

[2] junction - the attachment point between one fileset (the parent) and
the root of another (the child). A junction may be a special file system
object, like in AFS where a special symlink is used that contains volume
name, type, and cell name, or it may be a virtual object identified to the
server in some other way, perhaps using an exports file or repository. In
NFSv4 the server's pseudo filesystem contains only (virtual) directories
and junctions (to real filesystems).

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