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, 20224 yr by Superdean56
Updated Issues

Start by running memtest.

2 hours ago, JorgeB said:

Start by running memtest.

It could be a RAM issue?

Yes, most often is.

3 hours ago, JorgeB said:

Yes, most often is.

So far 3 hours in, memtest seems okay

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

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.

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. 

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

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

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.

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?

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

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

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

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.