Subject: [nfsv4] FedFS Meeting Minutes, 04/09/2009

From: James Lentini <[email-masked]>
Date: Thu, 9 Apr 2009 15:28:38 -0400 (EDT)

FedFS Meeting Minutes, 04/09/2009
---------------------------------

Attendees
---------

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

+ Review Action Items

  - James Lentini will re-phrase the root fileset's attribute requirements.

   ----

   A root fileset will be replicated throughout the federation. Therefore, a compact 
   representation that is compatible with heterogeneous fileserver implementations is 
   necessary. With this in mind, a root fileset will support a limited number of 
   recommended attributes as shown in the following table. The "Supported" column
   records the a root fileset's ability to contain the specified attribute. A 
   "Y" in the column means the attribute MUST be supported, a "N" means the 
   attribute MUST NOT be supported, and a "M" means the attribute MAY be 
   supported.

   +--------------------+----+-----------+------------------+
   | Name               | Id | Supported | Defined in:      |
   +--------------------+----+-----------+------------------+
   | acl                | 12 |     N     | Section 6.2.1    |
   | aclsupport         | 13 |     N     | Section 6.2.1.2  |
   | archive            | 14 |     M     | Section 5.8.2.1  |
   | cansettime         | 15 |     M     | Section 5.8.2.2  |
   | case_insensitive   | 16 |     M     | Section 5.8.2.3  |
   | case_preserving    | 17 |     M     | Section 5.8.2.4  |
   | change_policy      | 60 |     M     | Section 5.8.2.5  |
   | chown_restricted   | 18 |     M     | Section 5.8.2.6  |
   | dacl               | 58 |     N     | Section 6.2.2    |
   | dir_notif_delay    | 56 |     M     | Section 5.11.1   |
   | dirent_notif_delay | 57 |     M     | Section 5.11.2   |
   | fileid             | 20 |     M     | Section 5.8.2.7  |
   | files_avail        | 21 |     M     | Section 5.8.2.8  |
   | files_free         | 22 |     M     | Section 5.8.2.9  |
   | files_total        | 23 |     M     | Section 5.8.2.10 |
   | fs_charset_cap     | 76 |     M     | Section 5.8.2.11 |
   | fs_layout_type     | 62 |     N     | Section 5.12.1   |
   | fs_locations       | 24 |     Y     | Section 5.8.2.12 |
   | fs_locations_info  | 67 |     Y     | Section 5.8.2.13 |
   | fs_status          | 61 |     Y     | Section 5.8.2.14 |
   | hidden             | 25 |     M     | Section 5.8.2.15 |
   | homogeneous        | 26 |     M     | Section 5.8.2.16 |
   | layout_alignment   | 66 |     N     | Section 5.12.2   |
   | layout_blksize     | 65 |     N     | Section 5.12.3   |
   | layout_hint        | 63 |     N     | Section 5.12.4   |
   | layout_type        | 64 |     N     | Section 5.12.5   |
   | maxfilesize        | 27 |     M     | Section 5.8.2.17 |
   | maxlink            | 28 |     M     | Section 5.8.2.18 |
   | maxname            | 29 |     M     | Section 5.8.2.19 |
   | maxread            | 30 |     M     | Section 5.8.2.20 |
   | maxwrite           | 31 |     M     | Section 5.8.2.21 |
   | mdsthreshold       | 68 |     N     | Section 5.12.6   |
   | mimetype           | 32 |     M     | Section 5.8.2.22 |
   | mode               | 33 |     M     | Section 6.2.4    |
   | mode_set_masked    | 74 |     M     | Section 6.2.5    |
   | mounted_on_fileid  | 55 |     M     | Section 5.8.2.23 |
   | no_trunc           | 34 |     M     | Section 5.8.2.24 |
   | numlinks           | 35 |     M     | Section 5.8.2.25 |
   | owner              | 36 |     M     | Section 5.8.2.26 |
   | owner_group        | 37 |     M     | Section 5.8.2.27 |
   | quota_avail_hard   | 38 |     M     | Section 5.8.2.28 |
   | quota_avail_soft   | 39 |     M     | Section 5.8.2.29 |
   | quota_used         | 40 |     M     | Section 5.8.2.30 |
   | rawdev             | 41 |     M     | Section 5.8.2.31 |
   | retentevt_get      | 71 |     M     | Section 5.13.3   |
   | retentevt_set      | 72 |     M     | Section 5.13.4   |
   | retention_get      | 69 |     M     | Section 5.13.1   |
   | retention_hold     | 73 |     M     | Section 5.13.5   |
   | retention_set      | 70 |     M     | Section 5.13.2   |
   | sacl               | 59 |     N     | Section 6.2.3    |
   | space_avail        | 42 |     M     | Section 5.8.2.32 |
   | space_free         | 43 |     M     | Section 5.8.2.33 |
   | space_total        | 44 |     M     | Section 5.8.2.34 |
   | space_used         | 45 |     M     | Section 5.8.2.35 |
   | system             | 46 |     M     | Section 5.8.2.36 |
   | time_access        | 47 |     M     | Section 5.8.2.37 |
   | time_access_set    | 48 |     M     | Section 5.8.2.38 |
   | time_backup        | 49 |     M     | Section 5.8.2.39 |
   | time_create        | 50 |     M     | Section 5.8.2.40 |
   | time_delta         | 51 |     M     | Section 5.8.2.41 |
   | time_metadata      | 52 |     M     | Section 5.8.2.42 |
   | time_modify        | 53 |     M     | Section 5.8.2.43 |
   | time_modify_set    | 54 |     M     | Section 5.8.2.44 |
   +--------------------+----+-----------+------------------+

   The root fileset MUST NOT contain any named attributes. The root fileset
   MUST conform to all other attribute requirements defined in Section 5.6 
   of [NFSv4.1]. Attributes added in future versions of NFSv4 MAY be 
   supported.

   ---

   The fsid, mounted_on_fileid, and change_policy are mentioned 
   in the specification as recommended attributes for an absent 
   fileset. Chapter 11 has details on this.

   The text needs to be clarified to note that these are the 
   requirements for what attributes an object in the root 
   fileset may or may not have. An attribute listed as "Y" in 
   this list in not required to be set for every object in 
   root fileset.

   [AI] James Lentini update root filset attribute requirements.

  - Renu Tewari will create a root fileset I-D.

    Renu has put together a rough draft. The document will
    have some consistency requirements and use a "pull model" 
    for communicating root fileset information between the 
    NSDB and fileservers.

    Renu will clean up the document and send it out before 
    the next call.

    We discussed ways to allow a push model even if the 
    standard does not mandate it.

    An ONC RPC Callback would be an option if there was an 
    ONC RPC Fileserver-to-NSDB protocol.

    A goal is to limit the amount of information the fileservers 
    need to pull from the NSDB when an update occurs. One way to 
    to this would be to allow for different levels of the root 
    fileset to be retrieved separately. Each level might have its 
    own TTL value.

    Paul was comfortable with the root fileservers being 
    loosely coupled so that the consistency of the root fileset 
    might vary by a few minutes, but not by hours.
   
    If one junction point changes, we don't want to have the entire 
    root fileset change. One way to accomplish this in LDAP would 
    be for each directory to have a different entry. Each entry gives 
    another level of the file system. There is a possibility that each 
    level could be numbered or have a delta.

  - James Lentini schedule FedFS meeting time to discuss cache invalidation
    hints.

    Done.

+ Fileserver hints for invalid cached FSN -> FSL mappings (during migration)

  The problem statement is roughly as follows:

  There are 3 fileservers: A, B, and C.

  Fileserver A has a junction that contains FSN x. 

  FSN x maps to B://user/bob

  At some point, the bob fileset migrates to fileserver C.

  FSN x now maps to C://user/bob

  The problem is that fileserver A may have cached the 
  FSN X -> B://user/bob mapping. 

  How do we invalidate the mapping?

  One option would be to provide guidance on the upper bound for how 
  long a fileserver is allowed to cache an FSN -> FSL mapping. 

  If it is really cheap to query the FSN -> FSL mapping, then it is really 
  silly for the fileserver to wait 30 minutes to contact the NSDB.

  #1. Another option is the recommend that fileserver B have a junction 
  a B://user/bob that refers the client to C://user/bob. This seems 
  reasonable, but does not work if fileserver B is taken offline (perhaps 
  for maintenance) or if the client is unable to contact B.

  #2. Another option would be some sort of multicast protocol to send 
  out FSN -> FSL changes. This would have the disadvantage of 
  generating a lot of traffic in the federation. This would be another 
  administrative protocol that would be performed at the same time 
  the NSDB was updated. This idea didn't appeal to anyone.

  #3. Another option would be to have an ONC RPC protocol that pushed 
  a callback back to fileservers that registered an interest in a 
  particular FSN. This might also generate a lot of traffic.

  We concluded that implementation experience would be useful in 
  this area. At the moment, option #1 seems the most appealing.