From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xo6ZZ-0000ks-BV for qemu-devel@nongnu.org; Tue, 11 Nov 2014 03:13:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xo6ZT-0003cN-6F for qemu-devel@nongnu.org; Tue, 11 Nov 2014 03:13:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51107) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xo6ZS-0003cC-UH for qemu-devel@nongnu.org; Tue, 11 Nov 2014 03:13:03 -0500 Message-ID: <5461C507.60303@redhat.com> Date: Tue, 11 Nov 2014 09:12:55 +0100 From: Max Reitz MIME-Version: 1.0 References: <1415627159-15941-1-git-send-email-mreitz@redhat.com> <1415627159-15941-4-git-send-email-mreitz@redhat.com> <54612727.6030900@redhat.com> In-Reply-To: <54612727.6030900@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 , qemu-devel@nongnu.org Cc: Kevin Wolf , Peter Lieven , Stefan Hajnoczi On 2014-11-10 at 21:59, Eric Blake wrote: > 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 > s/bit/bits/ See my reply to your review on patch 2. I keep swapping knowing which to use - now I know, thanks! >> width to represent refcount values internally. >> >> 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(-) >> >> 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(BlockDriverState *bs, uint64_t *l1_table, >> for (i = 0; i < l1_size; i++) { >> uint64_t l2_offset = l1_table[i] & L1E_OFFSET_MASK; >> bool l2_dirty = false; >> - int l2_refcount; >> + int64_t l2_refcount; > 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...) Will do. Max > Reviewed-by: Eric Blake