Re: [PATCH docs/manager/storage v8 0/5] fix #7339: lvmthick: add option to free storage for deleted VMs

["Michael Köppl" <m.koeppl@proxmox.com>]

Thanks for the patches!

For this version I didn't have a SAN setup readily available, so I
tested with a loop-backed LVM thin pool. On top of a thin LV I created a
LVM-thick storage with discard enabled, created a VM on it, wrote some
data (dd), confirmed that the thin pool's allocation grew, and then
removed the VM. I observed the thin pool's usage drop back down again,
as expected. I saw the "discard (TRIM) data on image vm-9999-disk-0
(/dev/testlvm/del-vm-9999-disk-0)" as expected as well.

When also enabling saferemove, I could observe the usage in the thin
pool drop range by range, as well as observe the "zeroed-out ..." logs.
A thing I noticed is that it doesn't print the 100% log. For my case,
the last log line read 99.80% and then Logical volume
"del-vm-9999-disk-0" successfully removed. I don't think it's a
problem, though. Just looked a bit weird at first.

I also tested what happens if there's a failure during
discard+saferemove removal by making the LV readonly, removing the disk
(which shows "cleanup failed for lv vm-9999-disk-0..."), creating a new
disk with the same base name, removing it again, again yielding "cleanup
failed". Then I checked that `lvs testlvm` reports
failed-1-del-vm-9999-disk-0 and failed-2-del-vm-9999-disk-0, as expected.

Haven't had time yet to do a full review of the code, but added 2
comments on the individual patches.

Consider this:
Tested-by: Michael Köppl <m.koeppl@proxmox.com>

On Tue Jul 7, 2026 at 4:32 PM CEST, Lukas Sichert wrote:
> Logical volumes (LV) in an LVM (thick) volume group (VG) are
> thick-provisioned, but the underlying backing storage can be
> thin-provisioned. In particular, this can be the case if the VG resides
> on a LUN provided by a SAN via iSCSI/FC/SAS [1], where the LUN may be

[snip]