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

[Paolo Bonzini]

Il 29/05/2012 13:57, Geert Jansen ha scritto:
> 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.

Yes.

> 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.

No, it doesn't.  It's asynchronous; for continuous replication, the
target knows that it has a consistent view whenever it sees a flush on
the NBD stream.  Flushing the target is needed anyway before writing the
dirty bitmap, so the target might as well exploit them to get
information about the state of the source.

The target _must_ flush to disk when it receives a flush commands, not
matter how close they are.  It _may_ choose to snapshot the disk, for
example establishing one new snapshot every 5 seconds.

A synchronous implementation is not forbidden by the spec (by design),
but at the moment it's a bit more complex to implement because, as you
mention, it requires buffering the I/O data on the host.

> 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.

Yes, the drive-mirror coroutine will not go on to the next write until
the previous one is acked.

> 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?

Yes, this is already all correct.

> 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.

The copy phase will not have flushes (they are kind of useless).

> 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?

Yes.

Paolo