Re: [nfsv4] [Federated-fs] Comments on requirements document

["Everhart, Craig" <[e-mail]>]

Rob, thanks for the message and the clarifying questions. 

> -----Original Message-----
> From: Robert Thurlow [mailto:[e-mail]] 
> Sent: Thursday, October 23, 2008 12:40 PM
> 
> Let me list some things to see what you agree with.  The 
> following things seem true to me:
> 
> - A fileserver is part of the federation if it shares an FSL
>    listed in the NSDB
> 
> - A fileserver is part of the federation if it contains any
>    junctions that point to FSNs in the NSDB
> 
> Neither of these cases seem to be about what I'd call 
> singleton servers.  I'd say a singleton server will not 
> either return a referral or be the target of a referral, 
> which is why I think it's out of scope.
> 
> Rob T

These are helpful cases to consider.  But I'd say that these cases are
both true for singleton servers.

Some structure would be helpful, and you can tell me whether this makes
sense to you or doesn't.  I hope we've been on the same page.

I'm imagining fileservers in collections, where each collection is
basically the span of where a single NSDB (including its replicas, if
any) is authoritative.  Federated-FS is then about having multiple
collections cooperate in presenting a single name space, e.g., for a
single organization.  That Federation, then, has multiple NSDBs.  In
order to construct the namespace that's presented to NFS4 clients, any
given NFS4 fileserver in the federation may encounter junction
information--an FSN, identifying both an NSDB to use and an entry within
that NSDB.  The NFS4 fileserver consults the indicated NSDB for the FSLs
for the target filesystem ("fileset") and returns the information from
those FSLs to the NFS4 client as a referral.  The NFS4 client then
presents the sewn-together name space that the federation has presented
to it.

In this formulation, an NSDB is authoritative for a set of filesets on a
set of fileservers; it is not only authoritative for these
filesets/filesystems, but it is intimately tied to those filesets in
other ways.  For example, suppose an NSDB X were authoritative for
fileservers X1 and X2.  If the administrator for (X, X1, X2) moved a
fileset/filesystem from fileserver X1 to X2 (e.g., because X1 was
getting full), only NSDB X would have to be updated with the new
location.  Vendors are building such systems today.

With Federations, an organization can build a name space that spans
multiple collections, with multiple NSDBs.  A single organization (e.g.,
cnn.com) could buy a functioning collection (NSDB X, fileservers X1..X9)
and have it interoperate with a separate functioning collection (NSDB Y,
fileservers Y1..Y15), and the single organization could use the two
collections as piece parts in building its organizational name space.
With Fed-FS, any of the fileservers knows how to refer to a different
NSDB that is authoritative for an FSN.

So I'm just hoping that a degenerate "collection" of a single server can
play, too.  I'd like for it to be possible for server Z1 to be added to
a federation.  I can't think of a way to do that meaningfully other than
for filesystems housed solely in Z1 to be described in an NSDB (so that
other fileservers in the federations could refer to filesystems on Z1).
It would also be nice if I could install a junction in Z1 (as an FSN)
and have the NFS4 server on Z1 know how to interpret FSNs.

Z1's NSDB could be a tiny "NSDB" service that somehow comes with the
singleton server, or Z1 could in principle be added to one of the other
NSDBs that exist in the federation.

Does this make sense to you?

		Thanks,
		Craig
_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4