[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