Subject: [nfsv4] FedFS Meeting Minutes, 08/20/2009

From: James Lentini <[email-masked]>
Date: Thu, 20 Aug 2009 14:53:11 -0400 (EDT)

FedFS Meeting Minutes, 08/20/2009
---------------------------------

Attendees
---------

Andy Adamson (NetApp)
Craig Everhart (NetApp)
Sorin Fabish (EMC)
James Lentini (NetApp)
Pavan Mettu (Sun)
Trond Myklebust (NetApp)
Chris Stacey (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 week's meeting with this announcement.

+ Review NSDB Draft Changes
 
 We reviewed these changes to the NDSB draft:

 - Added suggestion to separate NSDB data from other LDAP data.
 - Prefixed LDAP object identifier names with fedfs
 - Updated LDAP query examples to use LDAP URI syntax
 - Minor clarifications for security considerations section

 Feedback is that the changes look good.

 [AI] James Lentini will republish the NSDB draft with these changes later
      today.

 [AI] James Lentini will send the updated NSDB draft for LDAP expert review

+ Review SNSDB Code Updates

 We reviewed these changes to the SourceForge project:

 - indentation style
 - added fedfs prefix
 - shared library build target

 James posted this code for review last Thursday.
 James had previously sent these to Dan Ellard for review. 

 [AI] James Lentini will checkin these changes to the SourceForge project 
      today.

+ Discuss DNS SRV Feedback

 Craig reviewed the DNS Directorate's feedback on the DNS SRV draft in the
 areas of:

 - Prune discussion of DNS operations
 - "second-level directories"
 - name for client mount point?
 - RW/RO optional name?  What NFS mount options to suggest for the root
   dirs (e.g., "intr")?

 The draft currently has some recommendations on how to address the
 resiliency of the target servers. This discussion is probably best for a 
 different document.

 There was some confusion over the term "second-level directories" that Craig
 will be clearing up. 

 Nico Williams raised a concern about what path the client mounts on the 
 target fileserver. The RR is unable to store an unbounded text string and the 
 draft states that these fileserver's pseudo root should be mounted. We
 discussed the ramifications of this. Craig is going to take the topic offline
 and address it in the next version of the draft.

 The draft recommends the convention that /nfs4 be used. Nobody proposed an 
 alternative convention. The consensus was to keep this as a recommendation
 (it is not a requirement).

 The reviewers found the . notation to indicate a read-only filesystem 
 problematic. Craig plans to drop this from the next version.

 What mount options should be recommended? The consensus was none. The client
 will be free to choose. It was noted that one might want the default options 
 for things named/mounted explicitly to be different than the options for 
 servers discovered while navigating the global namespace. 

 Craig plans to wait a week or two for additional comments and then update the
 draft.

+ Austin NFS Bake-a-thon

 Rob and Pavan plan to attend from Sun with an FedFS-capable NFS server. Their 
 server is currently using a local LDAP database to generate referrals. They 
 have implemented the FedFS queries and are using an LDAP client (JXplorer 
 http://www.jxplorer.org) to add and remove records in the NSDB. The server 
 isn't likely to support the admin protocol in Austin.

 They will be using the latest FedFS schema (the one that will be in the -03 
 NSDB draft). Those interested in interop testing should plan accordingly.
 
 Trond announced that the NFS client has just added the basic code to handle
 DNS names in referrals. This functionality should be merged into mainline
 Linux before bake-a-thon. Trond hopes to test interoperability with the Sun
 Fedfs-enabled server.

 We will keep this topic on the agenda as a recurring item to coordinate in
 preparation for the Bake-a-thon.

+ FedFS operations for NFSv4.2?

 Sorin has been looking at some work from CMU on namespace scalability. 
 He has some concerns about what happens when there are billions of 
 objects in a namespace. Some of these are related to pNFS, not FedFS. 

 Craig pointed out that a federated namespace allows the client to structure
 the namespace to deal with these issues.

 Sorin offered to write up the problem statement and give an example of the 
 issue in an email to the WG list.