[pve-devel] [PATCH pve-storage 03/10] common: qemu_img_create: add backing_file support

DERUMIER, Alexandre alexandre.derumier at groupe-cyllene.com
Fri Jul 4 14:31:04 CEST 2025


> 
> >>cluster_size is set to 128k, as it reduce qcow2 overhead (reduce
> >>disk,
> >>but also memory needed to cache metadatas)
>>
>>should we make this configurable?

I'm not sure yet, I have choose the best balance between memory <-
>performance (too big block reduce performance, too small increase
memory). they are 32 suballocated clusters of 4k with 128k
cluster_size, so for 4k workload, it's avoid over-amplication when it
need to read the parent snapshot chains.

If the image is really big, the best way to keep good performance, is
to increase the l2-cache-size. (maybe make it tunable)
the default qemu cache is 32MB, and it's able to handle 256GB image
with default 64k cluster without performance degradation.




>  sub qemu_img_create {
> -    my ($scfg, $fmt, $size, $path) = @_;
> +    my ($scfg, $fmt, $size, $path, $backing_path) = @_;
> +
> +    die "size can't be specified if backing file is used" if $size
> && $backing_path;

>>should we assert that $backing_path is only used with $fmt eq
'qcow2'?

yes indeed, qcow2 is the only format supporting a backing file

>  
>      my $cmd = ['/usr/bin/qemu-img', 'create'];
>  
> -    my $prealloc_opt = preallocation_cmd_option($scfg, $fmt);
> -    push @$cmd, '-o', $prealloc_opt if defined($prealloc_opt);
> +    my $options = [];
> +
> +    if ($backing_path) {
> +        push @$cmd, '-b', $backing_path, '-F', 'qcow2';

>>and then use $fmt here as well?

ok, will do




More information about the pve-devel mailing list