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

[Geert Jansen]

Hi,

On 05/24/2012 04:19 PM, Paolo Bonzini wrote:

> 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 have a few questions, apologies if some of these are obvious..

I assume the target can be any QEmu block driver including e.g. NBD? A 
networked block driver would be required for a continuous replication 
solution.

Does the drive-mirror coroutine send the writes to the target in the 
same order as they are sent to the source? I assume so.

Does the drive-mirror coroutine require that writes are acknowledged? 
I'd assume so, as you mention that the bit from the persistent bitmap is 
cleared after a write, so you'd need to know the write arrived otherwise 
you cannot safely clear the bit.

If the two above are true (sending in-order, and require acknowledgment 
of writes by the target), then I assume there is a need to keep an 
in-memory list with the IOs that still need to be sent to the target? 
That list could get too large if i.e. the target cannot keep up or 
becomes unavailable. When this happens, the dirty bitmap is needed to 
re-establish synchronized state again between the two images.

For this re-sync, i think there will be two phases. The first phase 
would send blocks marked as dirty by the bitmap. I assume these would be 
sent in arbitrary order, not the order in which they were sent to the 
source, right?

After the copy phase is done, in order to avoid race conditions, the 
bitmap should be reset and mirroring should start directly and 
atomically. Is that currently handed by your design?

Also probably the target would need some kind of signal that the copy 
ended and that we are now mirroring because this is when writes are 
in-order again, and therefore only in this phase the solution can 
provide crash consistent protection. In the copy phase no crash 
consistency can be provided if i am not mistaken.

Finally, again if i am not mistaken, I think that the scenario where 
synchronization is lost with the target is exactly the same as when you 
need to do an initial copy, expect that in the latter case all bits in 
the bitmap are set, right?

Regards,
Geert