From: Zdenek Kabelac <firstname.lastname@example.org>
To: LVM2 development <email@example.com>,
Pawan Sharma <firstname.lastname@example.org>,
Cc: Kapil Upadhayay <email@example.com>,
Mitta Sai Chaithanya <firstname.lastname@example.org>
Subject: Re: [linux-lvm] LVM2 : performance drop even after deleting the snapshot
Date: Thu, 13 Oct 2022 12:50:33 +0200 [thread overview]
Message-ID: <email@example.com> (raw)
Dne 13. 10. 22 v 8:53 Pawan Sharma napsal(a):
> adding this to lvm-devel mailing list also.
> *From:* Pawan Sharma
> *Sent:* Wednesday, October 12, 2022 10:42 PM
> *To:* firstname.lastname@example.org <email@example.com>
> *Cc:* Mitta Sai Chaithanya <firstname.lastname@example.org>; Kapil Upadhayay
> *Subject:* LVM2 : performance drop even after deleting the snapshot
> Hi Everyone,
> We are evaluating lvm2 snapshots and doing performance testing on it. This is
> what we are doing :
> 1. dump some data to lvm2 volume (using fio)
> 2. take the snapshot
> 3. delete the snapshot (no IOs anywhere after creating the snapshot)
> 4. run the fio on lvm2 volume
> Here as you can see, we are just creating the snapshot and immediately
> deleting it. There are no IOs to the main volume or anywhere. When we run the
> fio after this (step 4) and we see around 50% drop in performance with
> reference to the number we get in step 1.
> It is expected to see a performance drop if there is a snapshot because of the
> COW. But here we deleted the snapshot, and it is not referring to any data
> also. We should not see any performance drop here.
> Could someone please help me understand this behavior. Why are we seeing the
> performance drop in this case? It seems like we deleted the snapshot but still
> it is not deleted, and we are paying the COW penalty.
> System Info:
> OS : ubuntu 18.04
> Kernel : 5.4.0
> # lvm version
> LVM version:2.02.176(2) (2017-11-03)
> Library version: 1.02.145 (2017-11-03)
> Driver version:4.41.0
> We also tried on latest ubuntu with newer version of LVM. We got the same
Debugging 5 year old software is likely not going to get lot of attention
a) reproduce the issue with some recent kernel & lvm2
b) take 'dmsetup table && dmsetup status' before you run every 'fio' test
and present here your result in some form - otherwise we can hardly see what
is the problem.
What should be expected - if you use old/thick snapshots - when you 'drop'
snapshot - you have your original intact LV - so results should mostly match
results before you take the snapshot - but you clearly have to take into
account if you use some 'SSD/NVMe' discarding and other things - so always run
series of tests and average your results.
If you use thin snapshot - that you can get various results depending on your
settings of thin chunks, discard usage.
Also maybe try your benchmark with different filesystems...
linux-lvm mailing list
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
next prev parent reply other threads:[~2022-10-13 10:50 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 [this message]
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
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
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).