HELP : PARITY CHECK FINDING over 200,000 ERRORS. What does it mean?

[Superdean56]

Please see below, newer comments!

I now have over 200,000 errors!

 

--------------------------------------------------------------------------------------------------------------------

Hello Everyone,

I run my parity backup on the first of every month, last month I had 80 errors. I re-ran the backup and it finished with zero errors.

Now today, my parity backup ran and completed and I now have 1344 errors.

I ran SMART on all disks and they all seem perfectly fine, no issues

What does this mean? Thank you in advance

 

trinity-diagnostics-20211201-2028.zip

Edited January 2, 2022 by Superdean56
Updated Issues

[JorgeB]

Start by running memtest.

[Superdean56]

2 hours ago, JorgeB said:

Start by running memtest.

It could be a RAM issue?

[JorgeB]

Yes, most often is.

[Superdean56]

3 hours ago, JorgeB said:

Yes, most often is.

So far 3 hours in, memtest seems okay

[JorgeB]

If no errors are found during memtest run a couple o consecutive parity checks and post new diags, all without rebooting.

[trurl]

15 hours ago, Superdean56 said:

I run my parity backup on the first of every month

Why are you calling it a "backup"? It isn't.

[Superdean56]

52 minutes ago, trurl said:

Why are you calling it a "backup"? It isn't.

Yes, you are right, it’s not a backup. I just think of it that way. 

[trurl]

17 hours ago, Superdean56 said:

Yes, you are right, it’s not a backup. I just think of it that way. 

Thinking of things incorrectly can lead to mistakes

[Superdean56]

So one month later, 

 

I re-ran my sync with the "fix errors" unchecked.

It is currently syncing and I have over 300,000 errors detected so far.

I did an extended SMART test on every disk I have, and all come back with zero errors.

 

 

Can someone please explain this to me?

trinity-diagnostics-20220101-1249.zip

[Squid]

Dec 25 18:07:48 Trinity kernel: ata2.00: exception Emask 0x50 SAct 0x80808001 SErr 0x4090800 action 0xe frozen
Dec 25 18:07:48 Trinity kernel: ata2.00: irq_stat 0x00400040, connection status changed
Dec 25 18:07:48 Trinity kernel: ata2: SError: { HostInt PHYRdyChg 10B8B DevExch }
Dec 25 18:07:48 Trinity kernel: ata2.00: failed command: WRITE FPDMA QUEUED

 

Probably because of this.  Continual disconnects on the parity drive.  Reseat the cabling.  Also be aware that since the parity drive is a WD that if you're using a locking Sata Cable, it makes terrible connection unless the cable also has the internal "bump" that non-locking cables have (and many locking cables do not have them).

 

Reseat the cabling (both ends) to the drive without disturbing any of the other cables.

[Superdean56]

Thank you for responding!

 

funny thing is, last month I changed the cable to the parity drive. But you are right I do have a WD drive and the locking cables connected to it

 

so should I put a cable that does not have a locking clip? Just on the parity? Or all of them?

[Squid]

WD changed their shroud on the drives a number of years ago with the net result that only sata cables which are actually made to spec will work properly.  (And many / most of the locking cables are not to spec, whereas every non-locking cable is made to spec).  You're looking for a little internal "bump" inside the connector.  All non-locking have them and many / most locking do not

[Superdean56]

I see..

i changed a locking cable…with a locking cable

 looks like I will be ordering a new set of sata cables today

 

thank you! I will report back once I install new cables and run a parity backup

[Superdean56]

So I found some SATA cables without the locking clips. I changed them.
I even swapped the parity's SATA port with another HDD port on the motherboard

I re-ran the parity check and 2 hours in I already had over 120,000 errors detected

 

Someone, please help

trinity-diagnostics-20220101-1920.zip

[JorgeB]

6 hours ago, Superdean56 said:

I re-ran the parity check and 2 hours in I already had over 120,000 errors detected

That's expected, since previous one was non correct.