From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: LVM general discussion and development <linux-lvm@redhat.com>,
Gionatan Danti <g.danti@assyoma.it>
Subject: Re: [linux-lvm] Why is the performance of my lvmthin snapshot so poor
Date: Thu, 16 Jun 2022 03:53:23 -0400 [thread overview]
Message-ID: <Yqrhmwwbp5KfiEWb@itl-email> (raw)
In-Reply-To: <d354dfb0-c37e-8a85-6cf6-d4b3a7e9257d@bytedance.com>
[-- Attachment #1.1: Type: text/plain, Size: 1935 bytes --]
On Wed, Jun 15, 2022 at 03:42:17PM +0800, Zhiyong Ye wrote:
>
>
> 在 6/14/22 10:54 PM, Gionatan Danti 写道:
> > Il 2022-06-14 15:29 Zhiyong Ye ha scritto:
> > > The reason for this may be that when the volume creates a snapshot,
> > > each write to an existing block will cause a COW (Copy-on-write), and
> > > the COW is a copy of the entire data block in chunksize, for example,
> > > when the chunksize is 64k, even if only 4k of data is written, the
> > > entire 64k data block will be copied. I'm not sure if I understand
> > > this correctly.
> >
> > Yes, in your case, the added copies are lowering total available IOPs.
> > But note how the decrease is sub-linear (from 64K to 1M you have a 16x
> > increase in chunk size but "only" a 10x hit in IOPs): this is due to the
> > lowered metadata overhead.
>
> It seems that the consumption of COW copies when sending 4k requests is much
> greater than the loss from metadata.
>
> > A last try: if you can, please regenerate your thin volume with 64K
> > chunks and set fio to execute 64K requests. Lets see if LVM is at least
> > smart enough to avoid coping a to-be-completely-overwritten chunks.
>
> I regenerated the thin volume with the chunksize of 64K and the random write
> performance data tested with fio 64k requests is as follows:
> case iops
> thin lv 9381
> snapshotted thin lv 8307
That seems reasonable. My conclusion is that dm-thin (which is what LVM
uses) is not a good fit for workloads with a lot of small random writes
and frequent snapshots, due to the 64k minimum chunk size. This also
explains why dm-thin does not allow smaller blocks: not only would it
only support very small thin pools, it would also have massive metadata
write overhead. Hopefully dm-thin v2 will improve the situation.
--
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: 202 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/
next prev parent reply other threads:[~2022-06-16 7:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-13 8:49 [linux-lvm] Why is the performance of my lvmthin snapshot so poor Zhiyong Ye
2022-06-14 7:04 ` Gionatan Danti
2022-06-14 10:16 ` Zhiyong Ye
2022-06-14 12:56 ` Gionatan Danti
2022-06-14 13:29 ` Zhiyong Ye
2022-06-14 14:54 ` Gionatan Danti
2022-06-15 7:42 ` Zhiyong Ye
2022-06-15 9:34 ` Gionatan Danti
2022-06-15 9:46 ` Zhiyong Ye
2022-06-15 12:40 ` Gionatan Danti
2022-06-15 16:39 ` Demi Marie Obenour
2022-06-16 7:53 ` Demi Marie Obenour [this message]
2022-06-16 13:22 ` Gionatan Danti
2022-06-16 16:19 ` Demi Marie Obenour
2022-06-16 19:50 ` Gionatan Danti
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=Yqrhmwwbp5KfiEWb@itl-email \
--to=demi@invisiblethingslab.com \
--cc=g.danti@assyoma.it \
--cc=linux-lvm@redhat.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).