Every parity check (Manual) comes up with sync errors

[jowy_ham]

Previously I won't have any parity check sync errors for months. But lately, after I replaced 1 x HDD (faulty) and 1 x 8087 cable (replaced cable due to UDMA CRC error count). Sync errors have been popping up. Is that a cause for concern ?

 

For example, I did a parity check on :

24-Jan-2022, there were 766 sync errors

31-Jan-2022, there were 272 sync errors

01-Feb-2022, there were 128 sync errors

 

I'm in the progress of my 4th parity checks, and there are still 128 sync errors

 

Can experts please kindly advise on what I should do ? 

 

Attached is the diagnostics ZIP for your reference.

 

By the way, in the event that I need to replace a current HDD (8/10TB) with a higher capacity HDD (14TB), what's the correct procedure ?

Is it use new 14TB HDD to replace either 1 of the parity HDD, then use the replaced parity HDD as normal data HDD

 

 

tower-diagnostics-20220202-2117.zip

[trurl]

Connection problems on disk 4, check connections, both ends, SATA and power, including splitters.

 

Why do you have 50G docker.img? 20G is often more than enough.

 

Even more, why 100G libvirt? I don't think anyone has ever needed more than default 1G for that.

[jowy_ham]

41 minutes ago, trurl said:

Connection problems on disk 4, check connections, both ends, SATA and power, including splitters.

 

Why do you have 50G docker.img? 20G is often more than enough.

 

Even more, why 100G libvirt? I don't think anyone has ever needed more than default 1G for that.

At which log/area did U find that it is disk4 that is give the issue ? so that I may learn how to troubleshoot the issue in the future

 

For issue 2 & 3, how do I fix those "oversized" issue ? Do I have to recreate ?

Edited February 2, 2022 by jowy_ham

[ChatNoir]

4 hours ago, jowy_ham said:

At which log/area did U find that it is disk4 that is give the issue ?

Not a pro on drive connection issues, but your syslog has tons of this :

 

Feb  2 03:09:05 Tower kernel: ata4.00: exception Emask 0x10 SAct 0x3f800000 SErr 0x4090000 action 0xe frozen
Feb  2 03:09:05 Tower kernel: ata4.00: irq_stat 0x00400040, connection status changed
Feb  2 03:09:05 Tower kernel: ata4: SError: { PHYRdyChg 10B8B DevExch }
Feb  2 03:09:05 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED
Feb  2 03:09:05 Tower kernel: ata4.00: cmd 60/00:b8:a0:c6:cb/04:00:87:00:00/40 tag 23 ncq dma 524288 in
Feb  2 03:09:05 Tower kernel:         res 40/00:e8:a0:de:cb/00:00:87:00:00/40 Emask 0x10 (ATA bus error)
Feb  2 03:09:05 Tower kernel: ata4.00: status: { DRDY }
Feb  2 03:09:05 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED
Feb  2 03:09:05 Tower kernel: ata4.00: cmd 60/00:c0:a0:ca:cb/04:00:87:00:00/40 tag 24 ncq dma 524288 in
Feb  2 03:09:05 Tower kernel:         res 40/00:e8:a0:de:cb/00:00:87:00:00/40 Emask 0x10 (ATA bus error)
Feb  2 03:09:05 Tower kernel: ata4.00: status: { DRDY }
Feb  2 03:09:05 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED
Feb  2 03:09:05 Tower kernel: ata4.00: cmd 60/00:c8:a0:ce:cb/04:00:87:00:00/40 tag 25 ncq dma 524288 in
Feb  2 03:09:05 Tower kernel:         res 40/00:e8:a0:de:cb/00:00:87:00:00/40 Emask 0x10 (ATA bus error)
Feb  2 03:09:05 Tower kernel: ata4.00: status: { DRDY }
Feb  2 03:09:05 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED
Feb  2 03:09:05 Tower kernel: ata4.00: cmd 60/00:d0:a0:d2:cb/04:00:87:00:00/40 tag 26 ncq dma 524288 in
Feb  2 03:09:05 Tower kernel:         res 40/00:e8:a0:de:cb/00:00:87:00:00/40 Emask 0x10 (ATA bus error)
Feb  2 03:09:05 Tower kernel: ata4.00: status: { DRDY }
Feb  2 03:09:05 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED
Feb  2 03:09:05 Tower kernel: ata4.00: cmd 60/00:d8:a0:d6:cb/04:00:87:00:00/40 tag 27 ncq dma 524288 in
Feb  2 03:09:05 Tower kernel:         res 40/00:e8:a0:de:cb/00:00:87:00:00/40 Emask 0x10 (ATA bus error)
Feb  2 03:09:05 Tower kernel: ata4.00: status: { DRDY }
Feb  2 03:09:05 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED
Feb  2 03:09:05 Tower kernel: ata4.00: cmd 60/00:e0:a0:da:cb/04:00:87:00:00/40 tag 28 ncq dma 524288 in
Feb  2 03:09:05 Tower kernel:         res 40/00:e8:a0:de:cb/00:00:87:00:00/40 Emask 0x10 (ATA bus error)
Feb  2 03:09:05 Tower kernel: ata4.00: status: { DRDY }
Feb  2 03:09:05 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED
Feb  2 03:09:05 Tower kernel: ata4.00: cmd 60/00:e8:a0:de:cb/04:00:87:00:00/40 tag 29 ncq dma 524288 in
Feb  2 03:09:05 Tower kernel:         res 40/00:e8:a0:de:cb/00:00:87:00:00/40 Emask 0x10 (ATA bus error)
Feb  2 03:09:05 Tower kernel: ata4.00: status: { DRDY }
Feb  2 03:09:05 Tower kernel: ata4: hard resetting link
Feb  2 03:09:11 Tower kernel: ata4: link is slow to respond, please be patient (ready=0)
Feb  2 03:09:15 Tower kernel: ata4: COMRESET failed (errno=-16)
Feb  2 03:09:15 Tower kernel: ata4: hard resetting link
Feb  2 03:09:17 Tower kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Feb  2 03:09:17 Tower kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.SPT3._GTF.DSSP], AE_NOT_FOUND (20200925/psargs-330)
Feb  2 03:09:17 Tower kernel: ACPI Error: Aborting method \_SB.PCI0.SAT0.SPT3._GTF due to previous error (AE_NOT_FOUND) (20200925/psparse-529)
Feb  2 03:09:17 Tower kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.SPT3._GTF.DSSP], AE_NOT_FOUND (20200925/psargs-330)
Feb  2 03:09:17 Tower kernel: ACPI Error: Aborting method \_SB.PCI0.SAT0.SPT3._GTF due to previous error (AE_NOT_FOUND) (20200925/psparse-529)
Feb  2 03:09:17 Tower kernel: ata4.00: configured for UDMA/33
Feb  2 03:09:17 Tower kernel: ata4: EH complete

Seems to fit trurl's comment.

[trurl]

27 minutes ago, ChatNoir said:

syslog has tons of this :

and earlier in syslog you can see what disk that corresponds to:

Jan 30 21:23:54 Tower kernel: ata4.00: ATA-9: ST8000AS0002-1NA17Z,             Z840YTGS, RT17, max UDMA/133

 

[jowy_ham]

Thanks to all.

 

The issue has been resolved. Re-do both the SATA and power cables