Re: btrfs-progs 4.4 re-balance of RAID6 is very slow / limited to one cpu core?

[bbrendon@gmail.com]

I ran into some major problems with balancing a raid6 array recently
on 4.4. It wouldn't resume without crashing and yes, it was VERY slow.
In my case, it took 4 days. I found a link to the posting.

http://www.spinics.net/lists/linux-btrfs/msg51159.html


On Wed, Jan 27, 2016 at 8:34 AM, Austin S. Hemmelgarn
<ahferroin7@gmail.com> wrote:
> 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.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html