NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Volume schedule during peak usage
Running OS 6.10.1. My scrub runs 3 times a year and it takes about a week to finish. Is it possible to schedule it so that the scrub uses less CPU during peak usage and runs full bore at night w...
vrspectre wrote:
Running OS 6.10.1.
My scrub runs 3 times a year and it takes about a week to finish. Is it possible to schedule it so that the scrub uses less CPU during peak usage and runs full bore at night when nobody is using it?
It already is running at a background priority. FWIW, I believe the performance impact is largely due to the continuous disk I/O. I don't think CPU would be a major factor on an RN516 (which is what I think you have???).
It is possible to run the commands via ssh. There is a way to pause/resume the BTRFS scrub. Pausing mdadm checkarray is supposed to be possible, but I've never tried it.
One of the apps I have has a CPU usage which shows 100% cpu being used. I supposed I/O is probably also a bottle neck. basically i just want it to run at night and pause during the day.
Do you know how i might pause it and resume it? would love to schedule it.
vrspectre wrote:
Do you know how i might pause it and resume it? would love to schedule it.
I don't know exactly what command is being used for the mdadm piece, and that would matter for this. mdgm might know.
For the btrfs piece of it, you'd enter
# btrfs scrub cancel /path
to pause, and then later on use
# btrfs scrub resume /path
to resume it. The status is saved in a file, and it will pick up from where it left off.
You can see the status using
# btrfs scrub status -d /path
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.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
