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

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

Tested this version using a PVE guest with a disk with discard=1 on a
thin-provisioned LVM storage. I then created a thick-provisioned LVM in
the guest on which I allocated VM disks, wrote data to them, and freed
them under varying settings:

- With `pvesm set sanA --saferemove 1`, the data was
  actually zeroed out and usage actually grew since the disk is fully
  allocated by this
- With `pvesm set sanA --delete saferemove --on-volume-remove
  discard=1`, the previously allocated disk space was reclaimed as
  expected
- I also tried various settings for saferemove-stepsize and
  saferemove_throughput, confirming that the settings are actually
  applied during removal of the volume
- `pvesm set sanA --saferemove 1 --on-volume-remove discard=1` showed
  the data being zeroed-out in the logs and reclaimed the space, but I
  noticed something described in more detail below

On 2/6 I noted that I'm not sure that the data is actually zeroed-out on
the disk with syswrite. I tested this as well as follows:
- pvesm alloc sanc 913 vm-913-disk-0 4G
- Write 4G of a recognizable, super secret string to the disk
- pvesm free sanc:vm-913-disk-0 --> zeroed out the data according to the
  logs
- pvesm alloc sanc 913 vm-913-disk-0 4G
- Read from the disk

The hex dump showed the data still being there after zero-out:

00000000: 4554 2d56 4d2d 4441 5441 2d44 4f2d 4e4f  ET-VM-DATA-DO-NO
00000010: 542d 4c45 414b 0a53 4543 5245 542d 564d  T-LEAK.SECRET-VM
00000020: 2d44 4154 412d 444f 2d4e 4f54 2d4c 4541  -DATA-DO-NOT-LEA

So it seems the data is not actually guaranteed to be zeroed-out, but
the space is reclaimed and the logs suggest that everything worked as
expected. Adding an fsync call as suggested on 2/6 seems to fix this,
the hex dump then looks like this:

00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................

On Thu Jul 23, 2026 at 3:56 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
> thin-provisioned on the SAN side.

[snip]