Re: [pve-devel] [RFC storage] work-around #6543: do not use preallocation for qcow2 on top of LVM

["DERUMIER, Alexandre via pve-devel" <pve-devel@lists.proxmox.com>]

[-- Attachment #1: Type: message/rfc822, Size: 16531 bytes --]

From: "DERUMIER, Alexandre" <alexandre.derumier@groupe-cyllene.com>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [RFC storage] work-around #6543: do not use preallocation for qcow2 on top of LVM
Date: Wed, 23 Jul 2025 11:25:38 +0000
Message-ID: <0bd1078bb6845675cd31a54bb07607d870922e85.camel@groupe-cyllene.com>

Hi Fiona, I'm on holiday, can't verify, but before using qemu-img
measure I had implemented compute of metadatas size (It was not 100%
perfect).

This is strange, because I thinked that "qemu-img measure" was working
correctly (we need to pass it blocksize && l2_extended option too). I
had tried with a 1TB qcow2 volume.


Note that I'm almost pretty sure that l2_extended=on need
preallocation. (If I remember it's failing without it, and performance
of backed volumes are pretty bad with l2_extended).

-------- Message initial --------
De: Fiona Ebner <f.ebner@proxmox.com>
Répondre à: Proxmox VE development discussion <pve-
devel@lists.proxmox.com>
À: pve-devel@lists.proxmox.com
Objet: [pve-devel] [RFC storage] work-around #6543: do not use
preallocation for qcow2 on top of LVM
Date: 22/07/2025 17:31:50

With the default preallocation=metadata for qcow2, the image can grow
more than 'qemu-img measure' reports, see bug #6543. Currently, the
option does not seem to make a difference with 'qemu-img measure', so
that needs to be further investigated. Once it's safe to add
preallocation back here, it should also be re-added to the
qemu_img_resize() call. Also, the option should be passed along to the
qemu_img_measure() call, because otherwise, it wouldn't match the
actual creation options.

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
---

RFC, because this stop-gap might not even be complete (but it's the
best I have right now). Needs to be furhter investigated in any case.

 src/PVE/Storage/LVMPlugin.pm | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/src/PVE/Storage/LVMPlugin.pm
b/src/PVE/Storage/LVMPlugin.pm
index 8be2a10..fba592d 100644
--- a/src/PVE/Storage/LVMPlugin.pm
+++ b/src/PVE/Storage/LVMPlugin.pm
@@ -568,8 +568,14 @@ my sub lvm_qcow2_format {
     $class->activate_volume($storeid, $scfg, $name);
     my $path = $class->path($scfg, $name, $storeid);
 
+    # TODO with the default preallocation=metadata for qcow2, the
image can grow more than
+    # 'qemu-img measure' reports, see bug #6543. Currently, the option
does not seem to make a
+    # difference with 'qemu-img measure', so that needs to be further
investigated. Once it's safe
+    # to add preallocation back here, it should also be re-added to
the qemu_img_resize() call.
+    # Also, the option should be passed along to the
qemu_img_measure() call, because otherwise,
+    # it wouldn't match the actual creation options.
     my $options = {
-        preallocation =>
PVE::Storage::Plugin::preallocation_cmd_opt($scfg, $fmt),
+        # preallocation =>
PVE::Storage::Plugin::preallocation_cmd_opt($scfg, $fmt),
     };
     if ($backing_snap) {
         my $backing_volname = get_snap_name($class, $name,
$backing_snap);
@@ -927,8 +933,7 @@ sub volume_resize {
     );
 
     if (!$running && $format eq 'qcow2') {
-        my $preallocation =
PVE::Storage::Plugin::preallocation_cmd_opt($scfg, $format);
-        PVE::Storage::Common::qemu_img_resize($path, $format, $size,
$preallocation, 10);
+        PVE::Storage::Common::qemu_img_resize($path, $format, $size,
undef, 10);
     }
 
     return 1;

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel