[CRIU] [PATCH 2/2] introduce --skip-mnt cli option

[Oleg Nesterov]

On 04/03, Pavel Emelyanov wrote:
>
>
> > @@ -1004,6 +1035,13 @@ struct mount_info *parse_mountinfo(pid_t pid, struct ns_id *nsid, bool for_dump)
> >  			goto end;
> >  		}
> >
> > +		if (for_dump && should_skip_mount(new->mountpoint + 1)) {
>
> Sorry for being tedious, but I've found two more ... semantic problems with this option.

Thanks for the comments ;)

> The first is -- two or more mountpoints can have the same path in "mountpoint". E.g.
> # mount -t tmpfs none /tmp
> # mount -t ext4 none /tmp
> and we have two mounts on /tmp. This patch will skip both.

Yes. perhaps we can make should_skip_mount() more clever, say it can
take fsname into account. But see below.

> The second is -- if we have child mounts, then dump will be aborted due to inability
> to resolve parent for child mounts.

Yes, I even tried to document this in the changelog.

> I'm not sure how expected these two things from the user perspective are. For the latter,
> I think that skipping the whole subtree is expected. For the former -- I don't know.
>
> Thoughts?

I do not really know, but to me --skip-mnt should not try to be clever.
It should be simple and stupid. Except perhaps fnmatch() makes sense to
allow (say) "--skip-mnt /sys/fs/cgroup/*".

The main (only?) use-case for this option is the case when criu simply
can't dump/restore this mountpoint (autofs for example). Of course it
can't always help, this is just a workaround which can help sometimes
to overcome the limitations. And obviously criu will always have some
limitations.

So I leave the decision for you. But to me it would be better to force
the user of this option to understand what it does. Say, if "dump" fails
because the child mount can't find the skipped parent, he should add
another --skip-mnt option or do not dump. Otherwise, if we do this
automagically the user can probably be surpised, he might even miss the
fact that we skip more than he asked.

But let me repeat, this all is up to you.

Oleg.