Subject: [nfsv4] FedFS Meeting Minutes, 10/16/2008

From: James Lentini <[email-masked]>
Date: Thu, 16 Oct 2008 15:47:22 -0400 (EDT)

FedFS Meeting Minutes, 10/16/2008
---------------------------------

Attendees
---------

Dan Ellard (BBN)
Craig Everhart (NetApp)
James Lentini (NetApp)
Renu Tewari (IBM/ARC)
Robert Thurlow (Sun)

Minutes
-------

+ IETF Note Well Agreement

  This is a reminder that our discussions are governed by the 
  IETF Note Well Agreement. See:

    http://www.ietf.org/NOTEWELL.html

  We will start each weeks meeting with this announcement.

+ Review action items

  [AI] James Lentini will research how to deprecate the old 
       individuals drafts.

  Open. James asked other IETF authors what they had done 
  when a document was published as an individual draft 
  and then re-published as a working group draft. Most don't 
  worry about expiring an old draft. One respondent noted 
  that the IETF secretariat may be able to update the document's 
  replaced state. James has written the secretariat and 
  expects an answer in 5 days. If the procedure to deprecate 
  the old drafts is simple, we will do it. Otherwise, we will 
  allow them to expire on their own after 185 days.

+ Review requirements documents

  We reviewed the requirements document.

  Robert Thurlow sent his detailed notes to the mailing list.

  We discussed the text in requirement R1.

  The NOTE at the end of R1 says "this" requirement has been called 
  into question. R1 has 5 sub-requirements. The NOTE is unclear on 
  which one or multiple sub-requirements have been called into question.
  The consensus was that the text in the NOTE was outdated and that the 
  requirement had been generally agreed upon.

  We discussed the text in R1.C. This text does not read like a requirement.
  Instead it is a general description of how the FSN's work. We agreed that 
  it could be removed.

  We discussed the text for R7 and decided that R7 needed to be clarified 
  with an example and the requirements for the root namespace discovery and 
  organization needed to be added.

  [AI] Renu Tewari will draft root namespace requirements.

  [AI] Robert Thurlow volunteered to draft new text for the overview and R1.

  We had an extended discussion on the meaning of R8. We observed that this
  requirement only included the file server. Our protocols provide this
  information in the NSDB. We agreed that one motivation for this requirement 
  is to provide a simple mechanism for a administration tool to be able to 
  enumerate the namespace. 

  It was observed that keeping the junction information in the file servers 
  and NSDB synchronized is a difficult task. For example: if a directory that 
  is a junction is deleted on the file server, is the file server's
  representation of the namespace correct or is the NSDB's representation
  correct?

  It was asserted that having the junction information available in the NSDB 
  will allow an admin tool to be implemented more efficiently.

  [AI] James Lentini will draft requirements for what access an administrative 
       tool will need for junctions.

+ Continue Root Fileset Schema discussion

  We ran out of time. We will discuss this next week.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Robert Thurlow <[email-masked]>
Date: Wed, 22 Oct 2008 14:48:42 -0600

>   [AI] Robert Thurlow volunteered to draft new text for the overview and R1.

Here is my proposed new text for the fed-fs requirements document
(draft-ietf-nfsv4-federated-fs-reqts-00.txt).  Let me know if I
have helped things or not :-)

Overview section:

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 a
    "junction key" 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).  A junction key is
    implemented as the combination of the name of the NSDB and the FSN;
    we specify that the FSN is unique within the scope of the NSDB,
    which makes the junction keys 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.

Requirement R1:

    R1:   Requirements of each FSN:

          a.  Each FSN MUST be unique within the scope of an NSDB (so
              that the junction key can be globally unique).

          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

---

From: James Lentini <[email-masked]>
Date: Tue, 28 Oct 2008 16:34:28 -0400 (EDT)

>    filesets.  These references we call "junctions".  To provide

     containing files and directories, which may also reference other
     filesets.  We call these references "junctions".  To provide

>    implemented as the combination of the name of the NSDB and the FSN;

I find the above wording slightly misleading. Technically, the FSN 
contains the name of the NSDB. 

I'd suggest omitting the discussions on the junction key. I wonder if 
this is too much detail for the requirements document overview.

---

From: Peter Staubach <[email-masked]>
Date: Tue, 28 Oct 2008 16:37:16 -0400

>      filesets.  We call these references "junctions".  To provide

Just a nit --

How about "These references are called "junctions"."?

It seems like things read better if first person is avoided.

    Thanx...

       ps

---

From: Robert Thurlow <[email-masked]>
Date: Tue, 28 Oct 2008 14:39:07 -0600

> The revised overview looks good. A few minor comments below:

Thanks!

>      filesets.  We call these references "junctions".  To provide

Oh, of course - I dropped a word there, clearly.

> contains the name of the NSDB. 

True; the junction key is really implemented as an FSN itself.

> this is too much detail for the requirements document overview.

I could agree about level of detail.  "junction key" shows up
in the glossary and in the text, so if we nuke it everywhere,
that might be good.

Rob T

---

From: James Lentini <[email-masked]>
Date: Thu, 30 Oct 2008 14:44:08 -0400 (EDT)

>              instance of the fileset it names within the federation at

Technically speaking, an FSN doesn't provide the location of the 
fileset it names. The FSN points to the NSDB and the NSDB provides 
information to locate the fileset.

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

(c) combines the previous two bullets nicely.

>              part of a fileset which has an assigned FSN.

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.