Re: [Qemu-devel] [PATCH 0/3] info blockstats (block-qcow2): show highest allocated offset (bytes)

[Shahar Frank <sfrank@redhat.com>]

Kevin Wolf wrote:
> Uri Lublin schrieb:
>> Although there may be many free blocks below that number (allocated and
>> freed)
>> the file system can not deallocate those blocks, and they have to be reused
>> by qemu. Also note that due to fragmentation those free blocks may not
>> be used on next allocations.
> 
> Any idea what would it mean to performance if we changed the behaviour
> so that s->free_cluster_index always points to lowest free cluster? Then
> most of the fragmentation should be gone.
> 
free_cluster_index if already pointing the lowest known free space. The 
problem is that the its update logic is very simplistic so an allocation 
of multiple clusters may cause this pointer to skip many single (in fact 
  it will skip all cluster sequences that are shorter than the requested 
number), so the next allocation may miss it. This will increase the 
fragmentation. Note that it wasn't so important until Laurent Vivier 
implemented his optimizations that allocated cluster sequences.

see block-qcow2.c:alloc_clusters_noref() and
block-qcow2.c: update_cluster_refcount()

> If the impact would be too big we could still change the code to use two
> free_cluster_indexes, one for single cluster allocation and one for
> larger blocks. This was suggested earlier and I think there were even
> patches for it, but I don't seem to remember who exactly suggested this.
> 

I suggested it as part of the first zero-dedup patch, and that was 
because I suspected that the zero dedup may increase fragmentation due 
that simplistic free cluster indexes. In fact, having two or even 
several free pointers is probably a step in the right direction, but we 
may need some better allocation mechanism to really solve the problem 
(btree+ structure, or something else). The target should be a decent 
extend based allocation. This improve qcow2 performance and handle he 
fragmentation problem. The problem is that it will probably change the 
qcow2 internals, so may better implement a simple approach for qcow2 and 
start designing qcow3...

> Kevin
> 
> 

Shahar