Sometimes when things are really slow or even hung up with Btrfs, yet there's no blocked task being reported, a dev has asked for sysrq+t, so that might also be something to issue while the slow balance is happening, and then dmesg to grab the result. The thing is, I have no idea how to read the output, but maybe if it gets posted up somewhere we can figure it out. I mean, obviously this is a bug, it shouldn't take two weeks or more to balance a raid6 volume. I'd like to think this would have been caught much sooner in regression testing before it'd be released, so it makes me wonder if this is an edge case related to hardware, kernel build, or more likely some state of the affected file systems that the test file systems aren't in. It might be more helpful to sort through xfstests that call balance and raid56, and see if there's something that's just not being tested, but applies to the actual filesystems involved; rather than trying to decipher kernel output. *shrug* 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
