From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36928) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9jRC-00017m-Vp for qemu-devel@nongnu.org; Thu, 06 Sep 2012 17:16:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9jRB-0006iX-Lv for qemu-devel@nongnu.org; Thu, 06 Sep 2012 17:16:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62405) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9jRB-0006iR-Cf for qemu-devel@nongnu.org; Thu, 06 Sep 2012 17:16:33 -0400 Message-ID: <504912A6.4040607@redhat.com> Date: Thu, 06 Sep 2012 15:16:22 -0600 From: Eric Blake MIME-Version: 1.0 References: <812f2aca86713b00473144bb272f014cc5e8a7f4.1346351079.git.jcody@redhat.com> <5048AC83.8050508@redhat.com> <50490975.8040702@redhat.com> In-Reply-To: <50490975.8040702@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig93D29B20E5DD8F214829D0D5" Subject: Re: [Qemu-devel] [RFC v2 PATCH 2/6] block: add live block commit functionality List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: jcody@redhat.com Cc: Kevin Wolf , supriyak@linux.vnet.ibm.com, stefanha@gmail.com, qemu-devel@nongnu.org, pbonzini@redhat.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig93D29B20E5DD8F214829D0D5 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable 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. >>> >=20 >> What should we do with backing files that are smaller than the image t= o >> 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(). >> >=20 > 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? --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig93D29B20E5DD8F214829D0D5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBCAAGBQJQSRKnAAoJEKeha0olJ0NqCJkH/jHWB2eEFNdQP/fdXGmAyzID 08C+whUXLYDO+Aq0hxKQGzaUgHmq9rFSXpC+GrvXqh134df7adT3GolWZfZ29cPn eRnABveXsxFZ5C+UcoHKZaRxcIrSYkGaxyYlpkI3BCzp/5PDGIvwfhxLk7JWrc4L H+hqkum6hOXONsxlfTvq7sjcRu8qXII4C8kTCPMBuOSslq3L8/C8NgRqA/QBUiFh PtKec1r7y3UzEvCw+pAeQfVE08OOckmRw6n0kukNE6djN6iBx+jWq6o5BCVDjm/F fiqDz43oKmmHahf1dK4hs6Efv9tR5CiiyEftbzqbnFbanTJXQF9OFiogKA8B3GQ= =psWx -----END PGP SIGNATURE----- --------------enig93D29B20E5DD8F214829D0D5--