[CRIU] bug in shmem restore?

Andrei Vagin avagin at gmail.com
Thu Jun 23 23:37:57 PDT 2016


On Thu, Jun 23, 2016 at 10:45 PM, Mike Rapoport <mike.rapoport at gmail.com> wrote:
>
> On Jun 24, 2016 4:23 AM, "Andrew Vagin" <avagin at virtuozzo.com> wrote:
>>
>> On Thu, Jun 23, 2016 at 11:31:04AM +0300, Mike Rapoport wrote:
>> > Hi,
>> >
>> > I've been looking into reducing use of page-read  internals outside
>> > the page-read.c and found something that seems really weird.
>> >
>> > If auto_dedup is enabled, the restore_shmem_content punches a hole in
>> > the  pagemap image, but it never tries to read anything from the
>> > parent image. Moreover, open_page_read_at does not even bother to open
>> > parent image in case it opens shared memory image.
>> >
>> > If I understand correctly, if the hole is really punched, calling
>> > restore next time on the same set of images will fail.
>>
>> if you use --auto-dedup, you are going to run restore only once
>
> And what if I'd like to use the same checkpoint directories once more, e.g.
> on another host?

Maybe you have to run criu without the --auto-dedup option in this case?

>
>>   --auto-dedup          when used on dump it will deduplicate "old" data
>> in
>>                         pages images of previous dump
>>                         when used on restore, as soon as page is restored,
>> it
>>                         will be punched from the image.
>>
>> >
>> > Am I missing something?
>> >
>> > --
>> > Sincerely yours,
>> > Mike.
>> > _______________________________________________
>> > CRIU mailing list
>> > CRIU at openvz.org
>> > https://lists.openvz.org/mailman/listinfo/criu
>
>
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu
>


More information about the CRIU mailing list