Subject: [nfsv4] [FedFS] Meeting Minutes, 9/30/2010

From: James Lentini <[email-masked]>
Date: Thu, 30 Sep 2010 15:51:29 -0400 (EDT)

FedFS Meeting Minutes, 9/30/2010
--------------------------------

Attendees
---------

Andy Adamson (NetApp)
Craig Everhart (NetApp)
Sorin Faibish (EMC)
James Lentini (NetApp)
Chuck Lever (Oracle)
Paul LeMahieu (EMC)
Peter Staubach (EMC)
Robert Thurlow (Oracle)
Mark Uddin (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.

+ October Bake-a-thon Planning

  Mark Uddin has been configuring equipment for the Bake-a-thon. He has 
  installed and configured a DNS server on a Windows 2008 Server for 
  use testing the NFS DNS SRV record. This machine will also be used 
  for other purposes: VMware vCenter, pNFS testing.

  Mark asked if this DNS server will be useful for the NFS DNS SRV testing.
  Rob expected that it would be fine if it could return a standard DNS SRV 
  record.

  Mark reported that the NFS DNS SRV record is not setup yet on the server. 
  This DNS server will also be the DHCP server for the event.

  We haven't tested this configuration yet, but we would expect it to work

  Chuck asked if want to do IPv6 testing and if so does this DNS server
  support IPv6?

  Mark was unsure of the IPv6 support. We will check on this.

  Chuck requested that we have a procedure for installing an SRV record on
  this system. 

  Mark asked for a pointer to the NFS DNS SRV specification.

  [Editor's Note: the draft is here:
   http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-dns-srv-namespace-05]

  Craig Everhart will send Sorin an email with the important points 
  of the NFS DNS SRV record.

  Sorin reported that the Bake-a-thon talk agenda is available on 
  the website:

  http://www.citi.umich.edu/projects/nfsv4/citi_bakeathon/15th_nfsv4_bakeathon.html

  There will be conference rooms for break-out meeting with polycom 
  phones if someone needs to use them.

  The wireless network will allow for outbound VPN traffic.

  The wired network configuration has already been defined. Sorin will 
  send specifics on the IP addresses. 

  There is time on Friday to discuss ad hoc issues and summarize.

  Sorin will send his cell phone in case any issues arise during the weekend.

+ FEDFS_*_REPLICATION

  Craig noticed two items on a second reading of the draft.

  First, the description of the FEDFS_*_REPLICATION procedures is relatively 
  clear that they set the FSN for a present fileset, but don't manage a replication
  relationship between fileservers. However, he could imagine some confusion 
  in this area and may propose additional text to make this point more obvious.

  Secondly, Craig pointed out that the FEDFS_CREATE_REPLICATION procedure's 
  behavior when an "replication" FSN is already set on a fileset is undefined.
  The FEDFS_CREATE_JUNCTION procedure will fail with FEDFS_ERR_EXIST. We agreed 
  that the behavior of FEDFS_CREATE_JUNCTION and FEDFS_CREATE_REPLICATION 
  do not need to be the same. For FEDFS_CREATE_REPLICATION, Craig proposed that
  this procedure act a if it were setting an attribute and so it should 
  succeed if called on a fileset with an existing "replication" FSN.

  Rob agreed with Craig's proposed behavior.

  We discussed if implementing the FEDFS_*_REPLICATION procedures 
  are required (MUSTs) or optional (SHOULDs) for internal nodes in 
  the namespace.

  Rob observed that if NFS4ERR_MOVED is not returned for an object, the 
  NFS server is not required to support fs_locations. Therefore, the 
  FEDFS_*_REPLICATION procedures should be optional (SHOULDs or even MAYs).

  We agreed to list these as SHOULDs in the next revision.

  Chuck asked if this attribute follows a copy of a filset? Chuck observed 
  that one way to implement this in Linux is to use a filesystem's UUID to 
  location its "replication" FSN value. With that implementation, it would 
  be somewhat cumbersome for a copy of the filesystem (with different UUID)
  to locate its "replication" FSN value and return the same fs_locations 
  value.

  Rob noted that NFSv4's replication support is designed to work across 
  heterogeneous servers. In many instances, a "cp -r" command will be 
  sufficient to create a replica. For that reasons, it seemed prudent 
  to pursue Linux designs other than the one described above.

  Chuck asked if there recommendations on how to generate a UUID. 
  James suggested that folks review recommendations in Section 4.2.1.1 
  of draft-ietf-nfsv4-federated-fs-protocol-09 and reply with 
  feedback.

  We noted that the FEDFS_*_REPLICATION procedures have not be 
  implemented in either Linux or Solaris yet.

+ Admin Draft Update

  Draft -06 was posted on 9/29 with the following changes:

 - Each procedure now lists the errors it is allowed to return

 - In 5.2.1, the description of FEDFS_DELETE_JUNCTION
   indicated that if the targeted object was not a 
   junction, the error would be FEDFS_ERR_INVAL. In 
   similar situations in other parts of the specification, 
   the error is FEDFS_ERR_NOTJUNCT. The FEDFS_DELETE_JUNCTION
   description was corrected to use the FEDFS_ERR_NOTJUNCT 
   error.

 - The NOTEMPTY and NOTDIR error codes were removed since 
   they were no longer in use (text that referred to them 
   was removed from FEDFS_CREATE_JUNCTION in the previous revision).  

 - Error codes (FEDFS_ERR_NSDB_REFERRAL, ...) and text (5.3.2) was 
   added for LDAP referrals.

 - Type names used by both the JUNCTION and REPLICATION functions were 
   renamed for consistency (see CreateJunctionArgs, FedFsLookupArgs, 
   and FedFsLookupRes).

 - Added a FEDFS_ERR_DELAY and FEDFS_ERR_NOTSUPP error values

 - Added cache lookup error codes (FEDFS_ERR_NO_CACHE, 
   FEDFS_ERR_UNKOWN_CACHE, and FEDFS_ERR_NO_CACHE_UPDATE)

 - Added a synopsis for each procedure

 - Added a description of the FEDFS_NULL procedure (5.1) 

 Chuck had a list of questions for the group.

 - Should there be an error code for when an NSDB is missing an NCE?
   This seemed like a reasonable addition. We'll add an FEDFS_ERR_NONCE 
   error to every procedure where NOFSN or NOFSL are allowed.

 - What should be the error code if the NSDB returns a 
   permission error? We agreed that FEDFS_ERR_NSDB_LDAP_VAL can be used 
   for this case.

 - What should be the error if an FSL object is missing information? There 
   is an existing error code, FEDFS_ERR_NSDB_RESPONSE, for malformed 
   responses. We'll expand on the description of this error to note some of 
   situations (like this one) in which it should be used.

+ Multi-domain Access Draft update

  Andy has updated the multi-domain access draft. He has sent an email 
  to the WG reflector summarizing the changes and asking for feedback on 
  certain points. We will schedule time to discuss this at a future 
  meeting.

+ Meeting Schedule

  Our next meeting will be on October 14.

---

From: Chuck Lever <[email-masked]>
Date: Thu, 30 Sep 2010 16:11:00 -0400

> FedFS Meeting Minutes, 9/30/2010

...and clarify the differences between FEDFS_ERR_NSDB_RESPONSE, FEDFS_ERR_NSDB_FAULT, and FEDFS_ERR_NSDB_LDAP{_VAL}.

In addition, the NSDB_RESPONSE error code can be returned by the ADMIN protocol's FEDFS_LOOKUP_JUNCTION procedure.  The specific question I had is how an NFS fileserver should reply to GETATTR(fs_locations) if the NSDB returns obviously broken FSL information.

Some convention for the NFS server's reply in this case should be agreed upon outside of the ongoing FedFS discussion.

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

-- 
chuck[dot]lever[at]oracle[dot]com

---

From: James Lentini <[email-masked]>
Date: Thu, 30 Sep 2010 17:33:33 -0400 (EDT)

> > FedFS Meeting Minutes, 9/30/2010
<snip>
> ...and clarify the differences between FEDFS_ERR_NSDB_RESPONSE, 
> FEDFS_ERR_NSDB_FAULT, and FEDFS_ERR_NSDB_LDAP{_VAL}.

Not a problem.

> 
> In addition, the NSDB_RESPONSE error code can be returned by the 
> ADMIN protocol's FEDFS_LOOKUP_JUNCTION procedure.  

Correct, this is a valid error value for FEDFS_LOOKUP_JUNCTION.

> The specific question I had is how an NFS fileserver should reply to 
> GETATTR(fs_locations) if the NSDB returns obviously broken FSL 
> information.

Sorry for unintentionally leaving this out of the minutes.
 
> Some convention for the NFS server's reply in this case should be 
> agreed upon outside of the ongoing FedFS discussion.

I think another way to phrase this question is: How does an NFS server 
indicate that a file system has moved to an unknown location? One 
obvious possibility is to return a zero element locations array in the 
fs_locations structure.

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 30 Sep 2010 17:37:51 -0400

> obvious possibility is to return a zero element locations array in the 

NFS4ERR_STALE is the usual response. If you don't know where the
filesystem was migrated to, then what you have is not a migration event.
It is an unexport of the partition.

Cheers
  Trond