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

[Saied Kazemi]

You're right about /fs1 /fs2 example above, it can get pretty convoluted.

Regarding Docker container IDs, they are generated when new containers
(along with their new filesystems) are created.  For dump/restore, however,
we need to keep the same container ID and preserve the state of its
filesystem.  This requires Docker changes.  My comment was about the
difficulty of specifying long container root pathnames as command line
arguments to CRIU.  You'd have to first find the ID through docker ps and
then provide it in full (64 characters) in addition to the leading
/var/lib/docker/vfs/root/ string.  So recording the container ID during
dump, as it's currently, done is advantageous.

--Saied



On Thu, Jun 5, 2014 at 10:05 AM, Filipe Brandenburger <filbranden at google.com
> wrote:

> On Thu, Jun 5, 2014 at 9:57 AM, Pavel Emelyanov <xemul at parallels.com>
> wrote:
> >> The --ext-mount parameter could also take the name of a file with a
> >> set of directory mappings, which might be easier to maintain than two
> >> tokens with a magic separator between them...
> >
> > Not sure I understand this, can you elaborate?
>
> Something like --ext-mount /path/to/mappingfile and then have
> mappingfile use a format that makes it possible to list a number of
> mappings (no need for repeated options) and with no restrictions on
> the characters found in the path names (i.e. can handle paths with "="
> or ":" in them.)
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20140605/bf43ba01/attachment.html>