On Mon, Jan 25, 2016 at 4:34 AM, Christian Rohmann <crohmann@xxxxxxxxxxxxx> wrote: > Hey there Henk, btrfs-enthusiasts, > > > On 01/24/2016 03:30 AM, Henk Slager wrote: >> It might be that just a full balance runs faster, so no filters, you >> could try that. Otherwise I wouldn't know how to speedup, hopefully >> the fs is still usable while balancing. > > Yes the FS is still usable, munin shows just a little increate in iops > and disk latency. The filter should not affect the performance of a > balance at all. I am simply saying to only consider chunks which are not > spread across all disks yet. Finding out a chunks data distribution > should not add any burden on the balancing. > > The balancing is still VERY VERY slow, we still have 93% left to > balance. But since I did not hit any hardware limit (CPU or disk IO) I > am confident to say btrfs-balance is buggy in this regard. CPU single > thread performance will not explode anytime soon. But disks (or SSD) > will still grow in size and so will their potential iops. > > With a 8 - 12 disk array growth I am not doing something crazy that has > never been done before on a storage array either ;-) 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. -- Chris Murphy -- 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
