[CRIU] [RFC][PATCH 0/3] Proposal for native (w/o plugins) support for external bind mounts v2

[Pavel Emelyanov]

On 06/05/2014 08:49 PM, Saied Kazemi wrote:
> Pavel,
> 
> Actually the first attempt is working, albeit with a little help.  
> So I don't think we need to _replace_ the entire path that is relative
> to the FS's root with what is passed to CRIU on the command line.  We
> just need to find the missing part of the pathname and prepend it to the 
> relative path.

I do like the first approach myself, but here's the blocker case
for it, that I have in mind.

Consider we have two different filesystems mounted at /fs1 and /fs2
respectively, then we have two files named 'foo' on _both_. Then we
bind mount them into container and chroot it, like this

/fs1/foo -> /ct/root/file1
/fs2/foo -> /ct/root/file2
chroot(/ct/root)

CRIU would dump these two records into mountpoints.img file:

root: /foo  mountpoint: /file1
root: /foo  mountpoint: /file2

Even if we know, that first point is from /fs1 and the 2nd one is
from /fs2, we would not be able to tell this to CRIU using the first
version of this set.


The problem is even deeper. Consider we modify the example like this

/fs1/foo -> /ct/root/file1
/fs2/foo -> /ct/root/file2
umount /fs1
umount /fs2
chroot(/ct/root)

This is 100% valid, but after this there would not be able to find
out any full paths to /foo files from CRIU images.

> Let's look at the following realistic example from Docker.  Docker bind 
> mounts the container's /etc/host as follows:
> 
> mount /var/lib/docker/containers/<ID>/hosts /var/lib/docker/vfs/dir/<ID>/etc/hosts
> 
> The container's root is at /var/lib/docker/vfs/dir/<ID>.  For container's 
> /etc/hosts, CRIU records /containers/<ID>/hosts as source during dump.  On 
> restore, CRIU already has the container's root and ./etc/hosts within it, so
> all it needs is the leading /var/lib/docker for external bind mount.  In other 
> words, there is no need replacing the entire path which is --by the way--
> dynamically generated for each container and not always easy to figure out.

But if the <container-id> is always generated, the /containers/<ID>/...
record in the image files would be pointless, wouldn't it?

> Does it make sense?

Thanks,
Pavel