On Mon, Jul 01, 2013 at 06:09:55PM +0200, Peter Lieven wrote:
>
> Am 01.07.2013 um 16:13 schrieb Stefan Hajnoczi <stefa...@redhat.com>:
>
> > On Thu, Jun 27, 2013 at 03:11:32PM +0200, Peter Lieven wrote:
> >>
> >> /* device name */
> >> len = strlen(blk->bmds->bs->device_name);
> >> qemu_put_byte(f, len);
> >> qemu_put_buffer(f, (uint8_t *)blk->bmds->bs->device_name, len);
> >>
> >> + /* if a block is zero we need to flush here since the network
> >> + * bandwidth is now a lot higher than the storage device bandwidth.
> >> + * thus if we queue zero blocks we slow down the migration */
> >> + if (flags & BLK_MIG_FLAG_ZERO_BLOCK) {
> >> + qemu_fflush(f);
> >> + return;
> >> + }
> >
> > Not sure I understand this. Is the problem that the other side may
> > require an slow writev() to fill zeros? So you want to tell the
> > destination about the zeroes ASAP.
>
> Sorry, missed this question. Yes. If a lot of zero blocks is queued it delays
> migration because the target is idle while the source is queuing zero blocks.
Thanks. I think this makes sense.
Stefan
