[Federated-fs] Corrected formatting for federated-fs

[Everhart, Craig]

> From: Touretsky, Gregory [mailto:gregory.touretsky at intel.com] 
> > From: Everhart, Craig [mailto:everhart at netapp.com]
> >   As to mapping FSNs back to junction(s), I'm a little 
> curious about 
> > how that would work--what agent you imagine would be 
> responsible for 
> > maintaining that information.  I understand the desire to have the 
> > functionality from the management point of view.
> If NSDB will keep information about both junctions and 
> filesets - it may provide this functionality.
> Every time new junction gets created for some fileset, the 
> relevant NSDB would be update

Sure, in the absence of other changes, this works.  What happens when
you rename the junction or rename one of its parent directories in a
fileset?  Do you foresee the need to update the memory of the junction,
because it now has a different pathname from the root of the fileset to
the junction?  Is it a requirement to track this change, or for that
matter others that might happen--deletion of the junction, renaming of
the parent fileset, destruction of the fileset itself?  How about
replication of the fileset, making a duplicate of it somewhere?

I think the biggest impediment in the past to conceptualizing this has
been that pathname-based operations (rename or delete the junction,
rename a parent) don't typically involve the fileset management in any
way, so either they go ahead unimpeded and one is left with a flawed
memory of where the junctions were, or one intercepts some but not other
operations, or one has to periodically crawl filesets and update their
inventory of junctions.  The other, fileset-based, operations could in
principle be addressed more gracefully.

		Craig