Subject: [nfsv4] Global Namespace - Location Resolution

From: Manuel Pereira <[email-masked]>
Date: Thu, 7 Apr 2005 22:46:42 -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