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

[Everhart, Craig]

Rob, thanks for the stab at a motivation.  It's more light than dust, I think.

So, you're proposing a way to build a fileset-by-fileset enumerator, treating filesets as blobs with outgoing links?  That the NFS server could offer some maybe-not-totally-authoritative service that, for a fileset, enumerates the FSNs contained in that fileset?  Maybe there wants to be some more color commentary about the kinds of annotations that might exist in an NSDB for a given FSN, to assist the browsing effort.  That much could make sense.  This would, effectively, replace the pathname structure in the naïve browser.  With effort within each fileset, the paths to junctions could be found.

But there's still plenty of dust.  This waves the hands wildly at the problem of how even this data would be created and/or discovered and/or maintained.  Maybe the reply could come with some freshness indicator--this is data that resulted from a fileset sweep at time X, or this one FSN was here at time Y.  A given server might or might not choose to participate in this particular protocol.

Is this the cost (to a file server) of doing business as part of a federation?  To make its filesets browsable?

What permissions are associated with this browsing data?  With the protocol that does the browsing?

I'd still argue that the Dan/Craig model exists and is simple.  This is an extension.  Unlike the root-fileset discovery protocol that still exists in draft form, this isn't at all nailed down in a document, either.  Let's take one step at a time.

		Craig

> -----Original Message-----
> From: Robert Thurlow [mailto:robert.thurlow at sun.com] 
> Sent: Monday, June 09, 2008 6:37 PM
> To: Everhart, Craig
> Cc: Ellard, Daniel; federated-fs at sdsc.edu
> Subject: Re: [Federated-fs] Conf call 6/5/2008
> 
> Everhart, Craig wrote:
> > 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?
> 
> I don't want to keep a copy of all of the mapping data (with 
> or without authority) in the NSDB, either.  But I do wonder 
> if the motivation is something like this:
> 
> I want an admin application that can show me the whole 
> namespace.  I want to be able to browse it like a Google map, 
> going up/down, left/right in the global directory tree.  I'd 
> like to see which nodes are junctions, and to be able to 
> click on them and see the details about their replicas.  In 
> the fullness of time, I'd like to be able to click on a point 
> in the namespace and select an option to make that point a 
> separate, replicated filesystem, and to adjust the 
> characteristics of existing filesystems.
> 
> Now, if all we have is a way to drill down from the top of 
> the namespace for any particular path, this could be bloody 
> hard.  Having more information would help.  An alternate 
> question is, where could we get more info?
> 
> One suggestion is that the protocol permit a query to an NFS 
> server participating in the namespace, to list the junctions 
> in a particular filesystem.  If we could start at the top, 
> find the Nth level filesystems and ask them what junctions 
> point outside of the filesystem, we could enumerate the 
> namespace far quicker.  We would still have to send packets 
> all over the place - "find the root" DNS queries, NSDB 
> lookups, NFS accesses and whatever we use to enumerate 
> junctions in a filesystem - but I have always expected that.
> 
> Does this shed light or kick up dust? :-)
> 
> Rob T
>