Subject: RE: [nfsv4] Namespace terminology

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 16 Jan 2004 14:41:02 -0800

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

Right.  If you have a have an fs and a number of clients are accessing
it when it moves, then they will see a migration event.  I have not 
been referring to that sort of thing as a "referral".  However, there
may be other clients that did not reference that fs before it moved but
cross a mountpoint into it soon after it moves in which case they will
see a referral that will look exactly the same to them as a referral 
which happens because we cross into an fs that is absent and has never 
existed on the current server.  I call that latter a "pure referral"
but they both look the same to the client. 

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]]
Sent: Friday, January 16, 2004 5:25 PM
To: Ted Anderson
Cc: [email-masked]
Subject: Re: [nfsv4] Namespace terminology

On Thu, Jan 15, 2004 at 08:44:25AM -0500, Ted Anderson wrote:
> Here are some definitions for terms that have been used in this extended
> discussion.  I've tried to make the terms consistent with each other,
> and added some new ones, but I've borrowed text from the discussion
> liberally and without attribution.  There is some meta-discussion at the
> end.
> 
> 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.

 - It seems to me that sub-namespaces, or namespace fragments, can have
   multiple [path]names.

   See examples given earlier in the other thread.

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

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

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

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

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

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

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

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

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

> Do we need a better name for "LTE"?

Yes.  See above.

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

> 
> Additions, corrections, or reorganizational ideas are welcome.

Cheers,

Nico
-- 

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

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 30 Jan 2004 09:43:41 -0800

> > "Referral" refers to servers' use of the NFSv4 migration facility to
> > redirect a client in the process of crossing into a filesystem that does
> > not reside on the server it is talking to.
> > 
> > The distinction between "referral" and the rest of the NFSv4 migration
> > facility is about when the NFS4ERR_MOVED/GETATTR(fs_locations4) events
> > take place: a) "referral" -> before the client has acquired FH (much
> > less state) for a "migrated" resource, b) "migration" -> a resource the
> > client has an FH for, or even state, has actually moved.

Note that when a file system migrates, it may the case that some clients
see (a) and other clients see (b).  I think this is part of what is leading
to confusion.  I would describe this situation as a migration event in
which there is a referral of those clients in the (a)-situation.

> > 
> > In (a) the client doesn't know, and doesn't care, if the resource in
> > question ever actually did reside on the server doing the referral, and
> > it may not have, so one can hardly speak of migration (though referrals
> > are needed in order to support migration).

You can't speak of migration from those clients' point of view, but you
certainly can from the server's point of view and from the point of view
of the (b)-clients.

> Okay, maybe the problem is that I've been overzealous in defining names 
> for objects (even conceptual ones) and tried to force "referral" into 
> this scheme.

I don't think so.  

> However, I see that "referral" is the name for a process 
> that a server uses in connection with the verb "refer".  I think some 
> have used "referral" for (b), but perhaps we can just say that isn't 
> correct and not become confused.

I agree.

One problem is that the client and server views are not the same.  The server
can be doing a migration while one or more (or even all) clients see a 
referral.

>From the client's point of view, what is critical is whether he has seen an
FH for the filesystem in question.  That defines whether the client sees a
referral or a migration.  From the server's point of view, the critical fact
is whether the fs in question ever was on the server.  If it wasn't, then 
no clients can see a migration and all clients will see a referral.  I call
that situation, "pure referral" to distinguish it from migration from the 
server's point of view.

-----Original Message-----
From: Ted Anderson [mailto:[email-masked]]
Sent: Friday, January 30, 2004 12:14 PM
To: Nicolas Williams
Cc: [email-masked]
Subject: Re: [nfsv4] Namespace terminology

">" is On 1/30/2004 11:09, Nicolas Williams wrote:
">>" is On Fri, Jan 30, 2004 at 10:08:02AM -0500, Ted Anderson wrote:
">>>" On 1/16/2004 17:25, Nicolas Williams wrote:
">>>>" On Thu, Jan 15, 2004 at 08:44:25AM -0500, Ted Anderson wrote:

>>My concern about the automounter model is that it doesn't make any clear 
>>distinction between namespace junctions and location tables.
> 
> 
> But it does.
> 
> Here's the correspondence between automount concepts and what we've been
> discussing:
> 
>  automount feature		NFSv4 namespace feature
>  -----------------		-----------------------
> 
>  indirect map			sub-namespace config. DB
>  master map			namespace root for a domain
> 
>  "normal" indirect map entry	junction to a filesystem
>  map entry w/ -fstype=autofs	junction to another sub-namespace
> 
> ["normal" -> the -fstype option is set to "nfs" or not given]
> 
> Note that an indirect automount map can be referenced from multiple
> locations in the automount namespace (by using -fstype=autofs in
> automount entries, for example), which permits multiple paths to
> sub-namespaces, which we agree is good.

Okay this is good.  I gather that none of these examples actually 
include location information, those are in still other (non-indirect) maps.

>>                                                              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.
> 
> Check out:
> http://docs.sun.com/db/doc/816-0211/6m6nc66nc?a=view#automount-1m-indx-1

Thanks, I will.

>>I don't get your point here.  Are you arguing for the suitability of LTE 
>>as a name for this concept?
> 
> Well, first off I'm confused by "... conceptual mapping between a
> fragment and one or more physical locations where it is located."

I used the word "conceptual" here because the mapping might not actually 
use a table with entries be have some entirely different structure. 
However, maybe the term "mapping" should be viewed abstractly by itself.

> Second, "entry" indicates "table" or "database" to me, so "LTE" may be
> appropriate, but only in the context of a model of namespace
> configuration (which may well be what you had in mind and I just
> misread).

I think it may be what I had in mind, but I'm not quite sure if you mean 
more by "configuration" than just a table containing mappings.  I 
introduced this concept only to distinquish between namespace 
connections between "fragments" or "sub-namespaces" which I have been 
calling junctions, and the association between fragments/sub-namespaces 
and their locations.  Following Julian's usage I tried to make "map" 
refer just to the junctions and invented the term "location table" for 
the corresponding location information.  It seems like you prefer using 
"namespace" for "map" and "configuration" for "map" + "location table".

> https://www1.ietf.org/mail-archive/working-groups/nfsv4/current/msg00618.html

This exchange made sense to me.

> "Referral" refers to servers' use of the NFSv4 migration facility to
> redirect a client in the process of crossing into a filesystem that does
> not reside on the server it is talking to.
> 
> The distinction between "referral" and the rest of the NFSv4 migration
> facility is about when the NFS4ERR_MOVED/GETATTR(fs_locations4) events
> take place: a) "referral" -> before the client has acquired FH (much
> less state) for a "migrated" resource, b) "migration" -> a resource the
> client has an FH for, or even state, has actually moved.
> 
> In (a) the client doesn't know, and doesn't care, if the resource in
> question ever actually did reside on the server doing the referral, and
> it may not have, so one can hardly speak of migration (though referrals
> are needed in order to support migration).

Okay, maybe the problem is that I've been overzealous in defining names 
for objects (even conceptual ones) and tried to force "referral" into 
this scheme.  However, I see that "referral" is the name for a process 
that a server uses in connection with the verb "refer".  I think some 
have used "referral" for (b), but perhaps we can just say that isn't 
correct and not become confused.

>>You like sub-namespace better?
>
> Yes.  In particular it distinguishes the "root" of a domain's namespace,
> which I think is useful (see the "Namespace root server authorization"
> thread).

Okay.  I was thinking of a multi-level arrangement:
/gfs/ibm.com/ => the namespace for IBM's domain in Poughkeepsie
/gfs/ibm.com/research => a virtual directory within ibm.com
/gfs/ibm.com/research/almaden => another namespace hosted at Almaden
/gfs/ibm.com/research/hr => a namespace owned by HR dept in Research
/gfs/ibm.com/software => a namespace owned by Software Group
/gfs/ibm.com/hr => another virtual directory
/gfs/ibm.com/hr/us => a namespace hosted in Endicott
/gfs/ibm.com/hr/in => ditto, but in Bagalore

The part of the namespace hosted by ibm.com is a namespace fragment 
since it has authorization responsibility.  The namespace at 
/gfs/ibm.com/research/almaden is both a namespace and a sub-namespace. 
However, maybe it isn't too important to make this distinction.

Ted