linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Dale Stephenson <dalestephenson@mac.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Performance penalty for 4k requests on thin provisioned volume
Date: Thu, 14 Sep 2017 10:32:43 -0400	[thread overview]
Message-ID: <0BE09EDA-1239-4749-A303-44E64C5AE177@mac.com> (raw)
In-Reply-To: <56cdaa13-a10a-a545-3cb6-cb454330df3f@redhat.com>


> On Sep 14, 2017, at 7:13 AM, Zdenek Kabelac <zkabelac@redhat.com> wrote:
> 
> Dne 14.9.2017 v 12:57 Gionatan Danti napsal(a):
>> On 14/09/2017 11:37, Zdenek Kabelac wrote:
>>> Sorry my typo here - is NOT ;)
>>> 
>>> 
>>> Zdenek
>> Hi Zdenek,
>> as the only variable is the LVM volume type (fat/thick vs thin), why the thin volume is slower than the thick one?
>> I mean: all other things being equal, what is holding back the thin volume?
> 
Gionatan has hit on the heart of my concern.  I ordinarily expect minimal performance hit from remapping, and that’s clearly the case with the thick volume.  But it’s not the case with thin, even though I’ve already fully provisioned it.  Why is thin so much slower, and what can I do to make it faster?

> So few more question:
> 
> What is '/dev/sdb4'  ? - is it also some fast SSD ?
> 
Correct, it’s an SSD identical to the ones used in the array.

> - just checking to be sure your metadata device is not placed on rotational storage device)…
> 
It is not in this case.

> What is your thin-pool chunk size - is it 64K ?

In this case it is 512k, because I believed that to be the optimal chunk size for a 512k raid stripe.

> - if your raise thin-pool chunk size up - is it getting any better ?
> 

I have only tested direct to device at 64k and 512k, 512k performs better.  It is not obvious to me why 512k *should* perform better when all the requests are only 4k, except that a given size of metadata would obviously map to a larger size.  (That is, if no contiguous chunk indicators are used — in this particular case I would expect the thin provisioning to be completely contiguous.)

Thank you for your help.
Dale Stephenson

  reply	other threads:[~2017-09-14 14:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-13 15:33 [linux-lvm] Performance penalty for 4k requests on thin provisioned volume Dale Stephenson
2017-09-13 20:19 ` Zdenek Kabelac
2017-09-13 22:39   ` Dale Stephenson
2017-09-14  9:00     ` Zdenek Kabelac
2017-09-14  9:37       ` Zdenek Kabelac
2017-09-14 10:52         ` Gionatan Danti
2017-09-14 10:57         ` Gionatan Danti
2017-09-14 11:13           ` Zdenek Kabelac
2017-09-14 14:32             ` Dale Stephenson [this message]
2017-09-14 15:25       ` Dale Stephenson

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=0BE09EDA-1239-4749-A303-44E64C5AE177@mac.com \
    --to=dalestephenson@mac.com \
    --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).