Volume schedule during peak usage

As best as I can tell, the MDADM re-sync is triggered by the equivalent of echo repair > /sys/block/mdXXX/md/sync_action (where XXX is the array designator, 127 for most single-array NAS).  You should be able to pause it with echo 0 >/proc/sys/dev/raid/speed_limit_max. or slow it way down with something between the default of 200000 and 0.  Other methods I know of will cause it to start from scratch when re-started, not resume where it left off.

I have long complained that Netgear is needlessly stressing the drives and taking up valuable assets by doing both btrfs scrub and mdadm re-sync simultaneously.  My personal experience by doing each manually shows the total time for doing them separately is about the same as concurrently since each slows the other when they are concurrent.  They should be automatically sequential or two separate scheduled operations.  My only guess is that the only way to easily show the total progress is to actually only look at one of the processes as it is affected by the other.  In other words, lazy programming.

While the processes do take 100% of the CPU on a system like a 516, that's only when others aren't asking for time.  It's a bigger deal on less powerful NAS.  And the drive I/O is a huge problem with an EDA500 on any NAS.  When I had a 516 with two EDA500's, a scrub could backlog other processes needing access to the array in one of the EDA's that the whole NAS nearly locked up and the sync/scrub slowed to such a crawl (having already been slow with the eSATA port expansion interface), that I never even found out if it would ever come out of it.  I ultimately just did each manually via SSH, though I suppose I could have created a CRON process to do it periodically.  I moved to a rack-mount NAS instead.