[pve-devel] [PATCH qemu-server] qcow2: increase cache-size to 1GB

DERUMIER, Alexandre alexandre.derumier at groupe-cyllene.com
Thu Aug 14 13:10:06 CEST 2025


> 
> This patch increase cache to 1GB, enough to handle 8TB image
> 
> with default 32MB cache
> fio benchmark 4k randread/write:
> 
> 256GB image : 32MB cache : 40000 iops
> 1TB image: 32MB cache: 2500 iops
> 8TB image: 32MB cache: 2500 iops
> 1TB image: 1G cache: 40000 iops
> 8TB image: 1G cache: 40000 iops
> 
> 

>>have you benchmarked this?

yes, results are in this commit message (2500->40000iops with a 1TB
image with 64k cluster, same results with 128k cluster)

>> if so, did you compare it with using the
>>smaller cache-entry variant described in the file you linked:

Don't have tested it (I don't understand exactly this part to be
honest, but the default l2-cache-entry-size is already smaller, it's
4k, and we use 64k or 128k cluster size)


>>we also know the image size here, so we could use a capped, derived
>>value?
>>
>>what if the disk is resized? 

One problem is disk resize, because the cache size can't be increase
without restart. That's why I think it's better to use a big cache
size.(It's really a max value)


>> what about image files with bigger clusters?

I have tried with bigger blocksize (so less metadatas, less memory),
but snapshot performance are not great. (for example, 1MB cluster, this
is 32MB sub-cluster on snapshot (vs 4k sub-cluster with 128k cluster),
with 4k write, you need to rewrite 32MB.


Maybe l2_extended2=on  on main image could reduce the needed cache
memory, but from my tests it don't seem to help, I still need to
increase the cache (I'll try to retest it)

They are some good info in the suballocattion paper (including in the
video presentation)
https://blogs.igalia.com/berto/2020/12/03/subcluster-allocation-for-qcow2-images/





More information about the pve-devel mailing list