[Federated-fs] Conf call summary

Ellard, Daniel Daniel.Ellard at netapp.com
Thu Jun 19 12:41:19 PDT 2008



We had a short call today, due primarily to a smaller turnout than usual
and the fact that I didn't finish the spec I had planned to discuss
today.

Here's the summary of the recent activity:

On the phone this week:

Daniel Ellard - NetApp
Renu Tewari - IBM
Manoj Naik - IBM
Paul Taysom - EMC(?)
Theresa Raj - NetApp
Amy Weaver - NetApp

THE ROOT FILESET

Renu has been working with Paul LeMahieu to figure out how the contents
of the root fileset can be shared and replicated across a bunch of
NSDBs.  They hope to have something to share in the next few days.

The question was raised whether the info about the root fileset is best
served via an LDAP service -- some worries that:

A) the result of a query could easily be larger than LDAP can handle

B) there's no good way (that we know) to as the LDAP server "just give
me the changes that have occurred since the last time I asked -- don't
just give me everything."

So there's a nagging feeling (for some folks) that perhaps LDAP isn't
the right way to store/access/query this info.

Renu raised to possibility of just having the root fileset replicated,
but we will need a replication protocol that is both portable and knows
about junctions.

TRAVERSING THE NAMESPACE

The current proposal for the info that needs to be tracked by the NSDB
about the structure of the namespace is the following:

For each FSN = <junctionKey, NSDBname>, the NSDB named by NSDBname needs
to keep track, for all of the junctions within the fileset named by the
FSN, the target FSNs if any junctions within that fileset.  Each
junction is identified by both the FSN and child FSN but also by a
uniquifying identifier (perhaps the inode number -- if it's portable
across all replicas -- of the junction, or something like that) so that
if there are two junctions within the same fileset that have have the
same target, the junctions can be distinguished.

The server for a fileset must be able to give the path from its root to
the location of specified junctions.  This makes it possible to identify
the location, in the namespace, of all of the junctions.  (it is
possible for junctions to appear in multiple locations in the namespace,
but that is not a problem we need to solve, as far as I can tell.)

This makes the server interface a bit more complex.  Dan is working on a
spec for the new interfaces.

UPCOMING SCHEDULE

Dan will be at USENIX next week.  It's unclear how many other fed-fs
folk will be.  If most people are going to be available anyway, Dan will
arrange to have someone else host the call.

-Dan



 


More information about the Federated-fs mailing list