Am 03.02.25 um 17:11 schrieb DERUMIER, Alexandre: > -------- Message initial -------- > De: Fiona Ebner <f.eb...@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. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
