Mike Hommey: Shared subtrees
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 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.
As a preliminary note, you should know that while etch’s kernel supports shared subtrees, etch’s
mount 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 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 to replicate what I will be doing below. If you are using smount, just replacemount --make-type path
withsmount path type
As seen in my previous post, bind-mounting allows to attach a file hierarchy at some other place in the virtual file system.
mount --bind / /mnt
will make all the contents of / (/bin, /etc, …) available through /mnt (/mnt/bin, /mnt/etc, …).
On the other hand, sub-mounts will be ignored in such a case. For instance, /usr is usually a different mount point from /. It means /mnt/usr will be empty (provided it is empty in the underlying physical filesystem), instead of containing the same as /usr:
$ mount --bind / /mnt
$ ls /mnt/usr
$ ls /usr
bin games include lib lib32 lib64 local sbin share src X11R6
$ umount /mnt
If you also want /usr to be bind-mounted, you must use --rbind instead of --bind:
$ mount --rbind / /mnt
$ ls /mnt/usr
bin games include lib lib32 lib64 local sbin share src X11R6
$ ls /usr
bin games include lib lib32 lib64 local sbin share src X11R6
Obviously, sub-sub-mounts will also be propagated.
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:
$ awk '$2 ~ /^\/mnt/ print $2 ' /proc/mounts sort -r xargs umount
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 subtrees, and is the default. But before doing anything else, let’s setup our testing environment:
After, bind-mounting$ mkdir -p /a/a /b
$ touch /a/b /a/c
$ ls /a
a b c
$ ls /b
/a onto /b, let’s see what happens when mounting something under /a, then under /b:
$ mount --bind /a /b
$ ls /b
a b c
$ mount --bind /usr /a/a
$ ls /a/a
bin games include lib lib32 lib64 local sbin share src X11R6
$ ls /b/a
$ umount /a/a
$ mount --bind /usr /b/a
$ ls /a/a
$ ls /b/a
bin games include lib lib32 lib64 local sbin share src X11R6
$ umount /b/a
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.).
There are 2 other modes that allow to have some propagation: shared and slave.
shared allows mounts on both ends to be shared. Note you need to set the mode before bind-mounting:
You can even mount on one end and unmount from the other:$ umount /b# This is needed because
$ mount --bind /a /a/ais not initially a mount point and you can only apply subtree modes to mount points.
$ mount --make-shared /a
$ mount --bind /a /b
$ mount /dev/sda1 /a/a
$ ls /a/a
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
$ ls /b/a
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
$ umount /a/a
$ mount /dev/sda1 /b/a
$ ls /a/a
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
$ ls /b/a
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
$ umount /b/a
$ mount /dev/sda1 /a/a
$ umount /b/a
$ ls /a/a
slave allows mounts on the “master” end (/a in our case) to propagate to the “slave” end (/b), but not the other way around. The “master” end need to be shared :
There is a third mode,$ umount /b# Only for completeness, we already set
$ mount --make-shared /a/aassharedearlier.
$ mount --bind /a /b
$ mount --make-slave /b
$ mount /dev/sda1 /a/a
$ ls /a/a
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
$ ls /b/a
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
$ umount /a/a
$ mount /dev/sda1 /b/a
$ ls /a/a
$ ls /b/a
config-2.6.26-1-amd64 grub initrd.img-2.6.26-1-amd64 System.map-2.6.26-1-amd64 vmlinuz-2.6.26-1-amd64
$ umount /b/a
unbindable, that does something different:
$ umount /b
$ mount --make-unbindable /a
$ mount --bind /a /b
mount: wrong fs type, bad option, bad superblock on /a,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg tail or so
$ mount --bind /a/a /b
mount: wrong fs type, bad option, bad superblock on /a,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg tail or so
As you can see, it disallows bind mounting of /a and its subdirectories to some other place.
Finally, to put back the default mode, you can use:
$ mount --make-private /a
Similarly to --bind, there is also a recursive version of each: rshared, rslave, runbindable and rprivate, to apply these to sub-mounts.


There seems to be indeed a meme on
The new
Yours faithfully,
pommed v1.23 is out, with full support for the late 2008 laptops.
The LCD backlight inner workings got figured out finally, but there s a catch: the backlight won t react to the settings when running X11 with the proprietary nVidia drivers on the MacBook5,1 and the MacBookAir2,1. It works fine on the MacBookPro5,1 and it works fine on all three machines with the opensource nouveau driver. Switching to the console before setting the backlight and then back to X does work as a workaround.
So there s something up with the proprietary nVidia driver, and my uneducated guess is that the MacBook Pro may somehow be exempt from the issue due to its dual GPU config.
I ve also switched the nVidia machines to using the generic sysfs backlight driver in pommed. This driver has been there for some time for the PowerPC machines, so now it s part of the generic pommed code. You need the mbp_nvidia_bl driver in your kernel for this to work.
Don t panic! If you don t have it, pommed will fall back to the native driver (nv8600mgt) and everything will work just as before. Pommed will tell you if it has to fall back to the native driver, so check your logs if you want to know.
This release of pommed needs testing on all nVidia machines: MacBookPro3,1, MacBookPro4,1, MacBookPro5,1, MacBook5,1 and MacBookAir2,1. If anything doesn t work, tell me about it and I ll fix it.
Can somebody tell me, why 

I received a new laptop, a Dell Latitude E4300. I was a bit anxious with its level of support on Linux, because it only recently started being shipping, and it s full of recent Intel hardware. Also, with lenny being frozen for 5 months, we are currently a bit behind regarding hardware support.
I installed lenny on it, as I usually run
Some years ago I wrote a little tool called 