Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication]

[Dor Laor <dlaor@redhat.com>]

On 05/24/2012 05:19 PM, Paolo Bonzini wrote:
> Il 24/05/2012 16:00, Ori Mamluk ha scritto:
>>
>>> The dirty bitmap is managed by these QMP commands:
>>>
>>> * blockdev-dirty-enable: takes a file name used for the dirty bitmap,
>>> and an optional granularity.  Setting the granularity will not be
>>> supported in the initial version.
>>>
>>> * query-block-dirty: returns statistics about the dirty bitmap: right
>>> now the granularity, the number of bits that are set, and whether QEMU
>>> is using the dirty bitmap or just adding to it.
>>>
>>> * blockdev-dirty-disable: disable the dirty bitmap.
>>>
>>
>> When do bits get cleared from the bitmap?
>
> drive-mirror clears bits from the bitmap as it processes the writes.
>
> In addition to the persistent dirty bitmap, QEMU keeps an in-flight
> bitmap.  The in-flight bitmap does not need to be persistent.
>
>
> Here is how the bitmaps are handled when doing I/O on the source:
> - after writing to the source:
>    - clear bit in the volatile in-flight bitmap
>    - set bit in the persistent dirty bitmap
>
> - after flushing the source:
>    - msync the persistent bitmap to disk
>
>
> Here is how the bitmaps are handled in the drive-mirror coroutine:
> - before reading from the source:
>    - set bit in the volatile in-flight bitmap
>
> - after writing to the target:
>    - if the dirty count will become zero, flush the target
>    - if the bit is still set in the in-flight bitmap, clear bit in the
>      persistent dirty bitmap
>    - clear bit in the volatile in-flight bitmap

I didn't understand whether the persistent dirty bitmap needs to be 
flushed. This bitmap actually control the persistent known state of the 
destination image. Since w/ mirroring we always have the source in full 
state condition, we can choose to lazy update the destination w/ a risk 
of loosing some content from the last flush (of the destination only side).

This way one can pick the frequency of flushing the persistent bits map 
(and the respective target IO writes). Continuous replication can chose 
a timely based fashion, such as every 5 seconds. A standard mirroring 
job for live copy proposes can pick just to flush once at the end of the 
copy process.

Dor
>
>> "using the dirty bitmap or just adding to it" - I'm not sure I
>> understand what you mean. what's the difference?
>
> Processing the data and removing from the bitmap (mirroring active), or
> just setting dirty bits (mirroring inactive).
>
> Paolo
>