Subject: [nfsv4] FedFS Meeting Minutes, 03/26/2009

From: James Lentini <[email-masked]>
Date: Thu, 26 Mar 2009 15:28:22 -0400 (EDT)

FedFS Meeting Minutes, 03/26/2009
---------------------------------

Attendees
---------

Andy Adamson (NetApp)
Renu Tewari (IBM)
Robert Thurlow (Sun)
Paul Lemahieu (EMC)
James Lentini (NetApp)

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

  - Renu Tewari will investigate how rsync handles ACLs

  The base rsync has support for POSIX ACLs (getfacl). The 
  file system has to support ACLs. For some specific file 
  systems there is specialize support to transfer the ACLs 
  if the source and destination are the same file system.

  The origin of this question was thinking of how a root 
  fileset can be replicated. In a homogeneous environment, 
  a specialized protocol can be used. In a heterogeneous 
  environment, something else needs to be used.

  Could we use rsync to synchronize the root fileset?

  Who supports NFSv4 ACLs? Linux doesn't support ACLs.

  What do we want? We want a way to synchronize the 
  root fileset's junctions. Do we want to 
  synchronize attributes (ACLs)?

  A simpler solution is to have all security enforced 
  on the target fileset and the intermediary root 
  fileset directories are open.

  Note that the intention is to allow the root fileset 
  to be exported with RPCSEC_GSS protection.

  [AI] James Lentini will draft text for the root 
       fileset's attribute (ACL) requirements

+ IETF NFSv4 Working Group Feedback

  We received a number of questions, comments, and suggestions 
  at the meeting:

  - What does a READDIR of a directory that contains a junction return?

  Mike Eisler pointed out that this scenario is described here:

  http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-29#section-11.8.2

  - Beepy suggested that fileserver receive a hint to update their 
    FSN to FSL mapping when a migration occurs (LDAP replicas can take 
    a while to update or fileserver cache's can become stale). Focus 
    on something simple and workable.

  - The term "federation" suggests to some that we address 
    the problem of identity in a multi-domain environment.
    Need to be clear that this is not a FedFS specific problem.
    We should evaluate if the "federation" is the correct term.

  - LDAP does not require support for transactions. An update 
    to a single object is atomic. Multiple object transactions 
    require additional support. LDAP replication supports eventual 
    consistency. These are the semantics we require. See NSDB 
    draft, section 3.4.

  - User identity is important. We need to be clear that this is 
    a larger issue than FedFS. We also need to clarify implementation 
    from requirements.

+ Upcoming Events

  Bake-A-Thon is approaching (June 15th-19th). This is an 
  opportunity to demonstrate and test the interoperability of 
  FedFS or even just referrals.

---

From: Daniel Ellard <[email-masked]>
Date: Mon, 30 Mar 2009 09:24:49 -0400

>    on something simple and workable.

I'm confused in several ways about this statement, and I hope
someone who was there can clue me in.

A fileserver doesn't have the FSN to FSL mapping--was this meant
to read something like "fileserver send a hint to the NSDB to update
their FSN to FSL mapping" (or something like that?

>    We should evaluate if the "federation" is the correct term.

I believe that the precise term is "confederation", but most
people don't know exactly what that means, either, so we
might as well stick with the intuitive meaning.

Neither of these terms, however, necessarily implies a
what you mean by a multi-domain environment.  If we want
to convey that idea, it needs a different term.

The notion of federation is a common set of protocols that
all members agree to use, and that all members are peers,
but that's all.  It doesn't address issues of identity.

-Dan

---

From: Robert Thurlow <[email-masked]>
Date: Mon, 30 Mar 2009 07:36:45 -0600

> someone who was there can clue me in.

Hi Daniel,

Per discussion in the FedFS meeting on Thursday, I believe
this was to increase the correctness of the system when
fileservers cache FSN-to-FSL mappings.  Those mappings are
updated infrequently, so it is tempting to cache results on
the server to limit the traffic to the NSDB, but it is also
important that changes be noticed in a reasonable time.
Whether there is anything to actually do other than to bound
the maximum cache time, I don't think we know.

Rob T

---

From: James Lentini <[email-masked]>
Date: Mon, 30 Mar 2009 09:41:22 -0400 (EDT)

> the maximum cache time, I don't think we know.

Correct. A fileserver doesn't store the authoritative FSN to FSL 
mapping, but the current drafts allow the fileservers to cache the 
mapping information. See the Requirements draft, assumption A6, last 
paragraph:

        Note that it is not assumed that it is always required for a
        server to contact the NSDB node specified by the FSN in order to
        find the FSLs.  The relevant information stored in that NSDB
        node may also be cached local to the server or on a proxy NSDB
        node "near" the server.

The suggestion was that we have some mechanism to hint that cached
information was stale. Brian suggested we focus on changes to existing
FSN to FSL mappings (migrations). He observed that when new FSN to FSL
mappings are created for the first time, users are expecting to need
to wait for the new information to come online. Bounding the time a 
migration disrupts access to existing data is much more important.