Subject: [nfsv4] FedFS Meeting Minutes, 11/13/2008

From: James Lentini <[email-masked]>
Date: Thu, 13 Nov 2008 16:29:12 -0500 (EST)

FedFS Meeting Minutes, 11/13/2008
---------------------------------

Attendees
---------

Craig Everhart (NetApp)
Paul Lemahieu (EMC)
James Lentini (NetApp)
Renu Tewari (IBM/ARC) [for the last 5 minutes]
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.

+ IETF NFSv4 Meeting

  James is working on a draft slide deck. He will send it to the rest of 
  the group by Monday. 

  Robert suggested that we request participation from someone with LDAP 
  expertise. James agreed and will add this to the presentation.

+ New version of the requirements draft

  [AI] James Lentini will create a new version of the requirements draft next
       week

+ Recording a fileset's outgoing referrals (junctions) in the NSDB

  We've discussed this issue in the past. It has come up again on the mailing
  list.

  If one wants to browse the namespace by only interacting with NSDBs,
  then this would be needed.

  We speculated that browsing the namespace would be easier (fewer nodes to
  contact) if the information is in the NSDB.

  The problem is that the junction information would be in two places and 
  hence could get out of sync. If one location is authoritative, a tool 
  could be created to scrub the data.

  A potential disadvantage of relying on file servers to provide this 
  data is each file server must be contact for the information. In a 
  large federation with many file servers this would potentially be slow.

  Even with the filer server approach, there is a potential of receiving stale 
  information. A particular implementation may not be able to guarantee that 
  the data it is returning is valid (if for example a junction is being 
  deleted in parallel with the query) or the query could return moments 
  before a junction is deleted.

  We have an assumption that there will be far fewer NSDBs than file servers.
  This makes sense given that the file servers have higher network, etc.
  requirements. This leads to NSDBs being consolidated.

+ NSDB Enumeration

  The email discussions over the past few days have pointed out that there 
  is no way to enumerate the NSDBs in a domain.

  In the current design, when an admin creates an FSN->FSL mapping and 
  configures a junction, the admin uses an NSDB known a priori. Would it be
  useful for the admin to be able to query a file server to determine which
  NSDB to use? Nobody thought that this was a requirement.

  We then discussed how to add storage into the namespace. The storage may 
  be added for several reasons: new equipment, an existing data center that
  wants to start using the global namespace, the merger of two companies 
  with existing namespaces, etc.

  We should consider how to import information into the namespace databases.
  This is particularly important because the reason an organization would 
  want a global namespace is because it already has a significant amount of 
  existing storage.

  Storing metadata for a fileset would be useful. For example, being able 
  to annotate a fileset with cost center, admin owner, etc.

  One approach would be for the file servers to be able to register their 
  referable items in an NSDB.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4