[CRIU] why page-server does not transfer all the dumped pages?

[Hui Kang]

Hi, Pavel,
Thanks for your explanation.

- Hui

On Tue, Apr 28, 2015 at 11:45 AM, Pavel Emelyanov <xemul at parallels.com>
wrote:

> On 04/28/2015 06:35 PM, Hui Kang wrote:
> >
> > On Tue, Apr 28, 2015 at 11:28 AM, Pavel Emelyanov <xemul at parallels.com
> <mailto:xemul at parallels.com>> wrote:
> >
> >     On 04/28/2015 06:23 PM, Hui Kang wrote:
> >     > Hi,
> >     > I have tested about the disk-less page migrations. As the
> instruction says, after dumping
> >     > pages to the destination, there exists some small pages on the
> source node.
> >     >
> >     > I am just curious what is the rational of not transferring all the
> dumped pages. Thanks.
> >
> >     If you request for --page-server dump (or pre-dump) no pages are put
> in
> >     the source images. Do you see non-empty pages*.img files?
> >
> >
> > I follow the instructions on this link (
> http://criu.org/Disk-less_migration). Step 4 says "As was
> > said, CRIU images other than those with pages are very small and this
> won't take long. "
> > I am asking why those CRIU images are not sent to the page-server.
>
> Ah, I see.
>
> The idea behind this is quite simple. In order to transfer images as they
> are generated requires
> a non-trivial protocol for it. We didn't want to implement it since there
> exists plenty of them.
> And sine images are typically several hundreds kilos in size, we can just
> dump them into tmpfs,
> then scp (or rsync or whatever) into the destination side. With pages this
> trick doesn't work for
> two reasons. First, pages images can occupy gigs, we can't put them on
> tmpfs. Second -- while
> doing iterations we need to drop the overwritten pages from images, thus
> the transferring protocol
> is not just "copy". So, as a balance, we implemented the protocol for
> pages only.
>
> If you have ideas how to improve that and transfer all images w/o
> intermediate storage (even tmpfs)
> you're welcome to share it :)
>
> -- Pavel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150428/8c087113/attachment.html>