On restart my unRaid 7.0.1 went into parity check, unsure if that aligned with the regular parity check or if it was an unclean shutdown, but relatively normal behaviour so thought nothing of it. It's now 10 hours later and it's only 2.3% of the way through (quoting a 200 day estimated finish) and none of my docker services are accessible.

The docker page takes a long time to load, but when it does, it shows the normal expected Dockers on startup are active, however if I try to access them they are clearly not active. I'll either timeout or hit 400 Bad Request. My one VM however is running perfectly fine.

When I check dashboard, at times my CPU will list itself at 100% load and then will also drop down to regular use and RAM usage is still within the normal usage of the system, with only 67% listed as in use currently.

I'm at a loss to figure out the cause and figured a parity check might slow down the starting of services but not somehow make them unusable, especially since unRaid believes that the dockers have started successfully. The abnormal parity check may also be just a symptom of whatever the issue is as opposed to the cause.

dragon-diagnostics-20250605-1834.zip

Go to the BIOS, change the controller from IDE to AHCI, then start a new check and post new diags.

Controller changed to AHCI

dragon-diagnostics-20250605-2210.zip

You are getting continual retries on ata4 that look like cabling and/or power issues.

Jun 5 21:40:17 Dragon kernel: ata4.00: failed command: READ FPDMA QUEUED

Jun 5 21:40:17 Dragon kernel: ata4.00: cmd 60/80:a0:08:aa:aa/00:00:00:00:00/40 tag 20 ncq dma 65536 in

Jun 5 21:40:17 Dragon kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error)

Jun 5 21:40:17 Dragon kernel: ata4.00: status: { DRDY }

Jun 5 21:40:17 Dragon kernel: ata4: hard resetting link

I think this is the parity2 disk?

If you want to check the drive's health you should run the extended SMART test on it.

Thank you, I'm going to get some new SATA data cables today and if that doesn't work will look at the power side (currently all of my PSU power cables are in use).

However when I try to run the short or extended SMART test on parity 2 it completes within minutes and returns "No self-tests have been logged. [To run self-tests, use: smartctl -t]" in the history with "No Errors Logged".

I am able to download a SMART report, but I would expect it's not related to the the extended SMART test I tried to run on it

dragon-smart-20250607-0938.zip

Long test can't be completed in minutes, try a short one.

Thanks, I was able to successfully run both the short and extended test after changing cables, with no errors for the drive.

Currently waiting for the parity check to stabilise its estimate time (currently looking close to previous good parity check estimates), but it looks like it was just a faulty SATA data cable and possibly also a loose SATA power cable.

Parity check ran for normal amount of time but returned 3241331 errors. I would assume this be due to previous write errors against Parity 2 caused by the cabling issue. In terms of ensuring the parity data remain correct, would it be better to just rebuild Parity 2 as opposed to using the parity check to write corrections to the parity?

With so few errors, relatively speaking, a check correct is fine, if there were a lot of them a sync would be faster.