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

[Fiona Ebner]

Am 03.02.25 um 17:11 schrieb DERUMIER, Alexandre:
> -------- Message initial --------
> De: Fiona Ebner <f.ebner at proxmox.com>
>>> 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.
> 

We don't need to do it based on heuristics. It's really not worth the
effort then IMHO. I just kinda expected to be an image property at
first, but it does make sense that allocation is per-cluster.

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

Fair :)

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

Great! There also is the schema in Plugin.pm ;)

> 
> 
>>> 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).

I guess that makes sense, because it can be longer running. I noted that
qmp_block_resize() is already a coroutine, maybe that can be leveraged
if we were to implement the feature for live resize. But again, won't be
a blocker here and can still be considered later.

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

Okay, so not quite what we want here.