linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zdenek.kabelac@gmail.com>
To: LVM general discussion and development <linux-lvm@redhat.com>,
	Demi Marie Obenour <demi@invisiblethingslab.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 21:37:08 +0100	[thread overview]
Message-ID: <9a14a7a5-a8a1-a4d6-f9fd-012d3c170f2a@gmail.com> (raw)
In-Reply-To: <YgK+Avj+VURDqo7j@itl-email>

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,....)

For analysis of device hot points you could check 'dmstats' tool for DM devices.

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/


  reply	other threads:[~2022-02-08 20:37 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 [this message]
2022-02-08 21:02   ` Demi Marie Obenour
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=9a14a7a5-a8a1-a4d6-f9fd-012d3c170f2a@gmail.com \
    --to=zdenek.kabelac@gmail.com \
    --cc=demi@invisiblethingslab.com \
    --cc=dm-devel@redhat.com \
    --cc=frederic.pierret@qubes-os.org \
    --cc=linux-lvm@redhat.com \
    --cc=marmarek@invisiblethingslab.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).