Re: [Qemu-devel] [PATCH v2 00/45] Block job improvements for 1.3

[Kevin Wolf]

Am 26.09.2012 17:56, schrieb Paolo Bonzini:
> Hi all, this is the resubmission of my block job patches, originally
> meant for 1.2.  This still does not include a persistent dirty bitmap,
> which I hope to post in October.
> 
> The patches are organized as follows:
> 
> 01-13   preparatory work for block job errors, including support for
>         pausing and resuming jobs
> 
> 14-18   introduce block job errors, and add support in block-stream

Completed review of patches 1-18 now. Do you think it would make sense
to split them off and do a v3 while the review goes on for the rest of
the series? Dealing with huge series is hard for me as a reviewer, and
probably for you as an author as well.

> 19-25   preparatory work for block mirroring: new commands/concepts
>         and creating new functions out of existing code.
> 
> 26-33   introduce a simple version of mirroring.  The initial patch
>         add the mirroring logic, followed by the ability to switch to
>         the destination of migration and to handle errors during the job.
>         All these changes come with testcases.  Removing the ability to
>         query the target file is the main change from v1.

We can probably make a similar cut at patch 33 if necessary.

> 34-41   These patches introduce the first optimizations, namely supporting
>         an arbitrary granularity for the dirty bitmap.  The current default,
>         1M, is too coarse to let the job converge quickly and in almost
>         real-time.  These patches reimplement the block device dirty bitmap
>         to allow efficient iteration, and add cluster copy-on-write logic.
>         Cluster copy-on-write is needed because management will want to
>         start the copy before the backing file is in place in the destination;
>         if mirroring takes care of copy-on-write, BDRV_O_NO_BACKING can be
>         used even if the granularity is smaller than the cluster size.
> 
> 42-45   A second round optimizations, replacing serialized read-write
>         operations with multiple asynchronous I/O operations.  The various
>         in-flight operations can be of arbitrary size.  The initial copy
>         will end up reading large chunks sequentially (10M by default),
>         while subsequent passes can mimic more closely the guest's I/O
>         patterns.

Kevin