Re: [linux-lvm] Running thin_trim before activating a thin pool
On Mon, Jan 31, 2022 at 06:54:48PM +0100, Gionatan Danti wrote: > Il 2022-01-31 16:28 Demi Marie Obenour ha scritto: > > thin_trim is a userspace tool that works on an entire thin pool, and I > > suspect it may be significantly faster than blkdiscard of an individual > > thin volume. That said, what I would *really* like is something > > equivalent to fstrim for thin volumes: a tool that works asynchronously, > > in the background, without disrupting concurrent I/O. > > Are you sure that fstrim works asynchronously? > I remember "fstrim -v /mybigdevice" tacking some time (~30s). It’s happens online and without preventing other I/O from happening, whereas thin_trim can only be run offline. > > FYI, you might want to specify a full fingerprint here; short key IDs > > are highly vulnerable to collision and preimage attacks. > > Yeah, it is a 15 years old signature I must decide to update ;) > Thanks. Might want to generate a new key while you are at it :) (especially if the old one is weak) -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature ___ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Running thin_trim before activating a thin pool
Il 2022-01-31 16:28 Demi Marie Obenour ha scritto: thin_trim is a userspace tool that works on an entire thin pool, and I suspect it may be significantly faster than blkdiscard of an individual thin volume. That said, what I would *really* like is something equivalent to fstrim for thin volumes: a tool that works asynchronously, in the background, without disrupting concurrent I/O. Are you sure that fstrim works asynchronously? I remember "fstrim -v /mybigdevice" tacking some time (~30s). FYI, you might want to specify a full fingerprint here; short key IDs are highly vulnerable to collision and preimage attacks. Yeah, it is a 15 years old signature I must decide to update ;) Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Running thin_trim before activating a thin pool
On Mon, Jan 31, 2022 at 12:02:23PM +0100, Gionatan Danti wrote: > Il 2022-01-29 18:45 Demi Marie Obenour ha scritto: > > 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? > > I think that, if anything, it would be worse: a long discard during boot can > be problematic, even leading to timeout on starting other services. > After all, blkdiscard should be faster then something done at higher level. thin_trim is a userspace tool that works on an entire thin pool, and I suspect it may be significantly faster than blkdiscard of an individual thin volume. That said, what I would *really* like is something equivalent to fstrim for thin volumes: a tool that works asynchronously, in the background, without disrupting concurrent I/O. > -- > Danti Gionatan > Supporto Tecnico > Assyoma S.r.l. - www.assyoma.it > email: g.da...@assyoma.it - i...@assyoma.it > GPG public key ID: FF5F32A8 FYI, you might want to specify a full fingerprint here; short key IDs are highly vulnerable to collision and preimage attacks. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature ___ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Running thin_trim before activating a thin pool
Il 2022-01-31 14:41 Zdenek Kabelac ha scritto: > 'issue_discard' relates only to the internal lvm2 logic when some extents become free for reuse (so i.e. after 'lvremove/lvreduce/vgremove...'. However since with thin volumes no physical extents of VG are released (as the thin volume is releasing chunks from the thin-pool) - there is no discard issued by lvm. Ah, I missed that. Thank you Zdenek. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Running thin_trim before activating a thin pool
Dne 31. 01. 22 v 12:02 Gionatan Danti napsal(a): Il 2022-01-29 18:45 Demi Marie Obenour ha scritto: 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? I think that, if anything, it would be worse: a long discard during boot can be problematic, even leading to timeout on starting other services. After all, blkdiscard should be faster then something done at higher level. That said, I seem to remember that deleting a fat volume should automatically trim/discard it if issue_discard=1. Is this not true for thin volumes? 'issue_discard' relates only to the internal lvm2 logic when some extents become free for reuse (so i.e. after 'lvremove/lvreduce/vgremove...'. However since with thin volumes no physical extents of VG are released (as the thin volume is releasing chunks from the thin-pool) - there is no discard issued by lvm. Regards Zdenek ___ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Running thin_trim before activating a thin pool
Il 2022-01-29 18:45 Demi Marie Obenour ha scritto: 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? I think that, if anything, it would be worse: a long discard during boot can be problematic, even leading to timeout on starting other services. After all, blkdiscard should be faster then something done at higher level. That said, I seem to remember that deleting a fat volume should automatically trim/discard it if issue_discard=1. Is this not true for thin volumes? Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Running thin_trim before activating a thin pool
Il 2022-01-30 12:18 Zdenek Kabelac ha scritto: > Thin is more oriented towards extreme speed. VDO is more about 'compression & deduplication' - so space efficiency. Combining both together is kind of harming their advantages. Unfortunately, it is the only (current) solution to have snapshotting with data compression/deduplication. Integrating snapshot capability into VDO would be awesome! Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.da...@assyoma.it - i...@assyoma.it GPG public key ID: FF5F32A8 ___ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Running thin_trim before activating a thin pool
Dne 30. 01. 22 v 19:01 Demi Marie Obenour napsal(a): On Sun, Jan 30, 2022 at 06:56:43PM +0100, Zdenek Kabelac wrote: Dne 30. 01. 22 v 18:30 Demi Marie Obenour napsal(a): On Sun, Jan 30, 2022 at 12:18:32PM +0100, Zdenek Kabelac wrote: Then are always landing in upstream kernel once they are all validated & tested (recent kernel already has many speed enhancements). Thanks! Which mailing list should I be watching? lkml You could easily run in parallel individual blkdiscards for your thin LVs For most modern drives thought it's somewhat waste of time... Those trimming tools should be used when they are solving some real problems, running them just for fun is just energy & performance waste My understanding (which could be wrong) is that periodic trim is necessary for SSDs. This was useful for archaic SSDs. Modern SSD/NVMe drives are much smarter... Regards Zdenek ___ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Running thin_trim before activating a thin pool
On Sun, Jan 30, 2022 at 06:56:43PM +0100, Zdenek Kabelac wrote: > Dne 30. 01. 22 v 18:30 Demi Marie Obenour napsal(a): > > On Sun, Jan 30, 2022 at 12:18:32PM +0100, Zdenek Kabelac wrote: > > > Discard of thins itself is AFAIC pretty fast - unless you have massively > > > sized thin devices with many GiB of metadata - obviously you cannot > > > process > > > this amount of metadata in nanoseconds (and there are prepared kernel > > > patches to make it even faster) > > > > Would you be willing and able to share those patches? > > Then are always landing in upstream kernel once they are all validated & > tested (recent kernel already has many speed enhancements). Thanks! Which mailing list should I be watching? > > > What is the problem is the speed of discard of physical devices. > > > You could actually try to feel difference with: > > > lvchange --discards passdown|nopassdown thinpool > > > > In Qubes OS I believe we do need the discards to be passed down > > eventually, but I doubt it needs to be synchronous. Being able to run > > the equivalent of `fstrim -av` periodically would be amazing. I’m > > CC’ing Marek Marczykowski-Górecki (Qubes OS project lead) in case he > > has something to say. > > You could easily run in parallel individual blkdiscards for your thin LVs > For most modern drives thought it's somewhat waste of time... > > Those trimming tools should be used when they are solving some real > problems, running them just for fun is just energy & performance waste My understanding (which could be wrong) is that periodic trim is necessary for SSDs. > > > Also it's very important to keep metadata on fast storage device > > > (SSD/NVMe)! > > > Keeping metadata on same hdd spindle as data is always going to feel slow > > > (in fact it's quite pointless to talk about performance and use hdd...) > > > > That explains why I had such a horrible experience with my initial > > (split between NVMe and HDD) install. I would not be surprised if some > > or all of the metadata volume wound up on the spinning disk. > > With lvm2 user can always 'pvmove' any LV to any desired PV. > There is not yet any 'smart' logic to do it automatically. Good point. I was probably unware of that at the time. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature ___ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Running thin_trim before activating a thin pool
Dne 30. 01. 22 v 18:30 Demi Marie Obenour napsal(a): On Sun, Jan 30, 2022 at 12:18:32PM +0100, Zdenek Kabelac wrote: Dne 30. 01. 22 v 2:20 Demi Marie Obenour napsal(a): 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): Discard of thins itself is AFAIC pretty fast - unless you have massively sized thin devices with many GiB of metadata - obviously you cannot process this amount of metadata in nanoseconds (and there are prepared kernel patches to make it even faster) Would you be willing and able to share those patches? Then are always landing in upstream kernel once they are all validated & tested (recent kernel already has many speed enhancements). What is the problem is the speed of discard of physical devices. You could actually try to feel difference with: lvchange --discards passdown|nopassdown thinpool In Qubes OS I believe we do need the discards to be passed down eventually, but I doubt it needs to be synchronous. Being able to run the equivalent of `fstrim -av` periodically would be amazing. I’m CC’ing Marek Marczykowski-Górecki (Qubes OS project lead) in case he has something to say. You could easily run in parallel individual blkdiscards for your thin LVs For most modern drives thought it's somewhat waste of time... Those trimming tools should be used when they are solving some real problems, running them just for fun is just energy & performance waste Also it's very important to keep metadata on fast storage device (SSD/NVMe)! Keeping metadata on same hdd spindle as data is always going to feel slow (in fact it's quite pointless to talk about performance and use hdd...) That explains why I had such a horrible experience with my initial (split between NVMe and HDD) install. I would not be surprised if some or all of the metadata volume wound up on the spinning disk. With lvm2 user can always 'pvmove' any LV to any desired PV. There is not yet any 'smart' logic to do it automatically. 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, We hope we will add some direct 'snapshot' support to VDO so users will not need to combine both technologies together. Does that include support for splitting a VDO volume into multiple, individually-snapshottable volumes, the way thin works? Yes - that's the plan - to have multiple VDO LV in a single VDOPool. Regards Zdenek ___ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Running thin_trim before activating a thin pool
On Sun, Jan 30, 2022 at 12:18:32PM +0100, Zdenek Kabelac wrote: > Dne 30. 01. 22 v 2:20 Demi Marie Obenour napsal(a): > > 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; > > Hi > > Discard of thins itself is AFAIC pretty fast - unless you have massively > sized thin devices with many GiB of metadata - obviously you cannot process > this amount of metadata in nanoseconds (and there are prepared kernel > patches to make it even faster) Would you be willing and able to share those patches? > What is the problem is the speed of discard of physical devices. > You could actually try to feel difference with: > lvchange --discards passdown|nopassdown thinpool In Qubes OS I believe we do need the discards to be passed down eventually, but I doubt it needs to be synchronous. Being able to run the equivalent of `fstrim -av` periodically would be amazing. I’m CC’ing Marek Marczykowski-Górecki (Qubes OS project lead) in case he has something to say. > Also it's very important to keep metadata on fast storage device (SSD/NVMe)! > Keeping metadata on same hdd spindle as data is always going to feel slow > (in fact it's quite pointless to talk about performance and use hdd...) That explains why I had such a horrible experience with my initial (split between NVMe and HDD) install. I would not be surprised if some or all of the metadata volume wound up on the spinning disk. > > 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 > > Out-of-space recoveries are ATM much harder then what we want. Okay, thanks! Will this be fixed in a future version? > So as long as user can maintain free space of your VDO and thin-pool it's > ok. Once user runs out of space - recovery is pretty hard task (and there is > reason we have support...) Out of space is already a tricky issue in Qubes OS. I certainly would not want to make it worse. > > 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, > > We hope we will add some direct 'snapshot' support to VDO so users will not > need to combine both technologies together. Does that include support for splitting a VDO volume into multiple, individually-snapshottable volumes, the way thin works? > Thin is more oriented towards extreme speed. > VDO is more about 'compression & deduplication' - so space efficiency. > > Combining both together is kind of harming their advantages. That makes sense. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature ___ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Running thin_trim before activating a thin pool
Dne 30. 01. 22 v 2:20 Demi Marie Obenour napsal(a): 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; Hi Discard of thins itself is AFAIC pretty fast - unless you have massively sized thin devices with many GiB of metadata - obviously you cannot process this amount of metadata in nanoseconds (and there are prepared kernel patches to make it even faster) What is the problem is the speed of discard of physical devices. You could actually try to feel difference with: lvchange --discards passdown|nopassdown thinpool Also it's very important to keep metadata on fast storage device (SSD/NVMe)! Keeping metadata on same hdd spindle as data is always going to feel slow (in fact it's quite pointless to talk about performance and use hdd...) 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 Out-of-space recoveries are ATM much harder then what we want. So as long as user can maintain free space of your VDO and thin-pool it's ok. Once user runs out of space - recovery is pretty hard task (and there is reason we have support...) 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, We hope we will add some direct 'snapshot' support to VDO so users will not need to combine both technologies together. Thin is more oriented towards extreme speed. VDO is more about 'compression & deduplication' - so space efficiency. Combining both together is kind of harming their advantages. https://access.redhat.com/articles/2106521#vdo recommends exactly this use-case. Or am I misunderstanding you? There are many paths to Rome... So as mentioned above - you need to pick performance/space effieciency. And since you want to write your own thin volume managing software, I'm guessing you care about performance a lot (so we do - but with our given constrains that are limiting us to some level)... 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. It's been purely related to the initial BZ description which cares a lot about thin discard performance and following comment adds VDO discard into same equation... :) Regards Zdenek ___ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Running thin_trim before activating a thin pool
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 signature.asc Description: PGP signature ___ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Running thin_trim before activating a thin pool
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... 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... Regards Zdenek ___ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Running thin_trim before activating a thin pool
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 -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature ___ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
Re: [linux-lvm] Running thin_trim before activating a thin pool
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. I guess this would possibly justify some form of support for 'writable' component activation. Regards Zdenek ___ linux-lvm mailing list linux-lvm@redhat.com https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/