[CRIU] [RFC] mount: Add ability to c/r devtmpfs

[Pavel Emelyanov]

On 10/17/2014 04:53 PM, Cyrill Gorcunov wrote:
> On Fri, Oct 17, 2014 at 04:47:30PM +0400, Pavel Emelyanov wrote:
>> On 10/16/2014 08:59 PM, Cyrill Gorcunov wrote:
>>> Looking into experiments with OpenVZ kernel
>>> it seems plain tar over devtmpfs should be
>>> enough for a while. So here is a new option
>>> comes in "--devtmpfs-content".
>>
>> Can we instead compare the dev_t of the devtmpfs
>> with the host's one and, if match, just dump the
>> mountpoint?
> 
> What would you do if you need to restore on another host?

The same. We don't even have to make dump and restore be
consistent.

There are 4 combinations:

Both dump and restore don't see virtualized devtmpfs. This is
simple -- just don't dump devtmpfs and don't restore one.

Both dump and restore DO see own devtmpfs. This is also simple --
we dump its contents and restore one back.

Dump has virtualized devtmpfs, restore shares one with host.
Although we have the devtmpfs.tar.img, we don't need to restore
one. In case we really miss something from it, we will fail
on files opening. If not -- why should CRIU care?

Dump has shared devtmpfs, restore has its own instance. This,
I believe, would be absolutely identical to the previous.
We don't have te devtmpfs.tar.img, but by default the devtmps
has standard files and if container uses some "strange" one
we will still fail on files opening.

> This option is up to a user which should know what he is
> doing and if he really needs this content at all.
> .
>