Re: [Qemu-devel] [RFC PATCH] drive-backup 'stream' mode

[Paolo Bonzini <pbonzini@redhat.com>]

Il 14/10/2013 22:10, Wolfgang Richter ha scritto:
> Okay, I think my impression might be wrong, but I thought
> 'drive-mirror' would become deprecated with the new 'drive-backup'
> command and code.
> 
> If we look at what they do (current documentation and code),
> 'drive-backup' AFAIK behaves the same for all modes of 'drive-mirror'
> _except_ mode 'none' with _better_ consistency guarantees.  That is,
> 'drive-backup' clearly provides a point-in-time snapshot, whereas
> 'drive-mirror' may create a point-in-time snapshot, but it can not
> guarantee that.

They are different.

drive-backup provides a point-in-time snapshot at the time the job is
started.  Completing the job stops writing to the target.

drive-mirror provides a copy at the time the job is completed.
Completing the job stops writing to the source.

> In addition, 'drive-backup's code is cleaner, simpler, and easier to
> work with (in my opinion) than 'drive-mirror's code.  This is because
> of the new hooks in block.c for tracked requests etc. so that the job
> can insert code to be run on every write in a clean manner (I think).

The simpler code for drive-backup is because it doesn't have performance
requirements.  drive-mirror has to be optimized because otherwise too
many dirty sectors pile up and the job doesn't converge.  drive-backup
runs synchronously as the VM writes to the disk.

Using the hooks in block.c we can change drive-mirror to use an "active"
(but still asynchronous) approach as long as the in-flight I/O does not
exceed the size of the drive-mirror buffer.  This would not simplify the
code however, it would only guarantee that I/Os are performed in the
same order as the original operations issued by the VM.

Paolo