|
From: | Max Reitz |
Subject: | Re: [Qemu-devel] [PATCH v5 08/11] qcow2: Rebuild refcount structure during check |
Date: | Thu, 16 Oct 2014 17:27:50 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |