Do not scrub and resync simultaneously
On models with lower power CPUs (100 series for sure) or with an EDA500 attached (even on a 516), a scrub can completely, or at least nearly, lock up the NAS when runing a manual or scheduled scrub. On the 100 series, the CPU usage hits 100%, and this appears to make readynasd have problems and it's CPU usage to climb (which is when the total lockups occur). On a system with an EDA500, the eSATA channel is overwhelmed, and this can also cause readynasd to reach a high CPU use.
This is very clearly caused because a "scrub" via the GUI is both a BRTFS scrub and an MDADM re-sync simultaneously. If one goes into SSH and cancels the scrub, allowing the re-sync to complete, and then manually resumes the btrfs scrub via SSH (so no re-sync), then this problem does not occur.
While perhaps not totally simple to implement in the GUI, it is very clear that these should be sequential processes, not concurrent ones.
I recognize both the 100 series NAS and EDA500 are discontinued products, but you have an obligation to your purchasers to fix a problem that has been present since well before they were discontinued. I doubt seriously that doing this will substantially increase the time required for a scrub, and it will definatly decrease drive thrashng and it's negative effect on drive life.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.