From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xen3C-0000Gv-79 for qemu-devel@nongnu.org; Thu, 16 Oct 2014 11:33:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xen37-0002gV-A3 for qemu-devel@nongnu.org; Thu, 16 Oct 2014 11:33:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30490) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xen37-0002g8-1q for qemu-devel@nongnu.org; Thu, 16 Oct 2014 11:33:09 -0400 Message-ID: <543FE52F.2090803@redhat.com> Date: Thu, 16 Oct 2014 09:33:03 -0600 From: Eric Blake MIME-Version: 1.0 References: <1409348463-16627-1-git-send-email-mreitz@redhat.com> <1409348463-16627-9-git-send-email-mreitz@redhat.com> <5435C414.5030203@redhat.com> <543FE3F6.7030507@redhat.com> In-Reply-To: <543FE3F6.7030507@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DKtD0fR5Bj5vM8Q6axbxHbi0pv5nUCCIV" Subject: Re: [Qemu-devel] [PATCH v5 08/11] qcow2: Rebuild refcount structure during check List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , qemu-devel@nongnu.org Cc: Kevin Wolf , Stefan Hajnoczi , =?UTF-8?B?QmVub8OudCBDYW5ldA==?= This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DKtD0fR5Bj5vM8Q6axbxHbi0pv5nUCCIV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/16/2014 09:27 AM, Max Reitz wrote: >>> + memset(*refcount_table + old_nb_clusters, 0, >>> + (*nb_clusters - old_nb_clusters) * sizeof(uint16_t));= >> Is this calculation unnecessarily hard-coded to refcount_order=3D=3D4?= >=20 > While now in the process of editing this patch, no, this is not > hard-coded to that refcount_order. It's hard-coded to *refcount_table > being uint16_t *. I think this fine. Correct - our choice of uint16_t* is what hard-codes our current dependence on refcount_order=3D=3D4, and we assert that is the case elsew= here. > Making the in-memory refcount table > support variable refcount orders would be pretty hard and in fact we do= > not need it before we actually support other refcount_orders. Agreed. Particularly for refcount orders < 3, where you pack more than one refcount in a single byte. > When doing > that, I (or anyone else) will probably add some function read_refcount(= ) > which reads a refcount from a refcount block or a concatenation of > refblocks (such as this in-memory refcount table) while taking into > account a variable refcount_order. When that is done, we can rework thi= s > code. Fair enough. Don't hold up this series for that future improvement. >=20 > But for now it's fine to make the in-memory refcount table entries > uint16_t, which is the reason for all the sizeof(uint16_t). >=20 > Max >=20 >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --DKtD0fR5Bj5vM8Q6axbxHbi0pv5nUCCIV 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 iQEcBAEBCAAGBQJUP+UvAAoJEKeha0olJ0NqnwAIAKOHhaRlE48KDd9OBfX5XN+Q adhyDFpKzVKecdQii2cmxErw7Y5LHZ/aLHFV2NxoDG7nh3t3cwMSuzVcvf+7qqlt pPrIq+PpR9FLSnD9oPBWb7LWbBgQaMV9EPTOfJaLD78WaFBvzk1Ln0BqA87xF1vu d8o7uw28PER6/fTNfB5YEABqXTXMIJD3zAF54qRmvrU6qpaR1cb1rld+/KFyo8XW n+dJnpC7p2sI9w/CcN59CxTftKnvpXAQLLTZs8kknpB+cXSYXx4qmTiAuNtlihNh 0ZEJcLtVzVZ4SQrDyN2YwPM1FvlLcQxpZJ4L8zB8VXo/8xsbW/EBx3/YTkdAF0I= =93hI -----END PGP SIGNATURE----- --DKtD0fR5Bj5vM8Q6axbxHbi0pv5nUCCIV--