On 26 nov. 2009, at 16:50, Liran Schour wrote:
>
> Jan Kiszka <jan.kis...@siemens.com> wrote on 26/11/2009 15:53:49:
>
>
>>> + qemu_get_buffer(f, buf,
>>> + BLOCK_SIZE);
>>> + if(bs != NULL) {
>>> +
>>> + bdrv_write(bs, (addr >> SECTOR_BITS),
>>> + buf, block_mig_state->sectors_per_block);
>>
>> This synchronous write-back translates appears to be the reason for an
>> unusable migration (or restore from snapshot) speed: about 100 KB/s here
>> (ie. 22h for a rather small 8G guest :( ). Did you already try to
>> improve this situation?
>
> I have seen this behavior, but it seems that there is a very big difference
> in the performance if the new block device is based on an allocated file
> already (try the same migration to an already allocated file in the
> requested size) I am trying to figure out why we see this behavior.(any
> ideas?)
> Anyway we can turn the writes to be async but we have to synchronize all
> destinations writes before completing the migration and moving the guest to
> the destination. When the guest starts to run on the destination all writes
> should be finished, so anyhow we need to wait synchronously to the writes.
> I will look on this further next week.
You second patchset for this feature (around September 10) was much faster than
the others.
Do you remember what was different?
--
Pierre Riteau -- http://perso.univ-rennes1.fr/pierre.riteau/
