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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
