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

[Eric Blake]

On 10/16/2014 09:27 AM, Max Reitz wrote:

>>> +        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.

Correct - our choice of uint16_t* is what hard-codes our current
dependence on refcount_order==4, and we assert that is the case elsewhere.

> 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.

Agreed. Particularly for refcount orders < 3, where you pack more than
one refcount in a single byte.

> 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.

Fair enough. Don't hold up this series for that future improvement.

> 
> 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
> 
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature