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

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 16 Dec 2003 11:11:11 -0800

My assumption has been that the global namespace need not be extension of the
local namespace.  It might have a different structure.
 
On the other hand, I am assuming that fs units retain their integrity, even though many
different fs's on the same server may be found in widely different places in the namespace.
You are anticipating/advocating something much finer-grained.
 
I'm not against looking at a global namespace that incorporates the ability to distribute
objects in a fine-grained fashion but I'm definitely one of those who think that you have to 
walk before you can teleport.

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, December 16, 2003 9:44 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] Global namespace for v4.1?

I would like to add also a "basic" think and then I'll shout-up (I don't rally belong here - do I?). 
The underlying assumption of the discussion untill now was that the structure of global namespace is just an "extension" of the local namespace (a mount combination that all agree on by some miracle). 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. This places some burden on servers (minimal on clients) but is resilient to an form of migration and operations on the global DAG (or tree) become much more systematic and simple. Some implementations might restrict location even more (to subtrees) but at least you start from an understandable structural model and mapping it onto servers may be more or less restricted by implementations (you may want to state what is a minimum). Staring from a model that assumes an "agreed" mount scheme does not seem to me a very productive. 

But is you start with a global structure you can map it with ease into placement and you are in fact doing a "proper" extension of the current "neat" one tree view of an NFSV4 one server namespace. 

And IMHO there are many good arguments for burdening (almost) only the servers with this issue. 

Julo 

Brent Callaghan <[email-masked]> 
Sent by: [email-masked] 

15/12/2003 20:12 

Please respond to
[email-masked]

To
[email-masked] 

cc

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

Nicolas Williams wrote:
> IMO we need:
> 
>  - a referral mechanism (got that)
>  - a "root" finding mechanism (we can build that today as a set of
>    conventions, really)

Yes, a couple of important components, though, I should point out,
these elements are just a few in a long list of the list of features
that we expect of any general-purpose name service, e.g. LDAP, NIS, DNS etc.

I think what Julian is trying to point out is that a namespace is more
than just a collection of exported filesystems.  There's some expectation
that these filesystems will be organized in some way, most likely one or
more hierarchical trees, and their shape will be determined by the customer.

I predict that as the requirements of the namespace become more clearly
defined, the advantages of using an established name service will become
more apparent.

                Brent

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

---

From: Julian Satran <[email-masked]>
Date: Sun, 21 Dec 2003 17:50:24 +0200

It is not the granularity that I am after. I could live with directories 
or even subtrees. 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.

As for teleport - I never though about AFS in those terms (should I 
have?).

As for who is to do the mapping from a global namespace to a local-one I 
guess that the same kind of argument would favor a server done mapping.
If a third party reply to a client request is deemed too complex to be 
incorporated in the protocol (failure modes are more complex) then the 
"moved" paradigm could be used.
However arguments can be made that a "third party" reply can be more 
effective.

Julo

"Noveck, Dave" <[email-masked]> 
16/12/2003 21:11

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

My assumption has been that the global namespace need not be extension of 
the
local namespace.  It might have a different structure.
 
On the other hand, I am assuming that fs units retain their integrity, 
even though many
different fs's on the same server may be found in widely different places 
in the namespace.
You are anticipating/advocating something much finer-grained.
 
I'm not against looking at a global namespace that incorporates the 
ability to distribute
objects in a fine-grained fashion but I'm definitely one of those who 
think that you have to 
walk before you can teleport.
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, December 16, 2003 9:44 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] Global namespace for v4.1?

I would like to add also a "basic" think and then I'll shout-up (I don't 
rally belong here - do I?). 
The underlying assumption of the discussion untill now was that the 
structure of global namespace is just an "extension" of the local 
namespace (a mount combination that all agree on by some miracle). 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. This places some burden on servers (minimal on clients) 
but is resilient to an form of migration and operations on the global DAG 
(or tree) become much more systematic and simple. Some implementations 
might restrict location even more (to subtrees) but at least you start 
from an understandable structural model and mapping it onto servers may be 
more or less restricted by implementations (you may want to state what is 
a minimum). Staring from a model that assumes an "agreed" mount scheme 
does not seem to me a very productive. 

But is you start with a global structure you can map it with ease into 
placement and you are in fact doing a "proper" extension of the current 
"neat" one tree view of an NFSV4 one server namespace. 

And IMHO there are many good arguments for burdening (almost) only the 
servers with this issue. 

Julo 

Please respond to
[email-masked]

To
[email-masked] 
cc

Subject

Yes, a couple of important components, though, I should point out,
these elements are just a few in a long list of the list of features
that we expect of any general-purpose name service, e.g. LDAP, NIS, DNS 
etc.

I think what Julian is trying to point out is that a namespace is more
than just a collection of exported filesystems.  There's some expectation
that these filesystems will be organized in some way, most likely one or
more hierarchical trees, and their shape will be determined by the 
customer.

                Brent

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 22 Dec 2003 02:44:04 -0800

> location transparency, migration transparency, replication transparency. 

As long as control over the namespace is ultimately in the hands of the
relevant sysadmins I don't see why the namespace can't be constructed by
"arbitrary composition" -- as you put it.

Who are we to say what the sysadmin won't want to do?

> Transparency is what will keep applications and administration separate.

I'm not sure what you mean by tranparency here.  I'm interested in
seamlessness.

Users usually don't care one bit where their data is stored -- only that
the namespace and filesystems be reliably available and perform
decently.

In order to deliver on user expectations sysadmins need to be able to
reconfigure filesystem locations without having to reconfigure the
namespace (the structure of which tends to get hardcoded into
applications).

> However arguments can be made that a "third party" reply can be more 

Come now, referrals can certainly be used as a proxy to "third parties"
-- by which I take it you mean the directory.

Cheers,

Nico
--