> Now, as it is, the linux dentry cache would be confused by having
> potentially multiple aliases for the same path, but that's something that
> I consider to be a misfeature - but one that wasn't worth fixing
> considering that we didn't have any serious filesystems that could take
> advantage of it anyway (I think the only two filesystems we support right
> now that can do it at all are AFFS and iso9660, and for the latter I don't
> actuall yknow of anybody who does that kind of disks).
>
> But being able to handle hardlinked directories would actually be really
> nice: if you avoid loops (which is easy to do), it goes from being a
^^^^^^^^^^^^^^
mkdir a
mkdir b
mkdir a/c
ln a/c b/c
mkdir a/c/d
mv b a/c/d
If you have a way to deal with that... BTW, I strongly suspect
that any solution involving scanning potential ancestors is *not* good -
you can construct very unpleasant DoS that way.
> dangerous feature to a really nice one.
>
> Basically, I used to think that hardlinked directories are evil, and
> horrible. What changed my opinion was that (a) I found a few cases where I
> really wanted to use them and (b) I noticed that most of the reason for
> hating them was because they were hard to do right rather than anything
> fundamentally wrong with the concept.
>
> We can't do them right as is, but getting rid of ".." in the on-disk
> directory structure would be one step, and I think I can handle the dentry
> aliasing issue too.
Could you elaborate? I am trying to figure out the way to do that
and for the case of multiple links *from the same directory* I have a
kinda-sorta solution. For generic thing... I would really like to hear
your variant.
> Imagine, for example, a directory tree with a shared component. Wouldn't
> it be nice to just link it into the tree at multiple points? Imagine a
> chroot() environment, for a moment - symlinks don't work to the outside,
> but hardlinking does.
nullfs. It was invented for such things and we can do it. With
*very* small overhead - dcache helps big way here.
Cheers,
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/