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

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 22 Dec 2003 09:55:47 -0800

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

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. 

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

---

From: Julian Satran <[email-masked]>
Date: Tue, 23 Dec 2003 15:07:03 +0200

same color in text - Julo

"Noveck, Dave" <[email-masked]> 
22/12/2003 19:55

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

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

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

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