[linux-lvm] Running thin_trim before activating a thin pool

[Demi Marie Obenour]

On Sat, Jan 29, 2022 at 10:40:34PM +0100, Zdenek Kabelac wrote:
> Dne 29. 01. 22 v 21:09 Demi Marie Obenour napsal(a):
> > On Sat, Jan 29, 2022 at 08:42:21PM +0100, Zdenek Kabelac wrote:
> > > Dne 29. 01. 22 v 19:52 Demi Marie Obenour napsal(a):
> > > > Is it possible to configure LVM2 so that it runs thin_trim before it
> > > > activates a thin pool?  Qubes OS currently runs blkdiscard on every thin
> > > > volume before deleting it, which is slow and unreliable.  Would running
> > > > thin_trim during system startup provide a better alternative?
> > > 
> > > Hi
> > > 
> > > 
> > > Nope there is currently no support from lvm2 side for this.
> > > Feel free to open RFE.
> > 
> > Done: https://bugzilla.redhat.com/show_bug.cgi?id=2048160
> > 
> > 
> 
> Thanks
> 
> Although your use-case Thinpool on top of VDO is not really a good plan and
> there is a good reason behind why lvm2 does not support this device stack
> directly (aka thin-pool data LV as VDO LV).
> I'd say you are stepping on very very thin ice...

Thin pool on VDO is not my actual use-case.  The actual reason for the
ticket is slow discards of thin devices that are about to be deleted;
you can find more details in the linked GitHub issue.  That said, now I
am curious why you state that dm-thin on top of dm-vdo (that is,
userspace/filesystem/VM/etc ⇒ dm-thin data (*not* metadata) ⇒ dm-vdo ⇒
hardware/dm-crypt/etc) is a bad idea.  It seems to be a decent way to
add support for efficient snapshots of data stored on a VDO volume, and
to have multiple volumes on top of a single VDO volume.  Furthermore,
https://access.redhat.com/articles/2106521#vdo recommends exactly this
use-case.  Or am I misunderstanding you?

> Also I assume you have already checked performance of discard on VDO, but I
> would not want to run this operation frequently on any larger volume...

I have never actually used VDO myself, although the documentation does
warn about this.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20220129/920cf39d/attachment.sig>