Subject: [nfsv4] [FedFS] meeting agenda (4/29)

From: James Lentini <[email-masked]>
Date: Wed, 28 Apr 2010 17:43:01 -0400 (EDT)

Tomorrow's proposed agenda is below. Please let me know if you would
like to add additional topics.

    Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST
 Dial-in: 1-888-765-3653 (us)
          303-218-2659 (international)
      Id: 2354843

Proposed Agenda
---------------

+ 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.

+ LDAP Support for user defined root DSE attributes

+ Admin Protocol: NsdbName XDR Type

  Proposal from Chuck Lever to modify the FedFsNsdbName 
  type from:

  typedef opaque FedFsNsdbName<>;

  which that is a string with "addr:port" format to a

  struct FedFsNsdbName {
       unsigned int    port;
       opaque          hostname<>;
  };

  so that it is not necessary to parse the string for the 
  optional port value.

  For symmetry, the LDAP schema's fedfsNetAdd, its fedfsFslHost 
  subclass, and the fedfsNsdbName attributes could be updated 
  in a similar manner by also restricting them to the "addr" 
  portion and adding a fedfsNetPort attribute type and subclasses 
  for the "port" portion.

---

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 29 Apr 2010 17:20:13 -0400

Minutes from the FedFS meeting 29 Apr 2010.  Corrections and
clarifications are welcome.

Attending: 
	Andy Adamson (NetApp)
	Steve Dixon (RedHat)
	Craig Everhart (NetApp)
	Sorin Faibish (EMC)
	Chuck Lever (Oracle)
	Trond Myklebust (NetApp)
	Paul LeMahieu (EMC)
	Peter Staubach (EMC)
	Robert Thurlow (Oracle)

>   We will start each week's meeting with this announcement.

Well did we note.

> + LDAP Support for user defined root DSE attributes

Rob said that the OpenDS server could support the root DSE attributes
through a hack.  In the future, they hope to find a cleaner way.

>   portion and adding a fedfsNetPort attribute type and subclasses

Chuck's proposal was generally accepted.

Chuck noted that his field names are missing the "FedFs" decoration, but
that it's an uncontroversial thing to add it to them.

Chuck brought up the existence of coexistence with Samba's CIFS/MsDfs
implementation.  He spoke with Jeff Layton and Steve French of the Samba
team.  They explained that the existing Samba implementation implements
MsDfs junctions with symbolic links, the content of which is of the form
"msdfs:server1\dir1,server2\dir2".  This appears to reflect the early
MsDfs designs that didn't use Active Directory.  One issue that Chuck
wanted to discuss was exporting the same file system via Samba MsDfs and
NFSv4 simultaneously: what does a junction look like?  We currently
require a name to be an "empty directory" in the Admin protocol.  If
there's a Samba/MsDfs junction there already, it's not an empty
directory.  We don't have a coexistence strategy yet.

Broader discussion ensued.

Craig noted that Samba MsDfs is beyond the official scope of this group
with its "subgroup of the NFSv4 working group" hat.  He conjectured
that, nonetheless, everybody on the call was interested in ensuring that
Samba could be made to work.  Any design that we might generate could be
mentioned in a "best practices" or "implementation experience" document,
without exceeding our scope unduly.  Someone (Rob?) mentioned that our
Admin protocol, in insisting on an empty directory, goes rather out of
its way to make it impossible to coexist.

Rob noted that the Solaris implementation already supports a coexistence
strategy.  Its junctions are symlinks with a concatenation of content
for multiple file systems.  He wasn't specific, but explained that the
content of the symlink could be something like
	"cifs:server1\dir1,server2\dir2;nfs:server3:/dir3"
(that is, a sequence of content for the different file system export
types).  Each exporting file system is responsible for interpreting the
content as it wishes and extracting the meaning that it needs.

Trond raised another requirement: that file system migration must be
supported.  That is, if one file system on a server is at /a and a
second file system on the same server is mounted at /a/b, it should be
possible to move the second file system from this server to another one
without the client seeing a missing object.  Trond asked for an "atomic"
replacement operation, in which the NFSv4 client sees /a/b as either the
file system on the server or a referral to a relocated copy of the file
system, without the possibility of it seeing intermediate states such as
an empty directory.

After discussion, there was broad agreement that the "must be an empty
directory" requirement was an overreach of the specification.

Craig suggested that there are two separate requirements:
(1) coexistence with Samba's implementation of MS Dfs
(2) atomicity, from the client side, of file system migration
He suggested that we discuss solutions in e-mail.

Chuck mentioned one other fine point: there's no admin protocol error
code for "operation unsupported," but he felt that there should be.

Sorin asked people to get back to him within two weeks about dates for
the Bakeathon that he (well, EMC) is hosting.  He is currently aiming
for 4-8 Oct 2010, but has a proposal for 1-7 October also.

		Craig

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 29 Apr 2010 16:53:17 -0500

> directory" requirement was an overreach of the specification.

I agree.  I'd say: don't make any statement as to what kind of object
the junction point must or must not be, or whether it even must exist.

(For example: why should one not be able to create a junction that hides
a sub-tree of the fs?  IIRC possible on Unix and Unix-like systems to
mount over a non-empty directory.  No, one typically does not want to do
that, but that's not reason enough to codify this in FedFS.)

> (1) coexistence with Samba's implementation of MS Dfs

ISTM that fixing the "junction must be an empty directory" problem
should enable implementors to address (1) without further ado.

> He suggested that we discuss solutions in e-mail.

ISTM that fixing the "junction must be an empty directory" problem
should enable implementors to address (2) without further ado too!

:)

Who knew that that requirement would cause so much trouble?

Now, removing that requirement does potentially create some problems:

 - What about metadata attributes of the junction?  E.g., ACLs.

   IMO: junctions should be like symlinks: world-readable.  The metadata
   of the location referenced still matters, obviously.

 - What's left behind a junction when it is deleted?

   IMO: whatever had had the same name before, if anything.

And maybe some others I've not noticed.

Nico
--