I’ve seen “security” running before which was pretty busy and made it not just flash, it was solid on like the time a couple days ago. Also with a 6 disk array in a maximum 8 disk card, it has two data cables plugged into the raid card. Is it likely that all 6 disks are not only flashing lights, but solid on with one bad cable? Perhaps if it’s the raid card or maybe the data plane (maybe I could try plugging it into one of the two other 8 disk sections in the data plane it can handle 24 disks) that they’re plugged into. I’m guessing it was a consistency check by the raid card like Letcher Ross said which I presume wouldn’t show up on top.
Also, with a 3 way stripe raid 10 and 15000 rpm disks, theyre not SSDs but it’s pretty responsive, there’s not a lot of latency for a process to sit on its laurels. Unless the process is sleeping, it’s gonna be difficult to not put up some big cpu percentage numbers. On Sun, Jan 2, 2022 at 11:43 AM Crystal Kolipe <kolip...@exoticsilicon.com> wrote: > 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. > -- -Luke
