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 [email protected]
