× NETGEAR will be terminating ReadyCLOUD service by July 1st, 2023. For more details click here.
Orbi WiFi 7 RBE973
Reply

Re: Volume schedule during peak usage

vrspectre
Apprentice

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 when nobody is using it? 

Model: RN51600|ReadyNAS 516 6-Bay Diskless
Message 1 of 6
StephenB
Guru

Re: Volume schedule during peak usage


@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.   

Message 2 of 6
vrspectre
Apprentice

Re: Volume schedule during peak usage

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. 

Message 3 of 6
StephenB
Guru

Re: Volume schedule during peak usage


@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

 

 

 

Message 4 of 6
Sandshark
Sensei

Re: 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.

Message 5 of 6
StephenB
Guru

Re: Volume schedule during peak usage


@Sandshark wrote:

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.

Thx for sharing this.

 


@Sandshark wrote:

 

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.   


That of course makes sense, since the process is running in the background. I agree that the disk I/O is a bigger concern.

 

FWIW, I just let it run on schedule in my 526x, and haven't observed an objectionable performance drop (even with the disk trashing).  My RN202 has two jbod volumes, so the btrfs scrub part is the only thing that actually takes time/resources there.

 


@Sandshark wrote:

 

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.

 I'd rather be able to run the RAID resync and BTRFS scrub independently - even setting aside the resources needed.  They do two very different things.

Message 6 of 6
Top Contributors
Discussion stats
  • 5 replies
  • 1120 views
  • 2 kudos
  • 3 in conversation
Announcements