From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36851) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THEj7-0001WY-K3 for qemu-devel@nongnu.org; Thu, 27 Sep 2012 10:06:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THEj1-0000vq-DU for qemu-devel@nongnu.org; Thu, 27 Sep 2012 10:06:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64113) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THEj1-0000uI-5c for qemu-devel@nongnu.org; Thu, 27 Sep 2012 10:05:59 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8RE5woH003723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 27 Sep 2012 10:05:58 -0400 Message-ID: <50645D43.7000502@redhat.com> Date: Thu, 27 Sep 2012 16:05:55 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1348675011-8794-1-git-send-email-pbonzini@redhat.com> In-Reply-To: <1348675011-8794-1-git-send-email-pbonzini@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 00/45] Block job improvements for 1.3 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: jcody@redhat.com, qemu-devel@nongnu.org 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