Subject: Re: [nfsv4] Namespace terminology

From: Julian Satran <[email-masked]>
Date: Mon, 2 Feb 2004 15:13:53 +0200

[email-masked] wrote on 30/01/2004 17:08:02:

> Apologies for the delayed reply.
> 
> On 1/16/2004 17:25, Nicolas Williams wrote:
> > On Thu, Jan 15, 2004 at 08:44:25AM -0500, Ted Anderson wrote:
> >>fragment -- A sub-tree which is exported as an indivisible unit by a
> >>    server.  If the server is high in the namespace, this might be a
> >>    single directory containing nothing but referrals and hosted by an
> >>    LDAP database.  Lower in the namespace it would likely be a file
> >>    server's filesystem.  If the namespace supports file junctions 
then
> >>    a fragment might be as small as a single file.  Fragments have 
names
> >>    (possibly structured like pathnames) unique within each domain.
> > 
> >  - I've been calling this a "sub-namespace" -- I'm just as happy to 
use
> >    "namespace fragment," but "fragment" by itself seems insufficiently
> >    descriptive.
> 
> I agree.  I'm also open to some better term as well.
> 
> >  - It seems to me that sub-namespaces, or namespace fragments, can 
have
> >    multiple [path]names.
> > 
> >    See examples given earlier in the other thread.
> 
> Yes.
> 
> >  - Namespace fragments could also have multiple types of names, one 
type
> >    being pathnames (relative to other junctions or relative to a
> >    namespace root), another being more like automount map names.  The
> >    latter are often easier to reference.
> 
> I'm not clear exactly what automount map names are.  However, I agree
> that a fragment will have multiple types of names.  I'd call them
> "absolute pathnames", "relative (to another fragment) pathnames", and
> "fragment names".  The latter are arbitrary names (e.g.
> users.ota.backup), whose scope is local to a namespace domain.  This
> namespace domain becomes a qualifier for fragment names in junction 
> targets.  This qualifier might naturally default to the namespace domain 

> of the parent fragment, or could be specified explicitly.  In AFS terms 
> a namespace domain is a cell and junctions with an explicitly specified 
> domain are called cellular mountpoints.
> 
> >>junction -- a link between two fragments of the namespace that are
> >>    connected for the purposes of pathname traversal.  The fragment 
that
> >>    is the target of the junction replaces the junction in its parent
> >>    directory for purposes of file system operations; thus it operates
> >>    somewhat like symbolic links.
> > 
> >  - I'd say junctions are, conceptually and from users' perspectives,
> >    more like mounts than they are like symbolic links, though on the
> >    wire they look more like symbolic links.
> 
> Sure, but except for lstat() and unlink() symlinks are as invisible as 
> mounts to file system API users.
> 
> >>LTE -- (location table entry) the conceptual mapping between a 
fragment
> >>    and one or more physical locations where it is located.  Each
> >>    location is a URL(s) describing contact information for the server
> >>    exporting the fragment.
> > 
> >  - The word "entry" seems more appropriate to a concept directly 
linked
> >    to the directory.  Thus we could have "locations," "location 
tables"
> >    and "location table entries."
> 
> I don't get your point here.  Are you arguing for the suitability of LTE 

> as a name for this concept?
> 
> >>referral -- a combination of a junction and an LTE.  Thus a referral
> >>    maps a pathname to a physical location(s).  An NFSv4 client sees
> >>    referrals while the NFSv4 server sees junctions and LTEs.
> > 
> >  - This seems too simplified to me because:
> > 
> >     - A server may issue referrals as a result of namespace junctions,
> >       but it may also issue referrals as a result of FS migration.
> > 
> >     - A server need not issue a referral to clients crossing a 
namespace
> >       junction if the server is a location for both sides of the
> >       junction.
> 
> Okay.  This is a result of the complicated (and confusing) use of the 
> term "referral" on the mailing list.  Interestingly the term does not 
> appear in  RFC3530.  Maybe it would be better to define the word 
> explicitly to be some clear subset of its current (de facto) meaning and 

> select other terms for other aspects of its meaning.  This would seem 
> preferable to defining it as "that thing that NFSv4 servers do in this 
> list of situations".
> 

I agree that two different names should be used for migration and 
"entering a different realm"

> >>map -- the representation, perhaps stored in a database or 
configuration
> >>    file, of the connections between fragments.  The global map is
> >>    composed of many individual maps that point to each other in a
> >>    directed graph.  A map defines a domain of the namespace. (Because
> >>    these maps will be managed by many different entities, there is
> >>    little hope for guaranteeing acyclicity.  Clients of the namespace
> >>    will just have to cope.)  A domain's namespace map is supplemented
> >>    by a location table.
> >
> >  - I think, in the end, that there wil be no such thing as a "global
> >    namespace" or "global map" anymore than sysadmins allow it, for 
which
> >    reason I'd rather speak as little of it as possible and instead 
focus
> >    on per-administrative domain namespaces and the mechanisms by which
> >    the locations of those are determined -- given which a global
> >    namespace can follow trivially.  The point about cross-domain
> >    references and cycles is very important to make, however, the one
> >    being necessary to make a global namespace a better experience and
> >    the other being a result of the first.
> 
> I agree with this.  The concept of a global map may be useful in 
> explaining the namespace to users, but operationally it basically a 
fiction.

I am also in doubt of how useful it will be. But it would do no harm to 
align a default structure with the (reverse) DNS names so that the 
administrative domains could be named too. This may entice the 
administrators to use some regularity in the subtree (fragment) 
structuring too. Thus the ietf domain will have:

org.ietf.rfc/
org.ietf.drafts/
 
> >>location table -- tracks the location(s) of each fragment in the 
domain.
> >>    The location table is a list of LTE(s) keyed by fragment name.
> > 
> >  - I see the sub-namespace name as the name of the table, not the name
> >    of the entries in the table.
> 
> I think we agree the definitions of sub-namespace and fragment are the 
> same.  Then I mean a location table to look like this, one LTE per line:
>      ...
>      users.nico => mercury.acm.org
>      users.ota => venus.acm.org
>      software.X11r6.x86 => mars.acm.org, jupiter.acm.org
>      ...
> So there would be one table per server administrative domain (which 
> would often be one-to-one with namespace domains).
> 

I think it is critical to have ONE table per administrative domain - and 
that is in contrast to the automount tables that are client data structure 
and uniformity is at best voluntary. This does go to say that a client 
can't have ways to override the "uniform global structure" - it only says 
that the global structure must exist.

> >>filesystem -- a fragment that is stored in a file system and accessed 
by
> >>    a file server.
> >>
> >>virtual directory -- directories in fragments that contain only other
> >>    virtual directories and junctions.  Generally, a namespace server
> >>    will render a map stored in a database (e.g. LDAP) as a tree of
> >>    virtual directories.  The NFSv4 server's pseudo filesystem glues
> >>    together exported filesystems using virtual directories.
> > 
> >  - I'm not sure that this is necessary.  This restriction is common to
> >    "indirect" automount maps, but it isn't obvious that it must remain
> >    in a referral-based namespace.
> 
> I don't mean it as a restriction.  I may have confused things with the 
> reference to NFSv4's pseudo-fs.  Its directories are invisible to users 
> and used only by clients to navigate to exported filesystems.  For 
> virtual directories, I meant to describe a directory, high in the 
> namespace, that contains no files but only other virtual directories and 

> junctions and may be hosted by an LDAP database not a file system.  They 

> are virtual in that the underlying (database) representation might not 
> contain directories but only lists of junctions identified by fragment 
> names and relative pathnames.  However, they would be directories in the 

> sense that a user could "cd" to them and "ls" in them.
> 
> >    I've been thinking of the schema modelling for namespace
> >    configuration lately and the automounter model keeps coming up as a
> >    reasonably straightforward one that can, with few changes, model 
most
> >    of what we've been discussing.
> > 
> >    I'm particularly interested in making sure that whatever model we
> >    choose is workable for both, smart-clients and
> >    dumb-clients/smart-servers.
> 
> My concern about the automounter model is that it doesn't make any clear 

> distinction between namespace junctions and location tables.  But I have 

> no operational experience with automounter and my academic experience is 

> quite limited.  My reference for the automounter is Callaghan's "NFS 
> Illustrated".  I can well imagine that this isn't the best source. 
> Could you recommend a guide for understanding this system, which I 
> realized is not just a single system.
> 
> >>/net -- The Solaris automounter (and others) has an option to mount 
the
> >>    host namespace on some mountpoint (typically "/net") such that the
> >>    next path component down is a hostname and down from there there's
> >>    the exports or pseudo filesystem of the host in question.  Thus we
> >>    have: "/net/somehost/someshare/somepath".  This makes "net" 
(stored
> >>    in DNS) and "somehost" (stored in somehost's mtab) virtual
> >>    directories.
> >
> >  - The Solaris terminology for this is "the -hosts special map."  In 
the
> >    context of a global namespace composed of per-domain namespace I 
can
> >    also imagine a "-domains special map."
> 
> Exactly.
> 

I have to iterate that the issue I have with this model is that the map is 
a client map
and a client has no reference to a global map. This creates a deployment 
conundrum.

> >>DISCUSSION
> >>
> >>Should we try to find a better name for "fragments"?  It is a pretty
> >>generic term, but "namespace fragment" is clear enough though long.
> > 
> > Yes.  See above.
> 
> You like sub-namespace better?
> 
> >>Do we need a better name for "LTE"?
> >
> > Yes.  See above.
> 
> I didn't get your suggested alternative for LTE.
> 
> >>We could redefine "referral" to mean "LTE" instead of the collective
> >>"junction" + "LTE".  But this might be confusing and lead to
> >>misunderstandings, as it is already heavily used in this discussion
> >>(though not in RFC3530).
> > 
> > No.
> > 
> >>The term "map" comes by extension from automounter maps.  It is very
> >>generic and should be used as "namespace map" to disambiguate.  Should
> >
> > Fortunately the term maps nicely to the notion of namespace junctions.
> > See above.
> >
> >>we dispose of this term and use something like namespace domain or
> >>namespace database depending on circumstances?  By analogy with the
> >>automounter, perhaps "map" should be expanded to include "location
> >>table", however, this didn't seem to be implied by the original usage
> >>(by Julian on 21-Dec-2003).  In other words, should we say that a 
"map"
> >>is "namespace table" + "location table"?
> >
> > The term maps to a concept of a per-namespace junction sub-namespace
> > configuration database.
> 
> Ted
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4

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