[Federated-fs] Namespace design and fault tolerance

[Ellard, Daniel]

Last week I presented an overview of the requirements doc at the IETF
NFS working group.  My slides are here:

http://www3.ietf.org/proceedings/07jul/slides/nfsv4-1.pdf

The minutes are here:

https://datatracker.ietf.org/meeting/69/materials.html

One of the comments that came up during the presentation was that AFS,
with its everything-branches-off-the-afs-root namespace, had a nice
property in the face of cell failures -- if a cell fails, then
everything in the namespace that is NOT implemented in that cell is
still accessible.

The current spec permits the construction of namespaces that don't have
this property.  For example, if /a is implemented in member x, and /a/b
is implemented in member y, and /a/b/c is implemented in member z (and
there aren't any other ways to get to /a/b/c) then if y is misbehaving,
then /a/b/c is inaccessible.

However, the current spec doesn't force anyone to build their namespace
in this manner: it's perfectly fine to have everything branch off the
root.  It's also possible to have more than one way to get to something,
so you could have an intuitive namespace hierarchy and a fallback
AFS-like namespace living side by side.

The general rule is: if you don't have faith that you'll be able to
traverse any of the paths you know about to reach the members you're
interested in, then make your own path.  AFS took this to one extreme:
there's only one path to each cell, and everyone implements their own
copy of this path locally.  The current spec permits members to trust
each other, but doesn't require that they do.  We think that this trust
will be useful for members that already have close trust relationships,
but it shouldn't be used recklessly.

-Dan