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

[Kevin Wolf <kwolf@suse.de>]

Shahar Frank schrieb:
> 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

Right, that's what I thought, too. Until I looked at code again.

alloc_clusters_noref() moves free_cluster_index forward if the needed
number of cluster don't fit right there. It's only set back to the
lowest free cluster when that cluster is freed later.

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

Yes, it wouldn't have been a problem before these patches. But now what
is the right thing to do if we're having some one-cluster holes and want
to write a larger block? There are only two options: Try to find a place
where the clusters are physically contiguous for better performance but
at the cost of fragmentation (that's what we to today) or fill up all
the holes first at cost of performance (we could to that with a few
lines of code).

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

Maybe you're right. But actually I don't feel like starting qcow3 now...
And it would be a long term thing anyway.

Kevin