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
