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

Filipe Brandenburger filbranden at google.com
Thu Jun 5 09:32:04 PDT 2014


I'm not really in love with the --ext-mount approach but unfortunately
I still haven't managed to come up with something better than it...

If we do go with this approach, I'll do the small suggestion of using
":" as a separator character since it's way less likely to be found in
a path than "=", considering using ":" in a directory name will
already yield problems with settings like $PATH and $LD_LIBRARY_PATH
and it's also used as a separator between host and path in commands
like scp, etc.

Another option would be to just forego the whole "magic string tokens"
approach and have dump record the mount points with their real names,
then have restore refer to them as their original real names (e.g.
/foo/bar:/foo2/bar in restore, /foo/bar is only an option if it's
really found to be a bind mount during dump.)

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...

I really think the best approach would be to look into why this
information is not available, whether it's actually available in the
kernel itself and whether it could be exposed from the kernel...

Cheers,
Filipe


On Thu, Jun 5, 2014 at 8:10 AM, Pavel Emelyanov <xemul at parallels.com> wrote:
> So, the 1st attempt with modifying original mount points roots is
> not working since the paths we see in /proc and dump are relative
> to the FS's root, not relative to global (well, CRIU's) root.
>
> That said, we can try to go another route and here it is.
>
> On dump we use one or more --ext-mount option with A=B arguments.
> A denotes a mountpoint (as seen from the target mount namespace)
> criu dumps and B is the string that will be written into the
> image file instead of the mountpoint's root. E.g. if we have a
> /foo/bar bind mounted into container under /x name, then the
> --ext-mount /x=foobar option will tell criu, that /x is a mount
> point with external source and it should write "foobar" into image
> instead of the path read from /proc.
>
> On restore we use the same --ext-mount option(s) with similar
> A=B arguments, but this time criu treats A as string from the
> image's root field (foobar in the example above) and B as the
> path in criu's mount namespace the should be bind mounted into
> the mountpoint.
>
> For example, let's again imagine we have /foo/bar bind mounted
> into container under /x name and /foo/bar is inaccessible from
> this container.
>
> On dump we say --ext-mount /x=foobar and mountpoints.img will
> contain a mountpoint with root=foobar and mountpoint=/x. On restore
> we use --ext-mount foobar=/foo2/bar option. This will result the
> /foo2/bar from criu's namespace get bind-mounted to /x inside the
> container we restore.
>
>
> Thanks,
> Pavel
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu


More information about the CRIU mailing list