Subject: RE: [nfsv4] Global Namespace - LDAP Proposal for Location Resolution

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 26 Apr 2005 17:49:15 -0400

A few questions and comments:

> 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.

So a "fileset" is basically what NFSv4 calls a "filesystem".  So why the different
term?

Let me take a stab at suggesting some possible answers.  One thing about "fileset"
vs. "filesystem" is that "filesystem" seems bigger, although it needn't be so.
There has been some discussion about the proper unit of granularity for global
namespace mapping, and the suggestion that making this a filesystem is not
sufficiently fine-grained.  If you want to get to the individual file level, then
maybe it isn't, but if you don't need to go that far, then any size directory 
tree can be a fileset, just as it can be a filesystem.

Which gets us to the second possible reason.  Typically, right now, the set of 
files with a given fsid, a client-side fs if you will, is equal to the set of
files in a given server-side fs.  There are historical reasons for this, but
the important point is that this is not inherent to the protocol.  If we have a
good reason for one server-size fs to be mapped to hundreds of client-side fs's
(and I think that eventually many of us probably will), this is fully compatible 
with the protocol, although there may be scaling issues with implementations on 
both ends.  

One issue that I think we may be confronted with is that of creating filesets out
of existing directory trees.  What does not make sense as a fileset this year
may grow and need to be converted to that status next year.  I think we will
wind up having to tackle this issue.  The solution may be as simple as establishing
rules about fsid validity (and requirements to refetch) when volatile  filehandles
expire, or we may also need some corresponding support where volatile filehandles
are not suitable.  Anyway I don't think this is requirement for a global namespace
but I think that the reverse is quite likely.  The existence of a global namespace
may wind up making this a requirement for smooth operation and reconfiguration.

> 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. 

So the issue here is that for most purposes, you don't want the junction to be
visible to users and applications.  Most users and application would see not the
junction but the directory/fileset that the junction refers to.  The client would
presumably see a referral, i.e. a MOVED error and an fs_locations value derived
from the junction using your mapping scheme.

On the other hand, management applications and administrators would like to see 
what is in the junction and perhaps change it or establish new junctions.  In 
the case of symbolic links, the nfs client always sees them and may (by following
them) hide them from applications/users.  In this case, we have something that
is not exactly parallel, since, if I understand you, it is the server that is
going to either show these (READDIR/GETATTR says the type is "junction" and
allows you, via READJUNCTION(?) to get the contents) or doesn't (READDIR/GETATTR
may give you MOVED and the corresponding fs_locations value).  I think we need
a way to specify whether the client wants these to be visible objects or not but
beyond that I'm nor clear on the exact requirements, as far as to granularity, etc.  

> 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). 

<file system protocol> is worrisome in that nfsv2, nfsv3, nfsv4.0, nfsv4.1 are 
all different protocols, even though I would imagine that we would not want a 
fileset to have different locations for different nfs protocols.  RFC1738 describes 
the first part of a the URL as a "scheme" which governs the interpretation of what 
follows.  There is no scheme definition for "nfs" in the document but "nfs" is listed 
in section 4 as something for which a scheme has been discussed and that IANA should 
make this reserved.  There is a registration process described in section 4.  Has 
"nfs" been registered?

> In NFSv4 the server's pseudo filesystem contains only (virtual) directories and 
> junctions (to real filesystems).

Some server pseudo-fs's have to have mountpoints of real filesystems and not be
the style of junctions that you are talking about.  

Suppose netapp_eng_root is a server and has /usr/dnoveck/ontap/referral-prototype
which is a junction that points, through your mapping scheme, to the server nane-17 
and the volume/fs /vol/dnoveck-tree-xyz within it.  So, in that case /vol is virtual 
directory in the pseudo-fs.  The dnoveck-tree-xyz has better not be a junction or
else we have to map once again.  Maybe mapping once again is ok in this case but
the point is you have to stop mapping some time and access the data and this 
requires mount points of real filesystems which are not junctions. 

-----Original Message-----
From: Manuel Pereira [mailto:[email-masked]]
Sent: Friday, April 22, 2005 8:19 PM
To: [email-masked]
Subject: [nfsv4] Global Namespace - LDAP Proposal for Location Resolution

We are interested in comments and/or questions in response to our last post regarding global namespace and a standard approach to location resolution.[1] In that post, we described a three-tier naming architecture and focused on a standard location resolution scheme to offer a mapping repository for logical to physical resolution.

This approach does not have to be complicated and should strive to minimize operational dependencies. 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. An important goal in choosing a repository access protocol is that it be a well-established standard. The repository and access protocol to the repository must meet performance, scalability, security, and efficiency criteria for any proposed resolution scheme to be usefully practical to NFSv4. 

We believe that the repository and associated access protocol meet the said criteria. We also believe that the formation of a standard approach to location resolution in NFSv4 and the selection of a specific repository technology are separate decisions.

We consider one potential candidate for such a repository access protocol is the Lightweight Directory Access Protocol (LDAP). LDAP is perhaps the most prominent directory service available today, and therefore presents a reasonable candidate to consider with regard to an access protocol for a logical-to-physical mapping repository. Using existing LDAP deployment in enterprises and organizations can help reduce the management overhead of maintaining the global namespace and help consolidate I/T infrastructure. LDAP defines a communication protocol for accessing and searching a database of entries annotated with attributes. Accordingly, LDAP does not define a directory service but rather the transport and format of messages used by clients to access data in a repository. These messages deal with repository entries, whose structure and relationships are described by a schema. An LDAP repository may be defined as a specialized database serving relatively static information that is optimized for high volume read operations. LDAP uses a simplified and optimized access protocol that can be used in thin and relatively simple applications.

There are a number of LDAP characteristics that fit nicely with the essential requirements of a namespace resolution scheme. First, data stored in the global namespace should be relatively static under normal circumstances. Second, a thin and optimized client access protocol is clearly desirable. Third, LDAP implementations can hold over a billion objects on a single server demonstrating considerable scalability even within a single server. Fourthly, LDAP describes a “referral” feature which easily enables integration of multiple distributed servers, enabling delegation and wide-area scalability, which is very important to a global namespace resolution scheme. Lastly, LDAP has been used in enterprise IT environments for important business and infrastructure data, how LDAP's security model is mapped/integrated with the rest of an enterprise’s security domains can be a guideline of NFSv4's potential use of LDAP. Other features demonstrated by LDAP, which appeal to the resolution function of the global namespace, include: distributed replication mechanisms, extensibility, and performance.

Considering our comparison and consideration of LDAP as a potential candidate for an NFSv4 namespace repository access protocol, are we missing anything?

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

[1] http://www1.ietf.org/mail-archive/web/nfsv4/current/msg01653.html
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 26 Apr 2005 18:36:10 -0500

On Tue, Noveck, Dave wrote:
...
> make this reserved.  There is a registration process described in section 4.  Has 

Yes, "nfs" has been registered.  See: http://www.iana.org/assignments/uri-schemes
and more specifically: http://www.ietf.org/rfc/rfc2224.txt

Spencer