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

[Geert Jansen]

On 05/30/2012 05:06 PM, Paolo Bonzini wrote:

I think it's beginning to dawn on me that what you have is correct, when 
i combine this:

> 2) target flushes do not have to coincide with a source flush.  Writes
> after the last source flush _can_ be inconsistent between the source and
> the destination!  What matters is that all writes up to the last source
> flush are consistent.

with the statement you made earlier that the drive-mirror coroutine 
issues a target flush *after* a target write returns *and* the dirty 
count is zero.

However, i'm thinking that this design has two undesirable properties. 
Both properties have a high impact if you assume the replication 
appliance is high bandwidth but also potentially high latency (high 
latency because it runs in a guest, and is multiplexing I/Os for many 
different other VMs).

1) Target flushes are not guaranteed to happen at all. If the latency of 
the target is higher than the maximum interval between writes to the 
source, the bitmap will always be dirty when a write to the target 
returns, and a target flush will never be issued.

2) The fact that drive-mirror waits for acknowledgments of writes to the 
target means that there is at most one I/O outstanding and throughput is 
bound by latency.

The Promela model is a bit out of my league, unfortunately :)

Regards,
Geert