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

From: Craig Everhart <[email-masked]>
Date: Fri, 1 Apr 2005 17:17:05 -0500

Hi.  Thanks for the replies.  Some answers to your questions, etc.

Chenggong Fan <[email-masked]> wrote on 03/31/2005 07:17:35 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...
> 
> What I meant by the "location table" is the collection of mappings 
> between the logical nodes in the namespace to the physical location (or 
> locations).  What better wording do you suggest?

Maybe I simply don't understand this part of the problem statement.
With ERR_MOVED and fs_locations, there's a perfectly fine mechanism for
clients to learn about relationships between and among NFSv4 filesystems
(identified by fsid on a server).  Presumably these NFSv4 filesystems
have something to do with your "logical nodes," and it's clear that
such filesystems need to have physical locations.  But I guess that I 
don't
understand what you're getting at with "logical nodes" here.  I especially
don't understand why a table of "logical nodes" is *required*.

I believe that this preesentation of fs_locations information from servers
to clients provides an authoritative mapping, from the point of view of
the servers telling the clients, how to interpret pathnames relative to
the root of the set of related NFSv4 filesystems--to your "Uniformity of
View" point.  Is there something else that needs to be involved?

> > (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?)
> 
> 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.

OK, perhaps this would follow if I understood what you felt the 
requirements
were for the previous point.  But I don't understand them, so the question
stands.  By the way, I asked the specific point about duplication of path
information to try to help clarify what you intend.

Perhaps an example of your architecture here would be helpful to us all
(or at least to me).

> Thanks,
> Charles

                Thanks much,
                Craig

Craig Everhart
+1 919 543 2169 (tie 441 2169)
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Charles Fan <[email-masked]>
Date: Fri, 01 Apr 2005 14:55:51 -0800

Hi Craig,

I see the global namespace as a location-independent, uniform and 
transparent presentation of data from the servers to the clients.  In 
other words, it is the tree that the clients see after they mount the 
root server.  Each "node" in this tree (which is the root of a 
sub-namespace) may be mapped to a location on one of the physical file 
servers.  These mappings are what I referred to as global namespace 
mappings.

There needs to be a central repository of these mappings, in addition to 
the referals built into the file system of the root server.  The schema 
should capture not only the current mapping, but also the historic 
mappings.  (So it's not a duplication, by a superset of what's store 
inside the referals in the file system).  These information will be 
important for different storage management applications, for example for 
a backup/restore applications to find the backup copy of a particular 
piece of data at a particular time.

What do you think?

Charles

Craig Everhart wrote:
>  > > should be an agreed-on view and an agreed-on authoritative 
> procedure for
> such filesystems need to have physical locations.  But I guess that I don't

---

From: Charles Fan <[email-masked]>
Date: Fri, 01 Apr 2005 15:07:45 -0800

Sorry, typo:

> ... (So it's not a duplication, by a superset of what's store ...

should be:

... (So it's not a duplication, but a superset of what's stored ...

Charles

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 4 Apr 2005 16:40:38 -0500

On Fri, Apr 01, 2005 at 02:55:51PM -0800, Charles Fan wrote:
[...]
> the referals built into the file system of the root server.  [...]

I don't agree.

As long as clients know how to find the top levels of the namespace
somehow (e.g., through DNS SRV RRs as I've described before [and with
GSS-API domain-based service names]) then that and referrals provide
enough protocol to fashion a global namespace.

A standard directory and schema for configuring file namespaces (and
sub-namespaces) is a Good Idea (tm), but not a requirement that has
anything to do with the NFSv4 bits on the wire between clients and
servers.  This should be clear.

It should be possible to have a dumb-client/smart-server namespace, even
one where the smart servers do not use a central repository for their
namespace configuration.  (Though I hope for servers that are
interoperable w.r.t. namespace configuration, which leads me to want a
directory [LDAP will do] and schema for the it.)

---

From: Leo Luan <[email-masked]>
Date: Mon, 4 Apr 2005 15:48:47 -0700

Nicolas Williams <[email-masked]> wrote on 04/04/2005 02:40:38

> enough protocol to fashion a global namespace.

The top-levels of the namespace can potentially be rendered by some
designated NFS servers as well. These NFS servers would be resolving the
top-level namespace (through DNS lookups, etc) for the client in this case
(so the client can be dumber).  These NFS servers can also be configured to
show selected top-level namespace portions that need to be accessed by the
organization that owns these NFS servers.  This would be like the
traditional AFS cell.root volume that contains the mount points to cells
included in the top-level namespace that AFS clients of the local cell see.

OpenAFS supports Dynaroot (or Freelance client in Windows OpenAFS client)
where the AFS clients resolve the top-level namespace.  This is similar to
the discussed approach of letting NFS clients resolve cell root server
addresses themselves.

As long as cell root servers can be resolved consistently, I think we
should not rule out client or server-based top-level namespace resolution.

> servers.  This should be clear.

I believe any additional standard definition of external namespace service,
including possible mapping tables for logical/physical filesystems
(filesets), should have the goal of facilitating interoperable
namespace/replication management. IMHO, this goal is achievable without
forcing all products to adopt a particular approach.  For example,
individual products can manage their replica location resolution in their
proprietary ways and participate in global namespace without any problem.
But these products will not be interoperable with other products when it
comes to replica management.

> directory [LDAP will do] and schema for the it.)

I fully agree here.  The goal of a central repository approach is to
facilitate interoperation (in namespace management, replication management,
etc), not limiting it.

Leo Luan
IBM Almaden Research Center
408-927-1893 (IBM T/L: 457-1893)

---

From: Ted Anderson <[email-masked]>
Date: Tue, 05 Apr 2005 09:07:49 -0400

I feel there are several areas of confusion in this discussion, which I 
will try to clarify in this note.

On 4/4/2005 17:40, Nicolas Williams wrote:
 >>There needs to be a central repository of these mappings, in addition 
 >>to the referals built into the file system of the root server.  [...]
 >
 > I don't agree.

Charles seems to be suggesting here *both* a central repository and 
referals "built into the file system".  I interpret this latter phrase 
to mean junctions stored as special file system objects like AFS has. 
Craig has rightly expressed concern about the consistency of these two 
types of namespace information.

Both mechanisms have their individual strengths and *could* be used 
together.  But a problem statement document probably shouldn't require 
the use of both or should make it very clear why both are necessary.

I think there are two fairly distinct facets of the namespace problem: 
the top-level structure and "hierarchical mapping".  The first is 
locating and defining the upper levels of the namespace that lead to 
real filesystems holding data; this is roughly the domain of the NFSv4 
pseudo file system.  The second is the problem of attaching real 
filesystem to each other, which Charles refers to as "hierarchical 
mapping" in section 3.  (This may be more useful when connecting 
sub-portions of a filesystem, what we've earlier referred to as 
"fragments".)

Using a database for the top-level information is a familiar choice. 
While using junctions would make sense for hierarchical mappings, where 
consistency problems (i.e. between an external database and the 
directory structure of the parent filesystems) are more of an issue. 
But other arrangements and combinations may have benefits as well. 
Keeping these two aspects of the namespace problem in mind would help 
when framing requirements and considering approaches for managing 
namespace information.

 > included in the top-level namespace that AFS clients of the local 
cell see.

Both right.  I think there are two approaches in this area that often 
get confused.  In one case the client (not-dumb) uses DNS to query where 
it can find an NFSv4 file server that hosts the top-level of the 
namespace.  In the other case the client is statically configured to 
talk to one NFSv4 server (smart), which locates the proper top-level 
server and immediately redirects the client thither (clearly, no slouch 
either).  The server in this case may or may not use DNS to locate the 
proper top-level server.

In truth, the difference is not very great.  Probably all clients and 
servers should know about SRV records.  This allows customers the choice 
of how to configure their system and the best approach can be used as 
circumstances and good practices indicate.  Defining this SRV record 
format would be pretty easy and thus a good thing to do.

 > facilitate interoperation (in namespace management, replication 
management,

Okay, so down to brass tacks.  It seems we are mostly arguing about two 
basic things here: the concepts that relate to namespaces and whether 
specification of a central repository would aid interoperation.

The namespace concept definition problem is significant and important. 
We often find ourselves arguing at cross purposes and puzzling over 
unfamiliar terms (or worse, familiar terms used in unfamiliar ways). 
The problem statement would benefit from an explicit effort to lay out 
terms and explain relevant relationships.

There seems to be some consensus that a namespace repository would be 
useful.  But I wonder if everyone is envisioning the same or even 
compatible uses for it.  Also there is understandable concern about 
adopting a new database and its management.  These issues need to be 
addressed.

Hope this has provided more light than heat,
Ted Anderson

---

From: Craig Everhart <[email-masked]>
Date: Tue, 5 Apr 2005 10:39:59 -0400

Yay.  I suggest we burst this into two discussions, as Ted alludes.
There's enough meat for a
Requirements document for the top-level name space, with the rule that the
top level of the
inter-organizational (i.e., global) name space should go through a SRV
record interpretation
of some sort that points to the named organization's top-level NFSv4 file
servers.
Whether this SRV record interpretation is done by the NFSv4 client or by
some DNS-proxying
NFSv4 server really doesn't matter, since both conventions could be used
interchangeably,
without affecting the inter-organizational name space.  This seems to me to
be the key
agreement that could be achieved in order to make the inter-organizational
name space
spring into existence.  (Passing over, for now, the idea of any
conventional name to be
used as the first component of any such names.)  But it would suggest how
multiple targets
given by multiple SRV records are to be interpreted as multiple
fs_locations entries for the
referred-to organizational root filesystem (which could be replicated on
multiple servers).

Would a Requirements document be the right thing here?  Or is this just a
stand-alone
proposal to be embodied in an internet-draft?

The second discussion would deal, I think, with the structure of
inter-filesystem referrals
and whether there are conventions that could or should be established for
them.  On this
there seems to be far less consensus at the Requirements level, so the
debate appears
to be more open.

            Craig

Craig Everhart

---

From: Leo Luan <[email-masked]>
Date: Tue, 5 Apr 2005 10:05:39 -0700

Ted Anderson <[email-masked]> wrote on 04/05/2005 06:07:49 AM:

...

> format would be pretty easy and thus a good thing to do.

Right and this is why I said "As long as cell root servers can be resolved
consistently, I think we
should not rule out client or server-based top-level namespace resolution."

...

> Hope this has provided more light than heat,

I am not seeing real heated disagreements on this forum so far regarding
the global namespace approach. Everyone has agreed that using DNS for
resolving cell root servers is a good idea.  Everyone seems to be also
open-minded about the possibility of defining a namespace repository to
facilitate interoperation without requiring every product to use it.
Products can choose proprietary ways of managing their namespace info and
they can even have their own internal namespace repository.  The goal of a
standardized namespace repository, IMHO, is to allow vendors to choose to
be more interoperable with other vendors' products in namespace/replication
management.

Leo Luan

---

From: Charles Fan <[email-masked]>
Date: Wed, 06 Apr 2005 16:27:56 -0700

Hi,

Thanks for all the feedback to the draft.  In the first three paragraphs 
of section 5 of the draft, we listed three to-do items:

The third paragraph calls for a standard way how clients can find the 
top levels of the namespace.  (third paragraph of section 5).  From the 
email discussion there seem to be good agreement so far on this 
requirement so far, and even good agreement on the mechanisms to do it. 
  Perhaps someone could capture it in an Internet Draft?

The second paragraph calls for a clarification of the NFS4ERR_MOVED and 
fs_location specifications and how they support a referral mechanism 
that allows a subtree of a file system to attach to another file system. 
  The referral mechanism is a key to support necessary client-server 
communication and redirections for a global namespace, without requiring 
client software beyond the standard NFSv4 client software.  This item is 
not too contraversial either.  In fact real work is taking place by a 
number of people on this.  (With Dave Noveck and Carl Burnett's I-D and 
prototyping on a number of platforms including Linux, Solaris, AIX, EMC, 
and NetApp.

The first paragraph of section 5 looks to be causing the most 
discussions so far.  Good questions were asked: given that we have a 
referral mechanism inside NFSv4 protocol, and the referral mapping 
recorded inside of a NFSv4 server (possibly an NFSv4 "namespace server", 
a server consisting purely of referrals), why do we still require a 
central repository of the namespace mappings?

When we were writing the draft, I saw a number of reasons that it's a 
good idea to define a standard schema outside of the NFSv4 protocol to 
store and publish global namespace mappings and extended information 
associated with them.  I'll use backup/restore as one example where it's 
quite necessary:

As we know, NAS data are backed up often not using the file system 
protocol (e.g. NFS), but rather directly from the server (e.g. via 
NDMP).  The global namespace keeps the data presentation to end users 
constant while the physical location of the data changes.  Problems 
could occur during recovery.  Using a simple example: if a user would 
like to recover a file from its backup one week ago, the administrator 
now have a hard time to figure out which tape to grab.  Since user 
refers to the file by its logical path in the global namespace.  The 
file system only records the current namespace mapping, and is not 
required to remember the global namespace mapping at a particular time 
in the past.  So the administrator really has no idea which physical 
server actually housed the data one week ago.

To allow a global namespace to be truly usable in today's environment by 
the storage administrators, a richer set of data need to be kept with 
the global namespace, such as the historic mapping in the example above. 
  This is beyond what's defined as part of the NFSv4 protocol and it 
helps if there is a standard format that different solutions use to help 
their interoperability.  In the example above, the virtualization/global 
namespace solutions and the data protection (backup/restore) solutions 
can communicate to find the correct back-up if they both understand the 
same format of the historic namespace mapping.

Besides backup/restore, there are other end-user/administrator 
requirements that can be solved by stardizing an external schema to 
store and publish namespace mappings and extended information associated 
with them.  Other quick examples include providing the possibility for 
v3 and v2 clients to access the same namespace, interoperability with 
the CIFS namespace, etc.  In summary, we are not suggesting that this 
schema that we propose for us to work on is part of the standard NFSv4 
protocol.  It is certainly not.  But it is a standard that different 
storage management solution can follow to solve practical 
interoperability problems.  It could be worthwhile for this Work Group 
to work on it, to help make NFSv4 protocol attractive to both end-users 
and administrators.  What do people think?

Charles

---

From: "Jiaying Zhang" <[email-masked]>
Date: Thu, 7 Apr 2005 13:03:31 -0400

Hi,  here is my comment about namespace mapping.

> The first paragraph of section 5 looks to be causing the most discussions 
> so far.  Good questions were asked: given that we have a referral 
> mechanism inside NFSv4 protocol, and the referral mapping recorded inside 
> of a NFSv4 server (possibly an NFSv4 "namespace server", a server 
> consisting purely of referrals), why do we still require a central 
> repository of the namespace mappings?

I think it may be optional for a root server to decide if storing namespace 
mappings on
a central repository, or locally. But I agree it would help if we 
standardized the common
schemes to retrieve such mapping information from a central repository, like 
the standard LDAP schema
to store NFS locations and the standard DNS RR formats.

In CITI, we have used a home grown LDAP schema to store the NFS location 
info.
Here is the format we are currently using.

# Depends upon core.schema and cosine.schema

# OID Base is 1.3.6.1.4.1.2312.4
#
# Attribute types are under 1.3.6.1.4.1.2312.4.1
# Object classes are under 1.3.6.1.4.1.2312.4.2
# Syntaxes are under 1.3.6.1.4.1.2312.4.3

# Attribute Type Definitions

attributetype ( 1.3.6.1.4.1.250.1.64
        NAME ( 'fslocations')
        DESC 'NFS version 4 FS_Locations Information'
        EQUALITY caseIgnoreIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

objectclass ( 1.3.6.1.4.1.250.1.65 NAME 'rnfs'
        DESC 'NFS version 4 FS_Locations Information'
        SUP top AUXILIARY
        MUST ( cn $ fslocations )
        MAY ( description ) )

Jiaying

---

From: Ted Anderson <[email-masked]>
Date: Thu, 07 Apr 2005 14:51:02 -0400

On 4/6/2005 19:27, Charles Fan wrote:
 > Thanks for all the feedback to the draft.  In the first three
 > paragraphs of section 5 of the draft, we listed three to-do items:
 >
 > top levels of the namespace.  (third paragraph of section 5).  From
 > the email discussion there seem to be good agreement so far on this
 > The second paragraph calls for a clarification of the NFS4ERR_MOVED
 > and fs_location specifications and how they support a referral
 > mechanism that allows a subtree of a file system to attach to another
 > file system.
 > communication and redirections for a global namespace, without
 > requiring client software beyond the standard NFSv4 client software.
 > This item is not too contraversial either.  In fact real work is
 > taking place by a number of people on this.  (With Dave Noveck and
 > Carl Burnett's I-D and prototyping on a number of platforms including
 > Linux, Solaris, AIX, EMC, and NetApp.

I agree with these points.  Though, unfortunately, I have not yet had
time to read the Noveck-Burnett draft.

 > recorded inside of a NFSv4 server (possibly an NFSv4 "namespace
 > server", a server consisting purely of referrals), why do we still
 > require a central repository of the namespace mappings?

This is a key question that needs to be address, perhaps by expansion of
the problem statement.

 > associated with them.  I'll use backup/restore as one example where
 > it's quite necessary:
 >
 > To allow a global namespace to be truly usable in today's environment
 > by the storage administrators, a richer set of data need to be kept
 > with the global namespace, such as the historic mapping in the example
 > above.
 > helps if there is a standard format that different solutions use to
 > help their interoperability.  In the example above, the
 > virtualization/global namespace solutions and the data protection
 > (backup/restore) solutions can communicate to find the correct back-up
 > if they both understand the same format of the historic namespace
 > mapping.
 >
 > store and publish namespace mappings and extended information
 > associated with them.  Other quick examples include providing the
 > possibility for v3 and v2 clients to access the same namespace,
 > interoperability with the CIFS namespace, etc.  In summary, we are not
 > suggesting that this schema that we propose for us to work on is part
 > of the standard NFSv4 protocol.  It is certainly not.  But it is a
 > standard that different storage management solution can follow to
 > solve practical interoperability problems.  It could be worthwhile for
 > this Work Group to work on it, to help make NFSv4 protocol attractive
 > to both end-users and administrators.  What do people think?

I agree that an external repository of location information is a
valuable component of a global or enterprise-level namespace.  To
fortify this point, I think we should include a few other rationales or
usage cases to illustrate the benefits of (or at least enabled by) a
standard interface to filesystem location information.

In addition to:
   1. backup-migration-restore
   2. multi-protocol support (NFSv2/v3 and CIFS)
mentioned by Charles, I'd add:
   3. decouple the namespace management from replica management.
   4. coordinate location information for dispersed replicas.
   5. provide enhancements for advanced replica selection.

The decoupling concept allows replicas managed by different vendors to
have a standard method for registering their replicas so that all
servers and clients see a uniform view.  This would facilitate
interoperability between data servers and encourage development of
various strategies for creating, deploying and updating replicas.

The coordination issue addresses the problem of maintaining consistency
between multiple replicas that refer other filesystems when the targets
move or change their replication status.  The parent replicas may be in
PROM, on CD, distributed by the thousands or otherwise be difficult to
update consistently when the location information for the target
changes.  Generally, this situation arises when the structure of the
namespace changes at a different rate or with different privileges than
the location information does.

Good replica selection is a hard problem in general and may involve many
factors.  An external repository can include more information to guide
selection so that advanced servers, and clients as well, could do a
better job than a simple scheme could accommodate.  Making this replica
location information part of an (extensible) standard would facilitate
interoperation and encourage development of increasingly sophisticated
strategies to optimize the use of replicas.

These issues have mostly been touched upon in one way or another before
but I think there is value in collecting the arguments together to make
a clear case for this aspect of namespace functionality.

Ted Anderson

---

From: "Arun swaran Jagatheesan" <[email-masked]>
Date: Thu, 7 Apr 2005 17:58:02 -0700

I was late in following this discussion/thread and i am replying on a
better late than never basis. I am glad to see this discussion on the
namespace problem in this list. I hate to interrupt a good discussion..
i just want to confirm the objective and scope while defining the
problem statement.

There are different levels of Namespace that are possible:
* Inter/intra cluster Namespace
* Intra Organizational Namespace (Enterprise)
* Inter Organizational Namespace (Enterprise and its collaborators)
* Universal Namespace (Enterprise and any public)
Do we consider all these namespaces as part this same problem statement
for NFS? Will the solution(architecture or protocols etc.,) generated
from this community, applicable to all the above mentioned namespaces?

I am not sure if it is ok to discuss architecture or design requirements
at this stage of problem definition. It is good thing to have
location-independent naming or "logical namespace" as stated in the
requirements. Would it be useful and/or possible to have this
"hierarchical logical namespace"  independent of factors like: hierarchy
of the participating organizations, DNS hierarchy and geographical
distribution of physical locations?

Arun
~~~~~~~~~
Dream; because, dreams lead to thoughts; thoughts lead to action, and
action leads to achievement.

Arun swaran Jagatheesan
http://www.sdsc.edu/~arun/
San Diego Supercomputer Center.
(858)822.5452

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Ted Anderson
> Sent: Thursday, April 07, 2005 11:51 AM
> To: Charles Fan
> Cc: [email-masked]
> Subject: Re: [nfsv4]
> draft-fan-nfsv4-global-namespace-problem-statement-00.txt
>
>

---

From: Charles Fan <[email-masked]>
Date: Thu, 07 Apr 2005 18:11:03 -0700

Hi Arun,

In the beginning of section 3, we recognized different scopes of a 
"global namespace", very similar to how you outlined, and stated that 
this draft focuses on the enterprise namespace.

Charles

---

From: "Arun swaran Jagatheesan" <[email-masked]>
Date: Thu, 7 Apr 2005 18:21:03 -0700

Hi Charles,

Thanks for the instant clarification. I guess i should have been more
specific in my question. Does the Enterprise-Namespace under
consideration include:
- an enterprise location with heterogeneous storage systems
- an enterprise including  distributed locations? (west coast, east
coast, off-shore locations)
- an enterprise and it collaborators? (enterprise and it
collaborators/partners)

As you can see, i am trying to find the scope. My opinion is that same
size might not fit all the above requirements. In addition, i believe
that the infrastructure independence required at each level would differ
(and was the reason for my second part in the question below regarding
independence from location, DNS hierarchy etc.,)

Thanks in advance for your further clarification.

Arun

> From: Charles Fan [mailto:[email-masked]]
> Sent: Thursday, April 07, 2005 6:11 PM
> To: Arun swaran Jagatheesan
> Cc: [email-masked]
> Subject: Re: [nfsv4]
> >> > requirement so far, and even good agreement on the
> mechanisms to do
> >> > it.

---

From: Chenggong Fan <[email-masked]>
Date: Thu, 07 Apr 2005 21:15:07 -0700

Hi Arun,

> - an enterprise location with heterogeneous storage systems
Yes.

> coast, off-shore locations)
Yes.

> - an enterprise and it collaborators? (enterprise and it
I am not sure about this.  I think, in common cases, each enterprise 
will have its own namespace.

Charles

---

From: Craig Everhart <[email-masked]>
Date: Fri, 8 Apr 2005 12:48:49 -0400

I think that the "Enterprise-Namespace" idea is fractionated
inherently, as I think folks agreed, into top-level namespace
issues and filesystem-to-filesystem issues.  I read Arun's question
as referring to the filesystem-to-filesystem issues.  Is that
correct?

That said, I believe that a permission and administrative boundary
must exist on the files/directories level, and it doesn't
necessarily need special concern at the lower levels.  (For an
analogy, would it be OK if my web page included a link to a web
page deep inside your organization's web site?)

            Craig

Craig Everhart

---

From: "Arun swaran Jagatheesan" <[email-masked]>
Date: Fri, 8 Apr 2005 13:42:56 -0700

Hi Craig,
I am trying to understand the scope or pervasiveness level of this
"Enterprise Namespace" as inferred by the community and the problem
statement being defined. My objective is to find the relevance of this
work with other standards and if/how other standards can leverage from
this activity so that it benefits multiple communities.

>From Charles (rainfinty) response, i infer that the scope of this
"Enterprise Namespace" includes heterogeneous file systems, storage
systems etc. and they can be geographically distributed. The problem
statement does not include inter-enterprise namespace where the
individual participating enterprises would have different namespaces. I
guess the problem assumes the existence are presence of a enterprise
wide authentication/authorization schemes.

Thanks,
Arun

-----Original Message-----
From: Craig Everhart [mailto:[email-masked]]
Sent: Friday, April 08, 2005 9:49 AM
To: Arun swaran Jagatheesan
Cc: [email-masked]
Subject: RE: [nfsv4]

Craig

Craig Everhart

---

From: Craig Everhart <[email-masked]>
Date: Fri, 8 Apr 2005 17:14:57 -0400

Thank you, Charles and Ted, for offering examples that we can talk about
here.

Ted Anderson <[email-masked]> wrote on 04/07/2005 02:51:02 PM:

>  > ....

I agree that it would be very handy to capture the requisite data
at the time of making the backup.  That requisite data would be, for
each filesystem, the paths from the root of that filesystem to the
references to other filesystems.  With that data, it's possible to match
a historical name to the historical set of mappings.  Of course, the
actual historical name won't necessarily be from the same historical
period as was remembered in taking the backup.

Worse, of course, is that the user will likely remember today's name for
the backed-up file, and that won't match the remembered pathname data
either.

What I would recommend, for this example and for others, is that the
filesystems should have some identity that doesn't change very often,
if at all, regardless of the pathnames that lead to the references to
them, and regardless of the server or servers on which the filesystem
is housed.  This identity could be a user-specified name or a number or
both or whatever you want; it's just not a pathname.  In this case,
we backed up a collection of filesystems and remembered the identities
of those filesystems.  This solves our recovery request, too: we take
the pathname that the user gave us for the desired file, then most
often we can simply use the current filesystem data to figure out
the identity of the filesystem in which the pathname terminated.
If the current filesystem data doesn't help us, we can use the pathname
data that we saved when we did the backup in the first place.

(The addendum is that, when we saved that information, we saved not
only the pathnames from the root of each filesystem to the references
to the other filesystems, but we remembered the identities of the
referred-to filesystems.)

Now, is what I'm calling a "filesystem identity" the same thing that
you're calling a "namespace mapping"?  You might well disagree,
but I'm thinking that there's more to the namespace mapping--
in particular, I think that you might be remembering those
pathnames that I recommended being stored with the backup,
the pathnames from each filesystem root to its references to
other filesystems.  This is what I'd have the most trouble
with (particularly at the Requirements level).  I think it's
great to take a snapshot of these mappings, and to remember them
when it's useful, but it bugs me to have two disconnected copies
of the same data that are supposed to be synchronized.

>  > to both end-users and administrators.  What do people think?

I don't know everything about what CIFS would require to use a
scheme like this, like whether it's really necessary to put all
the pathnames in a database as well as in a filesystem.

I agree that NFSv2/v3 support is a great(!) idea.  There are multiple
schemes whereby this might be attacked; pre-capturing all possible
pathnames into a static automounter table (just as one example)
seems problematic to me.  Though I continue to agree that we go a
long way by associating some kind of identifier with a filesystem.

>    5. provide enhancements for advanced replica selection.

So I propose the unchanging filesystem identity as a first-class item,
and it makes sense to me to make filesystem references use the
unchanging filesystem identity as the target of the references.
I think this decouples the namespace management (creating and deleting
references, renaming directories) from the replica management (updating
the residencies of the filesystems).  Is that what you mean with (3)?

I'm just trying to figure out whether folks are aiming to mirror
filesystem-relative pathnames in some external scheme, or whether
it makes sense to remember, for each filesystem, the set of external
references it makes, or whether there's some authority/hint duality
in either kind of mirroring.  What are we aiming at?  We say
"namespace management" or "global namespace mappings," but what do
we mean?

> a clear case for this aspect of namespace functionality.

Good, but I just want to help clarify what we mean by "namespace
functionality" here.  I'm all for a first-class abstract identity
for filesystems.  What else is needed?

            Craig

Craig Everhart

---

From: Ted Anderson <[email-masked]>
Date: Wed, 13 Apr 2005 09:01:21 -0400

> you're calling a "namespace mapping"?  You might well disagree,

This is a key question to address, see below.

> the residencies of the filesystems).  Is that what you mean with (3)?

Yes.  The decoupling of namespace and replica/location management is a 
very good idea.  I think all 5 of these features are best addressed by 
an external repository that maps a stable filesystem name to its current 
(or historical) location.

> "namespace management" or "global namespace mappings," but what do

This is a clarification we need to make so we can agree on specifically 
what we are addressing.

Manuel's post[1] introduced a three-tier naming architecture that 
explicitly separates the path naming from the location resolution using 
a filesystem identity as a level of indirection between a pathname and 
its physical address(es).  I have long thought that this is the right 
approach.

Deferring for the moment the question of how mapping from pathnames to 
filesystem identities is performed, Manuel's note focuses on the 
question how the location resolution of those identities is done.  In 
particular, it suggests properties of an interface to such a service and 
a few attributes to accompany the basic location mappings.

This suggests three subtopics for discussion that can advance this phase 
of the namespace issue:
  1. Is a three-level namespace that separates path naming from the 
location resolution using a filesystem identity the right architecture?
  2. What interface should be used for location resolution component?
  3. Should attributes be defined to enhance the location information?

> for filesystems.  What else is needed?

Does the above clarify my position?  It sounds like Craig's 
recommendation of an "unchanging filesystem identity as a first-class 
item" would be consistent with the three-level architecture.  Charles, 
how does this fit with your thinking?  Others?

Ted Anderson

[1] http://www1.ietf.org/mail-archive/web/nfsv4/current/msg01653.html