From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwSUQ-0000vV-Cu for qemu-devel@nongnu.org; Wed, 01 Aug 2012 02:33:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SwSUP-0000Le-AY for qemu-devel@nongnu.org; Wed, 01 Aug 2012 02:33:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6234) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwSUP-0000LY-2d for qemu-devel@nongnu.org; Wed, 01 Aug 2012 02:33:01 -0400 Message-ID: <5018CD96.3080700@redhat.com> Date: Wed, 01 Aug 2012 08:32:54 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <50181B34.4090007@redhat.com> <50181C16.8010009@redhat.com> In-Reply-To: <50181C16.8010009@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 2/4] block: add live block commit functionality List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: jcody@redhat.com Cc: supriyak@linux.vnet.ibm.com, pbonzini@redhat.com, Eric Blake , qemu-devel@nongnu.org, stefanha@gmail.com Am 31.07.2012 19:55, schrieb Jeff Cody: > On 07/31/2012 01:51 PM, Eric Blake wrote: >> On 07/30/2012 11:16 PM, Jeff Cody wrote: >>> This adds the live commit coroutine. This iteration focuses on the >>> commit only below the active layer, and not the active layer itself. >>> >>> The behaviour is similar to block streaming; the sectors are walked >>> through, and anything that exists above 'base' is committed back down >>> into base. At the end, intermediate images are deleted, and the >>> chain stiched together. Images are restored to their original open >> >> s/stiched/stitched/ >> >>> + >>> +enum { >>> + /* >>> + * Size of data buffer for populating the image file. This should be large >>> + * enough to process multiple clusters in a single call, so that populating >>> + * contiguous regions of the image is efficient. >>> + */ >>> + COMMIT_BUFFER_SIZE = 512 * 1024, /* in bytes */ >>> +}; >> >> Paolo's latest round of patches got to the point of making this >> configurable for drive-mirror; is that something you should be copying here? > > Yes Though its use is very limited for live commit. For the mirror it's important because a larger number can mean that more data is unnecessarily written, and the target can become larger than the source. For live commit, I think using a larger buffer is always better. Hm, part of the difference is that I assume that commit uses bdrv_is_allocated() to check whether some data must really be copied. But then, there's no reason why mirroring couldn't do that as well. Paolo? Kevin