> On Jul 29, 2026, at 10:23 PM, David Christensen <[email protected]>
> 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
