All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Murphy <lists@colorremedies.com>
To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
Cc: Chris Murphy <lists@colorremedies.com>,
	Christian Rohmann <crohmann@netcologne.de>,
	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: Tue, 26 Jan 2016 13:20:25 -0700	[thread overview]
Message-ID: <CAJCQCtTMEHcc1CnuHqS=g23tsirQv3S9cmDcHaK0WXyQrRds1w@mail.gmail.com> (raw)
In-Reply-To: <56A7CF97.6030408@gmail.com>

On Tue, Jan 26, 2016 at 12:57 PM, Austin S. Hemmelgarn
<ahferroin7@gmail.com> wrote:
> On 2016-01-26 14:26, Chris Murphy wrote:
>>
>> On Tue, Jan 26, 2016 at 1:54 AM, Christian Rohmann
>> <crohmann@netcologne.de> wrote:
>>>
>>> Hey Chris and all,
>>>
>>> On 01/25/2016 11:13 PM, Chris Murphy wrote:
>>>>
>>>> Does anyone suspect a kernel regression here? I wonder if its worth it
>>>> to suggest testing the current version of all fairly recent kernels:
>>>> 4.5.rc1, 4.4, 4.3.4, 4.2.8, 4.1.16? I think going farther back to
>>>> 3.18.x isn't worth it since that's before the major work since raid56
>>>> was added. Quite a while ago I've done a raid56 rebuild and balance
>>>> that was pretty fast but it was only a 4 or 5 device test.
>>>
>>>
>>> Problem is that this balance did not work before going to 4.4 kernel,
>>> it's was simply crashing after about an hour or two of runtime.
>>>
>>> Currently I am using 4.4 kernel + btrfs-progs, so apart from 4.5rc1 I
>>> can not get any more bleeding edge.
>>>
>>> 4.5 I am happy to try, but not RC1 as there are already some bugs
>>> popping up regarding the BTRFS changes.
>>>
>>>
>>> On 01/26/2016 07:14 AM, Chris Murphy wrote:
>>>>
>>>> Christian, what are you getting for 'iotop -d3 -o' or 'iostat -d3'. Is
>>>> it consistent or is it fluctuating all over the place? What sort of
>>>> eyeball avg/min/max are you getting?
>>>
>>>
>>> "1672.81 K/s 1672.81 K/s  0.00 %  6.99 % btrfs balance start -dstripes
>>> 1..11 -mstripes 1..11 "
>>>
>>> but it's jumping up to 25MB/s for a few polls, but most of the time it's
>>> at 1.3 to 1.7 MB/s
>>
>>
>>
>> That is really slow. The fact you can't balance without crashing prior
>> to a 4.4 kernel makes me suspicious about the file system state. What
>> about reading and writing files? What's the performance in that case?
>> Is it just the balance that's this slow? Do you have the call traces
>> for older kernel crashes with balance? What btrfs-progs was used to
>> create the raid6 volume?
>>
>> Maybe the slowness is due to the -dstripes -mstripes filter. That's
>> relatively new. And I didn't try that. And I also don't really
>> understand the values you picked either. Seems to me if you've added
>> four drives relatively recently, there won't be many chunks using
>> 12-strip stripes, most of them will be 8-strip stripes. So I don't
>> really know what you're limiting.
>>
> The filters he used are telling balance to re-stripe anything spanning less
> than 12 devices.  So, in essence, it's only going to re-stripe the chunks
> from before the fourth disk was added.

Which is most of what's on the volume unless the 4 disks were added
and used for a while, but I can't tell what the time frame is. Anyway,
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.



-- 
Chris Murphy

  reply	other threads:[~2016-01-26 20:20 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 [this message]
2016-01-27  8:48                       ` Christian Rohmann
2016-01-27 16:34                         ` Austin S. Hemmelgarn
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='CAJCQCtTMEHcc1CnuHqS=g23tsirQv3S9cmDcHaK0WXyQrRds1w@mail.gmail.com' \
    --to=lists@colorremedies.com \
    --cc=ahferroin7@gmail.com \
    --cc=crohmann@netcologne.de \
    --cc=linux-btrfs@vger.kernel.org \
    /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.