NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
6.6.1 Scrub Hammers CPU
And when I say hammers, I mean it runs with -1 prio and causes 6-8 kernel worker threads each vying to consume 100% of CPU. So rabid is this consumption that all other background processes, including...
In the case of PLEX and DVBLink it's definitely the transcoding that was most affected. Recordings and other operations seemed ok.
Time Machine (really the AFP file service) would get so starved for cycles that my backup would corrupt and get flagged to be replaced (as TM is want to do) whenever it attempted to run during a scrub.
I fully appreciate the de ription of the scrub processes you present here, but I can tell you that until I forced them into idle with ionice I was having exactly the problems described. And once having done it the behaviors stopped.
I was rather hope to let the scrub finish, since this value has never been scrubbed fully, and it's 5 days in now at about 55%. But I'm happy to restart the process to compare the ioprio on the breads as reported and detail/verify the outcome of the tweaks. Been through a few iterations during this run. But I am in a state now where things are humming along nicely, even if the scrub is taking a while -- which is fine by me.
The affect on the other processes (whether it's CPU, IO, or a combination of both) is real and extremely annoying, however. So something does need adjustment here.
I do observed on Fedora that btrfs scrub behaves as described on the btrfs wiki and your description. The base process is in ioprio B4, as well as one of the threads, the thread doing the effective IO is in idle. Course on this system effective CPU utilization is under 40% (four threads) and iowait is almost nil. Debian is of course quite different in how kernel threads operate, but this is what I see on fedora.
I'll restart the scrub on the NAS later tonight and see what I see there to compare. Not totally apples and apples, but I think it's odd how btrfs stopped getting in the way of other services until it was ionice'd directly.
I'll report back once I've had a chance to observe it again without manual adjustments.
Time Machine (really the AFP file service) would get so starved for cycles that my backup would corrupt and get flagged to be replaced (as TM is want to do) whenever it attempted to run during a scrub.
I fully appreciate the de ription of the scrub processes you present here, but I can tell you that until I forced them into idle with ionice I was having exactly the problems described. And once having done it the behaviors stopped.
I was rather hope to let the scrub finish, since this value has never been scrubbed fully, and it's 5 days in now at about 55%. But I'm happy to restart the process to compare the ioprio on the breads as reported and detail/verify the outcome of the tweaks. Been through a few iterations during this run. But I am in a state now where things are humming along nicely, even if the scrub is taking a while -- which is fine by me.
The affect on the other processes (whether it's CPU, IO, or a combination of both) is real and extremely annoying, however. So something does need adjustment here.
I do observed on Fedora that btrfs scrub behaves as described on the btrfs wiki and your description. The base process is in ioprio B4, as well as one of the threads, the thread doing the effective IO is in idle. Course on this system effective CPU utilization is under 40% (four threads) and iowait is almost nil. Debian is of course quite different in how kernel threads operate, but this is what I see on fedora.
I'll restart the scrub on the NAS later tonight and see what I see there to compare. Not totally apples and apples, but I think it's odd how btrfs stopped getting in the way of other services until it was ionice'd directly.
I'll report back once I've had a chance to observe it again without manual adjustments.
It's worth noting that the resources consumed by btrfs scrub can vary widely depending on the files it's scrubbing at the time. Very fragmented files will result in a lot more I/O wait time, and more CPU consumption. Also, a ReadyNAS volume scrub also includes a MD RAID scrub, which adds to the I/O load. MD is generally pretty good at yielding to other I/O consumers, but it's still a minimum 30MB/sec used for that plus the CPU usage for parity calculation.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
