From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XemyD-0005g1-2V for qemu-devel@nongnu.org; Thu, 16 Oct 2014 11:28:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xemy6-0000oP-U7 for qemu-devel@nongnu.org; Thu, 16 Oct 2014 11:28:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63061) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xemy6-0000nu-MX for qemu-devel@nongnu.org; Thu, 16 Oct 2014 11:27:58 -0400 Message-ID: <543FE3F6.7030507@redhat.com> Date: Thu, 16 Oct 2014 17:27:50 +0200 From: Max Reitz 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> In-Reply-To: <5435C414.5030203@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Eric Blake , qemu-devel@nongnu.org Cc: Kevin Wolf , Stefan Hajnoczi , =?UTF-8?B?QmVub8OudCBDYW5ldA==?= Am 09.10.2014 um 01:09 schrieb Eric Blake: > On 08/29/2014 03:41 PM, Max Reitz wrote: >> + * cluster_count clusters; therefore, we have to allocate >> + * cluster_count - contiguous_free_clusters new clusters at the end of >> + * the image (which is the current value of cluster; note that cluster >> + * may exceed old_nb_clusters if *first_free_cluster pointed beyond the >> + * image end) */ >> + *nb_clusters = cluster + cluster_count - contiguous_free_clusters; >> + *refcount_table = g_try_realloc(*refcount_table, >> + *nb_clusters * sizeof(uint16_t)); >> + if (!*refcount_table) { >> + return -ENOMEM; >> + } >> + >> + memset(*refcount_table + old_nb_clusters, 0, >> + (*nb_clusters - old_nb_clusters) * sizeof(uint16_t)); > Is this calculation unnecessarily hard-coded to refcount_order==4? 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. 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. 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 this code. 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). Max