Re: [pve-devel] [PATCH pve-storage 0/2] move qemu_img_create to common helpers and enable preallocation on backed images

["DERUMIER, Alexandre via pve-devel" <pve-devel@lists.proxmox.com>]

[-- Attachment #1: Type: message/rfc822, Size: 13337 bytes --]

From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>, "f.ebner@proxmox.com" <f.ebner@proxmox.com>
Subject: Re: [pve-devel] [PATCH pve-storage 0/2] move qemu_img_create to common helpers and enable preallocation on backed images
Date: Tue, 27 May 2025 08:59:20 +0000
Message-ID: <195b55efe9e7c9257a867abb69b7a0909377d8a4.camel@groupe-cyllene.com>

> 
> 
> So no difference in needed memory, with or with extended_l2.
> 
> but the l2-cache-size tuning is really something we should add in
> another patch I think ,for general performance with qcow2.

>>If we want to enable extended_l2=on, cluster_size=128k by default for
>>all new qcow2 image, I think we should do it together with an
>>increased
>>l2-cache-size then.

yes, qemu have dumped the default to 32MB 3 years ago (so it can handle
256GB qcow2 image).  
I was expected with extended_l2=on reduce the number of l2 entry, so
reduce the needed memory, but it don't seem to be the case. (I have
wrote a message to the original author to see if it's normal))


>> But yes, should be its own patch. The above >>results
>>sound promising, but we'll need to test a bigger variety of
>>workloads.
>>If we don't find settings that improve most workloads, we can still
>>make
>>it configurable.

yes, I only have tested with local disk and 4k read/write, so I think
it should be tested more deeply, also on nfs and different blocksize




[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel