Re: filesystem namespace regions, or making mountd less bozotic

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Dec 06, 2012 at 08:55:56AM +0700, Robert Elz wrote:
 >   | I am tired of PR 3019 and its many duplicates, so I'd like to see a
 >   | scheme that allows managing arbitrary subtrees of the filesystem
 >   | namespace in a reasonably useful manner.
 > 
 > If you're going to do something like that, then you need to work out
 > what it means to have a file linked into different regions, and how
 > you'd manage to implement that.

There's a reason I was only talking about directories. Granted, for
some of the applications you might want to know what region(s) a file
is in; however, I think that for the time being at least there's no
reasonable way to do that. (I suppose you could give non-directory
vnodes an array of regions and update them during link and unlink, but
this could get prohibitively messy.)

If we ever get a linux-style namecache (where names become first-class
entities) then it becomes reasonably possible, because a file with
multiple hard links has multiple names, and the region is a property
of the name rather than the file. Such a setup is a long-term goal but
I don't expect to be getting there anytime soon.

 > On the other hand, if you're going to allow cross region links, then
 > you need to work out how a vnode for a file that's in multiple regions
 > (that is, for which path that end in multiple different regions reference
 > the same inode) manages to reference all the regions, and exactly what
 > that means to whatever access controls you (like nfs exportability) that
 > you have depending upon regions.

For most of the likely applications, a hardlinked file is effectively
in all the regions whose subtrees it appears in, so it is valid to
access it via any of these contexts. I don't think this creates a
problem once you have a way of keeping track of where it is.

-- 
David A. Holland
dholland%netbsd.org@localhost