From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoeQb-00059P-LD for qemu-devel@nongnu.org; Wed, 12 Nov 2014 15:22:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XoeQT-0008WC-NI for qemu-devel@nongnu.org; Wed, 12 Nov 2014 15:22:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38702) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoeQT-0008Vv-Gz for qemu-devel@nongnu.org; Wed, 12 Nov 2014 15:22:01 -0500 Message-ID: <5463C160.6030106@redhat.com> Date: Wed, 12 Nov 2014 13:21:52 -0700 From: Eric Blake MIME-Version: 1.0 References: <1415627159-15941-1-git-send-email-mreitz@redhat.com> <1415627159-15941-19-git-send-email-mreitz@redhat.com> <54636C67.1010504@redhat.com> <54636CE3.70808@redhat.com> <54639CA1.1010407@redhat.com> In-Reply-To: <54639CA1.1010407@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ch25jXIaWcbOekiMMioH0i86RKOxuvJTT" Subject: Re: [Qemu-devel] [PATCH 18/21] qcow2: Add function for refcount order amendment List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , qemu-devel@nongnu.org Cc: Kevin Wolf , Peter Lieven , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ch25jXIaWcbOekiMMioH0i86RKOxuvJTT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/12/2014 10:45 AM, Max Reitz wrote: > On 2014-11-12 at 15:21, Max Reitz wrote: >> On 2014-11-12 at 15:19, Eric Blake wrote: >>> On 11/10/2014 06:45 AM, Max Reitz wrote: >>>> Add a function qcow2_change_refcount_order() which allows changing t= he >>>> refcount order of a qcow2 image. >>> A thought: didn't you just submit a patch that marked the image as >>> dirty, nuked the on-disk refcount, then rebuilt one using the in-memo= ry >>> refcounts? Would reusing THAT code be any better than writing this >>> patch? >> >=20 > There are (at least) three problems with this approach. The first is a > rather cosmetic one: You can't easily give progress reports. There are > four time-consuming steps here (wiping references to the existing > reftable is not time-consuming), so this approach can only say when 25 = % > are done, 50 %, 75 % and 100 %. Yep, definitely annoying. >=20 > The second is that if an error occurs during rebuilding the refcount > structures, it's close to impossible to restore the old ones, because > the new structures may have been partially written thus overwriting the= > old ones. But having marked the image dirty should suffice to "solve" t= his. Solved, but not as clean as your current patch that maintains image consistency throughout and doesn't require a rebuild. I guess a tradeoff of clean images vs. code reuse can go either way. >=20 > And the third one is that the initial check (whether the image is > consistent at all) may throw an error because of refcount overflows. > This error will tell you to use amend to increase the refcount width. > Well, too bad. To solve this, we'd have to be able to do the refcount > consistency check with an arbitrary refcount order (in this case the > target refcount order), which would require some work on the check > functions. >=20 > I'll just go with the original idea for now. Okay. Just making sure we are considering alternatives when justifying why we go with a particular solution. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --Ch25jXIaWcbOekiMMioH0i86RKOxuvJTT 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJUY8FgAAoJEKeha0olJ0Nq7ecH/0OIhjif6jj7kZYmqAizyI1P VdXtho95eO/NOZ/CnZTtRA++deqR63iNdg0kVXYL1jZdAOg/99JWZA+CW2C96chC VahxJSIY404mrP1IU3e8YgaJwksv/DFbqsIcBjgzs2mtmr4RU36XlQKDV4sMjE36 f9hn0kTY1Df4z2vhJuvy1HjzSzQsrnVETq542DBXnZSZ4T870myPr3dbVy1OWwB8 0T7pXNfmYBT6HwUq/uHT5K3c7JnGP1SFQVf/uV2MtnhMp5YPptabrJQThKvjYF0L olgqlv6iYiGhlTewtt4WC7wyeq53Yyo/1uYKyZXcM/JW7Yt+t5yzdsQRV3C7DD8= =IzFg -----END PGP SIGNATURE----- --Ch25jXIaWcbOekiMMioH0i86RKOxuvJTT--