On Sun, Jan 02, 2022 at 11:09:40AM -0600, Luke Small wrote: > And if there was a super busy disk program running which would make a 2x3 > RAID10 array of 15000 RPM disks busy running on OpenBSD, I presume it would > be without fail taking up more than 1 percent cpu time, which nothing other > than top was.
Then you 'presume' incorrectly. Try running two dd processes concurrently, one that reads data from the start of a disk, (or in your case disk array), and one that reads data from near the end of the disk, (or array), using the raw character devices. I see <1% cpu usage for both dd processes testing on my current workstation. Think about why this might be happening. Sure, if you have a single process reading data from disk such that the disk is hitting it's maximum data transfer rate, it's probably reasonable to expect that the host CPU is going to be doing something with that data and the reading process will show more than 1% CPU usage in 'top'. However, your 'server' may well have more than one process accessing disk at the same time, reading from all over the media. To put it in very simple terms: the led that flashes on and off to show disk activity, will also be on whilst the heads are seeking across the disk. So if it's going from the first cylinder to the last and back again repeatedly, most of that time will not be spent actually writing data to the SATA bus or wherever else the disk is connected, so the flow of data to the CPU will be minimal, but the led will still be on. Quite possibly a particuar pattern of reads and writes caused the disk to thrash and therefore data throughput to fall. Or maybe one of the disks in the array was thermal re-calibrating itself. Or maybe your 'server' has an unreliable data cable somewhere. I'm not seeing anything that suggests that it's a software issue with OpenBSD.
