From: Zdenek Kabelac <zdenek.kabelac@gmail.com>
To: Pawan Sharma <sharmapawan@microsoft.com>,
LVM2 development <lvm-devel@redhat.com>,
"linux-lvm@redhat.com" <linux-lvm@redhat.com>
Cc: Kapil Upadhayay <kupadhayay@microsoft.com>,
Mitta Sai Chaithanya <mittas@microsoft.com>
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: <2bb9c754-3e8e-5c6a-c4fb-c4212d8de44f@gmail.com> (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:
https://listman.redhat.com/archives/dm-devel/2022-October/052367.html
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...
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/
next prev parent 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:
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=2bb9c754-3e8e-5c6a-c4fb-c4212d8de44f@gmail.com \
--to=zdenek.kabelac@gmail.com \
--cc=kupadhayay@microsoft.com \
--cc=linux-lvm@redhat.com \
--cc=lvm-devel@redhat.com \
--cc=mittas@microsoft.com \
--cc=sharmapawan@microsoft.com \
/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
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).