From: "Michael Köppl" <m.koeppl@proxmox.com>
To: "Lukas Sichert" <l.sichert@proxmox.com>, <pve-devel@lists.proxmox.com>
Subject: Re: [PATCH storage v11 4/6] fix #7339: lvm: add discard action for removed volumes
Date: Wed, 29 Jul 2026 17:12:00 +0200 [thread overview]
Message-ID: <DKB5H21JM5TY.2OBQJZJ7ZR7O1@proxmox.com> (raw)
In-Reply-To: <20260723135656.102972-5-l.sichert@proxmox.com>
On Thu Jul 23, 2026 at 3:56 PM CEST, Lukas Sichert wrote:
[snip]
> for (my $offset = 0; $offset < $size; $offset += $written) {
>
> if ($offset + $stepsize > $size) {
> @@ -441,6 +452,18 @@ my sub free_lvm_volumes_locked {
> }
>
> }
> + if ($on_remove_opts->{discard}) {
> + $discard_attempts++;
> +
> + eval { blockdev_ioctl_range($fh, BLKDISCARD, $offset, $written); };
This uses the same offset and stepsize as for BLKZEROOUT, but $stepsize
is based on saferemove-stepsize and write_zeroes_max_bytes. The
separate setting of discard_granularity is never read. It seems that
this causes problems because AFAICT the discard action only frees whole
allocation units. So how much space is reclaimed seems to depend on
whether the step size happens to be a multiple of the granularity of
allocation units, which is never checked.
I tried this by creating 3 thin pools differing in chunk size only
using `lvcreate --chunksize=...`, with an otherwise identical config
(saferemove=1, discard=1, saferemove-stepsize=1). On each, I created a
thin LV, then allocated a VM disk on it, wrote some data to it, and
afterwards freed it using `pvesm free` and checked how much space was
reclaimed:
granularity reclaimed
512K 100%
768K 50%
2M 0%
The same 2M pool reclaims fully with saferemove=0, where the discard is
a single whole-device /sbin/blkdiscard (AFAIU).
I'm not entirely sure if this is something that often occurs in the
wild. Perhaps someone else can chime in here, but if varying
granularities occur from time to time in production setups, it's a
problem because it happens silently. Logs always end successfully in
"successfully removed volume", even though the space might not have
been reclaimed.
> + if (my $err = $@) {
> + if ($discard_failures == 0) {
> + log_warn(
> + "blkdiscard for $written bytes at offset $offset failed: $err");
> + }
> + $discard_failures += 1;
> + }
[snip]
next prev parent reply other threads:[~2026-07-29 15:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 13:56 [PATCH docs/manager/storage v11 0/6] fix #7339: lvmthick: add option to free storage for deleted VMs Lukas Sichert
2026-07-23 13:56 ` [PATCH storage v11 1/6] lvm: saferemove: keep LVs where zero-out failed for manual zero-out Lukas Sichert
2026-07-23 13:56 ` [PATCH storage v11 2/6] lvm: saferemove: zero out volumes range by range Lukas Sichert
2026-07-29 15:34 ` Michael Köppl
2026-07-23 13:56 ` [PATCH storage v11 3/6] lvm: saferemove: make throughput an integer property Lukas Sichert
2026-07-23 13:56 ` [PATCH storage v11 4/6] fix #7339: lvm: add discard action for removed volumes Lukas Sichert
2026-07-29 15:12 ` Michael Köppl [this message]
2026-07-23 13:56 ` [PATCH manager v11 5/6] fix #7339: lvm: add discard-on-remove option to UI Lukas Sichert
2026-07-30 14:36 ` Michael Köppl
2026-07-23 13:56 ` [PATCH docs v11 6/6] fix #7339: lvm: document discard option Lukas Sichert
2026-07-30 14:34 ` [PATCH docs/manager/storage v11 0/6] fix #7339: lvmthick: add option to free storage for deleted VMs Michael Köppl
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=DKB5H21JM5TY.2OBQJZJ7ZR7O1@proxmox.com \
--to=m.koeppl@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.