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

From: Julian Satran <[email-masked]>
Date: Tue, 16 Dec 2003 16:44:18 +0200

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: Brent Callaghan <[email-masked]>
Date: Mon, 15 Dec 2003 10:12:13 -0800

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