There is a tool in dom0 called "thin_trim" which is part of the "device-mapper-persistent-data" package. It issues discards to the unallocated space of a dm-thin device that is not in use. This gets a bit trickier if it is an lvm2 device, as there's another management layer above the dm-thin store, but it is possible to use against one as per guidance here: https://github.com/jthornber/thin-provisioning-tools/issues/76 )
However, as you can see at the link: thin_trim can only be invoked against a *deactivated* thin pool. This is not possible in Qubes normal operation as dom0 lives *within* the thin pool with the other VMs** and therefore the pools cannot be deactivated. There seems to be no other tool available to issue discards directly against a thin pool's unallocated space***. `lvremove` does not do so, no matter what the documentation states. Effectively this means that some contents of past VMs, including disposable VMs, are sitting around in the unallocated storage space. I have a feature request open for an explicit blkdiscard call against LVs before lvremove is invoked, which addresses many but not all cases of remnant data. It would also be good hygiene to opportunistically issue discards against the unallocated thin pool space on a regular basis (e.g. weekly, on boot perhaps). If I were to brainstorm a bit, there is presumably a point during boot (before pivoting away from the initial ramdisk) or during shutdown (after unmounting dom0's root) where one could potentially invoke the thin_trim command (if you ensured that it and associated libraries were accessible at that point). Any guidance on how one would do so? Brendan ** might be an argument for dom0 to live in a separate pool? *** other than explicitly filling the thin pool up to ~99.9% with random data (directly or via a VM-attached LV), then issuing discards against that before/during removal...which is not an efficient approach for time and wear reasons. I also tried adding a linear LV to the VG, to run blkdiscard again... but the linear LV cannot encroach on the thin pool's allocation, so that wasn't helpful. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/47f6ec79-27de-4c02-9959-f006d9b04ce6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
