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