Subject: Re: [nfsv4] Overview and R1 rewrites (was Re: FedFS Meeting Minutes, 10/16/2008)

From: Robert Thurlow <[email-masked]>
Date: Thu, 06 Nov 2008 11:39:56 -0700

James Lentini wrote:

> I assume that the requirement will conclude with this paragraph from 
> the original document:
> 
>          Not all filesets in the federation are required to have a FSN
>          or be reachable by a FSL.  Only those filesets that are the
>          target of a junction (as described in R3) are required to have
>          an FSN.

I didn't find that I agreed with that, actually.  If files aren't
reachable via an FSN, they're not in the federation and won't
be seen by all clients - is that incorrect?  How?

Here's the wording I came up with, without "junction keys":

3.  Overview

    Today, there are collections of fileservers that inter-operate to
    provide a single namespace comprised of filesystem resources provided
    by different members of the collections, joined together with inter-
    filesystem references.  The namespace can either be assembled at the
    fileservers, the clients, or by an external namespace service, and
    is often not easy or uniform to manage.  The requirements in this
    draft are meant to lead to a uniform server-based namespace which
    is capable of spanning a whole enterprise and which is easy to
    manage.

    We define some terms to better describe the solution space.  A
    "fileset" is the abstract view of a filesystem in a uniform
    namespace, and may be implemented behind that abstraction by one or
    more physical filesystems at any given time.  Each fileset has a
    name called an "FSN" (fileset name), and each physical filesystem
    has a fileset location ("FSL").  A fileset is a directory tree
    containing files and directories, which may also references to other
    filesets.  These references we call "junctions".  To provide
    location independence, a junction does not contain information about
    the location of the real resource(s), but instead contains the
    FSN of the target, which can be used to look up the location
    information.  A service which can be used to map from FSN to FSL(s)
    we call a namespace database service (NSDB).  The FSN is composed
    of the name of the NSDB and a UUID unique within the NSDB, which
    makes the FSN globally unique.

    The NSDB provides a level of indirection from the virtual paths
    in the uniform namespace to the actual locations of files.  This
    makes it possible for servers to direct clients to the proper
    locations by existing mechanisms (e.g. the referrals mechanism
    within the [NFSv4] and [NFSv4.1] protocols).  Updates to the
    locations makes it possible to support migration and replication
    of physical filesystems that comprise the namespace, in a way
    that is transparent to filesystem clients.

    R1:   Requirements of each FSN:

          a.  Each FSN MUST be globally unique by being composed of
              a reference to an NSDB and an identifier unique within
              that NSDB.

          b.  The FSN MUST be sufficiently descriptive to locate an
              instance of the fileset it names within the federation at
              any time.

          c.  All FSNs MUST be invariant when their underlying
              filesystems
              move or are replicated; only mappings from FSN to FSL(s)
              change under these transformations.

          d.  All files accessible from the global namespace MUST be
              part of a fileset which has an assigned FSN.

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

---

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 6 Nov 2008 14:45:41 -0500

Robert, I generally like this cleanup very much.  Thanks.

I have to assume that the text that James pointed out was meant to mean
files and filesets that were supposed to be "root filesets",
discoverable through other (bootstrapping-like) means.

But I'm not sure what requirement R1.b. is meant to say.  Can you
illustrate it somehow?  It seems to me that an FSN isn't enough for
locating such an instance unless you can rely on an NSDB.  Is this
making some statement of availability of an NSDB service?

Thanks.

		Craig

> -----Original Message-----
> From: Robert Thurlow [mailto:[email-masked]] 
> Sent: Thursday, November 06, 2008 1:40 PM
> To: Lentini, James
> Cc: [email-masked]
> Subject: Re: [nfsv4] Overview and R1 rewrites (was Re: FedFS 
> Meeting Minutes, 10/16/2008)
> 
> James Lentini wrote:
> 
> I didn't find that I agreed with that, actually.  If files 
> aren't reachable via an FSN, they're not in the federation 
> and won't be seen by all clients - is that incorrect?  How?
> 
> ...

---

From: Robert Thurlow <[email-masked]>
Date: Thu, 06 Nov 2008 13:18:57 -0700

>>               instance of the fileset it names within the 

Hmmm, looking at this again, I don't see why we should have
R1.b. - if the FSN is globally unique, it can be used (via
the NSDB) to find an instance.  I had no visions of being
able to be without access to an NSDB (or locally cached
info from one).  How would you feel about drooping R1.b.?

Rob T

---

From: James Lentini <[email-masked]>
Date: Thu, 6 Nov 2008 15:21:55 -0500 (EST)

> discoverable through other (bootstrapping-like) means.

That would be one example. The other example that I assume the 
original authors had in mind was of file server that is part of the 
federation and serving a (legacy) fileset that is not part of the 
namespace.

---

From: James Lentini <[email-masked]>
Date: Thu, 6 Nov 2008 15:24:40 -0500 (EST)

> info from one).  How would you feel about drooping R1.b.?

I agree. It should not imply that the FSN can be used to locate a 
fileset without the NSDB.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 6 Nov 2008 15:32:53 -0500

> From: Lentini, James 
> > I have to assume that the text that James pointed out was meant to 
> > mean files and filesets that were supposed to be "root filesets", 
> That would be one example. The other example that I assume 
> the original authors had in mind was of file server that is 
> part of the federation and serving a (legacy) fileset that is 
> not part of the namespace.

It's hard to think of this as a fileset "in the federation."

But now I remember what the original point was.  The original text,
re-line-wrapped:

  Not all filesets in the federation are required to have a
  FSN or be reachable by a FSL.  Only those filesets that are
  the target of a junction (as described in R3) are required
  to have an FSN.

The idea was that a single file server might export lots of filesets,
joined by intra-fileserver links through some internal mechanism.  That
is, a client would traverse from fileset A to fileset B, both on the
same server.  When the file server encountered the intra-fileserver link
at the leaf of fileset A that would take it to fileset B, it would
simply make the traversal as per NFS4.  But fileset B wouldn't need to
have a separate FSN; nor would it need to be reachable by an FSL.  Of
course, if fileset B were to be relocated onto another file server, both
of these would have to be added.

Does that make more sense?

		Craig

---

From: James Lentini <[email-masked]>
Date: Thu, 6 Nov 2008 16:28:42 -0500 (EST)

> Does that make more sense?

It does to me.

---

From: Robert Thurlow <[email-masked]>
Date: Thu, 06 Nov 2008 15:21:05 -0700

>> How would you feel about drooping R1.b.?
> 

That leaves this:

          b.  All FSNs MUST be invariant when their underlying
              filesystems move or are replicated; only mappings from
              FSN to FSL(s) change under these transformations.

          c.  All files accessible from the global namespace MUST be
              part of a fileset which has an assigned FSN.

Rob T

---

From: Robert Thurlow <[email-masked]>
Date: Thu, 06 Nov 2008 15:36:04 -0700

Everhart, Craig wrote:

> The original text, re-line-wrapped:
> 

Since a fileset is, by our definition, a global namespace
abstraction, isn't the whole collection of files available
from the server a fileset, i.e. a FSN-named piece of the
collective?  If the client does not have to cross an NSDB-
backed referral to see the whole collection of files, I
don't see why we need to talk about this at all - the
internal details are not, in fact, filesets in the FedFS
sense.

Rob T

---

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 6 Nov 2008 17:48:38 -0500

> backed referral to see the whole collection of files, I don't 
> see why we need to talk about this at all - the internal 
> details are not, in fact, filesets in the FedFS sense.

I'll have to comb the docs better, but you could be right.

The case I'm worried about is whether the FedFS fileset encompasses the
whole possibly-complex thing, complete with internal linkages.  Servers
A1 and A2 in one collection (the old "collection") might even host file
systems that come with their own FSIDs and fs_location_info values on
the internal targets, or with no fs_location_info at all.  The client
might not have to cross an NSDB-backed referral, but it might need to
cross a referral that doesn't reside in the NSDB, but which (e.g.,
today) is resolved within the collection.

The simplest thing to do is to define "fileset" in this case as
something needing the full FSN/FSL treatment, irrespective of FSID or
fs_location references.  I'll look through the requirement doc to see if
we do that.

		Craig

---

From: Peter Staubach <[email-masked]>
Date: Fri, 07 Nov 2008 11:26:59 -0500

>              FSN to FSL(s) change under these transformations.

This would imply that it is not possible to replicate an FSN
to a different portion of the namespace controlled by a
different NSDB?

Off hand, this doesn't seem necessarily wrong or bad, but does
make me wonder a bit.  It would seem to impose some requirements
on the administration of the namespace(s) within a single
entity.

(Perhaps a slightly different topic, but while I am thinking
about it, is there support which to find out which NSDB might
contain the mapping for a specific fileset, something like
someone's home directory or /usr/dist and some such?)

>              part of a fileset which has an assigned FSN. 

This doesn't seem like a requirement of an FSN to me.  It feels
more to me like an additional high level requirement of the
global namespace.

    Thanx...

       ps

---

From: "Renu Tewari" <[email-masked]>
Date: Tue, 11 Nov 2008 15:40:39 -0800

On Fri, Nov 7, 2008 at 8:26 AM, Peter Staubach <[email-masked]> wrote:
>>> I agree. It should not imply that the FSN can be used to locate a fileset
>>> without the NSDB.
>>
>> That leaves this:
>>

The FSLs are the replicas and they could be anywhere as long as the
NSDB "owning" the FSN knows about them. Or when you say replicate to a
different part of the namespace it is more than you want to create  a
new junction to this FSN?

> more to me like an additional high level requirement of the

Does this imply that we cannot have a referral that is outside the
fed-fs boundary?

---

From: Peter Staubach <[email-masked]>
Date: Wed, 12 Nov 2008 09:17:27 -0500

> new junction to this FSN?

I don't understand how to read this.  An FSL is the location of
a file set, which is identified by a (FSN, NSDB) tuple, right?
A replica would be a copy of some file set, assigned the same
FSN as the original, but with a different FSL, right?

I am thinking of a company, with two administrative domains,
geographically separate, which decides to centralize the
administration of a set of tools which are used commonly
throughout the company.  They group these tools in a file
set and then want to replicate the file set so that both domains
get access to the file set in their own geographic region.

At first glance, each administrative entity would probably want
their own NSDB, for the namespace within the administrative
domain that they control.  Can they do this and also gain access
to the shared file set containing the tools?

---

Perhaps I am not understanding the concept of the NSDB?  I
thought that it was, perhaps too simply put, a database
containing the mapping of FSNs to FSLs.  Queries on it would
be to discover things like "where is my home directory" or
"where are the tools".  I was thinking of it like a virtual
file system in itself, describing a namespace.  Am I too
simplistic and just don't understand the NSDB yet?

    Thanx...

       ps

---

From: James Lentini <[email-masked]>
Date: Wed, 12 Nov 2008 12:20:35 -0500 (EST)

On Wed, 12 Nov 2008, Peter Staubach wrote:

> > > > > fileset

The FSN is the tuple (NSDB,UUID).

> FSN as the original, but with a different FSL, right?

Yes.

> to the shared file set containing the tools?

This would be possible. An NSDB can have two instances, one in each 
location.

---

From: "Daniel Ellard" <[email-masked]>
Date: Wed, 12 Nov 2008 14:28:58 -0500

On Thu, Nov 6, 2008 at 1:39 PM, Robert Thurlow <[email-masked]> wrote:
> James Lentini wrote:
>
>> I assume that the requirement will conclude with this paragraph from the
>> original document:
>>

Sorry, perhaps too late to help out..

The original intent of these lines was to state that not every
file (or directory, or volume) hosted by a server in the federation
needs to be part of the namespace.  For example, if you have two
volumes hosted on a server (let's call them /a and /b) then just
because /a is used, as the target of a junction, as part of the global
namespace doesn't imply that /b is reachable in any manner as
part of the namespace.  Just because a server plays some role
in the namespace doesn't mean that everything on that server
is accessible.  Again, it's the principle of federation -- local decisions
are still local.  Not every file on every file server gets sucked into
the federation namespace.

The rest of the wording is fine, but I think this "anti-requirement"
is important.  We don't want people thinking "so, this means that
everyone can find my /etc/password.shadow?"

-Dan

---

From: Rob Thurlow <[email-masked]>
Date: Wed, 12 Nov 2008 13:50:47 -0700

Daniel Ellard wrote:

> Just because a server plays some role

That helps, and I agree with it.

Rob T

---

From: Rob Thurlow <[email-masked]>
Date: Wed, 12 Nov 2008 14:02:56 -0700

> to a different portion of the namespace controlled by a

Hi Peter, my contribution:

I think the FSL could be re-used by a different FSN, putting
it into a different part of the namespace.  This means your
example of different parts of the same company could have
separate FSNs in convenient parts of their namespaces which
would both effect referrals to the same files.  Does that help?

Rob T