What I've tried:

1. Replaced SATA power and data cables to parity drive, which was showing ATA errors in syslog. ATA errors no more, but still getting parity sync errors.

2. Ran a correcting parity check - corrected 1M+ errors, but new errors appeared immediately on the next non-correcting check.

3. Reseated all RAM and removed the 7th DIMM - went from 7 DIMMs (asymmetric) to 6 DIMMs in 3 matched pairs. Mobo is Supermicro X10SRi-F.

4. Claude noted the errors are deterministic - same starting sector (8,637,552) with contiguous 8-byte stepping pattern, identical across every parity check regardless of RAM configuration. This reproducibility across reboots and RAM changes ruled out RAM as the cause. No way to verify if this is just an AI hallucination.

5. Claude identified disk5 (TOSHIBA HDWE140 874DK07HF58D, sdw) as suspect - SMART report shows 38 logged ICRC errors, UDMA CRC Error Count of 30, and 57,805 power-on hours. Every other drive on the same mpt2sas_cm1 controller shows 0 UDMA CRC errors, isolating the issue to sdw specifically rather than the controller or cabling.

Current theory: sdw is intermittently returning corrupted data over the SATA interface due to CRC errors, causing deterministic parity mismatches at the same sector region on every check. The drive is also extremely aged at 57,805 hours.

Planned next steps: Use Unbalance to move all data off sdw, unassign it from the array, run a fresh correcting then non-correcting parity check to confirm whether errors clear. If clean, replace sdw with a new drive. If errors persist after sdw is removed, further investigation needed.

Am I missing something?

ptero-diagnostics-20260503-1818.zip

You are using ECC RAM, so unlikely that is the issue, unless there's some other hardware problem. It could be one of the disks, but it's not easy to test, since you basically would need to remove one disk at a time and retest. It's rare, but it has happened before.

https://forums.unraid.net/topic/98510-solved-parity-sync-errors/

Do you see anything else in my diagnostics that could be causing this issue?

Nope, but that can be normal in these cases since it's a hardware problem.

What would you try first?

Since it's unlikely to be the RAM, it's most likely a disk; it could also be a controller. The latter will be easier to test, if you have a spare.

I replaced the disk Claude identified, ran an error-correcting sync, and then a non-correcting sync came back clean.