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

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

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 354 bytes --]

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?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

[Zdenek Kabelac]

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/

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

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 661 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

[Zdenek Kabelac]

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

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 2063 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

[Zdenek Kabelac]

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

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 4102 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

[Zdenek Kabelac]

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

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 2369 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

[Zdenek Kabelac]

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

[Gionatan Danti]

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.danti@assyoma.it - info@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

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 1109 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

[Gionatan Danti]

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.danti@assyoma.it - info@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

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 1358 bytes --]

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.danti@assyoma.it - info@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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

[Gionatan Danti]

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.danti@assyoma.it - info@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

[Zdenek Kabelac]

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

[Gionatan Danti]

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.danti@assyoma.it - info@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/

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

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 354 bytes --]

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?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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/