[Federated-fs] Conf call 6/5/2008

[Ellard, Daniel]

Notes from the call (corrections/additions/refinements welcome):

On the line: Paul, Mario, Rob, Renu, Dan (anyone else?)

Note on the schema: we should have a canonical way for representing
paths, so that if we need to translate from one representation to
another (i.e., NFS to CIFS) then there's no ambiguity which is which or
how to translate.  Nobody disagreed.

Work item: enumerate the other attributes of an FSL (and which are
optional vs. required). Need to be able to capture all the info in
fs_locations at the least.

Major topic of discussion: where is the namespace stored?  We spent most
of the hour having a lively discussion about this.  It appears that
there is a bit of a disconnect between what different people thought we
were doing.

In the current NSDB schema (and spec), the NSDB contains NO information
about the structure of the namespace.  All it knows is FSNs, but FSNs
are used as underpinnings of the namespace, not elements of the
namespace.  The servers know the structure of the parts of the namespace
that they implement, but not much beyond their borders.

An example might be useful:  imagine we have path /a/b/c/d.  This path
is implemented via two filesets: server X implements /a/b/c and knows
that /a/b/c is a junction to FSN alpha, which server Y implements /q/d.
The NSDB knows that the FSLs for alpha are Y:/q/d.

The current case:

	1. the NSDB has no idea that there's a junction at /a/b/c.  Only
server X knows that.

	2. server Y doesn't (necessarily) know that /q/d is the target
of alpha.

	3. server Y doesn't know that /q/d implements /a/b/c/d in the
global namespace.

The functionality requested by some participants (Renu, Paul, others?)
is that the NSDB -- or something similar -- knows what junctions
signify, and where filesets live in the namespace.  So, in the proposed
case:

	1. the NSDB knows that there's a junction at /a/b/c.  Server X
also knows this.

	2. (unchanged)

	3. server Y knows that its local /q/d implements /a/b/c/d in the
global namespace.  If /q/d is reachable via multiple paths, server Y
must be aware of all of them.

Paul added another bit of functionality: that a server (and perhaps a
client) can, in essence, stitch together its own pseudo-root for the
root fileset (and perhaps a few heavily-traveled descendants) by
querying an NSDB and learning enough about the namespace to get started.

<begin Dan's bias>

Although this leads to a more expressive NSDB, it also leads to a much
more complicated NSDB, with some annoying failure modes.  Some case
studies illustrate some issues:

- A user renames some component of the path /a/b/c, i.e., changing 'b'
to 'BB'.  In the "current case", this change is entirely local to server
X.  There is no need to propogate this change in the namespace to any
other entity (except for replicas of this fileset, and replication is
NOT defined as part of the protocol right now).  In the proposed case,
the NSDB needs to be updated to know that the path to junction alpha has
changed from /a/b/c to /a/BB/c, and server Y needs to know that its /q/d
now implements /a/BB/c/d.  These three updates must be synchronized, at
least causally, in order to prevent different observers from seeing
inconsistent versions of the namespace, with potentially erroneous
results.  Furthermore, these updates violate the rules of confederation
-- a user on system X has forced changes on the NSDB for Y and Y itself.
In the current case, no action on server X can force an update on Y or
Y's NSDB, which may be in a different administrative domain.

- The admin of X deletes junction /a/b/c.  Similar to the previous case,
this forces changes to the NSDB and Y.

<end Dan's bias>

-Dan




- The admin deletes