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

From: James Lentini <[email-masked]>
Date: Thu, 6 May 2010 15:37:07 -0400 (EDT)

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

Attendees
---------

Andy Adamson (NetApp)
Craig Everhart (NetApp)
Sorin Faibish (EMC)
Chuck Lever (Oracle)
James Lentini (NetApp)
Trond Myklebust (NetApp)
Peter Staubach (EMC)
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.

+ Admin Protocol

  Craig summarized where the discussions left off last week. 
  There were two topics being discussed at the end of last 
  week's meeting:

  (1) co-existence with Samba's DFS implementation
  (2) atomically migrate a file system

  We discussed why the Admin draft text states that a junction 
  must be created on an empty directory. 

  In the abstract this could be useful since there is no need 
  for the Admin protocol to be concerned with attributes for 
  the junction. In the NFS case, this does not appear to be a 
  concern as only a handful of attributes are accessible for
  an ERR_MOVED object and none of these need to be inherited 
  from a pre-existing object.

  Another item to consider is who has permission to create 
  an object. By requiring the junction's target object to 
  already exist, this is not an issue.

  Trond suggested that a junction could be treated like a
  symlink: the contents are world readable, and the target 
  object enforces permissions.

  We discussed the notion of an existing object 
  changing type. If the target of a JUNCTION_CREATE is a 
  file, then the file will be replaced by a junction to a 
  directory. This caused some grief in early implementations, 
  but nobody indicated that it was still a problem.

  Trond asked if we wanted to support the ability to annotate 
  a file system with its replicas. An NFS client can obtain 
  an fs_locations[_info] attribute to learn about the 
  file system's replicas.

  Rob observed that the process of determining the FSLs for 
  and FSN is disjoint from the decision to return ERR_MOVED.

  James suggested that the FEDFS_CREATE_JUNCTION call might 
  have a parameter that indicates if the targeted file system 
  object should be "hidden" by the junction (where "hidden" 
  means that attempts by a client to access the object result 
  in an ERR_MOVED) or left visible (which would support the 
  use case Trond suggested).

  Rob suggested that Admin draft's requirement that the 
  target of a CREATE_JUNCTION be amended and that there be a 
  verb to map a file system UUID to an FSL.

  There was a brief discussion of file system UUIDs. Trond 
  noted that Linux assigns a UUID to a file system when it is 
  formatted. The file system's UUID is then used as a component 
  of the NFS filehandle.

  [AI] Rob Thurlow will write a description of the verb for 
       adding replicas to a file system.

  Rob Thurlow brought up the wording changes in 3530bis that he 
  described at Connectathon. There are two changes related to 
  migrations: 

  Once a migration has occurred, the new server does not have 
  a relationship with the client and the client is not reachable 
  by the new server on the callback channel. The update will 
  include text that encourages transparent state migration in 
  this case.  

  Also related to migrations, there is no obvious way for a 
  client to tell if the state was transparently migrated or 
  if it should do state recovery. There is a clarification 
  on how the client can determine this in the update.

  Finally, we reviewed the other requirements the Admin 
  draft places on a junction's path. The text states 
  that the path is REQUIRED to exist (page 13). We agreed 
  that this requirement would be retained for all but the 
  final path component.

+ Next Meeting
 
  Our next meeting will be in two weeks on May 20.

---

From: Chuck Lever <[email-masked]>
Date: Fri, 07 May 2010 13:38:33 -0400

> FedFS Meeting Minutes, 5/6/2010

Now that we've discussed the existing empty directory requirement for 
CREATE_JUNCTION, perhaps another related detail that should be visited 
briefly is the requirement that DELETE_JUNCTION restore an object that 
used to be a junction to the state it was before it was a junction.

Thanks for the summary.

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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 7 May 2010 13:55:31 -0500

On Fri, May 07, 2010 at 01:38:33PM -0400, Chuck Lever wrote:
> Now that we've discussed the existing empty directory requirement
> for CREATE_JUNCTION, perhaps another related detail that should be
> visited briefly is the requirement that DELETE_JUNCTION restore an
> object that used to be a junction to the state it was before it was
> a junction.

Easy: make that a MAY or a SHOULD :)  Implementors who have no easy way
to restore the object obscured by a junction can simply act as though
that object was unlinked.  That means that CREATE_JUNCTION MAY/SHOULD
unlink objects obscured by junctions.

It would be easier to instead require that no object exist where a
junction is to be created.  I'd prefer this last approach.

Nico
--