Subject: Re: [nfsv4] draft-fan-nfsv4-global-namespace-problem-statement-00.txt

From: Craig Everhart <[email-masked]>
Date: Mon, 4 Apr 2005 12:35:06 -0400

Hi, Manuel.

Manuel Pereira/Almaden/IBM wrote on 04/01/2005 08:12:24 PM:
> Craig Everhart wrote:
> > (b) In 3, your second requirement for Uniformity of View. Yes, there
> > should be an agreed-on view and an agreed-on authoritative procedure
for
> > determining the global name space. But I think it's misleading and
> > constraining to say that the authoritative data for the namespace needs
> > to be in a table. It could just as easily, or perhaps better, be in the
> > "smart server" model, where it doesn't really matter where the smart
> > server gets its information. I'm all for the agreed-on root server--but
> > actually that root server should really be multiple. See (d) below...
>
> We agree with the notion of a “smart server”, as you have stated
> “where it doesn’t really matter where the smart server gets its
> information”, so long as the information obtained is from an
> authoritative repository.  We also believe that the essential
> namespace semantics need to be defined, perhaps in the form of a
> standard specification.

Well, we're talking about a requirements document, not the architecture for
a specific NFSv4 server here.  My question is what "essential namespace
semantics" means in this general context.  What NFSv4 gives us to work
with is what the target of a "fs_locations" attribute should be.  What
does "essential namespace semantics" have to do with that?  Presumably,
fs_locations already gives us some essential namespace semantics.
Are you arguing for some specific requirements on top of all such
targets?  (And if so, does it duplicate information from the paths in
file systems?  If so, why?  If not, how does it not?)

> Craig Everhart wrote:
> >> (c) In 5, what "namespace mappings"? I guess I don't understand what
> >> kind of schema you have in mind. Does it duplicate paths that are also
> >> in file systems? (Why?)
> >
> > Charles Fan wrote:
> > The namespace mappings are referred to the abstraction between the
> > logical namespace and physical locations.  We call for a standard
schema
> > to capture these mappings.
>
> This is a good description of namespace mappings.
>
> With respect to the “why” question, it is certainly necessary to
> maintain a “mapping” that resolves a logical representation to a
> physical location.

Well, a good idea, but is it a requirement?

> ... Such a mapping provides a necessary level of
> indirection, thereby enabling a certain degree of virtualization
> allowing target locations to freely move and change without
> impacting junctions/mount points stored in the filesystem (changes
> to target locations are handled in the namespace mappings).
>
> We believe this substantiates the need to standardize an object
> schema and access method to a resolution service responsible for
> handling logical to physical mappings.  Standardization is key for
> this particular service to ensure interoperability between various
> namespace service implementations and logical-to-physical
resolutionservices.

Once again, an example would help.

> Regards,
> Manuel Pereira
> ===============================
> IBM Almaden Research Center
> ===============================
> 650 Harry Road, San Jose, CA 95120
> 1-408-927-1935  [T/L 457]
> Pager: 800-946-4646 1492425
> http://mvp3.almaden.ibm.com
> [email-masked]

Craig Everhart
+1 919 543 2169 (tie 441 2169)

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