From: Fiona Ebner <f.ebner@proxmox.com>
To: Lukas Sichert <l.sichert@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [PATCH storage v9 3/5] fix #7339: lvm: add discard action for removed volumes
Date: Wed, 15 Jul 2026 12:26:18 +0200 [thread overview]
Message-ID: <57cf0d8b-4fa7-4e00-b106-e8c997f102dc@proxmox.com> (raw)
In-Reply-To: <20260713160008.121125-4-l.sichert@proxmox.com>
Am 13.07.26 um 6:00 PM schrieb Lukas Sichert:
> On LVM storages backed by thin-provisioned SAN LUNs, removing an LV does
> not release the allocated space on the backing storage. Using LVM's
> `issue_discards` can avoid that, but makes `lvremove` issue the discards
> while holding the cluster-wide storage lock, which can hit the lock
> timeout for large volumes.
>
> Add an `on-volume-remove` property with an initial `discard` action.
> Reject the option if discard is not supported by the backing devices.
> The cleanup worker issues the discard for the renamed LV before the
> final remove, so the long-running operation happens outside the storage
> lock. When combined with `saferemove`, the worker zeroes and discards
> the LV range by range, avoiding allocation of the whole LV with zeroes
> on thin-provisioned backing storage.
>
> Signed-off-by: Lukas Sichert <l.sichert@proxmox.com>
> Link: bugzilla.proxmox.com/show_bug.cgi?id=7339
Maybe include https:// ? I'd also prefer Buglink rather than Link, but
no big deal.
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
With one more comment and one more question below:
> @@ -411,8 +421,8 @@ my sub free_lvm_volumes_locked {
>
> if ($zeroout_variant eq 'blkzeroout') {
> eval { blockdev_ioctl_range($fh, BLKZEROOUT, $offset, $stepsize); };
> - if ($@) {
> - die "blkzeroout for $stepsize bytes at offset $offset failed: $@";
> + if (my $err = $@) {
> + die "blkzeroout for $stepsize bytes at offset $offset failed: $err";
> }
> $written = $stepsize;
> } elsif ($zeroout_variant eq 'syswrite') {
Should be squashed into the previous patch.
> +sub assert_discard_supported {
> + my ($vgname, $on_remove) = @_;
> +
> + return if !defined($on_remove);
> +
> + my $on_remove_opts = PVE::JSONSchema::parse_property_string('on-volume-remove', $on_remove);
> + if ($on_remove_opts->{discard}) {
> +
> + my $vgs = lvm_vgs(1);
> + my $vg = $vgs->{$vgname};
> + die "no such volume group '$vgname'\n" if !$vg;
> +
> + my $pvs = $vg->{pvs};
> + die "volume group '$vgname' has no physical volumes\n"
> + if !defined($pvs) || scalar($pvs->@*) == 0;
> +
> + # check if all the block devices configured to the volume group support discard
> + for my $pv ($vg->{pvs}->@*) {
> +
> + my $dev_path = abs_path($pv->{name}) // $pv->{name};
> +
> + if ($dev_path =~ m!^(/dev/[A-Za-z0-9_+./=-]+)$!) {
The information comes from LVM and is only used as the argument for
lsblk, so should we untaint with .* ? Or is there a specific reason for
this exact regex?
> + $dev_path = $1; # untaint
next prev parent reply other threads:[~2026-07-15 10:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 16:00 [PATCH docs/manager/storage v9 0/5] fix #7339: lvmthick: add option to free storage for deleted VMs Lukas Sichert
2026-07-13 16:00 ` [PATCH storage v9 1/5] lvm: saferemove: keep LVs where zero-out failed for manual zero-out Lukas Sichert
2026-07-15 10:26 ` Fiona Ebner
2026-07-13 16:00 ` [PATCH storage v9 2/5] lvm: saferemove: zero out volumes range by range Lukas Sichert
2026-07-15 10:26 ` Fiona Ebner
2026-07-13 16:00 ` [PATCH storage v9 3/5] fix #7339: lvm: add discard action for removed volumes Lukas Sichert
2026-07-15 10:26 ` Fiona Ebner [this message]
2026-07-13 16:00 ` [PATCH manager v9 4/5] fix #7339: lvm: add discard-on-remove option to UI Lukas Sichert
2026-07-15 10:26 ` Fiona Ebner
2026-07-13 16:00 ` [PATCH docs v9 5/5] fix #7339: lvm: document discard option Lukas Sichert
2026-07-15 10:26 ` Fiona Ebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57cf0d8b-4fa7-4e00-b106-e8c997f102dc@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=l.sichert@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox