On Tue, Dec 13, 2011 at 11:41:20PM +0100, Joerg Schilling wrote: > lofs has been introduced with NSE, the first project oriented revision control > system (based on SCCS). lofs at that time was used to create chrooted tailored > environments and of course, symlinks are important in such environments. > > Absolute symlinks in such an environment either point to a local equivalent or > they do not point to anything. Both is accepted behavior as this does not > differ from the non-chrooted case. > > Relative symlinks that point outside the chrooted environment are evaluated > according to the rules for symlinks and for the root directory. > > I see no can of worms here. What happens when you chroot into a _subtree_ of that lofs? How would that kind of symlink look like to readlink(2) and what would following it do to you? > Let me look at the "binding"... I cannot see any advantage compared to loopback > mounts. Do you know such an advantage? Why, yes - I do. A bunch of those. * lack of coherency issues; we don't get to deal with separate set of vnodes as Solaris does. * our variant is actually lighter, both in terms of memory consumption and in runtime overhead. * it's conceptually simpler - there is (as in any Unix) a forest of directory trees (one for each active fs) and there is a mount tree that glues a unified namespace out of their pieces. Each node in that tree bears an arbitrary subtree of some active fs. mount --bind simply creates a new mount node refering to subtree rooted at given directory (or a non-directory, while we are at it, in which case we want the mountpoint to be a non-directory as well). * it plays well with namespaces - just make the mount tree a property of process, just as the descriptor table, cwd/root, address space, etc., with the only difference being that fork(2) shares that one instead of copying; clone(2) does allow creating a copy (so does unshare(2)). That's a lot cleaner than chroot, BTW, and being able to put a part of fs into such environment without plopping the whole tree into it is very convenient. > point related symlinks. Given the fact that the Rock Ridge filesystem is older > than Linux and that RR introduced mount point related absolute symlinks, isn't > this bind mount something that could have been avoided? > > Well, I have to admit that Solaris does not implement mount point related > absolute paths in symlinks with Rock Ridge even though it could be done. > Seems like I should write than code ;-) Seems like somebody in Sun had enough taste to say "no, thanks" to that kind of kludge, actually, but don't let that stop you - not our kernel, not our headache and all such... FWIW, mount --bind is loosely based on Plan 9 bind(8). There are differences in semantics (their variant leads to possibility of infinite mount trees, which is _not_ something gracefully dealt with by existing Unix codebase) and implementation differs as well, but the basic idea comes from there. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
