archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <>
To: Pawan Sharma <>,
	LVM2 development <>,
	"" <>
Cc: Kapil Upadhayay <>,
	Mitta Sai Chaithanya <>
Subject: Re: [linux-lvm] [EXTERNAL] Re: LVM2 : performance drop even after deleting the snapshot
Date: Tue, 18 Oct 2022 13:15:38 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <PUZP153MB0751F596ABAFA828502BA50FAC289@PUZP153MB0751.APCP153.PROD.OUTLOOK.COM>

Dne 18. 10. 22 v 5:33 Pawan Sharma napsal(a):
> Hi Zdenek,
> I would like to highlight one point here is that we are creating and then 
> deleting the snapshot immediately without writing anything anywhere. In this 
> case, we are expecting the performance to go back to what it was before taking 
> the thin snapshot. Here we are not getting the original performance after 
> deleting the snapshot. Do you know any reason why that would be happening.

As explained in my previous post - with thin-provisioning - you are getting 
metadata updates for bTrees - thus there is no 'revert' to previous 'metadata 
state' - there is rolling update of bTrees which is by design 'seek 
unfriendly' - so for the performance hunting users the use of SSD/NVMe type 
storage for these metadata volumes is basically a must (and it's been designed 
for that).

The old 'thick' snapshot where you allocate explicit COW LV storage is going 
to give here your expected behavior - however you will (of course) loose all 
the benefits you get with thin-pools.

With thin-pool (as also mentioned in my previous post) - if you can't afford 
dedicated low-latency storage - you need to scale-up chunk size - so the 
amount of metadata updates is reduced together (lowering seeking). I'm afraid 
you can't expect much more in the near future.

FYI there is to be merged in the upcoming kernel this patch set:

which should also help a lot with multithreaded load on thin-pools

There is also some new metadata format being experimented with - but whether 
this will also tackle anything in the seek friendlier logic is hard to tell...



linux-lvm mailing list
read the LVM HOW-TO at

  reply	other threads:[~2022-10-18 11:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-12 17:12 [linux-lvm] LVM2 : performance drop even after deleting the snapshot Pawan Sharma
2022-10-13  6:53 ` Pawan Sharma
2022-10-13 10:50   ` Zdenek Kabelac
2022-10-14 19:31     ` [linux-lvm] [EXTERNAL] " Mitta Sai Chaithanya
2022-10-17 13:10       ` Zdenek Kabelac
2022-10-17 13:41         ` Erwin van Londen
2022-10-20 18:19           ` Zdenek Kabelac
2022-10-18  3:33         ` Pawan Sharma
2022-10-18 11:15           ` Zdenek Kabelac [this message]
2022-10-14 19:50   ` [linux-lvm] " Roger Heflin
2022-10-14 20:28     ` Roberto Fastec
2022-10-17  5:01       ` Kapil Upadhayay
2022-10-17 15:16       ` 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:

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

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).