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

Robert Thurlow robert.thurlow at sun.com
Tue Jun 10 11:59:26 PDT 2008


Everhart, Craig wrote:
> 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?

Yes, that's a good restatement.  Any server for a fileset could be asked 
what links point outside it.

   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.

You jumped back to talking about the NSDB, which brings back the idea of 
some data being replicated there; where did that come from?

> 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.

This is probably due to my implementation ideas creeping in, and could 
be suspect.  I expect we'll add a new filesystem object type to our OS 
for junctions, and that we could respond to a query with the moral 
equivalent of 'find $ROOT -type junction'.  That's not time-bounded, so 
a timestamped cache would be good (your "freshness indicator").

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

Hmmm, unconsidered, does depend on the protocol that provides the 
visibility.  Perhaps you could see any path that you could traverse
with the same authentication?  (I know, more work for the server.)

> I'd still argue that the Dan/Craig model exists and is simple.  This is an extension.

Agreed.

Rob T


More information about the Federated-fs mailing list