{"id":218,"date":"2008-12-13T12:45:47","date_gmt":"2008-12-13T10:45:47","guid":{"rendered":"http:\/\/glandium.org\/blog\/?p=218"},"modified":"2010-01-27T08:52:26","modified_gmt":"2010-01-27T07:52:26","slug":"shared-subtrees","status":"publish","type":"post","link":"https:\/\/glandium.org\/blog\/?p=218","title":{"rendered":"Shared subtrees"},"content":{"rendered":"

As reply to my previous post about per-process namespaces<\/a>, Russell wrote about pam-namespace and shared subtrees<\/a>. As he reports, pam-namespace (that I discovered by the occasion) can do what I was suggesting would be nice for pam-tmpdir.<\/p>\n

Anyways, I was actually already planning to write about shared subtrees and how they can be useful with namespaces. In this first post, I will introduce shared subtrees, while in a follow-up post I will introduce how they can usefully be used with namespaces.<\/p>\n

As a preliminary note, you should know that while etch's kernel supports shared subtrees, etch's mount<\/code> doesn't support the necessary options. Lenny's mount is unfortunately uninstallable on etch due to its dependency on a newer libc. But you can find a smount<\/code> utility's source code in Documentation\/filesystems\/sharedsubtree.txt in the kernel source, where other explanations about the feature are available. So, you can either backport lenny's util-linux to etch, or build smount<\/code> to replicate what I will be doing below. If you are using smount<\/code>, just replace <\/p>\n

mount --make-type<\/em> path<\/em><\/code><\/p><\/blockquote>\n

with <\/p>\n

smount path<\/em> type<\/em><\/code><\/p><\/blockquote>\n

As seen in my previous post<\/a>, bind-mounting allows to attach a file hierarchy at some other place in the virtual file system.<\/p>\n

mount --bind \/ \/mnt<\/code><\/p><\/blockquote>\n

will make all the contents of \/<\/code> (\/bin<\/code>, \/etc<\/code>, ...) available through \/mnt<\/code> (\/mnt\/bin<\/code>, \/mnt\/etc<\/code>, ...).<\/p>\n

On the other hand, sub-mounts will be ignored in such a case. For instance, \/usr<\/code> is usually a different mount point from \/<\/code>. It means \/mnt\/usr<\/code> will be empty (provided it is empty in the underlying physical filesystem), instead of containing the same as \/usr<\/code>:<\/p>\n

$ mount --bind \/ \/mnt
\n$ ls \/mnt\/usr
\n$ ls \/usr
\nbin games include lib lib32 lib64 local sbin share src X11R6
\n$ umount \/mnt
\n<\/code><\/p><\/blockquote>\n

If you also want \/usr<\/code> to be bind-mounted, you must use --rbind<\/code> instead of --bind<\/code>:<\/p>\n

$ mount --rbind \/ \/mnt
\n$ ls \/mnt\/usr
\nbin games include lib lib32 lib64 local sbin share src X11R6
\n$ ls \/usr
\nbin games include lib lib32 lib64 local sbin share src X11R6
\n<\/code><\/p><\/blockquote>\n

Obviously, sub-sub-mounts will also be propagated.<\/p>\n

Since recursively bind-mounting will create a bunch of mount points, unmounting can become a hassle. You can use the following command to unmount everything:<\/p>\n

$ awk '$2 ~ \/^\\\/mnt\/ {print $2}' \/proc\/mounts | sort -r | xargs umount<\/code><\/p><\/blockquote>\n

Now, this is where shared subtrees come in. After the bind mount has been done, if you mount something on either side of the bind mount, the new mount is not propagated. This is called private<\/code> subtrees, and is the default. But before doing anything else, let's setup our testing environment:<\/p>\n

$ mkdir -p \/a\/a \/b
\n$ touch \/a\/b \/a\/c
\n$ ls \/a
\na b c
\n$ ls \/b
\n<\/code><\/code><\/p><\/blockquote>\n

After, bind-mounting \/a<\/code> onto \/b<\/code>, let's see what happens when mounting something under \/a<\/code>, then under \/b<\/code>:<\/p>\n

$ mount --bind \/a \/b
\n$ ls \/b
\na b c
\n$ mount --bind \/usr \/a\/a
\n$ ls \/a\/a
\nbin games include lib lib32 lib64\tlocal sbin share\tsrc X11R6
\n$ ls \/b\/a
\n$ umount \/a\/a
\n$ mount --bind \/usr \/b\/a
\n$ ls \/a\/a
\n$ ls \/b\/a
\nbin games include lib lib32 lib64\tlocal sbin share\tsrc X11R6
\n$ umount \/b\/a
\n<\/code><\/p><\/blockquote>\n

As I said earlier, these new mounts are not propagated. Note that I used bind-mounts as sub mounts, but it would work all the same with other kind of mounts (device, fuse, etc.).<\/p>\n

There are 2 other modes that allow to have some propagation: shared<\/code> and slave<\/code>.<\/p>\n

shared<\/code> allows mounts on both ends to be shared. Note you need to set the mode before bind-mounting:<\/p>\n

$ umount \/b
\n$ mount --bind \/a \/a<\/code> # This is needed because \/a<\/code> is not initially a mount point and you can only apply subtree modes to mount points.
\n$ mount --make-shared \/a
\n$ mount --bind \/a \/b
\n$ mount \/dev\/sda1 \/a\/a
\n$ ls \/a\/a
\nconfig-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64\tSystem.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
\n$ ls \/b\/a
\nconfig-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64\tSystem.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
\n$ umount \/a\/a
\n$ mount \/dev\/sda1 \/b\/a
\n$ ls \/a\/a
\nconfig-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64\tSystem.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
\n$ ls \/b\/a
\nconfig-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64\tSystem.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
\n$ umount \/b\/a
\n<\/code><\/p><\/blockquote>\n

You can even mount on one end and unmount from the other:<\/p>\n

$ mount \/dev\/sda1 \/a\/a
\n$ umount \/b\/a
\n$ ls \/a\/a
\n<\/code><\/p><\/blockquote>\n

slave<\/code> allows mounts on the \"master\" end (\/a<\/code> in our case) to propagate to the \"slave\" end (\/b<\/code>), but not the other way around. The \"master\" end need to be shared<\/code> :<\/p>\n

$ umount \/b
\n$ mount --make-shared \/a<\/code> # Only for completeness, we already set \/a<\/code> as shared<\/code> earlier.
\n$ mount --bind \/a \/b
\n$ mount --make-slave \/b
\n$ mount \/dev\/sda1 \/a\/a
\n$ ls \/a\/a
\nconfig-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64\tSystem.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
\n$ ls \/b\/a
\nconfig-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64\tSystem.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
\n$ umount \/a\/a
\n$ mount \/dev\/sda1 \/b\/a
\n$ ls \/a\/a
\n$ ls \/b\/a
\nconfig-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64\tSystem.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
\n$ umount \/b\/a
\n<\/code><\/p><\/blockquote>\n

There is a third mode, unbindable<\/code>, that does something different:<\/p>\n

$ umount \/b
\n$ mount --make-unbindable \/a
\n$ mount --bind \/a \/b
\nmount: wrong fs type, bad option, bad superblock on \/a,
\n       missing codepage or helper program, or other error
\n       In some cases useful info is found in syslog - try
\n       dmesg | tail or so
\n$ mount --bind \/a\/a \/b
\nmount: wrong fs type, bad option, bad superblock on \/a,
\n       missing codepage or helper program, or other error
\n       In some cases useful info is found in syslog - try
\n       dmesg | tail or so
\n<\/code><\/p><\/blockquote>\n

As you can see, it disallows bind mounting of \/a<\/code> and its subdirectories to some other place.<\/p>\n

Finally, to put back the default mode, you can use:<\/p>\n

$ mount --make-private \/a<\/code><\/p><\/blockquote>\n

Similarly to --bind<\/code>, there is also a recursive version of each: rshared<\/code>, rslave<\/code>, runbindable<\/code> and rprivate<\/code>, to apply these to sub-mounts.<\/p>\n","protected":false},"excerpt":{"rendered":"

As reply to my previous post about per-process namespaces, Russell wrote about pam-namespace and shared subtrees. As he reports, pam-namespace (that I discovered by the occasion) can do what I was suggesting would be nice for pam-tmpdir. Anyways, I was actually already planning to write about shared subtrees and how they can be useful with […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[23],"class_list":["post-218","post","type-post","status-publish","format-standard","hentry","category-pdo","tag-en"],"_links":{"self":[{"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=\/wp\/v2\/posts\/218","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=218"}],"version-history":[{"count":3,"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=\/wp\/v2\/posts\/218\/revisions"}],"predecessor-version":[{"id":661,"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=\/wp\/v2\/posts\/218\/revisions\/661"}],"wp:attachment":[{"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=218"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=218"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=218"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}