On Tue, Dec 13, 2011 at 08:25:26PM +0100, Jan Kara wrote: > > If this is implemented the way it is implemented in Solaris, there is a > > nearly empty vfs layer, specific to the loopback mount that indirectly > > calls the vfs functions for the base FS. So on Solaris this is > > possible and it would work as expected. > Again, note that loopback mounts are not the hard part here. I could have > mounted standard block devices and nothing interesting would have changed > in my example. What is interesting is that I can create a directory tree > where root of some filesystem is not accessible (there is not a valid path > that would resolve to it) but it's subdirectory is accessible. For the sake of completeness: ; mount /dev/sda1 /mnt ; ls /mnt foo bar ; mkdir /tmp/splat ; mkdir /tmp/wank ; mount --bind /mnt/foo /tmp/splat ; mount --bind /mnt/bar /tmp/wank ; umount /mnt and at that point we have fs on sda1 still active, with two subtrees bound to /tmp/splat and /tmp/wank resp. Root from /sda1, however, is _not_ available anywhere in your namespace. As for the implementation, it's light-weight, all right - more so than what you seem to describe as Solaris one. We do *not* play with stacking here; rather than doing that, we have a pair (vfsmount, dentry) used to describe a point in namespace. The latter is more or less a counterpart of vnode; the former is a point in mount tree. Note that it is *NOT* a counterpart of e.g. BSD struct mount - that would be struct super_block. There may be many vfsmounts refering to the same fs; all of them share struct super_block, etc. - dentry tree is shared, not mirrored. All IO is done as usual, pretty much ignoring the vfsmount side of things (modulo things like per-mountpoint read-only/noatime/etc.). Pathname resolution acts on (vfsmount,dentry) pair, the first component getting changed when we hit a mountpoint and when we walk .. from (mnt, mnt->mnt_root). Process' current directory and root are (vfsmount,dentry) pairs, of course. Each vfsmount refers to a subtree on some filesystem; those subtrees might contain one another, etc. - no coherency problems, since the underlying objects are shared. Filesystem gets shut down when there's no vfsmounts left. Moreover, different processes might have completely unrelated mount trees and any filesystem may have an arbitrary set of subtrees mounted in any namespaces. Up to sysadmin... -- 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
