[pve-devel] [PATCH pve-storage] qcow2: resize: add preallocation support

[DERUMIER, Alexandre]

-------- Message initial --------
De: Fiona Ebner <f.ebner at proxmox.com>
À: Proxmox VE development discussion <pve-devel at lists.proxmox.com>
Cc: Alexandre Derumier <alexandre.derumier at groupe-cyllene.com>
Objet: Re: [pve-devel] [PATCH pve-storage] qcow2: resize: add
preallocation support
Date: 03/02/2025 15:39:41

Am 19.12.24 um 17:18 schrieb Alexandre Derumier via pve-devel:
> Seem that we totally forgot to add it, it's available since 2017
> https://antiphishing.vadesecure.com/v4?f=TmtFVlNVNmxSYnFaWFhxYhCRpRpL
> 9Z3oy4_Tk4UXcP5N_qAOXqIRqmal4wpM8L7y&i=d09ZU0Z5WTAyTG85WWdYbKbcMR2wMI
> IXhqLwqdlSH4I&k=DWI7&r=UTEzTUpQcktwRVdhdEg1TKCFOzhw8CGaAiMfyFTpTR_LTs
> pF9zP2JS-LN0ctA-XBzHeMG-
> sD1OqL3ihNxDMXJg&s=ee8fad1f3a3cde35c58d5e5735a648efe5c5270d76a0a57b9a
> 6909d8d3104966&u=https%3A%2F%2Fwww.mail-archive.com%2Fqemu-
> devel%40nongnu.org%2Fmsg436979.html

Nit: it's better to link to the commit rather than the mailing list for
things that are already applied.

>>Missing your Signed-off-by.

oops,sorry

>>Hmm, I wanted to suggest to query the image to see what kind of
>>preallocation it was created with and then use that setting to stay
>>consistent. 
>>But that information doesn't seem to get recorded (on an
>>image-wide level) AFAICS.

for full pre-allocation, I think we can simply check the current qcow2
usage vs the size configured.

for qcow2 metadatas, I really don't known any way to do it.

>> It might be surprising that changes to the
>>storage configuration setting will also apply to already existing
>>images

Personnaly, I was more surprised than this never have worked on resize
before ^_^.

That don't shock me that it's respect the current assigned option at
the moment of the resize.

>>and we should document the behavior for resize in the description of
>>the
>>'preallocation' setting.

But yes, it should be documented.
I'll write a patch of pve-docs


>>Seems like the "block_resize" QMP command does not have the setting
>>at
>>all, so if we add it here, the behavior would still be inconsistent
>>in
>>that regard :/ But oh well, could still be added on top later if we
>>can
>>get that feature in upstream. But should also be documented, that it
>>doesn't apply for live resize.

yes, indeed, it doesn't exist for live running image. (I think to have
seen discussion on the qemu mailing about it, but it require some kind
of block job if I remember correctly).

It's existing a preallocate-filter 

https://qemu.googlesource.com/qemu/+/refs/tags/v8.0.3/block/preallocate.c

but it's a little bit different, it's preallocating live.
(allocating by chunk of 1MB for example, when you have a 4k write
reaching EOF)



Thanks for the review !



> ---
>  src/PVE/Storage/Plugin.pm | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/PVE/Storage/Plugin.pm b/src/PVE/Storage/Plugin.pm
> index 6a6a804..d0ce3ae 100644
> --- a/src/PVE/Storage/Plugin.pm
> +++ b/src/PVE/Storage/Plugin.pm
> @@ -1166,7 +1166,9 @@ sub volume_resize {
>  
>      my $format = ($class->parse_volname($volname))[6];
>  
> -    my $cmd = ['/usr/bin/qemu-img', 'resize', '-f', $format, $path ,
> $size];
> +    my $prealloc_opt = preallocation_cmd_option($scfg, $format);
> +
> +    my $cmd = ['/usr/bin/qemu-img', 'resize', "--$prealloc_opt", '-
> f', $format, $path , $size];
>  
>      run_command($cmd, timeout => 10);
>  
> -- 
> 2.39.5
> 
>