Re: Disk I/O slowness

[Casey Deccio <casey@deccio.net>]

> On Jul 29, 2026, at 10:23 PM, David Christensen <dpchrist@holgerdanske.com> wrote:
> 
> That looks like a nice motherboard:
> 
> https://www.supermicro.com/en/products/motherboard/X12DPi-N6

Thanks :)

> 
>>> Have you disabled Intel PCH RAID in Setup -- e.g. so that the motherboard disk interface ports appear as non-RAID ports (SATA/SAS)?
>> No, I haven't tried that.
> 
> 
> I expect Intel PCH RAID is turned off, or you would not see all three disks.  But, it would be good to double check.

I was surprised to see the three disks also because I assumed it was a hardware RAID.  But apparently Intel's PCH RAID is a software RAID solution from everything I've read, which explains why mdadm is involved and /dev/sd{a,b,c} show up.

> 
>>> How are the disk drives connected to the motherboard?  What is the speed rating of the cables?  Do the cables have locking connectors?  If you are using backplanes/ racks, what is their speed rating?
>> Thanks.  These are all good questions.  I don't have the cable specs or speed ratings on hand (and won't be able to check them for a few days, unfortunately), but they are the cables that came with the motherboard.  
> 
> 
> The motherboard has "14 SATA3 (6 Gbps)" ports and I expect the included cables will match.  I just wanted to make sure that you were not using leftover cables that could be 3 Gbps or 1.5 Gbps (been there, done that, hated it).
> 
> 
> For single SATA cables, I do prefer locking cables -- to prevent accidental disconnects when I am working inside the case.  These cables are also marked "6 Gbps", so I can verify in the future:
> 
> https://www.cablematters.com/pc-187-156-3-pack-straight-60-gbps-sata-iii-cable.aspx
> 
> https://www.cablematters.com/pc-188-156-cable-matters-3-pack-90-degree-right-angle-60-gbps-sata-iii-cable-18-inches.aspx

Thanks for the helpful information.  I'll double check when I can get a the box, but I'm pretty sure the cables are securely seated -- if not locked -- and that the rates are sufficient.

> 
>> In the mean time, I'll try some of the other tests that you (and others) have kindly suggested.
>> As a point of reference, however, I built another machine with the same drives and cables (different motherboard), and I haven't experienced these issues.
> 
> 
> If that motherboard is more recent than Debian Stable, the included Linux kernel might not support the C621A chipset and/or other chips on the board.  Please check if the Linux kernel in Debian 13.6 has support for the Intel C621A chipset.  Also check if there are bug reports for that combination.  If support is lacking, or if there are issues, you might need a newer kernel from backports or you might need to run Testing.

Since it's a software RAID, I wonder if this might be the issue.  I'll check the driver support to see what is in the kernel and also if there are proprietary drivers that Intel provides.

> Does dmesg(1) report any error messages during transfers?

Not that I can see.

> 
> 
>>> Have you run SMART long tests on each of the three disk drives in the RAID5?  If not, please do so now.  Please post the extended reports from the top through and including the end of the section "SMART Attributes Data Structure revision number: ...".
>> I've started the SMART long tests on the three drives in the RAID5.  It will take a few hours to run, so I'll report back.
> 
> 
> Okay.

Still working on it, apparently.

> 
>>> How are you transferring files?  Please post your console session.
>> From a different machine:
>> $ sudo rsync -av /home/someuser root@newmachine:/home/
> 
> 
> Rather than timing sync(1) commands on the destination machine, add the --progress option to rsync(1) on the source machine.  Alternatively, add the --verbose option.  Understand that rsync(1) is doing a lot of work behind the scenes and that network traffic can slow down, speed up, pause, etc., over the course of a transfer.

Thanks.  I think that's what "-v" is doing?  The transfers look good, as far as I can tell.  They might be a bit slower than I would expect, but transferring nonetheless.  The problems I have observed have seemed to be more with the I/O while the transfer is going than with the transfer itself, though there is probably more that I haven't uncovered.

Thanks,
Casey