Re: [Qemu-devel] [PATCH v5 08/11] qcow2: Rebuild refcount structure during check

[Max Reitz <mreitz@redhat.com>]

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