Subject: [nfsv4] Review of draft-ietf-nfsv4-federated-fs-reqts-03

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Sep 2009 15:06:50 -0500

Upon request I have reviewed much of draft-ietf-nfsv4-federated-fs-
reqts-03.

I have a new, fundamental comment to make about the notion of federated
filesystem described in that I-D, as well as in draft-ietf-nfsv4-
federated-fs-protocol.  That comment follows.

The supposed namespace database (NSDB) does not actually model junctions
(mounts, whatever)!

Therefore the NSDB does not actually describe a namespace at all.  It's
just a collection of objects naming discrete filesystems (excuse me,
"filesets") and listing their locations.

No wonder I couldn't figure out how the root of a domain's namespace is
to be specified in the NSDB.  The answer was that that root is a
junction, and as such not to be specified by the I-Ds' conception of an
NSDB.  The conception of NSDB in these I-Ds doesn't seem to me to be
very useful.  What am I missing?

Consider the good old automounter.  It's a client-side, centralized,
not-easily-federatable technology.  But it does allow one to present a
unified (or multiple unified) namespace(s), because it does allow one to
"mount" filesets anywhere in the namespace.  The automounter achieves
that via "hierarchical automount map entries" and automount map entries
that mount automount maps.

My conception of an NSDB would be a federatable automount-like
server-side facility that defines actual namespaces.

I think it's crucial to add an object class to represent junctions.
Junctions consist, logically, of three items:

a) a fileset name,
b) a path relative to the root of (a),
c) the name of a fileset, and optionally a path relative to it, to mount
   on (b).

Here (a) and (b) together form the name of a junction object.

Finally, I believe that the NSDB, junction object class included, would
be much simplified by using LDAP in a more natural way.  E.g., UUIDs
would not be needed in object names, nor would the fedfsNsdbName
attribute be needed.  Plus it'd be easier to deploy with existing
directory infrastructures (folks who want to use separate directories
for the NSDB could, but they wouldn't be forced to).

Nico
--

---

From: "Everhart, Craig" <[email-masked]>
Date: Wed, 9 Sep 2009 17:30:23 -0400

Inline. 

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Wednesday, September 09, 2009 4:07 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [nfsv4] Review of draft-ietf-nfsv4-federated-fs-reqts-03
> 
> Upon request I have reviewed much of 
> draft-ietf-nfsv4-federated-fs- reqts-03.
> 
> I have a new, fundamental comment to make about the notion of 
> federated filesystem described in that I-D, as well as in 
> draft-ietf-nfsv4- federated-fs-protocol.  That comment follows.
> 
> The supposed namespace database (NSDB) does not actually 
> model junctions (mounts, whatever)!
> 
> Therefore the NSDB does not actually describe a namespace at 
> all.  It's just a collection of objects naming discrete 
> filesystems (excuse me,
> No wonder I couldn't figure out how the root of a domain's 
> namespace is to be specified in the NSDB.  The answer was 
> that that root is a junction, and as such not to be specified 
> by the I-Ds' conception of an NSDB.  The conception of NSDB 
> in these I-Ds doesn't seem to me to be very useful.  What am 
> I missing?

The NSDB, however named, is just intended to be a collection of mappings
from arbitrary keys to collections of fileset locations.  The idea is
that those arbitrary keys would be stored in parent filesets.

The idea here is to allow a parent fileset to refer to a child fileset,
but to have it be a soft mapping, interpreted through a database.  Thus,
the parent could be immutable, and the location of the child fileset
could change; the database could be updated with the changes.

But the parent fileset remains the source of the "namespace".

> Consider the good old automounter.  It's a client-side, 
> centralized, not-easily-federatable technology.  But it does 
> allow one to present a unified (or multiple unified) 
> namespace(s), because it does allow one to "mount" filesets 
> anywhere in the namespace.  The automounter achieves that via 
> "hierarchical automount map entries" and automount map 
> entries that mount automount maps.

Right.  This is different from the automounter.  And it, too, allows one
to present a unified namespace.  And that namespace happens to be
specified by the server side, not the client side or by automounter
maps.

> My conception of an NSDB would be a federatable 
> automount-like server-side facility that defines actual namespaces.
> 

In Fed-FS, the (b) component is already present, in the directories and
files of the parent fileset (a).  And the whole point of the NSDB, as
stated, is as a slightly abstracted version of (c).

In this formulation, the "junction" is most simply given as an object in
a parent fileset, one that contains or indicates the particular
"arbitrary key" used as the key for the NSDB lookup, coupled with some
identification of the NSDB service to be used.  One derives (a) as the
fileset in which the junction exists; (b) is the instantaneous pathname
of the junction object relative to the root of its fileset; and (c) is
the result when you execute the lookup of the "arbitrary key" in the
indicated NSDB.

> Finally, I believe that the NSDB, junction object class 
> included, would be much simplified by using LDAP in a more 
> natural way.  E.g., UUIDs would not be needed in object 
> names, nor would the fedfsNsdbName attribute be needed.  Plus 
> it'd be easier to deploy with existing directory 
> infrastructures (folks who want to use separate directories 

Now we're getting to what looks like the crux of the issue: what looks
most natural to LDAP.  But the fundamental thing Fed-FS is aiming at is
a filesystem-centric view of federation, not an LDAP-centric view.
After all, when I rename some element of the (b) path of some junction
in the federation, I want that change to be reflected in what clients
see, and I want them still to be able to navigate subsidiary junctions,
without updating all the LDAP directories in the NSDB.

Is there some better way to achieve that with LDAP?

> Nico

		Craig

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 9 Sep 2009 17:13:19 -0500

Rob Thurlow and I talked at length on the phone about this.

He explained to me why representing junctions in the NSDB is not
terribly useful, but he agreed that representing a small set of
junctions, all close to the domain root, in the NSDB makes sense -- and
evidently there is/was a document covering this.

You'll recall that I specifically asked about how domain roots are
defined in the NSDB.  The reason I asked is that it seems to me that
domain roots consisting of simple fs skeletons and sprinkled with
junctions would allow for heterogeneous roots.  Being able to use the
NSDB to replicate that structure and those junctions would be useful.

This addresses my fundamental issue with the NSDB.

That leaves the LDAP base DN issues.  I believe that there is a way to
address those.  I've a meeting tomorrow right before the fedfs concall;
if it ends early enough I'll join the fedfs concall and we'll discuss
the LDAP issues there.

Thanks,

Nico
--