From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49881) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TA0vZ-0003p4-Vn for qemu-devel@nongnu.org; Fri, 07 Sep 2012 11:57:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TA0vV-0002DL-VB for qemu-devel@nongnu.org; Fri, 07 Sep 2012 11:57:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4635) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TA0vV-0002DH-NG for qemu-devel@nongnu.org; Fri, 07 Sep 2012 11:57:01 -0400 Message-ID: <504A192C.1090001@redhat.com> Date: Fri, 07 Sep 2012 11:56:28 -0400 From: Jeff Cody MIME-Version: 1.0 References: <812f2aca86713b00473144bb272f014cc5e8a7f4.1346351079.git.jcody@redhat.com> <5048AC83.8050508@redhat.com> <50490975.8040702@redhat.com> <504912A6.4040607@redhat.com> In-Reply-To: <504912A6.4040607@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v2 PATCH 2/6] block: add live block commit functionality Reply-To: jcody@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , supriyak@linux.vnet.ibm.com, pbonzini@redhat.com, qemu-devel@nongnu.org, stefanha@gmail.com On 09/06/2012 05:16 PM, Eric Blake wrote: > On 09/06/2012 02:37 PM, Jeff Cody wrote: >> On 09/06/2012 10:00 AM, Kevin Wolf wrote: >>> Am 30.08.2012 20:47, schrieb Jeff Cody: >>>> 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 stitched together. Images are restored to their original open >>>> flags upon completion. >>>> > >> >>> What should we do with backing files that are smaller than the image to >>> commit? In this version, data is copied up to the size of the backing >>> file, and then we get -EIO from bdrv_co_do_writev(). >>> >> >> We could leave it like that, and let it receive -EIO in that case. >> Alternatively, we could try and determine before the commit if the data >> will fit in the base, and return -ENOSPC if not. > > Neither sounds appealing. Why can't we first try to resize the base to > the new data size being committed, and only fall back to -ENOSPC or -EIO > if the resize fails? > OK - we will attempt to resize the base, and return the appropriate error on failure or if unsupported for the format.