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

[Pavel Emelyanov]

On 06/05/2014 08:32 PM, Filipe Brandenburger wrote:
> 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.

Makes sense to me. Will rework.

> Another option would be to just forego the whole "magic string tokens"
> approach and have dump record the mount points with their real names,

My idea was that in dump files we should not have anything, that 
refers to the "outer world" of the container we dump. Any knowledge
about these outer things should come from criu caller, not from the
images. According to this ->root strings for external mount points
should be at least empty in the images.

> 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 problem is that original names are not full paths, but names of
a file _withing_ their filesystem. IOW, if you call

# mount --bind /foo/bar/foobar /x

in /proc/self/mountinfo you may see see any of the /foo/bar/foobar,
/bar/foobar and /foobar as the mountpoint root.

Having that using these strings is difficult for two reasons:

a) they may coincide
b) knowing what you have just bind-mounted, it would be hard to 
   evaluate what the resulting string would look like (as in the
   example above).

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

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

AFAIK this info is provided in this form simply because there's
not way to distinguish FS mounts from bind-mounts in the kernel 
and for "just mounts" printing anything but "/" as the root path
simply makes no sense.

Moreover, the root of the mountpoint (the source directory of a
bind mount) can be accessible via many paths, and it's not clear
which one to print there.

Thanks,
Pavel