public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
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




  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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal