Mounts

From Linux Checkpoint / Restart Wiki
(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
See 'Mounts namespaces' under  http://ckpt.wiki.kernel.org/index.php/LPC2009. [http://www.research-service.com/custom-research-paper.html research paper]
+
See 'Mounts namespaces' under  http://ckpt.wiki.kernel.org/index.php/LPC2009.
(fill in a more detailed design here)
+
 
 +
For private mounts namespaces inside a container we should be able to
 +
detect which mounts distinct from those in the container init's namespace.
 +
Recreating these mounts, including propagation info, should not be difficult.
 +
 
 +
The fuzzy part is what to do about mounts in the container init's namespace.
 +
It is not clear that there is a reliable way to
 +
 
 +
  # detect what was mounted by the container init
 +
    ## Do we compare to container_init->parent, which may have changed?
 +
    ## Or against checkpointer's mounts, from which container mounts may not even be reachable?
 +
  # predict how the container init's mounts should be hooked into the system
 +
 
 +
We are safest punting on (2) and simply requiring that the container init's environment
 +
is recreated before calling sys_restart().
 +
 
 +
We can probably also safely punt on (1) in the same way.  In particular:
 +
 
 +
  # a container which was started using libvirt or [[lxc.sf.net|lxc]] can just recreate the same mounts based on fstab as were created for the original container
 +
  # for a more custom HPC job, the software doing the checkpoint may want to analyze /proc/initpid/mountinfo to decide what to do.

Revision as of 19:50, 17 February 2010

See 'Mounts namespaces' under http://ckpt.wiki.kernel.org/index.php/LPC2009.

For private mounts namespaces inside a container we should be able to detect which mounts distinct from those in the container init's namespace. Recreating these mounts, including propagation info, should not be difficult.

The fuzzy part is what to do about mounts in the container init's namespace. It is not clear that there is a reliable way to

  # detect what was mounted by the container init
    ## Do we compare to container_init->parent, which may have changed?
    ## Or against checkpointer's mounts, from which container mounts may not even be reachable?
  # predict how the container init's mounts should be hooked into the system

We are safest punting on (2) and simply requiring that the container init's environment is recreated before calling sys_restart().

We can probably also safely punt on (1) in the same way. In particular:

  # a container which was started using libvirt or lxc can just recreate the same mounts based on fstab as were created for the original container
  # for a more custom HPC job, the software doing the checkpoint may want to analyze /proc/initpid/mountinfo to decide what to do.
Personal tools