Parity Issues

[clowncracker]

I just ran a parity check on unRAID and in the 3+ years of using it I've never had issues.  I was hoping someone could help me determine where the issue is and how to correct it.

Edited July 5, 2022 by clowncracker

[itimpi]

We cannot see what lead up to that scenario - you would need to enable the syslog server to get logs that can survive a reboot.    Are any of your drives indicating SMART issues on the Dashboard?

 

Looking at the time it started I assume that was a scheduled check?    We normally recommend that scheduled checks are set to be non-correcting as you do not want a drive that is playing up to corrupt parity.   When you get errors from such a check you try and work out why and check things like the power and SATA cabling that can cause errors.  You then run correcting checks manually when you are reasonably certain you have no outstanding hardware/drive issues.

[clowncracker]

I have the syslog file that can be reviewed.  Disk 9 (which is my newest drive) has 572 UDMA CRC errors, not sure if that is the root cause of the issue.

Do I have any recourse at this point?  Any sort of data validation I can do to look for potentially corrupted data?

 

 

Edited July 5, 2022 by clowncracker

[itimpi]

CRC errors are connection issues normally caused by either the power or SATA cabling.   They normally trigger a retry and as long as that works the system simply continues unaffected. They never reset to 0 so you just want them to stop increasing.

 

To be able to detect corrupted data you need to either be using BTRFS as the file system or be using something like the Dynamix File Integrity plugin so that you have checksums of your files.

[clowncracker]

I just installed the Dynamix File Integrity plugin.  If I do a build & export now, there is nothing to check against right?  Is there anything I can do at this point?

Is the syslog file not helpful for determining the problem?

Edited July 1, 2022 by clowncracker

[trurl]

Go to Main - Array Operation, click History, and post a screenshot

[clowncracker]

[trurl]

Is that the entire History?

 

Syslog only seemed to be logging P corrections, not Q (parity2), though it didn't log all the corrections. But it does make me wonder if Q was completely valid and P just had those (relatively) few sync errors. Have you had unclean shutdown?

[trurl]

Unrelated, but see if you can fix this which is getting logged a lot

Jul  1 04:31:01 crond[2085]: failed parsing crontab for user root: ? * MON-FRI * /usr/local/emhttp/plugins/ca.turbo/scripts/turboSchedule.php disable 840 > /dev/null 2>&1

 

[trurl]

3 hours ago, itimpi said:

Looking at the time it started I assume that was a scheduled check?    We normally recommend that scheduled checks are set to be non-correcting as you do not want a drive that is playing up to corrupt parity.

You didn't specifically comment on this. Was it a scheduled check, and were the scheduled checks set to correct?

[clowncracker]

It was a scheduled check, here is the full history.

Unrelated, but I fixed the cron for that plugin so that error should stop popping up.

[trurl]

36 minutes ago, trurl said:

Have you had unclean shutdown?

Also, have you changed your scheduled checks to be non-correcting now?

[clowncracker]

I changed my scheduled checks to be non-correcting.  I had one unclean shutdown on 6/23.

[trurl]

10 minutes ago, clowncracker said:

one unclean shutdown on 6/23

So the parity check which complete without sync errors on 6/24 was after that?

 

Why the cancelled parity checks in that history?

[clowncracker]

Correct.  The 6/24 parity check was after the unclean shutdown on 6/23.  There were no parity issues at that point.

The 6/25 parity check was started on accident, meant to hit the mover button. The other check on 7/1 (after the 434 errors) was me thinking about starting another parity check after the issues came up but deciding to wait for more info on the forum before I proceeded.

Edited July 1, 2022 by clowncracker

[trurl]

2 hours ago, clowncracker said:

starting another parity check

Do that, make it a non-correcting check. Since you have already corrected parity, it should have zero sync errors this time. Don't reboot, get diagnostics after so we can compare this check with the previous one.

[clowncracker]

@trurl attached are the updated diagnostics.  Parity check finished with 0 errors.

 

Edited July 5, 2022 by clowncracker

[trurl]

Looks good.

[clowncracker]

I appreciate all your help with this @trurl