[Federated-fs] Notes from the last conf call

[Ellard, Daniel]

First, a reminder: there's another federated-fs conf call, 2pm EST,
1-888-765-3653, conference ID 6206056.

Some notes from last week:

1. The Linux v4 client has some shortcomings that make it unable to take
advantage of the full features of the current federated-fs protocol.  I
wasn't fully aware of these before, unfortunately, but even if I had
been, it's not obvious how to change the protocol to address these
problems (actually, I believe it's not possible at all, without changing
the basic requirements and philosophy...).  Since I think we can expect
that, for many deployments, a reasonable number of the clients of a
large federated-fs are going to be running Linux, this is something that
has to be addressed if this protocol is going to succeed.  We need to
come up with a plan for getting the features we want into Linux. (ditto
for any other clients we've overlooked that have quirks)

The problems with the Linux client are that migration (and
dynamically-changing replica sets) isn't supported, and fs_locations
can't require DNS lookups.  The first problem can be worked around by
nailing down the location of each fileset, but that removes a lot of the
value of the protocol.  The second problem can be worked around by using
raw IP addresses in the fs_locations passed to the client, but this
assumes that the client would resolve a given name in the same manner as
the server (or the server can figure out how the client would resolve
them).  Again, removing this layer of abstraction removes some of the
value of the protocol.

2.  In the recent "admin protocol" spec
(http://tools.ietf.org/id/draft-ellard-nfsv4-federated-fs-admin-00.txt)
the prose is not clear about who the admin is.  This will be addressed
in the next draft.  In the meanwhile, here's the summary: the admin
referenced by the description of this protocol is the administrator for
the server on which junctions are created, removed, or queried about by
this protocol.  This admin is NOT assumed to have any administrative
authority on the servers that host the filesets referenced by these
junctions, nor on the NSDB location that "owns" those filesets.  It is
typically the case that the admin has authority to query that NSDB
location in order to find FSNs, but it does not require the authority to
modify the contents or state of that NSDB location in any manner visible
to the protocol.

Note that this implies something potentially important about the info
that the NSDB location manages: the NSDB doesn't keep track of the links
INTO an FSN.  There is no way to query an NSDB to ask "what filesets
have junctions that point to FSN x?" or anything like that.  [If you
think this is a bad idea, speak up, and let us know why!]

The end result of this is that in order to create a junction from path
/a/b on server foo to FSN X, all that is necessary is to have admin
privs on foo that allow you to insert a junction at that path.  There is
no need to have any privs (or even to communicate in any way) on the
NSDB referenced by FSN X, or on the servers that host the FSLs that
implement X.

This means that it is possible to create junctions to FSNs that don't
exist, or FSNs that have no FSLs.  It's even possible to create a
junction that is owned by an FSN that doesn't exists or is offline.  In
theory, you could create a junction from a meaningless sequence of
random bit (and I'm sure someday someone will).  It's useful to be able
to create junctions in this manner for bootstrapping.  It's the
responsibility of the admin to check that the junction can be traversed
if the destination is believed to be correct, and do the right thing (as
defined by local policy) if it does not.  The analogy here is symlinks:
they're not guaranteed to actually resolve; you can create the symlink
before you create the file or directory they "link" to -- or you might
never create it.

3.  There was a lot of discussion about paths -- are we using the
pseudo-root to specify server-local paths, or what?  The current spec
says that *any* path that can be interpreted locally by the server is
OK.  Remember that this protocol is used between a server and its admin
-- so the admin is presumed to have local knowledge and access about the
file system.  In fact, it is even possible to insert a junction into a
file system that the server doesn't export at the time that the junction
is created.

If there is more than one server-interpretable path that leads to the
same junction, then any of those paths may be used to refer equivalently
to the junction.

If the junction is renamed or moved to another directory, then the
original path(s) might no longer work.  Some folks objected to this,
because it means that the admin might lose track of where junctions are.
This is no different, however, from the result of renaming or moving any
other object in the file system.  We could track junctions so that we
always know where they are, but this might require extensive plumbing in
the server file system and I'm not sure what the advantages are.  [If
you've got some, please articulate them!]

4.  Renu is organizing a federated-fs BOF at FAST.  Hope to see you
there.

-Dan


-- 
Daniel Ellard, Ph.D.
Advanced Technology Group, Network Appliance, Inc.