Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> 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?
As mentioned, the readlink would be evaluated in the original filesystem and as
the result is only a string, the interpretation has to be done later with
respect to the chroot facts.
> > 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.
I see more coherence isssues with the way this "bind" has been explained to me.
The separate set of vnodes creates a clean layering.
> * our variant is actually lighter, both in terms of memory
> consumption and in runtime overhead.
I would believe the converse:
- a function call does not cause much runtime overhead
- the memory requirements for the Solaris model seems to lighter than
something that needs to supply data structures even in case they are
not used.
> * 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).
I see no advantage here.
> * 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.
It is not about chroot but about a clean name space at fs level and I see a
cleaner implementation if every mount results in an own related vfs.
> > 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...
The Solaris RR implementation has been written in 1988 already and at that
time, the kernel did not keep path names of mount points as it does now that
getcwd() is a syscall and procfs2 provides path names for objects.
Nobody touched the path conversion code since then.....
But you remind me of a hsfs/iso9660 problem on Linux that has not been fixed
since a long time:
Around 2004/2005, someone from FreeBSD discovered that FreeBSD, Linux and
Solaris all paniced from mounting a iso9660 strange data. FreeBSD has been
enhanced and together with a friend, I introduced range checks and other
hardening for the Solaris implementation. While it is no longer possible to
harm Solaris with a bad iso9660 media, this is still easy with Linux.
> 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.
>From the man page of bind(1) on Plan 9, the related idea is rather something
like the SunOS translucent filesystem (tfs) that has been introduced together
with lofs in 1986 for NSE. I cannot see a direct relation between Linux and
Plan 9 here.
Jörg
--
EMail:joerg@xxxxxxxxxx (home) Jörg Schilling D-13353 Berlin
js@xxxxxxxxxxxxxxx (uni)
joerg.schilling@xxxxxxxxxxxxxxxxxxx (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
--
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
