linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zdenek.kabelac@gmail.com>
To: Demi Marie Obenour <demi@invisiblethingslab.com>
Cc: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Running thin_trim before activating a thin pool
Date: Sun, 30 Jan 2022 18:56:43 +0100	[thread overview]
Message-ID: <57a77ded-703d-d8a6-a919-2a68ba4cf97f@gmail.com> (raw)
In-Reply-To: <YfbLMQ7a6D479vz6@itl-email>

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/

  reply	other threads:[~2022-01-30 17:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-29 18:52 Demi Marie Obenour
2022-01-29 19:42 ` Zdenek Kabelac
2022-01-29 20:09   ` Demi Marie Obenour
2022-01-29 21:40     ` Zdenek Kabelac
2022-01-30  1:20       ` Demi Marie Obenour
2022-01-30 11:18         ` Zdenek Kabelac
2022-01-30 17:30           ` Demi Marie Obenour
2022-01-30 17:56             ` Zdenek Kabelac [this message]
2022-01-30 18:01               ` Demi Marie Obenour
2022-01-30 18:42                 ` Zdenek Kabelac
2022-01-30 20:22           ` Gionatan Danti
  -- strict thread matches above, loose matches on Subject: below --
2022-01-29 17:45 Demi Marie Obenour
2022-01-31 11:02 ` Gionatan Danti
2022-01-31 13:41   ` Zdenek Kabelac
2022-01-31 14:12     ` Gionatan Danti
2022-01-31 15:28   ` Demi Marie Obenour
2022-01-31 17:54     ` Gionatan Danti
2022-01-31 19:04       ` Demi Marie Obenour

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57a77ded-703d-d8a6-a919-2a68ba4cf97f@gmail.com \
    --to=zdenek.kabelac@gmail.com \
    --cc=demi@invisiblethingslab.com \
    --cc=linux-lvm@redhat.com \
    --subject='Re: [linux-lvm] Running thin_trim before activating a thin pool' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).