From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Zdenek Kabelac <zdenek.kabelac@gmail.com>,
LVM general discussion and development <linux-lvm@redhat.com>,
device-mapper development <dm-devel@redhat.com>
Cc: "Frédéric Pierret" <frederic.pierret@qubes-os.org>,
"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Subject: Re: [linux-lvm] Thin pool performance when allocating lots of blocks
Date: Tue, 8 Feb 2022 16:02:40 -0500 [thread overview]
Message-ID: <733f87f3-5ed9-b266-b951-4526f872bad1@invisiblethingslab.com> (raw)
In-Reply-To: <9a14a7a5-a8a1-a4d6-f9fd-012d3c170f2a@gmail.com>
[-- Attachment #1.1.1.1: Type: text/plain, Size: 1770 bytes --]
On 2/8/22 15:37, Zdenek Kabelac wrote:
> Dne 08. 02. 22 v 20:00 Demi Marie Obenour napsal(a):
>> Are thin volumes (which start as snapshots of a blank volume) efficient
>> for building virtual machine images? Given the nature of this workload
>> (writing to lots of new, possibly-small files, then copying data from
>> them to a huge disk image), I expect that this will cause sharing to be
>> broken many, many times, and the kernel code that breaks sharing appears
>> to be rather heavyweight. Furthermore, since zeroing is enabled, this
>> might cause substantial write amplification. Turning zeroing off is not
>> an option for security reasons.
>>
>> Is there a way to determine if breaking sharing is the cause of
>> performance problems? If it is, are there any better solutions?
>
> Hi
>
> Usually the smaller the thin chunks size is the smaller the problem gets.
> With current released version of thin-provisioning minimal chunk size is
> 64KiB. So you can't use smaller value to further reduce this impact.
>
> Note - even if you do a lot of tiny 4KiB writes - only the 'first' such write
> into 64K area breaks sharing all following writes to same location no longer
> have this penalty (also zeroing with 64K is less impactful...)
>
> But it's clear thin-provisioning comes with some price - so if it's not good
> enough from time constrains some other solutions might need to be explored.
> (i.e. caching, better hw, splitting FS into multiple partitions with
> 'read-only sections,....)
Are the code paths that break sharing as heavyweight as I was worried
about? Would a hypothetical dm-thin2 that used dm-bio-prison-v2 be
faster?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 4963 bytes --]
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 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-02-08 21:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-08 19:00 [linux-lvm] Thin pool performance when allocating lots of blocks Demi Marie Obenour
2022-02-08 20:37 ` Zdenek Kabelac
2022-02-08 21:02 ` Demi Marie Obenour [this message]
2022-02-08 21:30 ` Zdenek Kabelac
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=733f87f3-5ed9-b266-b951-4526f872bad1@invisiblethingslab.com \
--to=demi@invisiblethingslab.com \
--cc=dm-devel@redhat.com \
--cc=frederic.pierret@qubes-os.org \
--cc=linux-lvm@redhat.com \
--cc=marmarek@invisiblethingslab.com \
--cc=zdenek.kabelac@gmail.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).