NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
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?
4 Replies
Does free -m show a memory bottleneck?
My (idle) rn526x shows this
root@NAS:~# free -m total used free shared buffers cached Mem: 3844 2768 1075 19 2 1501 -/+ buffers/cache: 1265 2579 Swap: 1019 5 1014 root@NAS:~#Doesn't seem so:
total used free shared buffers cached Mem: 3845 3336 508 5 4 1282 -/+ buffers/cache: 2049 1795 Swap: 1529 0 1529Five days does seem unusually long, especially compared with the 628X running the same drives. Since the drives aren't reporting errors, I'd be interested in whether the resync is actually being limited by the NAS rather than the disks.
One thing I'd check is the actual resync speed in /proc/mdstat over a few minutes while the backup jobs are running and again when they're stopped. If the speed changes significantly, the workload may be competing with the resync. It may also be worth checking the RAID layout and current array state, since a resync after a particular type of array event can behave differently from a routine maintenance operation.
It's my backup unit. The shares don't even allow SMB access, only RSYNC. The only other task is the daily backups, which are occurring as normal. And none of this has changed except the used space and number of files, which is a very small change WRT the volume size.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
