Subject: RE: [nfsv4] Global namespace for v4.1?

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 12 Jan 2004 10:48:45 -0800

I'm going to do a rainbow reset, leaving most of the history in the section below.
 
I already agreed that appropriate granules may simplify some implementations (although AFS is a good proof to the contrary!). 
I am afraid however that I do not agree to the assumption that different fss will surface wildly different semantics. 
 
That's not my assumption.  I think that as a practical matter there will be a large group of servers that will have a good reason to maintain common semantics and will attempt to do so on an ad-hoc basis, most of the time being relatively successful.  Nevertheless, the spec takes the position it does for a reason, which I think is that defining those common semantics with the requisite specificity in a formal document and getting agrement on them is, to say the least, a non-trivial task, i.e. everybody was too lazy to take this on and I'm no exception.
 
Having a global namespace without basic semantic assumtions is hardly acceptable. 
 
Yup.
 
You do not expect clients to be aware of the semantic difference?
 
I do expect them to be aware of the semantic differences.  If two files are within the same fs, then the threshhold for semantic identity that they have to meet is high.  And getting people to specify that and agree to is just (a whole lot of) work.

I guess that the only thing I am looking for  a "single global map" - i.e. besides the export "fragments" present in present NFSV4 a map of all those fragments being the same for all participating servers. It can be exported by a limited subset of servers (at least 2 for redundancy) with some simple decision rules if the maps do not agree.
 
Then maybe we don't disagree.  I had understood that there was a disagreement about the granularity of that map, i.e. that the units are mapping are seen at the protocol level as filesystems.  This simplifies the clients' perception of fs semantic differences (and therefore the urgency of providing identical semantics) and also allows us to avoid such issues as fileid space mapping in that when you have multiple client-visible fs's, you have separate fileid spaces with no extra work.
 
One disagreement that I have with a "single global map" (but expect is not an issue between us) is that I don't think you will have a single common global map (scalability issues) but I set of co-ordinated maps each with an approriate level of redundancy.  For example, I can see a global map for /nfsv4 (let's say) for which the entry for /nfsv4/com/netapp would take you to another set of (less)-global mapping servers and so on.  I expect that that is OK with you as well.

With the scheme I suggested above any client will mount the same global structure wherever it sees fit but the global structure is guaranteed to be unique. 
This will include only "global" fragments. Also the map may use only art of the exported fragments - namely those forming the global space.
 
I don't have anything to disagree with there.

The scheme I suggested can be summed up in a page or two (no need for the 7 pages of overhead). Unfortunately I don't feel qualified to do it (I will have to get acquainted with many of the NFSV4 detail). But if nobody else comes forward...
 
We haven't been exactly deluged by volunteers in this area :-( 

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Monday, January 12, 2004 9:26 AM
To: Noveck, Dave
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [nfsv4] Global namespace for v4.1?

filling the rainbow - Julo 

"Noveck, Dave" <[email-masked]> 

30/12/2003 17:23 

To
Julian Satran/Haifa/IBM@IBMIL 

cc
<[email-masked]>, <[email-masked]>, <[email-masked]> 

Subject
RE: [nfsv4] Global namespace for v4.1?

Same color (in italics ) for me. 

"Noveck, Dave" <[email-masked]> wrote on 22/12/2003 17:07:34:

> 
> 
> 
> > It is not the granularity that I am after. I could live with directories
> > or even subtrees.
> 
> OK, glad to hear it.
> 
> I was going by your statements:
> 
> > IMHO a good global namespace should be imposed without artificially 
> restricting 
> > the way components are placed. 
> 
> > It should also not have (or not have it standardized) a mapping to 
> local namespaces. 
> > I.E., in theory a file in the global namespace may be located anywhere.
>  
> > Probably you may want to restrict this to directories but you should not go 
> > beyond this. 
> 
> >From which I concluded that the current v4 model, which made fs's (significant
> trees) the unit of migration and referral, was not acceptable to you.
> 
> > The thing that I am concerned about is that building a global map based on an 
> > "arbitrary" composition of local maps will not get you the transparency that 
> > every enterprise is looking for - location transparency, migration 
> transparency, 
> > replication transparency. Transparency is what will keep applications and 
> > administration separate. 
> 
> Maybe I'm not understanding the problem you are worried about.  As far as what
> I have proposed, each fs can be at an arbitrary position within the namespace,
> and that typically will not depend on the server or servers on which the fs is 
> currently hosted.  Does that address your concern?
> 
Arbitrary in reference to what? If it is in a fixed position in the global namespace that addresses my concern. 
Arbitrary with respect to its position in the local namespace of the server hosting it.  My understand of your concern was what you were worried that there was some sort binding between the local name and the position in the global namespace and I don't think anyone is proposing that there is. 

> > As for teleport - I never though about AFS in those terms (should I have?).
> 
> I don't know AFS well enough to understand how it deals with the granularity
> issue.  I know there is a global namespace but is it the case that directories
> within it can be arbitrarily located and still manipulated as if they were
> within a single fs?  If so, then it does seem to me kind of science-fictional 
> and something that is rather distant, in the context of a protocol like NFS 
> where multiple separately-derived implementations need to interoperate.
> 
Not necessarily - in AFS the "local names" in the local filespace have no relevance to the global names 
However the same effect could be achieved with "bigger granules".  Interoperability - I am not aware of any interopearbility issues that become simpler by that or another choice of building the global tree. 
Let me  try again.  If your granules are visible to clients as file systems, then interoperability becomes a matter of the server providing some version of acceptable v4 semantics and the client being able to do that.  If you have granules that are smaller than that, in that a client sees two files or directories on different servers as part of the same fs, then the ante on interoperability goes up quite a bit.  For better or worse, v4 allows different servers to implement their own fs semantics (within limits) and takles the position that it is not the jobof the protocol to impose a semantic uniformity, but merely to provide remote access to the fs semantics exported by the server.   Further, an action like renaming a directory on one server between two parent directories on two different servers becomes very interesting if we have to test with the possible range of implementations of client, target directory server, source parent directory server, destination parent directory server. 
I already agreed that appropriate granules may simplify some implementations (although AFS is a good proof to the contrary!). 
I am afraid however that I do not agree to the assumption that different fss will surface wildly different semantics. Having a global namespace without basic semantic assumtions is hardly acceptable. You do not expect clients to be aware of the semantic difference? 

As any decent implementation will use some form of name caching any local naming action is bound to have global effects. As for semantic uniformity I am not sure that I understand or agree. The naming structures and rules have to be uniform over the global space for it to be really useful (you are not suggesting changing character casing rules or name lengths when crossing implementation boundaries). 

I am not suggesting that such variability would be a good thing or something that I would implement in a global namespace.  The problem is precisely how to prevent it.  V4 servers may implement case-sensitive or case-insensitive naming (and it allows servers to refuse to rename open files, or to allow that, etc.)  That kind of variability wouldn't be my choice but it was the choice of the working group.  If you have a global namespace which is fine-grained (i.e. the distribution units are smaller than a file-system), then this is an issue that you have to address, somehow and it is one of many in which the definition of v4, by allowing servers different semantic choices, complicates the implementation of a fine-grained global namespace.  It is one of many issues that one needs to address. if you want to go down this route. 
  
 I think that a clear set of export rules a global namespace constructors will simplify interoperability not complicate it and an attempt to build something that is no more that the chain of mounts in previous versions is not very useful. 
If you can define such rules, and the group agress to them within a reasonable time, then that would be great, but I fear that it may be quite difficult.  As far as the usefulness of something more limited and coarse-grained, I guess we just disagree.  I'm willing to settle for something not as good, that I know can be built, without confronting some basic issues in v4.  I think the result is still quite useful. 

I guess that the only thing I am looking for  a "single global map" - i.e. besides the export "fragments" present in present NFSV4 a map of all those fragments being the same for all participating servers. It can be exported by a limited subset of servers (at least 2 for redundancy) with some simple decision rules if the maps do not agree.
------------------- 

If you limit yourself to referrals servers or the referal-servers will have to guarantee the "unique" structure of the global name-space. 
Don't know what you mean here. 
My understanding is that you will use referrals wherever you reach a "mount point". Those could be different on each sever (or you have to replicate on all or use a separate global name/referral server. 

There are two classes of referrals here to deal with.  The first is those that are referrals from mount points within a real filesystem (i.e. a filesystem that has real files within it and not only directories that lead to referrals).  For this class, you only have a consistency issue when the filesystem in question is replicated and I would presume that the identity of the referral will be assimilated to the general issue of the identity of the data within the individual replicas of the replicated fs.  There has been in the past some discussion of a v4 server-to-server migration and replication protocol to allow such replicas to be co-ordinated, even among different types of servers, but there has been no progress on that recently.  Without that, replication is going to be implemented individually and it is the responsibility of the servers implementing the repllicas to keep them the same including the same referrals.  As a practical matter, the server implementations must be the same. 
  
The second class of referrals are those in what we might call global pseudo-fs's, which implement fs's devoted to providing a global or enterprise-wide or site-wide namespace, by means of a set f referrals within the fs.  Today, we are in a similar situation to the first case in that only implementaton-specific replication is available.  My assumption is that work will proceed on a naming service definition (LDAP or whatever) and then referral servers or referral fs implementatins will fetch data from a common name service with multiple server sproviding the same data sicne they are obtaining them from the same source (issues of dealing with stale data from the name service as configutations are changing is left as an exercise for the I-D writer). 

With the scheme I suggested above any client will mount the same global structure wherever it sees fit but the global structure is guaranteed to be unique. 
This will include only "global" fragments. Also the map may use only art of the exported fragments - namely those forming the global space.

> The v4 approach relies, for its simplicity, on the fact that the separately
> located subtrees are separate fs's and thus you cannot link files between them,
> move directories between them, etc.  That's why I characterized that 
> as "walking",
> i.e. something we know how to do, can be done within the bounds of RFC3530,
> albeit with a number of rough edges, and only requires that we travel the
> road laid out for us, putting one foot in front of the other.
> 
I am not sure that I would characterize moving directories as a bad thing

I wouldn't characterize it as a bad thing, either.  I would however, characterize it as a difficult thing when the participating directories are in different servers.  If people want this functionality badly enough, then the people in this group will work to provide it but it would not be easy.  So maybe this indicates that perhaps "teleportation" is the wrong metaphor.  Maybe a better analogy would be a controlled fusion power reactor.  The basic physics is understood and it is just a matter of figuring out the engineering of confining a plasma at the appropriate temperatures and pressures.  It's just work and money and time. 

You seem to suggest that it will never work (or it will take as long as fusion power). But AFS was (is) here for a long time and people love it 
  
It works in the context of AFS, and that's fine.  Making it work in the context of NFS presents a whole different set of challenges.  To stretch my analogy a bit more (probably to or beyond the breaking point), the sun has been here for a long time and people love it and it produces power from thermonuclear fusion with no problem. The problem is transferring that form of power production to an environment in which a strong gravitational field is not available to neatly solve the confinement problem.  There are lots of things that AFS can do easily that NFS has difficulty doing.  We want to retain NFS's basic structure ot modify it incrementally.  This imposes constraints on our ability to get some of the desirable features of AFS into NFS, as much as we'd like them. 
  
Perhaps I'm being unduly pessimistic.  My perception of the difficulty is basically a reflection of the fact that I don't know how to do this.  If you (or someone else) knows how to do this within the constraints of NFS (making only moderate changes to NFS, or making radical changes and convincing the working group as a whole that these are justified) , then I would love to see an I-D explaining how to do this.   I think doing this on fine-grained basis is very difficult and that we are going to have enough work handling a global namespace on an fs granularity basis.  However, I would be quite happy to be proved wrong. 
  
 The scheme I suggested can be summed up in a page or two (no need for the 7 pages of overhead). Unfortunately I don't feel qualified to do it (I will have to get acquainted with many of the NFSV4 detail). But if nobody else comes forward...

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 12 Jan 2004 15:31:57 -0600

On Mon, Jan 12, 2004 at 10:48:45AM -0800, Noveck, Dave wrote:
> One disagreement that I have with a "single global map" (but expect is
> not an issue between us) is that I don't think you will have a single
> common global map (scalability issues) but I set of co-ordinated maps
> each with an approriate level of redundancy.  For example, I can see a
> global map for /nfsv4 (let's say) for which the entry for
> /nfsv4/com/netapp would take you to another set of (less)-global mapping
> servers and so on.  I expect that that is OK with you as well.

Without some sort of domain-based hierarchy we certainly can't make this
happen.

What I envision is that some commonly-agreed-to path from any one
domain's namespace root will lead to referrals to other domains'
namespace roots.

Gee, something like /net, but called something else if you wish :)

/nfsv4/domains/netapp.com/... <---- netapp.com's domain namespace
/nfsv4/hosts/nfs.ietf.org/... <---- nfs.ietf.org's local namespace

Note that I can see a sub-namespace being spliced in in multiple
locations, e.g.,

/nfsv4/domains/ietf.org/liasons/itu-t.org/... <--- referral to ITU-T's namespace

Each domain's admins would be free to turn this off, or to limit what
other domains' namespaces are visible in this way.  Again, much as with
/net.

> With the scheme I suggested above any client will mount the same global
> structure wherever it sees fit but the global structure is guaranteed to
> be unique.  This will include only "global" fragments. Also the map may
> use only art of the exported fragments - namely those forming the global
> space.
> 

Me either.

Nico
-- 

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

---

From: Julian Satran <[email-masked]>
Date: Tue, 13 Jan 2004 14:49:20 +0200

This sounds right to me. Julo

Nicolas Williams <[email-masked]> 
12/01/2004 23:31

To
"Noveck, Dave" <[email-masked]>
cc
Julian Satran/Haifa/IBM@IBMIL, [email-masked], [email-masked], 
[email-masked]
Subject
Re: [nfsv4] Global namespace for v4.1?

/nfsv4/domains/ietf.org/liasons/itu-t.org/... <--- referral to ITU-T's 
namespace

Me either.

Nico
--

---

From: Ted Anderson <[email-masked]>
Date: Tue, 13 Jan 2004 09:15:43 -0500

> I'm going to do a rainbow reset, leaving most of the history in the 

Thanks, I'm glad we're back to something that can be followed in plain text.

 > On 1/12/2004 9:26, [email-masked] wrote:
 > > I guess that the only thing I am looking for a "single global map" -
 > > i.e. besides the export "fragments" present in present NFSV4 a map
 > > of all those fragments being the same for all participating
 > > servers. It can be exported by a limited subset of servers (at least
 > > 2 for redundancy) with some simple decision rules if the maps do not
 > > agree.
>  

Right.  The single global map is really a collection of separate maps 
maintained by each namespace owner.  Each owner of a section of the 
namespace may delegate ownership to a lower section by pointing to 
another server.  This pointing is accomplished by the part of the 
referral I've been calling a (namespace) junction.  This namespace 
ownership delegation model works fine until you get to the root.  At 
that point I think we have to rely on convention, configuration and DNS 
to get the global namespace bootstrapped into existence.

I would like to make sure we all understand the terminology.  I take 
Julian's term "fragment" to mean any sub-tree which is exported as a 
unit by a server.  If the server is high in the namespace, this might be 
a single directory containing nothing but referrals hosted by an LDAP 
database.  Lower in the namespace it would likely be a file server's 
filesystem.  Is this right?

I guess the term "map" comes by extension from automounter maps.  A map 
is the representation, perhaps stored in a database or configuration 
file, of the connections between fragments.  As mentioned above, it 
seems clear that there will be many individual maps that point to each 
other in a directed graph.  (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.)  So calling a global 
map "single" or "unique" is a bit confusing.  Perhaps these words are to 
emphasize that there is a global namespace in which everyone 
participates, not lots of disjoint namespaces that have international scope.

> > With the scheme I suggested above any client will mount the same
> > global structure wherever it sees fit but the global structure is
> > guaranteed to be unique. This will include only "global"
> > fragments. Also the map may use only art of the exported fragments -
> > namely those forming the global space.
>  

I'm not sure how a "global" fragment differs from some other kind, 
except that maybe it has a connection to the root ("backwards" against 
the flow of the directed edges, to use graph terminology).

> The scheme I suggested can be summed up in a page or two (no need for 
> the 7 pages of overhead). Unfortunately I don't feel qualified to do it 
> (I will have to get acquainted with many of the NFSV4 detail). But if 
> nobody else comes forward...
>  

Maybe I will be able to volunteer soon, however, I have doubts about the 
estimated length.

I imagine there would be at least two parts.  One would be file system 
agnostic, describing general properties of the namespace.  It would 
define terms, as I've been trying to do lately, and say a little about 
the semantics of the namespace itself.  As we've noted here the 
semantics are important for interoperability but difficult to pin down. 
  The question of the root would have to be addressed, this is a hard 
one both because of the ownership issues mentioned above and because of 
the conceptual importance of the top level layout.

The second part would address NFSv4 realization of the namespace. 
Mostly this would concern what the NFSv4 client's role is, the meaning 
of fs_locations, which attributes apply to referrals, etc.  It would 
also describe how top levels of the namespace are rendered by NFSv4 
servers to their clients.  Other parts could address realization by 
CIFS, HTTP, and other protocols.

Ted

---

From: Ted Anderson <[email-masked]>
Date: Tue, 13 Jan 2004 10:36:38 -0500

To keep the namespace discussion easier, I'd be inclined to defer trying 
to reach agreement on the actual namespace layout for now.  Agreeing on 
the architecture, semantics and mechanisms will be hard enough.

However, we probably can't ignore the problem entirely and having some 
concrete examples in mind will help understand and communicate about the 
other issues.

> Without some sort of domain-based hierarchy we certainly can't make this

No disagreement here.

> domain's namespace root will lead to referrals to other domains'

This seems backwards to me.  Probably due to my background with type 1 
clients (i.e. clients that do the namespace heavy-lifting instead of the 
servers doing it, namely AFS), I think of the namespace from the 
client's perspective and as clients mostly outside any domain.  There is 
some justification for this, pathnames are user visible, contain domain 
information and are often shared between users in different domains. 
Also the Grid concept of virtual organizations envisions entities that 
have fluid relationships with multiple domains.

I think that the root of the namespace should be "above" all the domains 
which own various sub-trees.  But maybe what you are saying is not that 
different as long as each "domain's namespace root" looks the same.

> Gee, something like /net, but called something else if you wish :)

I am not familiar with /net, at least, not under that name. :)

> /nfsv4/hosts/nfs.ietf.org/... <---- nfs.ietf.org's local namespace

The problem with having namespaces for hosts, is that they aren't 
location independent.  What if you want to retire the host, or combine 
it with another machine, or the DNS administators at your site come up 
with another host naming scheme?  Do those parts of the namespace 
suddenly get new names?  Ideally not.  So while I can imagine many cases 
where host-based names are expedient or necessary I don't think the 
concept should be enshrined at the top of the global namespace.

> other domains' namespaces are visible in this way.  Again, much as with

I don't think the local domain (or the local domain's servers delivering 
the namespace to client) should meddle with other domain's namespace.

I feel as if I'm seeing / expressing more disagreement that we really 
have here, but I don't understand your underlying model very well and 
the examples you give here look strange (at least to my AFS eyes).

My thinking is that the namespace root should contain three types of 
names: machine-local, domain-local and global.  The machine-local names 
include (storage) resources that are private and local.  The 
domain-local portion includes resources that are shared but which are 
specific to the domain. Conceivably, there might be several concentric 
domain-local names.  Mostly data is global.  Ideally much domain data is 
addressed using global names and protected with access control, so the 
domain-local portion of the namespace can be very limited.  For example,

/gfs/...               <-- global file system
/gfs/netapp.com/...    <-- NetApp's portion of the global namespace
/gfs/ietf.org/...      <-- etc.
/ibm/hr/handbook/...   <-- IBM's intranet, employee handbook
/almaden/site/printcap <-- IBM Almaden's intranet, printer locations
/...                   <-- everything else is on the local machine.

Note that the domain-local examples don't seem very compelling, at least 
to me, the Almaden printcap file could just as well be under 
/gfs/ibm.com/almaden/site, but probably there are better examples.

Ted Anderson

---

From: Julian Satran <[email-masked]>
Date: Tue, 13 Jan 2004 17:59:17 +0200

> to get the global namespace bootstrapped into existence.

The problem is that if you rely on referrals - each server can build it's 
own referrals.
Instead of referrals we can use just one global map (name definition list) 
that admittedly may have some parts missing for some clients.

> filesystem.  Is this right?

Right. This seems to be a scheme NFS4 implementers can live with - and I 
am ready to give up the cleaner AFS approach in which a fragment can be a 
file.

> participates, not lots of disjoint namespaces that have international 
scope.
The trouble with the automounter scheme is that each client can create 
it's own automounter map and you end up with something that is far from 
one global namespace.

> CIFS, HTTP, and other protocols.

Ted you can count me in for a small time fragment. Wouldn't it be neat to 
start from an existing namespace structure?

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 Jan 2004 11:08:19 -0600

> The problem is that if you rely on referrals - each server can build it's 

True.  I've mentioned this before myself.  I am, nonetheless, willing,
eager even, to take a middle of the road position that allows the
namespace to be built mostly with referrals.

In my view we need to make sure that domain-wide namespace root servers
are authorized to dish out those roots and associated referrals, and for
the rest clients will have to trust those namespace root servers to
issue referrals only to other NFS servers which can be trusted to not
lie about the sub-namespaces delegated to them.

Which is why I harped earlier in this thread about the need to address
the root finding problem.  It's also why I mentioned domain-based
principal naming, since domain-based principal naming would allow the
server authentication and authorization steps to be performed together
and with no additional protocols being necessary for the authorization
step.

> that admittedly may have some parts missing for some clients.

Can't be _one_ map -- it could be one map per-domain though.

But since I think we can solve the root server authorization problem
easily I'd rather do that than leave client-side automounting as the
only way to effect a namespace.

[...]
> it's own automounter map and you end up with something that is far from 

I have absolutely no problem with clients being able to locally override
domain-wide configuration information, _provided_ that that's what
sysadmins want.  Or, in other words, we need to give sysadmins both, the
power to enforce domain-wide policies on clients and exceptions/override
mechanisms.  I say this from experience -- legacy being a common cause
of local overrides.

[...]
> start from an existing namespace structure?

Yes and no.  I think that the actual looks, aesthetics, if you wish, of
the namespace can be addressed separately from the mechanism used to
instantiate a namespace which, in turn, can be addressed separately from
how the namespace configuration information is modelled in the
directory.

Further, I think some aspects of the looks of a namespace as
instantiated on a client may be out of scope for this WG.  Assume we
have per-domain namespaces and a global namespace built from that, then
answer this: who are we to say where in a client's local namespace these
namespaces should be mounted?

In these examples:

/nfsv4/domains/ietf.org/RFCs
/nfsv4/domains/ietf.org/...
/nfsv4/hosts/nfs.ietf.org/...

I see the "/nfsv4" prefix as being part of the client's local namespace,
and it could just as well be "/nfs," "/cifs," "/fs," "/foo" and so on.
And I don't see why, or how, this WG can do anything stronger on this
than to issue a recommendation on that matter (if for no other reason
than that we can't guarantee that such paths are available on all
clients, or even at all possible on all existing and/or future
platforms).

Nico
--

---

From: Brent Callaghan <[email-masked]>
Date: Tue, 13 Jan 2004 09:46:53 -0800

> lie about the sub-namespaces delegated to them.

I hate to belabour a point, but if the client interacts directly
with the name service (rather than through an NFSv4 server intermediary)
then there is no new "root server authorization" problem to solve.

Those clients that are already using a secure name service (e.g. LDAP or
Active Directory) have previously authenticated the provider of the service
and rely on it to provide lots of other enterprise data.

Data for a global filesystem name service is just an add-on.

	Brent

---

From: Brent Callaghan <[email-masked]>
Date: Tue, 13 Jan 2004 10:03:54 -0800

Nicolas Williams wrote:
> :
> Since, IMO, we must accept the primacy of the client-local namespace I'd
> rather not discuss this too much and focus, instead, on how to construct
> [on the wire] the domain-wide namespaces and namespace location and let
> the clients be responsible for gluing the NFS v4 namespace onto their
> corresponding client-local access points.

Yes, customers already use global namespaces of their own making, and
are very protective of them.  In my experience, they react strongly to
external opinions as to the structure of a global namespace.  For instance,
the notion of a single, well-known root, e.g. "/gfs" does not appeal to
those who are already using paths like "/afs", "/net" or "/usr/local"
in a global way.

Neither can you paper over an imposed structure with symbolic links.
As much as we might think symlinks are transparent - they are not, e.g.
fire up some application GUI file chooser and instead of a friendly
"/home/brent" path you see instead "/gfs/northcentral.eng/dctwg-all/mumblyfrotz/brent".
Not good.

Let's not get bogged down in deciding the naming structure that *we* want.
Let's give customers something flexible enough that let's them build
what *they* want.

	Brent

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 Jan 2004 11:26:41 -0600

> concrete examples in mind will help understand and communicate about the 

Agreed.

[...]
> different as long as each "domain's namespace root" looks the same.

;)

> I am not familiar with /net, at least, not under that name. :)

The Solaris automounter (and others) has an option to mount the host
namespace on some mountpoint, typpically "/net" such that the next path
component down is a hostname and down from there there's the exports or
virtual fs of the host in question.  Thus we have:

/net/somehost/someshare/somepath

for any host that exports NFS shares.

> concept should be enshrined at the top of the global namespace.

No matter.  The hosts automount is extremely useful and customers want
it, in spite of the faults you raise.

> the namespace to client) should meddle with other domain's namespace.

In practice users tend to have a certain fs hierarchy that they are used
to and wish to preserve.  Usually they can achieve this by having
symlinks (or automount magic) to layer the view they are used to onto
their domain's namespace.  This is what I was addressing, and one way
for users to address this is to glue their local domain's namespace, or
a sub-namespace thereof, onto some expected place.  Perhaps it was too
early to address this, but if I hadn't mentioned it someone else would
have asked about it :)

I don't think we disagree on the fundamentals here.

> the examples you give here look strange (at least to my AFS eyes).

They derive from my experience with a real world large environment that
used NFS, not AFS, and had a very custom namespace.

[...]
> /...                   <-- everything else is on the local machine.

Yes, this is fine and what I imagine also, though I can also imagine
this:

/gfs/sun.com/standards/RFCs -> [referral to ietf.org sub-namespace]

> /gfs/ibm.com/almaden/site, but probably there are better examples.

Remember, this is new stuff and today users of NFSv2/3 w/ automounters
have only domain-local namespaces and legacy will dictate that these
remain as accessible when v4 is rolled out as they used to be.

In practice clients could implement legacy domain-local paths as
symlinks into the global namespace or by explicitly mounting a
sub-namespace outside the conventional global namespace, so that:

/ibm/...

could be implemented as a symlink to /gfs/ibm.com/..., or by mounting
the IBM namespace onto /ibm/.

(We need to agree on some terminology here also -- we're making some up
as we go.)

Cheers,

Nico
--

---

From: Skottie Miller <[email-masked]>
Date: Tue, 13 Jan 2004 10:55:33 -0800

> those who are already using paths like "/afs", "/net" or "/usr/local"

As a customer, I'd like to chim in here.

We currently have a global namespace, implemented via autofs with maps
delivered via LDAP.  This namespace is multi-site, and abstracts 20 file
servers and 16 NFS caches into a set of file paths that work on all the
clients.

The namespace co-exists with the client local-disk namespace, and is
anchored at "/".  the NFS branches of this namespace are are implemented
as top-level automounts, anchored at (e.g.)
/studio/MOVIEA
/studio/MOVIEB
...

the current implementation reflects limitations of client automounters,
but it has one important trait: it works for us, and solves our need.

Not only are we protective of this namespace, our applications, data,
users and system managment tools have come to depend on them.  To reinforce
your point: If migrating to NFS v4 required me to change the existing namespace,
we *would* *not* ever migrate. it'd be too disruptive.

And to address some points in:

Jim Rees wrote:

> Can we please refrain from using v3 terms like "automounter" and "map?"  I
> don't know what these mean.

You can't ignore v2 & v3 when looking at v4.  It would be impossible for me
to migrate our whole infrastructure to NFSv4 at the same time.  As with the
adption of any new technology, it needs to co-exist with my existing stuff
until we're comfortable, and then we'd transition over time.

so, since v2, v3 & v4 need to co-exist, and since the transition will
take time, I need a way to place NFSv4 mounts into my existing namespace.
and as of today, the mechanism I'd use to do that is to change a
branch of the name space in the existing maps such that it was an NFSv4
mount.

I understand that this means I don't get all the advantages of a single
global namespace.  at least not until we're all-the-way migrated off
the existing file delivery protocols.

...

> I don't know if we should use dns, ldap, or something else, but we do need
> to all agree on the same global root directory if we are going to implement
 
> Let's give customers something flexible enough that let's them build

absolutly.  its the only way you'll get adoption.

 -skottie

-- 

Scott Miller                 | Animation Technology
work: [email-masked] | Dreamworks Feature Animation
life: [email-masked]
  "Change is required. Growth is optional" -anon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 Jan 2004 13:31:41 -0600

> then there is no new "root server authorization" problem to solve.

[This thread has seen lots of belaboring of points, and I'm as guilty as
 anyone else.  So don't hold back :^)]

The "root server authorization" problem has at least one simple
solution[1].

I mentioned the problem early on in this thread, IIRC, and in spite of
that problem referrals seem quite popular as a namespace construction
mechanism.  That may be because as long as the solution is simple
referrals do not lose their appeal.

> Data for a global filesystem name service is just an add-on.

I see several models for authenticating the namespace configuration:

1) authenticate the directory servers, secure the channels to them,
   trust their data

2) authenticate directory data

3) authenticate namespace root NFSv4 servers, authorize them to serve
   their namespace roots, trust subsequent referrals

4) authenticate NFSv4 referrals

(2) and (4) are not trivial.

(1) we have already.  And (3), I contend, we can get easily.  In fact,
both (1) and (3) have share the server authorization problem, which has
been mostly ignored in the LDAP/SASL space -- see the thread that starts
with

[1]  http://www.imc.org/ietf-sasl/mail-archive/msg01066.html

If we can get (3) with ease then why give up on it?

Nico
--

---

From: Ted Anderson <[email-masked]>
Date: Tue, 13 Jan 2004 14:59:09 -0500

> for any host that exports NFS shares.

This sounds fine to me.  I just read "somehost" as 
"domains-toplevel-nameserver".

...
> it, in spite of the faults you raise.

I agree that customers want it, and as you (later) and Skottie 
mentioned, there is the transition problem anyway.  However, I wouldn't 
encourage it by recommending the namespace be layed out this way. 
Instead, I'd suggest something like: /net/ieft.org/nfs.

> /gfs/sun.com/standards/RFCs -> [referral to ietf.org sub-namespace]

Sure, this is just a special case of each domain laying out its 
namespace as it likes.  In this case there will be multiple referrals to 
ietf.org.  And if ietf.org choses to add to its namespace the namespaces 
of organizations that participate in its working groups, you'll also 
have cycles.  Though, with enough finely-grained namespace fragments, 
one could imagine sun.com/standards/RFCs referring to ietf.org/RFCs 
instead of ietf.org and thereby avoid referencing ietf.org/participants.

> corresponding client-local access points.

I agree.

> (We need to agree on some terminology here also -- we're making some up

Yes.

Ted Anderson

---

From: Ted Anderson <[email-masked]>
Date: Tue, 13 Jan 2004 15:17:06 -0500

> Let's give customers something flexible enough that let's them build

I agree that we can't insist on how clients/customers lay out their 
namespace.  However, the motivation to use a canonical arrangement is 
different for domain-local data than for global data.  So because 10 
customers using automounter use 10 different layouts none of which match 
the "out of the box" layout, does not mean that the same logic applies 
to global names.  The whole point of global names is that they are the 
same everywhere.  While users sharing data can remember to do a bit of 
syntactic mapping (which will probably be necessary for Windows users 
anyway), it will be clear to everyone that the less of this the better. 
  So agreeing on /fs or /... or some such, for global pathnames is going 
to seem like a good idea to most people and organizations.  So that 
everyone who wants to can use the same names, there needs to be some 
strong recommendations about these things to let everyone start on the 
same page.  On the other hand, these recommendations don't necessarily 
belong in the same RFC(s) describing the architecture, semantics and 
mechanisms.

 > As much as we might think symlinks are transparent - they are not,
 > e.g.  fire up some application GUI file chooser and instead of a
 > friendly "/home/brent" path you see instead
 > "/gfs/northcentral.eng/dctwg-all/mumblyfrotz/brent".  Not good.

The question of papering over ugly/long global names with symlinks is a 
good one.  One approach is the view "/home" as another referral to the 
same namespace fragment that 
"/gfs/northcentral.eng/dctwg-all/mumblyfrotz/" refers to within the 
northcentral.eng domain.  On the other hand sometimes the 
non-transparency is good.  If you send me a picture of your new house as 
"/home/brent/house.jpeg" because that is where you put it, that isn't 
going to be very useful when my "/home" is pointing to 
"/gfs/ibm.com/almaden/k56/quux".  At least with symlinks, "cd /home;pwd" 
gives me the correct global name.

Ted

---

From: Skottie Miller <[email-masked]>
Date: Tue, 13 Jan 2004 12:17:23 -0800

Nicolas Williams wrote:
 
> If you're an advanced user of automounter maps you may well be using
> automounter variable interpolation also and may wonder how on earth that
> functionality could possibly be replaced with referrals.  And we have to
> preserve that functionality (I used to work in an environment that
> absolutely depended on it).  I see more than one way to do replace that
> with referrals, and we should get to that topic at some point (note to
> whoever starts a thread on it: set an appropriate Subject: pls).

Automount variables are critical to keeping the namespace the same
everwhere, while directing clients to mirrors or caches of the original
data.

> Why this approach?  Other approaches are possible.  For example:

I didn't say "as of today" loud enough ;-)  I'd use this approach because
its what we do today, and its comfortable.

>  - NFSv2/3/4 + automounter (overrides referrals)
> 
>  - NFSv2/3 + automounter for v2/3 clients, NFSv4 + referrals for v4
>    clients

If I can stick NFSv4 mounts + referrals in the tree at (or below) the
same level as the V2 & V3 mounts, then this would work.  

> The second one you could only implement after deploying v4 server
> software and properly configuring the namespace so that the automounter
> view of it is congruent to the referrals view of it.

agree.  an NFSv4 aware automounter, or an automounter aware referrals
mechanism, or somthing like that.  the point is that the need to co-exist
transparently to the users and the existing namespace.

 -skottie

--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 Jan 2004 13:47:24 -0600

> we *would* *not* ever migrate. it'd be too disruptive.

Bingo.

There can be one namespace, as some desire, but sub-namespaces have to
be mountable anywhere on a client that the user/admin wants -- otherwise
legacy will prevent migration.  So we must agree on the primacy of the
client-local namespace and allow for views (as Jon Haswell puts it) into
the global namespace.

I myself am more concerned with the problem of finding and constructing
domain-specific namespaces than I am with how it all looks from the
client p.o.v. at the end of the day.

Cheers,

Nico
--

---

From: Julian Satran <[email-masked]>
Date: Mon, 19 Jan 2004 00:48:10 -0800

> gives me the correct global name.

Interesting - I was thinking that when getting to a global namespace we 
can "standardize" also some shorthands - e.g., /home has some universal 
meaning and is related to the principal :-)