From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60528) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VF1bI-0007mg-Fp for qemu-devel@nongnu.org; Thu, 29 Aug 2013 08:45:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VF1bD-00088w-Fw for qemu-devel@nongnu.org; Thu, 29 Aug 2013 08:45:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:29038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VF1bD-00088q-7i for qemu-devel@nongnu.org; Thu, 29 Aug 2013 08:45:19 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7TCjIoo024750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 29 Aug 2013 08:45:18 -0400 Message-ID: <521F425D.5030400@redhat.com> Date: Thu, 29 Aug 2013 06:45:17 -0600 From: Eric Blake MIME-Version: 1.0 References: <1377775241-26278-1-git-send-email-mreitz@redhat.com> <1377775241-26278-3-git-send-email-mreitz@redhat.com> In-Reply-To: <1377775241-26278-3-git-send-email-mreitz@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XtH6mDpEPC7Ew91CB0UR9UIhXiKNIHUub" Subject: Re: [Qemu-devel] [PATCH v2 2/3] qcow2: Implement bdrv_amend_options List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: Kevin Wolf , qemu-devel@nongnu.org, Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XtH6mDpEPC7Ew91CB0UR9UIhXiKNIHUub Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/29/2013 05:20 AM, Max Reitz wrote: > Implement bdrv_amend_options for compat, size, backing_file, backing_fm= t > and lazy_refcounts. >=20 > Downgrading images from compat=3D1.1 to compat=3D0.10 is achieved throu= gh > handling all incompatible flags accordingly, clearing all compatible an= d > autoclear flags and expanding all zero clusters. >=20 > Signed-off-by: Max Reitz > --- > +/* > + * Expands all zero clusters on the image; important for downgrading t= o a qcow2 > + * version which doesn't yet support metadata zero clusters. Do we have to fully write 0 blocks into the image no matter what, or are there cases where, when the file has a backing image and we know the backing image has 0 bytes at the same offset, where we could flatten by removing the cluster and letting the reference defer to the backing file? It's always safer to write 0 blocks into this image, but it may be worth considering whether we need the (ability) to try the alternate method as it results in a smaller file and potentially faster conversion.= > + > + /* the refcount order might be different in newer images - however= , qemu > + * doesn't support anything different than 4 anyway, so nothing to= fix > + * there */ This sounds risky. Wouldn't it be safer to error out if the image didn't have a refcount order of 4, than to just ignore it; on the grounds that if qemu DOES add support for non-4 refcount order, an error will at least alert someone to the fact that they need to add some (potentially complicated) code here? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --XtH6mDpEPC7Ew91CB0UR9UIhXiKNIHUub 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.14 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJSH0JdAAoJEKeha0olJ0NqQMYH/Aoaia5engzcycZDmm0m9Jj8 S3BrpTlG4bfZ7BbJey/nih/+mEegF2yURX/4YZzQH834n4Io+7ZWfi1Ws/FfE/w/ WxZhuIgH4B8mp9KbY8qrdwr2wW55fsFaEJTlzmSY83p/oYAfeUSTTQUhXjRfQppK s4s6vOvKVKJUcTBUM7LeQOJEHIAtuo0zQxPfXCdVo4b9mAD29+I96XfrV6UUBHOG HbdaHFAP28fUR9hpxGDWtVRGBmHTzrjoM/sSvGAIG2Uox/M3uppN6+6HF2R6T9uJ wUWGRLN0Ceo4n1SesZQZ9ay7n3uL/9lCBZtb2+oCp5wLDF1MQ5021vzPKDfipgo= =7aXj -----END PGP SIGNATURE----- --XtH6mDpEPC7Ew91CB0UR9UIhXiKNIHUub--