[CRIU] [RFC] FSTYPE__UNSUPPORTED/AUTO && non-virtual filesystems

[Oleg Nesterov]

On 03/30, Christopher Covington wrote:
>
> On 03/30/2015 11:35 AM, Oleg Nesterov wrote:
> >
> > you know I am very-very new to criu/etc, not sure I understand you
> > correctly...
> >
> > On 03/30, Christopher Covington wrote:
> >>
> >> Hi Oleg,
> >>
> >> On 03/28/2015 02:18 PM, Oleg Nesterov wrote:
> >>
> >>> BUT. This makes me think again that we do want --ignore-this-mountpoint
> >>> option. Why not? And afaics trivial to implement. Of course, this will
> >>> be "use at your own risk" too.
> >>
> >> How hard would it be to unshare the mount namespace, unmount the mountpoint
> >> you want to ignore, and then dump the checkpoint?
> >
> > How can unshare help? Perhaps you mean setns() + umount? But there can be
> > other processes in the same mnt ns which need this mountpoint?
>
> I usually dump very simple process trees in simple environments where this
> sort of thing can work. It sounds like you have a more sophisticated process
> tree and environment where it wouldn't work.

Heh ;) my process tree is the single

	perl -e 'close STDIN; close STDOUT; close STDERR; sleep'

process ;) But it runs in another (non root) mnt namespace. And I am trying
to dump/restore it from the root namespace.

> (As far as I can tell, setns() is
> for using a namespace that already exists, probably created by special flags
> passed to clone() while unshare() creates a new namespace and uses it in one
> call.)

Yes, so I think unshare can't help...

> > But the main question is why we can't add a cli option for that? And the
> > patch is really simple after cleanups I sent. Hopefully I'll send it today
> > if I have a bit of time.
>
> I just wanted to check if it might be even simpler to do it outside of CRIU
> than inside.

Perhaps, but I still do not see how... and to me the cli option looks like
the simplest solution.

OK. Lets discuss this again when I send the patch? I'll cc you. Unfortunately
I do not have time today, will try to do this tomorrow.

Oleg.