[Federated-fs] Draft of requirements for a federated filesystems

Daniel Ellard ellard at netapp.com
Mon Mar 26 19:30:49 PDT 2007


My comments interspersed below.

A lot of the feedback was concerned with the style and organization of the
document; we'll attempt to address those in the next draft.  What I'm going
to try to address right now is some of the problems that you identified that
make it difficult to understand the points we were trying to make, so that
people who are reading the first draft won't run into the same problems.

One meta-comment: this really is a draft -- a work in progress.  Feedback
and suggestions for change (as well as suggestions to improve the
exposition) are more than welcome.


> Overall, replication, migration and annotation appear to be
> additions to the basic functionality of federation.  There ought
> to be some rationale for why they make sense as part of the
> basic specification of federation functionality.

Replication and migration are fairly commonplace in cluster protocols, and
users quickly become addicted to them.  We assume that clusters are going to
be federation members, so we think it would be a fatal flaw if we limited
the federation protocol to prohibit them, because this would reduce the
federation-visible functionality of these members.

At the same time, however, note that neither replication or migration is
required by the federation protocols -- you don't have to support either one
of these in order to be a federation member!  The only requirement is that
if you support migration/replication (AND you want to be able to tell other
federation members that filesets you host have moved or are replicated) then
you need to implement the protocols for sharing this information with other
members.

Annotations are a separate issue, and perhaps they will be omitted.  Their
justification is that when we worked through some use cases, it was very
useful to have a way for admins to annotate FSNs, FSLs, etc and have this
info managed by the NSDB makes it easy to access the annotations and keep
them in synch with the objects they describe.  There are other ways to do
this, of course, and we're open to suggestions, but this seems to work well.


> Definitions of acronyms (e.g., FSL) should *always* include the
> expansion of the acronym (e.g., FileSystem Location - note that
> the "S" is potentially ambiguous without this expansion).

Yes, it's clearly ambiguous... It's supposed to be Fileset Location!

> Junction key definition needs to be expanded - why is the lookup
> being done?

This is a bit of our preconceptions about the implementation showing
through...

There are a number of ways this might be accomplished, and the details are
not essential to the requirements.  The reason we treat this as a key is
that this gives us a layer of indirection that allows us to lift a lot of
the potential complexity out of the server and into the NSDB.  The server
just needs to keep track of opaque keys for each junction.  All the info
about the destination of the junction is kept in the NSDB.  So if the
fileset is migrated, the junction key stays the same but the entry in the
NSDB is updated.  Similarly if the fileset is migrated; one junction key
might match several entries.  The source server doesn't need to know that
the destination has changed, it just needs to know to talk to the NSDB that
has the info about that junction key.

>> A4.  All fileservers in the federation MUST operate within
>>         the same authentication/authorization domain.
> 
> I'm not sure, but I need a crisp definition of "authentication/
> authorization domain" to understand what's going on here.  Also,
> this text:
> 
> ... a shared authentication mechanism.  This mechanism is
>       not defined or further described in this document.
> 
> may be in conflict with A3, depending on how "authentication/
> authorization domain" is defined.

We're postponing defining this scheme -- but we are requiring that such a
scheme is specified in the protocol (or some specified set, if one isn't
enough).

> R2 is written in terms of "directory hierarchy", not "fileset" -
> why??  This has implications on fileset behavior/functionality
> *as viewed from the federation* that need to be explained.
> Absent this explanation, the second paragraph of R2 ("It is
> the responsibility ...") may be in conflict with the first.

We have a bootstrapping problem -- right now we have a world built out of
file systems and directories, but what we want is filesets.  So we need a
way to get the system started by "promoting" hierarchies into filesets.

> R8a and R8b talk about filesystems as opposed to filesets.
> That does not appear to be consistent with the use of the term
> filesets elsewhere, e.g., in the definitions of fileset and
> filesystem in the glossary.  What's going on here?

Again, this is part of the bootstrapping problem.  R8a helps the admin
figure out what raw materials are available (filesystems) for he or she to
create filesets from.  This could be done other ways, so it's a SHOULD.

R8b helps the client (or server to help the client) to find out information
that might be necessary (or merely useful) to access the filesystem
underlying a fileset location.


> Also on R14, annotations are potentially dangerous to
> interoperability if a client looks for an annotation and only
> traverses the junction if that annotation is present.  There
> should be a requirement prohibiting this sort of bad behavior,
> particularly on vendor- specific annotations.

I can't think of a way to do this short of prohibiting access to the
annotations to non-admin clients...  But maybe that's not a bad idea,
although it would make it impossible to use annotations to express ideas
like priority (from NFSv4.1).

Another idea, not explored in the requirements, is to come up with a list of
standard annotations that have specific forms and standard interpretations,
and make this part of the spec.  I don't want to open that discussion until
we figure out whether we really want annotations in the first place,
however.

Thanks,
    -Dan




More information about the Federated-fs mailing list