From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCY6f-0002OE-7e for qemu-devel@nongnu.org; Fri, 14 Sep 2012 11:47:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCY6Z-00076D-C3 for qemu-devel@nongnu.org; Fri, 14 Sep 2012 11:47:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43750) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCY6Z-000765-4R for qemu-devel@nongnu.org; Fri, 14 Sep 2012 11:46:55 -0400 Message-ID: <505350FE.1060402@redhat.com> Date: Fri, 14 Sep 2012 09:45:02 -0600 From: Eric Blake MIME-Version: 1.0 References: <1261b29106dbe3ccd08bac7ce737e67bd5ae8577.1347629357.git.jcody@redhat.com> In-Reply-To: <1261b29106dbe3ccd08bac7ce737e67bd5ae8577.1347629357.git.jcody@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig036B8CAD1BA9DB9270FAE5A3" Subject: Re: [Qemu-devel] [PATCH 2/8] block: add live block commit functionality List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Cody Cc: kwolf@redhat.com, pbonzini@redhat.com, stefanha@gmail.com, qemu-devel@nongnu.org, supriyak@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig036B8CAD1BA9DB9270FAE5A3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/14/2012 07:41 AM, 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. >=20 > 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 > + > +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 p= opulating > + * contiguous regions of the image is efficient. > + */ > + COMMIT_BUFFER_SIZE =3D 512 * 1024, /* in bytes */ I'm guessing you will add a followup patch that depends on Paolo's series for controlling the granularity of this buffer? Or is it less important for the commit case? > + > +static void coroutine_fn commit_run(void *opaque) > +{ > + ret =3D base_len =3D bdrv_getlength(base); > + if (base_len < 0) { > + goto exit_restore_reopen; > + } > + > + if (base_len < s->common.len) { > + ret =3D bdrv_truncate(base, s->common.len); > + if (ret) { > + goto exit_restore_reopen; > + } > + } Question: is it valid to have a qcow2 file whose size is smaller than it's backing image? Suppose I have base[1M] <- mid[2M] <- top[3M] <- active[3M], and request to commit top into base. This bdrv_truncate() means I will now have: base[3M] <- mid[2M] <- top[3M] <- active[3M]. If I then abort the commit operation at this point, then we have the situation of 'mid' reporting a smaller size than 'base' - which may make 'mid' invalid. And even if it is valid, what happens if I now request to commit 'mid' into 'base', but 'base' already had data written past the 2M mark before I aborted the first operation? I'm worried that you may have to bdrv_truncate() the entire chain to keep it consistent, which is more complex because it requires more r/w files. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig036B8CAD1BA9DB9270FAE5A3 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/ iQEcBAEBCAAGBQJQU1D+AAoJEKeha0olJ0NqsxYH/Ar0cgxKq0MDqzKx3q9fjXCo JrSdZ7nt3S8YqyDfHIW/ErP7dEHVJBvKUhfueY9y+EqoWTSgowDbIAX6RMkP4cfT x1IqSkYVs2ChXN+znDgPXYoqyPsko6Zn1zfTa5Tz253oq/0UpIfGCkBjdFFb8rGq lOFWyBdt1dWIbOfQO2mekL+yJeslmNLG/o789/L4D7WBnyA6qgNGendlqLKKmt6b v47Bkw6PXTUWMrM+xiZIQjvx/PpJ6guK+Ybp3hJ+UjHzpU+D3DqSQx6yQpAn9vVI 9w22Lu5K8/gWgUDJLmBFGVRKotOddRoXSLstXd+TyfTcsHjyAZ+alAF6tAzbCYk= =fzrS -----END PGP SIGNATURE----- --------------enig036B8CAD1BA9DB9270FAE5A3--