From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Christian Rohmann <crohmann@netcologne.de>,
Chris Murphy <lists@colorremedies.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs-progs 4.4 re-balance of RAID6 is very slow / limited to one cpu core?
Date: Wed, 27 Jan 2016 11:34:22 -0500 [thread overview]
Message-ID: <56A8F18E.3070400@gmail.com> (raw)
In-Reply-To: <56A88452.6020306@netcologne.de>
On 2016-01-27 03:48, Christian Rohmann wrote:
>
>
> On 01/26/2016 09:20 PM, Chris Murphy wrote:
>> nyway,
>> it seems reasonable to try a balance without the filters to see if
>> that's a factor, because those filters are brand new in btrfs-progs
>> 4.4. Granted, I'd expect they've been tested by upstream developers,
>> but I don't know if there's an fstest for balance with these specific
>> filters yet.
>
> I have another box with 8 disks RAID6 on which I simply did a balance
> with no newly added drives. Same issue ... VERY slow running balance
> with IO nowhere near 100% utilization and many many days of runtime to
> finish.
Hmm, I did some automated testing in a couple of VM's last night, and I
have to agree, this _really_ needs to get optimized. Using the same
data-set on otherwise identical VM's, I saw an average 28x slowdown
(best case was 16x, worst was almost 100x) for balancing a RAID6 set
versus a RAID1 set. While the parity computations add to the time,
there is absolutely no way that just that can explain why this is taking
so long. The closest comparison using MD or DM RAID is probably a full
verification of the array, and the greatest difference there that I've
seen is around 10x.
next prev parent reply other threads:[~2016-01-27 16:34 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-22 13:38 btrfs-progs 4.4 re-balance of RAID6 is very slow / limited to one cpu core? Christian Rohmann
2016-01-22 14:51 ` Duncan
2016-01-24 2:30 ` Henk Slager
2016-01-25 11:34 ` Christian Rohmann
2016-01-25 22:13 ` Chris Murphy
[not found] ` <CAKZK7uxdX9UBPOKButtPjqBOdVUfHdRTimP+W34fkz1h9P+wHg@mail.gmail.com>
2016-01-26 0:44 ` Fwd: " Justin Brown
2016-01-26 5:17 ` Chris Murphy
2016-01-26 6:14 ` Chris Murphy
2016-01-26 8:54 ` Christian Rohmann
2016-01-26 19:26 ` Chris Murphy
2016-01-26 19:27 ` Chris Murphy
2016-01-26 19:57 ` Austin S. Hemmelgarn
2016-01-26 20:20 ` Chris Murphy
2016-01-27 8:48 ` Christian Rohmann
2016-01-27 16:34 ` Austin S. Hemmelgarn [this message]
2016-01-27 20:58 ` bbrendon
2016-01-27 21:53 ` Chris Murphy
2016-01-28 12:27 ` Austin S. Hemmelgarn
2016-02-01 14:10 ` Christian Rohmann
2016-02-01 20:52 ` Chris Murphy
2016-02-09 13:48 ` Christian Rohmann
2016-02-09 16:46 ` Marc MERLIN
2016-02-09 21:46 ` Chris Murphy
2016-02-10 2:23 ` Chris Murphy
2016-02-10 2:36 ` Chris Murphy
2016-02-10 13:19 ` Christian Rohmann
2016-02-10 19:16 ` Chris Murphy
2016-02-10 19:38 ` Chris Murphy
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=56A8F18E.3070400@gmail.com \
--to=ahferroin7@gmail.com \
--cc=crohmann@netcologne.de \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.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.