All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexander 'Leo' Bergolth" <leo@strike.wu.ac.at>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] very slow sequential writes on lvm raid1 (bitmap?)
Date: Mon, 07 Nov 2016 16:58:15 +0100	[thread overview]
Message-ID: <5820A497.80501@strike.wu.ac.at> (raw)
In-Reply-To: <6c916712-d43b-d456-9a4b-f8c801201639@redhat.com>

On 11/07/2016 11:22 AM, Zdenek Kabelac wrote:
> Dne 7.11.2016 v 10:30 Alexander 'Leo' Bergolth napsal(a):
>> I am experiencing a dramatic degradation of the sequential write speed
>> on a raid1 LV that resides on two USB-3 connected harddisks (UAS
>> enabled), compared to parallel access to both drives without raid or
>> compared to MD raid:
>>
>> - parallel sequential writes LVs on both disks: 140 MB/s per disk
>> - sequential write to MD raid1 without bitmap: 140 MB/s
>> - sequential write to MD raid1 with bitmap: 48 MB/s
>> - sequential write to LVM raid1: 17 MB/s !!
>>
>> According to the kernel messages, my 30 GB raid1-test-LV gets equipped
>> with a 61440 bit write-intent bitmap (1 bit per 512 byte data?!) whereas
>> a default MD raid1 bitmap only has 480 bit size. (1 bit per 64 MB).
>> Maybe the dramatic slowdown is caused by this much too fine grained
>> bitmap and its updates, which are random IO?
>>
>> Is there a way to configure the bitmap size?
> 
> Can you please provide some results with  '--regionsize'  changes ?
> While   '64MB' is quite 'huge'  for resync I guess 'the current' default
> picked region size is likely very very small in same cases.

Ah - thanks. Didn't know that --regionsize is also valid for --type raid1.

With --regionsize 64 MB, the bitmap has the same size as the default
bitmap created by mdadmin and write performance is also similar:

*** --regionsize 1M
1048576000 bytes (1,0 GB, 1000 MiB) copied, 63,957 s, 16,4 MB/s
*** --regionsize 2M
1048576000 bytes (1,0 GB, 1000 MiB) copied, 39,1517 s, 26,8 MB/s
*** --regionsize 4M
1048576000 bytes (1,0 GB, 1000 MiB) copied, 32,8275 s, 31,9 MB/s
*** --regionsize 16M
1048576000 bytes (1,0 GB, 1000 MiB) copied, 30,2903 s, 34,6 MB/s
*** --regionsize 32M
1048576000 bytes (1,0 GB, 1000 MiB) copied, 30,1452 s, 34,8 MB/s
*** --regionsize 64M
1048576000 bytes (1,0 GB, 1000 MiB) copied, 21,6208 s, 48,5 MB/s
*** --regionsize 128M
1048576000 bytes (1,0 GB, 1000 MiB) copied, 14,2028 s, 73,8 MB/s
*** --regionsize 256M
1048576000 bytes (1,0 GB, 1000 MiB) copied, 11,6581 s, 89,9 MB/s


Is there a way to change the regionsize for an existing LV?

Cheers,
--leo
-- 
e-mail   ::: Leo.Bergolth (at) wu.ac.at
fax      ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria

  reply	other threads:[~2016-11-07 15:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-07  9:30 [linux-lvm] very slow sequential writes on lvm raid1 (bitmap?) Alexander 'Leo' Bergolth
2016-11-07 10:22 ` Zdenek Kabelac
2016-11-07 15:58   ` Alexander 'Leo' Bergolth [this message]
2016-11-08  9:26     ` Zdenek Kabelac
2016-11-08 15:15       ` Alexander 'Leo' Bergolth
2016-11-11 14:30         ` Brassow Jonathan
2016-11-11 23:23           ` Brassow Jonathan
2016-11-18 10:12         ` Zdenek Kabelac
2016-11-18 11:08           ` Alexander 'Leo' Bergolth
2016-11-26 23:21             ` Alexander 'Leo' Bergolth

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=5820A497.80501@strike.wu.ac.at \
    --to=leo@strike.wu.ac.at \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.