From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: FW: Symbolic link with absolute target path in UDF - not working properly? Date: Wed, 14 Dec 2011 00:45:03 +0000 Message-ID: <20111214004503.GK2203@ZenIV.linux.org.uk> References: <20111212141817.GA5473@quack.suse.cz> <4ee73093.ByQYnWpgRk/yNHIS%schily@schily.net> <20111213161303.GE11747@quack.suse.cz> <4ee799c8.IGU4Fg9P4wlTkYIO%schily@schily.net> <20111213192526.GA20267@quack.suse.cz> <4ee7ad60.v6cTrJDUPPEjdDhI%schily@schily.net> <20111213202653.GJ2203@ZenIV.linux.org.uk> <4ee7d490.dvuacxTYdtBRcPEP%schily@schily.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: otnaccess@hotmail.com, linux-fsdevel@vger.kernel.org, joerg@schily.net, jack@suse.cz To: Joerg Schilling Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:44534 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754176Ab1LNApH (ORCPT ); Tue, 13 Dec 2011 19:45:07 -0500 Content-Disposition: inline In-Reply-To: <4ee7d490.dvuacxTYdtBRcPEP%schily@schily.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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.