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

Everhart, Craig Craig.Everhart at netapp.com
Mon Jun 9 13:44:28 PDT 2008


I *totally* agree with Dan's bias on this.  It's a surprise to me that
others thought that there was a "namespace" that existed independently
of the file systems that make it up.

What is the relationship between path data that exists both in a fileset
(in a file server--Dan's #1 case) and in the NSDB and (as in Paul's
addendum to Dan's #3) all the instances of the parent path data that are
subsidiary filesets?  Is there some authoritative copy with the others
just hints?  What is the replication protocol by which path data is
propagated?  How consistent does it have to be?

If we were stumbling thinking about the constraints on fileset
replication and consistency, why would this be a simple answer?  Right
now it's an unmotivated, underspecified, and unconstrained additional
criterion for any implementation.  (And them's its good points...:-})

If others (Paul? Renu?) feel like this needs to be changed, could they
do it with a more fleshed-out proposal?

		Thanks,
		Craig 

> -----Original Message-----
> From: Ellard, Daniel 
> Sent: Thursday, June 05, 2008 5:10 PM
> To: federated-fs at sdsc.edu
> Subject: [Federated-fs] Conf call 6/5/2008
> 
> 
> 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 
> 
> 
> 


More information about the Federated-fs mailing list