Hmm... That's interesting. Is there a CPU usage threshold before the filer becomes "Busy"? Is it 60%, 70% or what?
I have a firm and definitive answer:
It depends.
Seriously, there are four main resources that a filer can run out of, and sysstat(1) reports on all four. They are:
- CPU - network bandwidth - disk bandwidth - caching memory
A filer can perform surprisingly well at 90%+ CPU utilization if the other resources aren't bottlenecked. Our kernel does a pretty good job of avoiding queuing delays and really does seem to operate pretty well even at full utilization.
On the other hand, the performance might be unacceptably poor at 40% CPU utilization if the cache age is low, and the disk bandwidth has reached it's limit.
Of course, with the CPU, it's easy to see how much is left, because it is reported as a percentage. There's no simple solution for figuring out how much disk bandwidth is left, because the disk subsystem can be bottlenecked on raw disk bandwidth, on disk head seeks, or even on the SCSI or Fibre Channel connection. And of course, the bottleneck depends in part on the access patterns. Sequential reads from large files is relatively easy, because the blocks will be near each other on disk and seeking will be minimized. Random reads from files throughout the file system will generate lots of seeks that will really slow things down.
The original question was in the context of a disk scrub. This generates both disk I/O, which can contribute to a disk bottleneck, and CPU to look at the data, which can contribute to a CPU bottleneck.
Where the bottleneck will actually turn out to be depends on lots of things: How many disks? how many SCSIs (or Fibre Channels)? What's the disk access pattern from users?
I know that I haven't answered your question, but hopefully I've shed some light on why it's a hard question. :-)
Dave