[lxc-devel] [RFC] yet another rootfs pinning change

Christian Seiler christian at iwakd.de
Sat Sep 28 06:36:33 UTC 2013


Hi,

I'm attaching a patch that makes additional chanes to the rootfs
pinning mechanism. It can also be found under:
<https://github.com/chris-se/lxc/tree/rootfs-pinning>

This patch implements things that were floating around in discussions
earlier. I know it is still in flux of how to best handle ro-remounts
at shutdown, so the idea is that this patch would be applied if lxc
will stick with the pinning mechanism. (Which seems likely to me at
this point because of the kernel change that remount without bind will
still remount the whole filesystem, see automounting improvements.)

A bit of rationale for the choices:

 - Don't auto-delete the file after creation because of NFS problems.
 - But then the file will lurk around the system for the whole time, so
   make it hidden, i.e. make the filename start with a dot.
 - Cleanup after ourselves at shutdown. This will still leave files
   in case of a power failure.
 - Because we now cleanup after ourselves at shutdow, and a rootfs
   could be used by potentially multiple containers, encode the pid of
   lxc-start in the filename. That way, even with cleanup, only after
   the last container using that rootfs ends the last hold file will be
   released.
 - Continue to NOT use O_EXCL, see previous discussions, since we don't
   want container startup to fail after reboot with power failure.

Note that the hold file is inside the rootfs now (previously it was
in a directory one level higher), but that was already the case with my
previous rootfs pinning commit that's already applied to master. The
rationale behind this is that I've run into the situation where I have
rootfs on a separate filesystem, but that this filesystem is already
mounted on the host (for various reasons), such that a hold file in the
parent directory will be of no use. But the current change means that
the hold file will leak into the container. I do not think this is
problematic, since the worst thing someone inside the container could
do is unlink it, and that does not affect the basic functionality.

-- Christian





More information about the lxc-devel mailing list