Re: [pve-devel] [PATCH pve-storage] qcow2 format: enable subcluster allocation by default

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

[-- Attachment #1: Type: message/rfc822, Size: 16382 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] qcow2 format: enable subcluster allocation by default
Date: Thu, 14 Nov 2024 08:31:06 +0000
Message-ID: <98cdc246d14fdfc5dcfedf09dd4bc596acb0814f.camel@groupe-cyllene.com>

Hi Fiona,

I'm really sorry, I didn't see your reponse, lost in the flood of email
:(


>>How does read performance compare for you (with 128 KiB cluster
size)?

>>I don't see any noticeable difference in my testing with an ext4
>>directory storage on an SSD, attaching the qcow2 images as SCSI disks
>>to
>>the VM, neither for reading nor writing. I only tested without your
>>change and with your change using 4k (rand)read and (rand)write.
>>
>>I'm not sure we should enable this for everybody, there's always a
>>risk
>>to break stuff with added complexity. Maybe it's better to have a
>>storage configuration option that people can opt-in to, e.g.
>>
>>qcow2-create-opts extended_l2=on,cluster_size=128k
>>
>>If we get enough positive feedback, we can still change the default
>>in a
>>future (major) release.

What disk size do you use for your bench ? 
It's really important, because generally, the more bigger, the slower
read in qcow2 will be , because l2 metadatas need to be cached handle
in memory. (and qemu have 1MB cache by default)

witout subcluster, for 1TB image, it's around 128MB l2 metadas in qcow2
file. 

for write, it's mostly for first block allocation, so it's depend
of the filesystem behind, if fallocate is supported.
(I have seen really big difference on shared ocfs2/gfs2 fs)

Also, for write, this is helping a lot with backing file. (so for
linked qcow2 clone, and maybe in the future for external snapshots).
Because currently, if you write 4k on a overlay , you need to read the
full cluster 64k on the base write, and rewrite it. (so 8x
overamplification)


They are good information from the developper :
https://blogs.igalia.com/berto/2020/12/03/subcluster-allocation-for-qcow2-images/


I really don't think it's hurt, but maybe a default for 9.0 release to
be safe. (I'll try to have the external snapshot ready for this date
too)


Regards,

Alexandre

> Signed-off-by: Alexandre Derumier <alexandre.derumier@groupe-
> cyllene.com>
> ---
>  src/PVE/Storage/Plugin.pm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/PVE/Storage/Plugin.pm b/src/PVE/Storage/Plugin.pm
> index 6444390..31b20fe 100644
> --- a/src/PVE/Storage/Plugin.pm
> +++ b/src/PVE/Storage/Plugin.pm
> @@ -561,7 +561,7 @@ sub preallocation_cmd_option {
>   die "preallocation mode '$prealloc' not supported by format
> '$fmt'\n"
>       if !$QCOW2_PREALLOCATION->{$prealloc};
>  
> - return "preallocation=$prealloc";
> + return "preallocation=$prealloc,extended_l2=on,cluster_size=128k";

Also, it doesn't really fit here in the preallocation helper as the
helper is specific to that setting.

>      } elsif ($fmt eq 'raw') {
>   $prealloc = $prealloc // 'off';
>   $prealloc = 'off' if $prealloc eq 'metadata';
> -- 
> 2.39.2
> 
> 



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