Looking for smart data on failed drive

[manofcolombia]

I have an array with on parity disk and only one data disk, both 6TB.
Logged into unraid this morning and found that my data drive has been "Disabled due to read errors"

Ok thats fine, I probably have a bad drive. No biggie, I just bought these drives from amazon and the replacement will be here on Tuesday. 

However, I can't pull the smart data from the drive. I would like to confirm the smart data is accurate being that this array lives in a new server that I also just got. 
Its in an R710 with an H200 in (DELL) IT mode and thus I would like to confirm that its not just something odd with unraids relationship with the H200.

Also, since this drive has been disabled, I'm assuming that the parity drive is the one thats doing all the heavy lifting now since none of the services in unraid went down. What would happen if the server was rebooted either from a power outage or from me taking it down to pull the bad drive out to confirm smart data outside in a debian machine or something else without the H200? 

Attached the diagnostics, but that also doesn't have smart data from the bad drive I assume because its disabled

And below is what I see in disk logs:

 

Apr 7 12:23:25 stylophora emhttpd: TOSHIBA_HDWN160_672GK0E2FPAE (sdc) 512 11721045168
Apr 7 12:23:25 stylophora kernel: mdcmd (2): import 1 sdc 64 5860522532 0 TOSHIBA_HDWN160_672GK0E2FPAE
Apr 7 12:23:25 stylophora kernel: md: import disk1: (sdc) TOSHIBA_HDWN160_672GK0E2FPAE size: 5860522532
Apr 7 12:23:38 stylophora emhttpd: TOSHIBA_HDWN160_672GK0E2FPAE (sdc) 512 11721045168
Apr 7 12:23:38 stylophora kernel: mdcmd (2): import 1 sdc 64 5860522532 0 TOSHIBA_HDWN160_672GK0E2FPAE
Apr 7 12:23:38 stylophora kernel: md: import disk1: (sdc) TOSHIBA_HDWN160_672GK0E2FPAE size: 5860522532
Apr 7 12:23:55 stylophora emhttpd: shcmd (709): /usr/local/sbin/set_ncq sdc 1
Apr 7 12:23:55 stylophora emhttpd: shcmd (710): echo 128 > /sys/block/sdc/queue/nr_requests
Apr 8 02:44:15 stylophora kernel: sd 3:0:1:0: [sdc] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 23 b1 1d 30 00 00 02 00 00 00
Apr 8 02:44:49 stylophora kernel: sd 3:0:1:0: [sdc] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 23 b1 1d 30 00 00 02 00 00 00
Apr 8 02:45:03 stylophora kernel: sd 3:0:1:0: [sdc] tag#0 CDB: opcode=0x0 00 00 00 00 00 00
Apr 8 02:45:07 stylophora kernel: sd 3:0:1:0: [sdc] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 23 b1 1d 30 00 00 02 00 00 00
Apr 8 02:45:22 stylophora kernel: sd 3:0:1:0: [sdc] tag#0 CDB: opcode=0x0 00 00 00 00 00 00
Apr 8 02:45:26 stylophora kernel: sd 3:0:1:0: [sdc] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 23 b1 1d 30 00 00 02 00 00 00
Apr 8 02:46:24 stylophora kernel: sd 3:0:1:0: [sdc] killing request
Apr 8 02:46:24 stylophora kernel: sd 3:0:1:0: [sdc] killing request
Apr 8 02:46:24 stylophora kernel: print_req_error: I/O error, dev sdc, sector 0
Apr 8 02:46:24 stylophora kernel: print_req_error: I/O error, dev sdc, sector 0
Apr 8 02:46:24 stylophora kernel: print_req_error: I/O error, dev sdc, sector 0
Apr 8 02:46:24 stylophora kernel: print_req_error: I/O error, dev sdc, sector 0
Apr 8 02:46:24 stylophora kernel: print_req_error: I/O error, dev sdc, sector 0
Apr 8 02:46:24 stylophora kernel: sd 3:0:1:0: [sdc] UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
Apr 8 02:46:24 stylophora kernel: sd 3:0:1:0: [sdc] CDB: opcode=0x88 88 00 00 00 00 00 23 b1 1d 30 00 00 02 00 00 00
Apr 8 02:46:24 stylophora kernel: print_req_error: I/O error, dev sdc, sector 598809904
Apr 8 02:46:24 stylophora kernel: sd 3:0:1:0: [sdc] UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
Apr 8 02:46:24 stylophora kernel: sd 3:0:1:0: [sdc] CDB: opcode=0x8a 8a 00 00 00 00 01 00 00 00 30 00 00 00 08 00 00
Apr 8 02:46:24 stylophora kernel: print_req_error: I/O error, dev sdc, sector 4294967344
Apr 8 02:46:24 stylophora kernel: sd 3:0:1:0: [sdc] Synchronizing SCSI cache
Apr 8 02:46:24 stylophora kernel: sd 3:0:1:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00

And here is what I see in general syslog:

 

Apr 8 08:00:30 stylophora speedtest: Host: UNC Chapel Hill (Chapel Hill, NC) [159.66 km]
Apr 8 08:00:30 stylophora speedtest: Ping (Lowest): 28.534 ms | Download (Max): 34.19 Mbit/s | Upload (Max): 1.24 Mbit/s
Apr 8 08:00:30 stylophora speedtest: Internet bandwidth test completed
Apr 8 12:00:02 stylophora speedtest: Internet bandwidth test started
Apr 8 12:00:31 stylophora speedtest: Host: Comcast (Richmond, VA) [172.99 km]
Apr 8 12:00:31 stylophora speedtest: Ping (Lowest): 22.851 ms | Download (Max): 89.51 Mbit/s | Upload (Max): 3.05 Mbit/s
Apr 8 12:00:31 stylophora speedtest: Internet bandwidth test completed
Apr 8 15:37:35 stylophora emhttpd: req (29): cmdSpinup=disk1&csrf_token=****************
Apr 8 15:37:35 stylophora kernel: mdcmd (38): spinup 1
Apr 8 15:37:35 stylophora kernel: md: do_drive_cmd: lock_bdev error: -2
Apr 8 15:42:20 stylophora kernel: mdcmd (39): spindown 1
Apr 8 15:42:20 stylophora kernel: md: do_drive_cmd: lock_bdev error: -2
Apr 8 15:42:20 stylophora emhttpd: req (30): cmdSpindown=disk1&csrf_token=****************
Apr 8 15:42:20 stylophora emhttpd: error: mdcmd, 2639: No such file or directory (2): write
Apr 8 15:43:03 stylophora emhttpd: req (32): cmd=/webGui/scripts/disk_log&arg1=sdc&csrf_token=****************
Apr 8 15:43:03 stylophora emhttpd: cmd: /usr/local/emhttp/plugins/dynamix/scripts/disk_log sdc
Apr 8 15:43:33 stylophora emhttpd: req (33): cmd=/webGui/scripts/disk_log&arg1=sdb&csrf_token=****************
Apr 8 15:43:33 stylophora emhttpd: cmd: /usr/local/emhttp/plugins/dynamix/scripts/disk_log sdb
Apr 8 15:52:18 stylophora emhttpd: req (34): cmdSpindown=disk1&csrf_token=****************
Apr 8 15:52:18 stylophora emhttpd: error: mdcmd, 2639: No such file or directory (2): write
Apr 8 15:52:18 stylophora kernel: mdcmd (40): spindown 1
Apr 8 15:52:18 stylophora kernel: md: do_drive_cmd: lock_bdev error: -2
Apr 8 15:53:51 stylophora emhttpd: req (35): cmd=/webGui/scripts/disk_log&arg1=sdc&csrf_token=****************
Apr 8 15:53:51 stylophora emhttpd: cmd: /usr/local/emhttp/plugins/dynamix/scripts/disk_log sdc

Thanks
 

stylophora-diagnostics-20180408-1606.zip

[itimpi]

The fact that a drive is disabled does not mean it’s SMART data cannot be obtained.    Failing to get SMART data normally means the drive has dropped offline (which was probably why it was disabled).    In such a scenario the system needs rebooting before the SMART data can be accessed.     More often than not a disk dropping offline is not due to the disk failing but an external factor such as a cabling or controller issue.

[manofcolombia]

26 minutes ago, itimpi said:

The fact that a drive is disabled does not mean it’s SMART data cannot be obtained.    Failing to get SMART data normally means the drive has dropped offline (which was probably why it was disabled).    In such a scenario the system needs rebooting before the SMART data can be accessed.     More often than not a disk dropping offline is not due to the disk failing but an external factor such as a cabling or controller issue.

So you suggest I reboot and try and remount. See if it comes back up? 

 

[trurl]

Check connections before rebooting. Bad connections are by far the most frequent cause of disabled disks seen here on this forum, with controller issues a distant second, and actual bad disks trailing by quite a bit.