Subject: [nfsv4] [FedFS] Meeting Minutes, 05/28/2009

From: James Lentini <[email-masked]>
Date: Thu, 28 May 2009 15:02:57 -0400 (EDT)

FedFS Meeting Minutes, 05/28/2009
---------------------------------

Attendees
---------

Andy Adamson (NetApp)
Craig Everhart (NetApp)
James Lentini (NetApp)
Paul Lemahieu (EMC)
Renu Tewari (IBM)
Rob 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 week's meeting with this announcement.

+ New meeting time?

  A regular meeting attendee has an permanent conflict with part 
  of this call.

  If a new time at which all regular participants can attend is found,
  we will move the call. Otherwise, we will need to keep this time.

  [AI] James Lentini will poll for times over email.

+ Bake-a-thon (June 15-19)
  http://www.connectathon.org/bakeathon/

  No news.

+ FSL Caching

  We briefly reviewed the problem statement and then 
  discussed the potential soluctions.

  An FSL cache needs to be updated whenever a FSL is added or 
  removed for an FSN.

  For reference, here is an example of the problem we are 
  attempting to solve: Suppose there are three fileservers named 
  A, B, and C and fileserver A contains a junction to fileset X
  stored on fileserver B. Now suppose that fileset X is migrated from 
  fileserver B to fileserver C and the corresponding FSL information for 
  fileset X in the appropriate NSDB is updated. If fileserver A has a 
  cached FSL for fileset X, a user traversing the junction on fileserver A 
  will be referred to fileserver B even though fileset X has migrated to 
  fileserver C. If fileserver A was not caching FSL records, it would have 
  obtained the correct location of fileset X from the NSDB.

  The possible options are:

  1. No caching

     No support for this.

  2. Administrative convention

     The proposal sent to the mailing list:

     http://www.ietf.org/mail-archive/web/nfsv4/current/msg07029.html
 
  3. Change client
	- add new client operation(s)
	- new client behavior: server assumes cache miss based on client
	  behavior (still requires changes to client software)

  4. List of caching fileservers per FSN

     The basic idea is to keep a list of fileserver's caching an FSN 
     in the FSN's NSDB record. When an FSL is added or removed from the FSN, 
     the admin software would push the update to all the fileservers on 
     the list.

     There was concern over the fact that this would be a persistent list 
     since it would survive NSDB reboots. What would be responsible for 
     maintaining the list?

     Would it be possible to update the list for another administrative
     domain? For example, a fileserver in one domain may have a junction 
     for an FSN in another domain. How would that fileserver change
     the remote NSDB's FSN record?

     How would the list be cleaned up? One idea was for entries on the list 
     to be timestamped. If an entry was older than some threshold (1 week?) 
     it would be ignored.

  5. FSN Delegations

     We would like a mechanism like NFS delegations that would allow 
     the fileserver to obtain a delegation on the FSN LDAP object and 
     be notified when the FSN object changed.

     James suggested that LDAP triggers might be of use. He found this 
     white paper on LDAP triggers:

     http://www.sun.com/blueprints/0204/817-5231.pdf

     Are LDAP triggers supported across LDAP implementations?

     [AI] Paul Lemahieu will research LDAP trigger functionality, 
          including standardization, scalability, and configurability 
          (conditions that can cause the trigger to fire).

  6. An upper bound on how long fileserver's are allowed to cache FSLs

     How long? Some number of seconds?

     Paul and Rob suggested using the worst case scenario to determine how many 
     referrals need to be supported per second, e.g. the "monday morning 
     login storm" scenario or the "compute farm reboot" scenario. 

     LDAP performance data, perhaps from Active Directory, would be useful.

     [AI] James Lentini will research LDAP performance numbers (queries per
          second and connections)