[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: filesystem namespace regions, or making mountd less bozotic
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
Main Index |
Thread Index |