[CRIU] [PATCH 0/2] files: Add ability to skip certain files for size check

Pavel Emelyanov xemul at virtuozzo.com
Fri Mar 24 07:19:18 PDT 2017


On 03/24/2017 05:05 PM, Cyrill Gorcunov wrote:
> On Fri, Mar 24, 2017 at 12:43:49PM +0300, Pavel Emelyanov wrote:
>>>>
>>>> I don't like the idea of such an option :( I'd rather agree on
>>>> some quirk inside the criu code to skip files of that kind.
>>>
>>> The option is just fine. Otherwise we leave customers without
>>> ability to restore applications which use acct() syscall. 
>>
>> Come on, for Virtuozzo case, you can put any hack into vzkernel and
>> keep tiny patch in criu .spec file ;)
> 
> You must be kiddin, right? 

No. The proper fix to the problem we've faced is to fix the upstream
kernel somehow to let CRIU know whether the file in question is acct
or not. At the same time we have to somehow "live with it" till the
fix is propagated to the world. For this short period I propose to
add a quirk OR vz-specific fix. Not the generic criu option we'll
have to maintain for a long time.

> Vz case already have a quirk and I
> don't like it -- it's not firmware which is immutable in most
> case (for which kernel has to carry hackinsh fixups). The
> acct() syscall is pretty valid and any program can use it.
> 
> For our containers we know which quirks to add and can
> hardcode it. But how to be with the rest of the users?
> They really have to be able to say criu somehow -- hey,
> this file is known to be changed after the stop, please
> don't check for its size on restore.

Exactly. If we have this option, "the rest of the users" will have
to know which files are changed after stop and pass this to criu.
What's the point in scattering this knowledge, let's better have it
once in criu and remove it when we have kernel patch.

>>> How mayn quirks we will have to keep?
>>
>> With this option, you'll have to maintain the same set of quirks anyway.
>> But in another (hell knows which) place.
> 
> In turn, they _may_ be dynamic with the option. And
> if someone come with such error because he can't restore
> container we can tell him -- just pass this option
> on restore procedure.

No, things doesn't work this way :) You cannot take random criu user
and make it change the set of options it passes to criu. E.g. users
of "docker checkpoint" complain about this all the time -- there's
not way to add a single option to how docker (well, runc) calls criu.

Quirks for _this_ _particular_ _case_ would work. Environment variables
might also work. The /etc/criu.conf would be the perfect way, but we
still don't have one.

-- Pavel



More information about the CRIU mailing list