My unraid box appears to be having issues recently bu tI can't see an obvious reason why. The disks are all showing as ok with 0 errors but each time I do a parity check I get ~800000 errors that clearly aren't being corrected (it's ticked to correct when running the parity check).

 

I'm also seeing issues when accessing from a windows machine via smb with strange lock up and what looks like smb streams that are hanging when viewing from the console.

 

For instance I try to browse a directory contents from Windows and it just hangs the explorer window. If I try to browse the same directory by sshing into my unraid box I can list the directory contents without any issue.

 

How can I dig further to find out what or where the issue?

Post some diagnostics, my first thought is a hardware issue given the parity check....

Diags attached.

downloadbox-diagnostics-20161202-1330.zip

You are having issues with the SAS2LP, since the logs only show issues on 4 of the 7 connected disks you can may want to start by checking the mini SAS cables.

Which log highlights this? It was working fine and seems like the issues started since upgrading to 6.2.4 but I couldn't say for absolute certainty that the dates match.

ata8.00: exception Emask 0x0 SAct 0x2 SErr 0x0 action 0x6 frozen
Nov 29 15:50:40 downloadbox kernel: sas: ata9: end_device-1:4: dev error handler
Nov 29 15:50:40 downloadbox kernel: ata8.00: failed command: READ FPDMA QUEUED
Nov 29 15:50:40 downloadbox kernel: ata9.00: exception Emask 0x0 SAct 0x100000 SErr 0x0 action 0x6 frozen
Nov 29 15:50:40 downloadbox kernel: ata8.00: cmd 60/00:00:b8:39:e6/04:00:53:00:00/40 tag 1 ncq 524288 in
Nov 29 15:50:40 downloadbox kernel:         res 40/00:ec:c0:08:60/00:00:1e:00:00/40 Emask 0x4 (timeout)
Nov 29 15:50:40 downloadbox kernel: ata9.00: failed command: READ FPDMA QUEUED
Nov 29 15:50:40 downloadbox kernel: ata9.00: cmd 60/00:00:b8:39:e6/04:00:53:00:00/40 tag 20 ncq 524288 in
Nov 29 15:50:40 downloadbox kernel:         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov 29 15:50:40 downloadbox kernel: ata9.00: status: { DRDY }
Nov 29 15:50:40 downloadbox kernel: ata8.00: status: { DRDY }
Nov 29 15:50:40 downloadbox kernel: ata9: hard resetting link
Nov 29 15:50:40 downloadbox kernel: ata8: hard resetting link
Nov 29 15:50:40 downloadbox kernel: sas: ata10: end_device-1:5: dev error handler
Nov 29 15:50:40 downloadbox kernel: ata10.00: exception Emask 0x0 SAct 0x1000 SErr 0x0 action 0x6 frozen
Nov 29 15:50:40 downloadbox kernel: ata10.00: failed command: READ FPDMA QUEUED
Nov 29 15:50:40 downloadbox kernel: ata10.00: cmd 60/00:00:b8:39:e6/04:00:53:00:00/40 tag 12 ncq 524288 in
Nov 29 15:50:40 downloadbox kernel:         res 40/00:54:40:10:00/00:00:00:00:00/40 Emask 0x4 (timeout)
Nov 29 15:50:40 downloadbox kernel: ata10.00: status: { DRDY }
Nov 29 15:50:40 downloadbox kernel: ata10: hard resetting link
Nov 29 15:50:40 downloadbox kernel: sas: ata11: end_device-1:6: dev error handler
Nov 29 15:50:40 downloadbox kernel: ata11.00: exception Emask 0x0 SAct 0x40 SErr 0x0 action 0x6 frozen
Nov 29 15:50:40 downloadbox kernel: ata11.00: failed command: READ FPDMA QUEUED
Nov 29 15:50:40 downloadbox kernel: ata11.00: cmd 60/00:00:b8:31:e6/04:00:53:00:00/40 tag 6 ncq 524288 in
Nov 29 15:50:40 downloadbox kernel:         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov 29 15:50:40 downloadbox kernel: ata11.00: status: { DRDY }
Nov 29 15:50:40 downloadbox kernel: ata11: hard resetting link
Nov 29 15:50:41 downloadbox kernel: sas: sas_form_port: phy0 belongs to port3 already(1)!
Nov 29 15:50:41 downloadbox kernel: sas: sas_form_port: phy1 belongs to port4 already(1)!
Nov 29 15:50:41 downloadbox kernel: sas: sas_form_port: phy2 belongs to port5 already(1)!
Nov 29 15:50:41 downloadbox kernel: sas: sas_form_port: phy3 belongs to port6 already(1)!
Nov 29 15:50:42 downloadbox kernel: drivers/scsi/mvsas/mv_sas.c 1430:mvs_I_T_nexus_reset for device[1]:rc= 0
Nov 29 15:50:42 downloadbox kernel: drivers/scsi/mvsas/mv_sas.c 1430:mvs_I_T_nexus_reset for device[2]:rc= 0
Nov 29 15:50:42 downloadbox kernel: drivers/scsi/mvsas/mv_sas.c 1430:mvs_I_T_nexus_reset for device[0]:rc= 0
Nov 29 15:50:42 downloadbox kernel: drivers/scsi/mvsas/mv_94xx.c 625:command active 0000001D,  slot [1].
Nov 29 15:50:42 downloadbox kernel: ata9.00: configured for UDMA/133
Nov 29 15:50:42 downloadbox kernel: ata9.00: device reported invalid CHS sector 0
Nov 29 15:50:42 downloadbox kernel: ata9: EH complete
Nov 29 15:50:42 downloadbox kernel: ata8.00: configured for UDMA/133
Nov 29 15:50:42 downloadbox kernel: ata8: EH complete
Nov 29 15:50:42 downloadbox kernel: ata10.00: configured for UDMA/133
Nov 29 15:50:42 downloadbox kernel: ata10: EH complete
Nov 29 15:50:43 downloadbox kernel: drivers/scsi/mvsas/mv_sas.c 1430:mvs_I_T_nexus_reset for device[3]:rc= 0
Nov 29 15:50:43 downloadbox kernel: ata11.00: configured for UDMA/133
Nov 29 15:50:43 downloadbox kernel: ata11.00: device reported invalid CHS sector 0
Nov 29 15:50:43 downloadbox kernel: ata11: EH complete
Nov 29 15:50:43 downloadbox kernel: sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 4 tries: 1
Nov 29 15:50:43 downloadbox kernel: drivers/scsi/mvsas/mv_94xx.c 625:command active 00000017,  slot [3].
Nov 29 15:50:43 downloadbox kernel: drivers/scsi/mvsas/mv_94xx.c 625:command active 0000000F,  slot [4].

Thanks, what's the simplest way to identify which disk is which from that log?

Disks 1, 2, 3 and 4.

Interesting, they're all Samsung 2Tb drives that are getting on a bit. I guess it might be time to get replacing.

The problem is not he disks, if you have a spare miniSAS cable and all 4 disks are on the same one replace it, if you don't have a spare switch with the other one so we can see if the issues follows the cable.

Ok, I'll try that as I don't have a spare cable. Seems odd for a cable to start having issues.

It can also be the SAS2LP, or power issues, etc, you'll need to rule out one thing at a time.

It's currently doing a parity check and at 30% with 0 errors. Should I expect to have issues running this test if it's failing to read those drives properly?

Looks like an intermittent issue, it may or not manifest during a parity check.

Seems to be behaving since I reseated all of the SAS cables.