Resync part of scheduled scrub excessively long
Previous scheduled scrubs on my backup NAS have taken 5 days. The BTRFS portion of the currently active scrub task took 3 days, but I don't know if that's typical -- I don't typically look. But what is definitely atypical is that the MDADM re-sync part has been running for 5 days and is only 454% complete. watch cat /proc/mdstat says it has more than a week to go, and that's not including any slow-downs caused by the backup tasks. I've tried bumping up dev.raid.speed_limit_max and dev.raid.speed_limit_min, but that seems to do nothing in the short term and then they get set back to the defaults quickly by the OS. But I never had to do that before, anyway. Drives are showing no errors, so that doesn't seem to be the issue. The kworker tasks are all running at around 60-65% of CPU, so there is no throughput issue I can see (not that that should have changed, either). It is interesting that my primary (a 628X) takes only 3 days for the same amount of data on 8x drives in RAID6 where my backup (a 528X) takes 5 days with only 6x of the same drives in RAID5, so CPU resources or RAM do seem to be a factor to an extent. I've previously had large, highly fragmented files cause a very long BTRFS scrub, but AFAIK, the data content shouldn't matter for the re-sync -- it resyncs all sectors regardless of content. I'm going to let this one complete regardless of how long it takes, but what else can I try to speed it up or at least get the next one back to a normal duration?
