No subject


Mon Mar 1 10:08:44 PST 2010


except proc, tmpfs,  and devpts be a bind mount from the container's
parent mounts namespace.  That way restart can be completely independent
of devices and fs layout, and /bin/restart or lxc-restart or whatever
can just recreate the mnt/directory structure of the parent.  Then
the kernel can just slice and dice with bind mount.

But let's assume the container has /tmp2 bind-mount on /tmp.  Near as
i can tell, asking for the path of the source of that bind mount is
like asking what the real filename of an inode is - there is no single
reliable answer.  So my plan right now is to record the maj:min and
the device-relative pathname - in other words the info we have in
/proc/mountinfo.  The problem is that makes us dependent on devices.

I think we'll have to deal with that with translation of checkpoint
images.

Second, mounts changes caused by host.  Let's say the container was
created with /var/spool being a mount (mount --bind . .) and that
/var/spool is either a shared or slave mount.  Now, after the container
has been started, the host does a mount --bind /usr/spool/mail /var/spool/mail.
A few ways we could deal with that:

	1. We refuse checkpoint of a container which has any mounts
	   propagation escaping the container.  That'll turn into one
	   very ugly check, but should be do-able.  However, it is not
	   100% reliable.  In particular, after the bind mount above,
	   the container could have done mount --make-rprivate /var/spool.
	   Now checkpoint will not catch the past propagation leak,
	   and restart will be 'wrong'.

	2. A wrapper around the checkpoint program records the mounts
	   which existed when the container was started, and records
	   any changes at the time of checkpoint.
	
	3. (save your 'yuck's please :) We only allow mounts - or maybe
	   mounts propagation - checkpoint relative to either a
	   previous checkpoint, or some sort of configuration file
	   showing the initial state of mounts.

	   So perhaps if you want mounts c/r in a container, you must
	   start the container in a frozen state, do your first checkpoint
	   before the container's init starts up, and then do incremental
	   checkpoints from there.

Third, there is the issue of mounts propagation in general.  I suspect
the only sane thing to do is to require that propagation into and out
of the container is set up correctly by /bin/restart - not our problem
how that is done - and then we can re-create propagation between mounts
in all mounts namespaces which are isolated inside the container.

Finally, it isn't lost on me that we may have everything we need in
userspace through /proc/self/mountinfo.  In fact, we can even tell
mounts namespaces since /proc/$$/mountinfo will give us different
mount ids for / in different mounts namespaces.  So perhaps we can
have user-cr/restart.c do the CLONE_NEWNS and restore mounts.

Comments?

thanks,
-serge


More information about the Containers mailing list