On 02/01/2016 09:52 PM, Chris Murphy wrote: >> Would some sort of stracing or profiling of the process help to narrow >> > down where the time is currently spent and why the balancing is only >> > running single-threaded? > This can't be straced. Someone a lot more knowledgeable than I am > might figure out where all the waits are with just a sysrq + t, if it > is a hold up in say parity computations. Otherwise perf which is a > rabbit hole but perf top is kinda cool to watch. That might give you > an idea where most of the cpu cycles are going if you can isolate the > workload to just the balance. Otherwise you may end up with noisy > data.
My balance run is now working away since 19th of January: "885 out of about 3492 chunks balanced (996 considered), 75% left" So this will take several more WEEKS to finish. Is there really nothing anyone here wants me to do or analyze to help finding the root cause of this? I mean with this kind of performance there is no way a RAID6 can be used in production. Not because the code is not stable or functioning, but because regular maintenance like replacing a drive or growing an array takes WEEKS in which another maintenance procedure could be necessary or, much worse, another drive might have failed. What I'm saying is: Such a slow RAID6 balance renders the redundancy unusable because drives might fail quicker than the potential rebuild (read "balance"). Regards Christian -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
