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

From: James Lentini <[email-masked]>
Date: Thu, 9 Oct 2008 15:38:43 -0400 (EDT)

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

Attendees
---------

Dan Ellard (BBN)
Craig Everhart (NetApp)
Paul Lemahieu (EMC)
James Lentini (NetApp)
Renu Tewari (IBM/ARC)
Robert Thurlow (Sun)
Mario Wurzl (EMC)

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.

  [AI] James Lentini will send message to fedfs list notifying subscribers that 
       the fedfs list will be deprecated and instructing people to switch to 
       the NFSv4 list.

  Complete.

+ Stimulating discussion on the NFSv4 working group list

  We'd like to have more interactions with the working group at large.

  Are the documents complete?

  We think it would make sense to start with the requirements document.

  For next week, we will review the requirements document. Feedback can be 
  sent in email or given at the next meeting. Our goal will be to determine if
  the document is complete from our perspective.

+ Root Fileset Schema

  Renu sent a nice writeup in email on our discussions thus far. We 
  reviewed her writeup:

  LDAP replication does not use a master/slave model. All of the LDAP 
  instances are masters. Any LDAP instance can be updated and it will 
  be replicated to the others. The last write to an object will win.

  How long does it take servers to communicate changes? It can be anywhere
  from almost immediately to 15 minutes depending on the implementation.

  The LDAP working group did not define a replication protocol initially. 
  Each implementation (Active, iPlanet,...) had its own. This had problems.
  There have been attempts to address this. Normally, the synchronization is 
  on an object type basis. This mechanism is described in RFC2307. Some of 
  the synchronization mechanisms are specific to two implementations: between 
  Active Directory and iPlanet or between Active Directory and OpenLDAP. Mario 
  will look into this further. Mario has not looked into how iPlanet and 
  OpenLDAP can synchronize.

  Have we reached a consensus on having a master NSDB?

  If LDAP does not support synchronization between arbitrary instances, 
  can we require it?

  To date, we've defined an NSDB to be one or more LDAP instances. As long 
  as the LDAP instances withing a single NSDB can synchronize between
  themselves, this will work.

  The proposal is to not allow multiple administrative entities to change 
  the root fileset. The administration of the root fileset is only in one 
  administrative domain.

  How do we represent the root fileset schema?

  The proposed approach is to have the root fileset be a pseudo directory.
  The file server's will create a representation of the root fileset on the
  fly.

  Are there replication issues with this? No, no issues beyond those for 
  normal FSLs that may have copies in multiple locations.

  We generated several questions:
   How does the server generate file handles?
   Will the root fileset have its own unique file system id?
   How will the file server indicate that the contents of the root fileset 
    have changed?
   Does the schema need to contain mtime information?

  Observation: The root fileset is similar to the pseudo root in NFSv4.

  Proposal: The modified time on a directory that contains one or more junctions
  should be the same as the most recent junction.

  Rational: This will ensure that the client will know that the junction has
  changed.

  How frequent does the server need to update the mtimes?

  We ran through an example of how the root fileset would be used:
  1. The client locates the federated root fileserver using DNS.
  2. The client gets the fileserver's root fh and does a READDIR.
  3. The fileserver sends a query to the NSDB requesting all the children 
     of the root.
     NOTE: how does the fileserver know it should go to the NSDB?
  4. The results to the server indicate what is under the root fileset.

  There are two possibilities for the LDAP schema:
  A. Each directory is represented by a unique object in LDAP.
  B. The entire root fileset layout is described, in bulk, in a single 
     LDAP object

  For option A, the directory hierarchy does not need to be reflected 
  in LDAP. The entries can describe their relationship, but be on the 
  same level in LDAP if necessary.

  A disadvantage of option B is that the size of the root fileset would
  be limited.

  How many entries do we expect in the root fileset? Is there a good way to 
  get data on this? Using automounter maps, how many entries would be expected 
  to be created. Does the ease of use of FedFS result in more entries.

+ Next week

 - review requirements documents
 - continue Root Fileset Schema discussion
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4