From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xo7fK-0008Ky-KQ for qemu-devel@nongnu.org; Tue, 11 Nov 2014 04:23:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xo7fD-0001cn-GC for qemu-devel@nongnu.org; Tue, 11 Nov 2014 04:23:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xo7fD-0001cY-9c for qemu-devel@nongnu.org; Tue, 11 Nov 2014 04:23:03 -0500 Date: Tue, 11 Nov 2014 10:22:53 +0100 From: Kevin Wolf Message-ID: <20141111092253.GA3674@noname.redhat.com> References: <1415627159-15941-1-git-send-email-mreitz@redhat.com> <1415627159-15941-4-git-send-email-mreitz@redhat.com> <54612727.6030900@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <54612727.6030900@redhat.com> Subject: Re: [Qemu-devel] [PATCH 03/21] qcow2: Use 64 bits for refcount values List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Peter Lieven , qemu-devel@nongnu.org, Stefan Hajnoczi , Max Reitz --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 10.11.2014 um 21:59 hat Eric Blake geschrieben: > On 11/10/2014 06:45 AM, Max Reitz wrote: > > Refcounts may have a width of up to 64 bit, so qemu should use the same >=20 > s/bit/bits/ >=20 > > width to represent refcount values internally. > >=20 > > Signed-off-by: Max Reitz > > --- > > block/qcow2-cluster.c | 9 ++++++--- > > block/qcow2-refcount.c | 37 ++++++++++++++++++++----------------- > > block/qcow2.h | 7 ++++--- > > 3 files changed, 30 insertions(+), 23 deletions(-) > >=20 > > diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c > > index df0b2c9..ab43902 100644 > > --- a/block/qcow2-cluster.c > > +++ b/block/qcow2-cluster.c > > @@ -1640,7 +1640,7 @@ static int expand_zero_clusters_in_l1(BlockDriver= State *bs, uint64_t *l1_table, > > for (i =3D 0; i < l1_size; i++) { > > uint64_t l2_offset =3D l1_table[i] & L1E_OFFSET_MASK; > > bool l2_dirty =3D false; > > - int l2_refcount; > > + int64_t l2_refcount; >=20 > You may want to mention in the commit message that you choose a signed > type to allow negative for errors, and therefore we really allow only up > to 63 useful bits. Or even mention that this is okay because no one > can feasibly generate an image with more than 2^63 refs to the same > cluster (there isn't that much storage or time to do such a task in our > lifetime...) Should patch 1 then set refcount_max =3D 2^63 for refcount order 6? Also note that while it might not be feasible to create a cluster with 2^63 references, this doesn't mean that it's impossible to create a cluster with a stored refcount of (more than) 2^63. We'll have to have checks there. Kevin --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJUYdVtAAoJEH8JsnLIjy/WLhUP/jONSs/Cs7OQtYt8zZLKYXrR N4VbjAw1IOIFj6TYc70WmGJTCckvQYrOGbVw6KVBK6rsn14RZqBAun/XHrGZ1Unf QoekXqI4hjheKlY8b52eZdOE76lxa4Y0ndoS1kCI0Yv7nyc2ygXFQF7rS6GVbCqb n0vJXi08i2OS3zrpUcSjldqsy4ksfVqadPRWd+dSkM/xfOuq/qJDWBLzo+wg0iya HFqS/ZKyBcMqxBjrtRChsntbzO3bLn0GmKgQ5colNyVPheqeQCaFHrRf4ksmj9t3 fqkrPQmnN+dagqhgATfqfI7dmXXqrACFbRLFEo5UfHZfFtIQpOpKsKNsjFWVYDVK WJyUwmaLOdraSBv43p/a0+DLld0sSk0bdopaXXJW2J/KHfy1HxXtMnrksM7EsdhE prXMrlsIxRqUmWnT0yJTzcFjZl3KrqzgMQHho+8+bz7D7mJMV2Iki6J/Tuq2Laro WZ0pEMEFELAzbTzgRNHJpmwTCKQNNOWOKp2r0rmeCAnggf/iW0/sT1jb6OFbKudt IOhl4E40o/bhcDosoFN61pfIHNzZ1xfyl6g2mhSCSUPLVZQs2b7W4/rn0pPr6gxz SG6BFJLPtVrcbxa+L0sUBTjX1o88ZRfrk/iW/lNjsPup+7AKAuYu2uZkCA80rVmX CUEoxz3GjWJ03JAyoBns =2SPb -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT--