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

[Everhart, Craig]

More inside... 

> -----Original Message-----
> From: Robert Thurlow [mailto:robert.thurlow at sun.com] 
> Sent: Tuesday, June 10, 2008 2:59 PM
> To: Everhart, Craig
> Cc: Ellard, Daniel; federated-fs at sdsc.edu
> Subject: Re: [Federated-fs] Conf call 6/5/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?

Well, a file server will know about the outgoing links from a fileset in terms of its FSNs.  For the NFSv4 protocol use, the file server will go evaluate those FSNs by calling the NSDB.  For the protocol we're contemplating, my guess is that the most general thing is that the file server can just return the FSNs and let the browser consult the NSDB.  It certainly requires less work from the file server (but still a non-trivial amount).


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

Right, file servers will need to be able to recognize their junctions, though just how they do that is a private matter.

There are lots of models by which fileset-to-(set of FSNs) could be maintained, and the freshness indication is just a vague escape clause for some of them (as is the ENOSYS-type result).  One could even (perish the thought) combine fileset-relative path names with the FSNs, with all the freshness caveats and more.  This would be pretty much all that your imaginary motivation scenario required, but what's missing is the hand-wavy parts: how is this result maintained, how fresh is it, how wrong can it be?


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

Right, with a big potential limitation on the use cases, unless the server does a really complete job of a really messy multiple-object-ACL merge.  Yow.  Is my imagination so limited that I don't see this happening soon?

There might be special cases like returning "everything that the unauthenticated user could see" but this could be just about nothing in real deployments.  I doubt that the IETF would be really fond of a protocol that encouraged such a use case.


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