[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