On 6/17/19 10:28 AM, [email protected] wrote:
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 would fully expect lvremove to issue discards, if lvm is configured
for it. Did you try changing /etc/lvm/lvm.conf so that "issue_discards =
1" ?
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?
I think Marek wanted in the future to move dom0 root to a regular
(static) lv in the same volume group. But also, it should be possible
for a user to perform this switch manually by creating a static lv,
copying dom0 root contents to new root, and then changing the necessary
grub entries. If you don't rename the old thin lv and name the static lv
'root', then you'll have to change fstab as well.
At that point, you might be able to deactivate any configured pools from
/lib/systemd/system-shutdown as this gets executed right after
filesystems become read-only. Although a systemd unit might get you
closer to the point you want to be.
But definitely try lvm.conf "issue_discards = 1" first. ;) There is also
the "thin_pool_discards" setting.
*** 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.
The way to zero-fill would be with a thin lv. If you think of thin pool
as a filesystem, you would zero-fill an fs by creating a file. Just
don't max out the pool completely, or you may end up with an un-bootable
system.
--
Chris Laprise, [email protected]
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/4469ac3e-46db-55f8-ba86-c80134e9b691%40posteo.net.
For more options, visit https://groups.google.com/d/optout.
