Subject: [nfsv4] [FedFS] Meeting Minutes, 5/20/2010

From: James Lentini <[email-masked]>
Date: Thu, 20 May 2010 15:53:29 -0400 (EDT)

FedFS Meeting Minutes, 5/20/2010
--------------------------------

Attendees
---------

Lawrence Anthony
Craig Everhart (NetApp)
Chuck Lever (Oracle)
Paul LeMahieu (EMC)
James Lentini (NetApp)
Trond Myklebust (NetApp)
Peter Staubach (EMC)
Renu Tewari (IBM)
Robert Thurlow (Oracle)

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.

+ Bake-a-thon

  Solaris will support referrals (fs_locations) over v4.1.

  Trond is looking forward to testing referrals in the 
  Linux 4.1 client. 

  A Windows pNFS client will be there.

+ Locating NSDB entries in an LDAP Directory

  We discussed the proposal described here:

  http://www.ietf.org/mail-archive/web/nfsv4/current/msg08005.html

  Rob observed that this was moving the information into our 
  part of the schema.

  Craig thought that this was a good strategy.

+ Admin Protocol

  - Replicas

  Rob wrote descriptions of procedures to associate replicas with a 
  fileset and sent them to the mailing list. Rob's proposal is 
  included below.

  Rob created separate operations to help separate the junction 
  concept from the replica concept.

  If a server has some scheme defined to return fs_locations[_info] 
  separate from FedFS, Rob does not see this being managed by the 
  FedFS Admin protocol.

  Trond agreed that it was not necessary to manage other schemes.

  In Rob's proposal, junction information takes precedent over 
  replication information.

  A fileset is identified by a path. The filesystem that contains 
  the last component of the path is the one the procedure targets.
  The fileserver will be able to determine this. All objects in the 
  fileset will then report the replica if queried.

  James asked if combining the two lookup functions had been considered.
  Rob said that it would be possible, but that he felt that keeping 
  the concepts separate was worthwhile.

  - NSDB Name Equivalence 

  Chuck asked if there were situations in which NSDB names should be 
  deemed equivalent? 

  James noted that the current Admin draft does not yet cite the 
  NFSv4 rules for preparing strings. Using the NFSv4 string prep 
  profile for NSDB names will eliminate some opportunities for 
  ambiguity.

  James also noted that the Admin draft defines two NSDB names 
  to be equivalent in the case that an NSDB name does not 
  include a port (e.g. nsdb.example.com and nsdb.example.com:389 
  are equivalent).

  Craig noted that case folding for character sets outside of 
  US ASCII can be complicated.

  Chuck raised the issue of a typo in an NSDB name. Is an 
  Administrator expected to be able to locate this record via 
  the protocol or local tools?

  We discussed if a procedure to list all of a fileserver's NSDB 
  parameters would be useful.
  
  We believe that the case insensitive string prep profile being 
  prepared for rfc3530bis will be used for NSDB Name strings. Use 
  of this profile should eliminate any ambiguity in the text about 
  character case in NSDB names.

  We discussed if a procedure to delete NSDB parameters would be 
  useful. The current text suggests that these records may be 
  removed when no junction references them (see the last paragraph 
  of section of 5.2).

+ Next Meeting
 
  Our next meeting will be in two weeks on June 3.

  We plan to start updating the NSDB and Admin drafts to 
  bring them in sync with our email and phone discussions.

-------------------------------------------------------------------

Rob Thurlow's draft describing procedures to set the replication 
locations for a fileset:

To support replication, we need something very like the current
FEDFS_CREATE_JUNCTION, FEDFS_DELETE_JUNCTION and FEDFS_LOOKUP_FSN.
We could add a flag to each and complicate the description of
the operations, but I feel better about writing them up as
distinct operations.

I propose to add the following:

To section 2, Protocol:

   ///      FedFsStatus FEDFS_ADD_REPLICATION(
   ///                   FedFsCreateJunctionArgs) = 7;
   ///      FedFsStatus FEDFS_REMOVE_REPLICATION(
   ///                   FedFsPathName) = 8;
   ///      FedFsLookupFsnRes FEDFS_LOOKUP_REPLICATION_FSN(
   ///                   FedFsLookupFsnArgs) = 9;

To section 5, Procedures:

   FEDFS_ADD_REPLICATION  Set an FSN representing the replication
       information for the fileset containing the pathname
   FEDFS_REMOVE_REPLICATION  Remove the replication information for
       the fileset containing the pathname
   FEDFS_LOOKUP_REPLICATION_FSN  Query the server to discover the
     current replication information (if any) at the given path

New section 5.7.  FEDFS_ADD_REPLICATION

   This operation indicates the replication information to be
   returned for a particular fileset.  An NFSv4.x client may
   request fs_locations or fs_locations_info at any time to detect
   other copies of this fileset, and this operation supports
   this by supplying the FSN the fileserver should use to respond.
   This FSN should be associated with the entire fileset in which
   the path resides, and should be used to satisfy fs_locations
   or fs_locations_info attribute requests whenever no junction
   is being accessed; if a junction is being accessed, the FSN
   specified by FEDFS_CREATE_JUNCTION will take precedence.

   This operation differs from FEDFS_CREATE_JUNCTION in that it
   controls a fileset-wide attribute not associated with a
   junction.

   The server SHOULD permit this operation even on read-only
   filesets, but MAY return FEDFS_ERR_ROFS if this is not possible.

   If the path contains an invalid UTF-8 character, then status
   FEDFS_ERR_BADCHAR must be returned.

   The path is REQUIRED to exist and be completely local to the server.
   It MUST NOT contain a junction.  If any component of the path is
   a junction, then this operation MUST fail with status FEDFS_ERR_NOTLOCAL.
   The path may contain a symbolic link (if supported by the local server),
   but the traversal of the path must remain within the server-local
   namespace.

   The server MAY enforce the local permissions on the path, including
   the final component.  If the path cannot be traversed because of
   insufficient permissions, or the final component is an unexecutable
   or unwritable directory, then the operation MAY fail with status
   FEDFS_ERR_ACCESS.

   The operation SHOULD fail with status FEDFS_ERR_NSDB_PARAMS if the
   fileserver does not have any connection parameters on record for the
   specified NSDB.

New section 5.8.  FEDFS_REMOVE_REPLICATION

   This operation removes any replication information from the
   fileset in which the path resides, such that NFSv4.x client
   requests for fs_locations or fs_locations_info in the absence
   of a junction will not be satisfied.

   This operation differs from FEDFS_DELETE_JUNCTION in that it
   controls a fileset-wide attribute not associated with a
   junction.

   The server SHOULD permit this operation even on read-only
   filesets, but MAY return FEDFS_ERR_ROFS if this is not possible.

   If the path contains an invalid UTF-8 character, then status
   FEDFS_ERR_BADCHAR must be returned.

   The path is REQUIRED to exist and be completely local to the server.
   It MUST NOT contain a junction.  If any component of the path is a
   junction, then this operation MUST fail with status FEDFS_ERR_NOTLOCAL.

   The server MAY enforce the local permissions on the path, including
   the final component.  If the path cannot be traversed because of
   insufficient permissions, or the parent directory of the junction
   unexecutable or unwritable directory, then the operation MAY fail
   with status FEDFS_ERR_ACCESS.

New section 5.9.  FEDFS_LOOKUP_REPLICATION_FSN

   This operation queries a server to determine whether a fileset
   containing the given path has replication information associated
   with it, and if so, the FSN for that replication information.

   This operation differs from FEDFS_LOOKUP_FSN in that it
   inquires about a fileset-wide attribute not associated with a
   junction.

   If the path contains an invalid UTF-8 character, then status
   FEDFS_ERR_BADCHAR must be returned.

   The path is REQUIRED to exist and be completely local to the server.
   It MUST NOT contain a junction.  If any component of the path is a
   junction, then this operation MUST fail with status FEDFS_ERR_NOTLOCAL.

   The server MAY enforce the local permissions on the path, including
   the final component.  If the path cannot be traversed because of
   insufficient permissions, or the parent directory of the junction is
   an unexecutable or unwritable directory, then the operation MAY fail
   with status FEDFS_ERR_ACCESS.

   Interpretation of the 'resolve' parameter shall be the same as
   specified in Section 5.3 for the FEDFS_LOOKUP_FSN operation.