Hello,

 

I recently made the switch from a zfs pool in linux to unraid as I wanted to be able to upgrade my storage. I switched when I did because after a year of leaving my server running I found out you are supposed to run data checks. Well, after a year of not checking, I had loads of errors. I tried every cable trick and nothing helped. I don't know exactly how much data I lost but it was no more than a couple hundred GBs in array of 30TB. So not too catastrophic.

 

I then switched to Unraid, hoping a dedicated OS would help me out. Well, I have been running this array for a little over a month and, as per community suggestions I had seen, the first quarterly Parity Check has started running. I am 70% through and there are a little over 3000 errors. I have seen people saying that anything more than 0 is a worrying amount.

 

I have attached the Diagnostics ZIP file which should have all the information you need.

I am running Unraid V6.12.13.

 

My hardware is:

• Intel i5-13500
• ASRock H610M-HVS
• 64GB (2x32GB) Corsair Vengeance DDR4-3200
• x3 Seagate Exos X18 16TB HDD (A little over a year old)
• x3 Seagate Ironwolf Pro NAS 16TB HDD (A little over a month old)
• Diyeeni 8 port SATA expansion card. PCI-E x1 to SATA 3.0

 

If my interpretation of the smart data is correct then all the hard drives have a large amount of errors. Which is odd to me. I don't feel like its an HDD problem.

 

When switching to unraid I copied across the 30TB of data to 2 of the new drives. Then I added the rest with 1 old and 1 new as the parity. I am running dual parity with 4 data drives. I am yet to run a mem test but my instinct is that it is my cheap (£40) chinese sata expander. I was looking to upgrade to one of those LSI expansion things but I haven't done proper research into what model to grab.

 

If anyone has any advice for me on how to solve this, as it seems to be the same thing that ate away at my Linux ZFS Pool over the year I had it, I would appreciate the help.

mockingjay-diagnostics-20250107-1913.zip

Connection problems on disks 1, 3.

 

Maybe not the cause of parity errors or previous data loss though.

 

12 minutes ago, chitchat9177 said:

I am yet to run a mem test

You shouldn't attempt to run any computer unless you are reasonably confident that memory is working perfectly. Everything goes through RAM, the OS and other executable code, your data, everything. The CPU can't do anything with anything until it is loaded into RAM.

28 minutes ago, trurl said:

Connection problems on disks 1, 3.

Do you mind telling me what information tells you this?

 

29 minutes ago, trurl said:

You shouldn't attempt to run any computer unless you are reasonably confident that memory is working perfectly. Everything goes through RAM, the OS and other executable code, your data, everything. The CPU can't do anything with anything until it is loaded into RAM.

I am very confident there is nothing wrong with the RAM. It's less than a year old and a brand I have been using my for ages. It was just a troubleshooting test I had read people suggesting when the drives seem okay.

logs/syslog

Jan  6 00:00:01 Mockingjay kernel: md: recovery thread: check P Q ...
Jan  6 00:07:34 Mockingjay kernel: ata10.00: exception Emask 0x10 SAct 0xe000 SErr 0x4010000 action 0xe frozen
Jan  6 00:07:34 Mockingjay kernel: ata10.00: irq_stat 0x80400040, connection status changed
Jan  6 00:07:34 Mockingjay kernel: ata10: SError: { PHYRdyChg DevExch }
Jan  6 00:07:34 Mockingjay kernel: ata10.00: failed command: READ FPDMA QUEUED
...
Jan  6 00:20:55 Mockingjay kernel: ata9.00: exception Emask 0x10 SAct 0xa3ffffcf SErr 0x4010000 action 0xe frozen
Jan  6 00:20:55 Mockingjay kernel: ata9.00: irq_stat 0x80400040, connection status changed
Jan  6 00:20:55 Mockingjay kernel: ata9: SError: { PHYRdyChg DevExch }
Jan  6 00:20:55 Mockingjay kernel: ata9.00: failed command: READ FPDMA QUEUED
Jan  6 00:20:55 Mockingjay kernel: ata9.00: cmd 60/80:00:a8:29:fa/00:00:4e:00:00/40 tag 0 ncq dma 65536 in

 

system/lsscsi.txt

[9:0:0:0]    disk    ATA      ST16000NM000J-2T SN04  /dev/sdc   /dev/sg2 
...
[10:0:0:0]   disk    ATA      ST16000NE000-2RW SN03  /dev/sdd   /dev/sg3 

 

smart folder has sdc disk3, sdd disk1. also in system/vars.txt

Does anyone know why the parity completion notifications differs from the summary at the bottom of the array page?

 

 

18 hours ago, trurl said:

logs/syslog

Jan  6 00:00:01 Mockingjay kernel: md: recovery thread: check P Q ...
Jan  6 00:07:34 Mockingjay kernel: ata10.00: exception Emask 0x10 SAct 0xe000 SErr 0x4010000 action 0xe frozen
Jan  6 00:07:34 Mockingjay kernel: ata10.00: irq_stat 0x80400040, connection status changed
Jan  6 00:07:34 Mockingjay kernel: ata10: SError: { PHYRdyChg DevExch }
Jan  6 00:07:34 Mockingjay kernel: ata10.00: failed command: READ FPDMA QUEUED
...
Jan  6 00:20:55 Mockingjay kernel: ata9.00: exception Emask 0x10 SAct 0xa3ffffcf SErr 0x4010000 action 0xe frozen
Jan  6 00:20:55 Mockingjay kernel: ata9.00: irq_stat 0x80400040, connection status changed
Jan  6 00:20:55 Mockingjay kernel: ata9: SError: { PHYRdyChg DevExch }
Jan  6 00:20:55 Mockingjay kernel: ata9.00: failed command: READ FPDMA QUEUED
Jan  6 00:20:55 Mockingjay kernel: ata9.00: cmd 60/80:00:a8:29:fa/00:00:4e:00:00/40 tag 0 ncq dma 65536 in

 

system/lsscsi.txt

[9:0:0:0]    disk    ATA      ST16000NM000J-2T SN04  /dev/sdc   /dev/sg2 
...
[10:0:0:0]   disk    ATA      ST16000NE000-2RW SN03  /dev/sdd   /dev/sg3 

 

smart folder has sdc disk3, sdd disk1. also in system/vars.txt

 

Thank you for the information

9 minutes ago, chitchat9177 said:

Does anyone know why the parity completion notifications differs from the summary at the bottom of the array page?

It's a known issue, should be fixed for v7, the notification is the one that is wrong, would recommend running memtest first, and if nothing is found, run a correcting parity check, then another one to confirm no more errors.

6 minutes ago, JorgeB said:

It's a known issue, should be fixed for v7, the notification is the one that is wrong, would recommend running memtest first, and if nothing is found, run a correcting parity check, then another one to confirm no more errors.

Thanks for the information about the notification.

 

I'll get on and do your recommendations and see if anything is revealed. Thanks.

Fixed:

 

Memory test showed no problems. Ran a correcting parity, then ran a parity check and had even more errors after a day. Then started to run another and had 182 after a couple hours so stopped and bought an LSI 9211-8i.

 

Not only has my speed drastically increased (nearly maxing out the HDDs at 250MB/s each) but my errors are down to 0 for now.

 

 

Partiy check seems to slow to about 150MB/s in the last 10% which is interesting but still way faster than before. 1 day instead of 3 is a big improvement. The big error check was one of the disks not being picked up when I first installed the new card but reseating all the cables fixed that.

49 minutes ago, chitchat9177 said:

Partiy check seems to slow to about 150MB/s in the last 10% which is interesting

Always slows down.

 

It progresses from the outer tracks to the inner tracks. RPM and data density are constant. So, longer outer tracks have more data than shorter inner tracks. So less data per RPM.