Re: Disk I/O slowness

> On Jul 29, 2026, at 10:23=E2=80=AFPM, David Christensen =
<[email protected]> wrote:
>=20
> That looks like a nice motherboard:
>=20
> https://www.supermicro.com/en/products/motherboard/X12DPi-N6

Thanks :)

>=20
>>> 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.
>=20
>=20
> 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.

>=20
>>> 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. =20
>=20
>=20
> 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).
>=20
>=20
> 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:
>=20
> =
https://www.cablematters.com/pc-187-156-3-pack-straight-60-gbps-sata-iii-c=
able.aspx
>=20
> =
https://www.cablematters.com/pc-188-156-cable-matters-3-pack-90-degree-rig=
ht-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.

>=20
>> 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.
>=20
>=20
> 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.

>=20
>=20
>>> 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.
>=20
>=20
> Okay.

Still working on it, apparently.

>=20
>>> How are you transferring files?  Please post your console session.
>> =46rom a different machine:
>> $ sudo rsync -av /home/someuser root@newmachine:/home/
>=20
>=20
> 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=