Enver Posted April 24, 2017 Share Posted April 24, 2017 Hello, For as long as I have had my unRAID server I have had the following logged against two unassigned volumes. Apr 22 12:24:30 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Apr 22 12:24:30 Tower kernel: sd 1:0:0:0: [sdb] tag#0 Sense Key : 0x5 [current] Apr 22 12:24:30 Tower kernel: sd 1:0:0:0: [sdb] tag#0 ASC=0x20 ASCQ=0x0 Apr 22 12:24:30 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Apr 22 12:24:30 Tower kernel: sd 1:0:0:1: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Apr 22 12:24:30 Tower kernel: sd 1:0:0:1: [sdc] tag#0 Sense Key : 0x5 [current] Apr 22 12:24:30 Tower kernel: sd 1:0:0:1: [sdc] tag#0 ASC=0x20 ASCQ=0x0 Apr 22 12:24:30 Tower kernel: sd 1:0:0:1: [sdc] tag#0 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Somethings you need to know: sdb - RAID 5, 40 Terabyte volume, presented outside the array via unassigned plugin. sdc - RAID 1, 300 Gigabyte volume, presented outside the array via unassigned plugin and then passed-through to a VM. The errors are logged every thirty seconds. I did some research and found the following: Sense Key = 0x5 Errors All 0x5 sense key errors are information errors. The 0x5 sense key is a host/RAID controller interaction sense key. This key’s errors indicate that the RAID controller received an illegal request from the host. In some cases, the host is sending out a command, asking an individual drive to perform a read or write operation. However, the problem is that no host can communicate directly to the individual drives in a hardware RAID device. The host can only communicate with the RAID controller. In this case, the RAID controller is returning an illegal request statement back to the host, stating that it doesn't understand what the host is asking. Based on the following article I have mapped the ASC and ASCQ error codes against each volume: http://www.t10.org/lists/asc-num.htm#ASC_20 ASC/ . . . . . ASCQ DZTPROMAEBKVF Description20/00 DZTPROMAEBKVF INVALID COMMAND OPERATION CODE Question: Is there a way to suppress these error codes in syslog? Is there a way to configure unRAID to ask operation of the RAID controller rather than the individual volumes? I believe the host is attempting to request temperature data directly from the HDD's instead via the RAID controller. I realise the above is a benign error, but would really love to suppress this error. Is anyone else seeing this on an ARECA card or any other SCSI controller that is configured not to pass-through(JBOD) disks? Thanks, Enver 1 Quote Link to comment
Lev Posted October 29, 2017 Share Posted October 29, 2017 On 4/24/2017 at 3:51 PM, Enver said: Is anyone else seeing this on an ARECA card or any other SCSI controller that is configured not to pass-through(JBOD) disks? Yes. And thank you for posting about it, I have been having the same issue. Agree. It needs suppression. @limetech my logs also so a match to confirm. Possible to open change request? On 4/24/2017 at 3:51 PM, Enver said: Apr 22 12:24:30 Tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Apr 22 12:24:30 Tower kernel: sd 1:0:0:0: [sdb] tag#0 Sense Key : 0x5 [current] Apr 22 12:24:30 Tower kernel: sd 1:0:0:0: [sdb] tag#0 ASC=0x20 ASCQ=0x0 Apr 22 12:24:30 Tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Apr 22 12:24:30 Tower kernel: sd 1:0:0:1: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Apr 22 12:24:30 Tower kernel: sd 1:0:0:1: [sdc] tag#0 Sense Key : 0x5 [current] Apr 22 12:24:30 Tower kernel: sd 1:0:0:1: [sdc] tag#0 ASC=0x20 ASCQ=0x0 Apr 22 12:24:30 Tower kernel: sd 1:0:0:1: [sdc] tag#0 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 My log, same setup as Enver, two drives from Areca RAID controller, only difference is I'm not using UD, : Oct 29 00:56:50 tower kernel: sd 1:0:0:1: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Oct 29 00:56:50 tower kernel: sd 1:0:0:1: [sdc] tag#0 Sense Key : 0x5 [current] Oct 29 00:56:50 tower kernel: sd 1:0:0:1: [sdc] tag#0 ASC=0x20 ASCQ=0x0 Oct 29 00:56:50 tower kernel: sd 1:0:0:1: [sdc] tag#0 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Oct 29 00:56:50 tower kernel: sd 1:0:0:2: [sdd] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Oct 29 00:56:50 tower kernel: sd 1:0:0:2: [sdd] tag#0 Sense Key : 0x5 [current] Oct 29 00:56:50 tower kernel: sd 1:0:0:2: [sdd] tag#0 ASC=0x20 ASCQ=0x0 Oct 29 00:56:50 tower kernel: sd 1:0:0:2: [sdd] tag#0 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Quote Link to comment
Enver Posted November 12, 2017 Author Share Posted November 12, 2017 On 10/29/2017 at 6:24 PM, Lev said: Yes. And thank you for posting about it, I have been having the same issue. Agree. It needs suppression. @limetech my logs also so a match to confirm. Possible to open change request? My log, same setup as Enver, two drives from Areca RAID controller, only difference is I'm not using UD, : Oct 29 00:56:50 tower kernel: sd 1:0:0:1: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Oct 29 00:56:50 tower kernel: sd 1:0:0:1: [sdc] tag#0 Sense Key : 0x5 [current] Oct 29 00:56:50 tower kernel: sd 1:0:0:1: [sdc] tag#0 ASC=0x20 ASCQ=0x0 Oct 29 00:56:50 tower kernel: sd 1:0:0:1: [sdc] tag#0 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Oct 29 00:56:50 tower kernel: sd 1:0:0:2: [sdd] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Oct 29 00:56:50 tower kernel: sd 1:0:0:2: [sdd] tag#0 Sense Key : 0x5 [current] Oct 29 00:56:50 tower kernel: sd 1:0:0:2: [sdd] tag#0 ASC=0x20 ASCQ=0x0 Oct 29 00:56:50 tower kernel: sd 1:0:0:2: [sdd] tag#0 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 @limetech Hello, Could we please have this error suppressed in 6.4. This is superfluous error with no downsides that I have experienced. It seems to be temperature sensor related; my Areca RAID 6 card is watercooled so its not an issue for me. The error seems to be related to the fact unRAID can't interpret the temperature sensor messages. Quote Link to comment
limetech Posted November 18, 2017 Share Posted November 18, 2017 On 10/29/2017 at 1:24 AM, Lev said: Yes. And thank you for posting about it, I have been having the same issue. Agree. It needs suppression. @limetech my logs also so a match to confirm. Possible to open change request? My log, same setup as Enver, two drives from Areca RAID controller, only difference is I'm not using UD, : Oct 29 00:56:50 tower kernel: sd 1:0:0:1: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Oct 29 00:56:50 tower kernel: sd 1:0:0:1: [sdc] tag#0 Sense Key : 0x5 [current] Oct 29 00:56:50 tower kernel: sd 1:0:0:1: [sdc] tag#0 ASC=0x20 ASCQ=0x0 Oct 29 00:56:50 tower kernel: sd 1:0:0:1: [sdc] tag#0 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Oct 29 00:56:50 tower kernel: sd 1:0:0:2: [sdd] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Oct 29 00:56:50 tower kernel: sd 1:0:0:2: [sdd] tag#0 Sense Key : 0x5 [current] Oct 29 00:56:50 tower kernel: sd 1:0:0:2: [sdd] tag#0 ASC=0x20 ASCQ=0x0 Oct 29 00:56:50 tower kernel: sd 1:0:0:2: [sdd] tag#0 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Please type this command and note if it causes those messages to be immediately logged: smartctl -A /dev/sdc 1 Quote Link to comment
bonienl Posted November 18, 2017 Share Posted November 18, 2017 On 4/25/2017 at 12:51 AM, Enver said: The errors are logged every thirty seconds. Is there a difference with browser opened or closed? I have seen this kind of messages when the hdparm program is executed. Any of your plugins using that? (or perhaps start in safemode) 1 Quote Link to comment
Lev Posted November 19, 2017 Share Posted November 19, 2017 4 hours ago, limetech said: Please type this command and note if it causes those messages to be immediately logged: smartctl -A /dev/sdc No. It doesn't trigger it. Quote Link to comment
Lev Posted November 19, 2017 Share Posted November 19, 2017 4 hours ago, bonienl said: Is there a difference with browser opened or closed? I have seen this kind of messages when the hdparm program is executed. Any of your plugins using that? (or perhaps start in safemode) No however I played around in the UI and found some trigger points. @limetech .. It will trigger on ANY disk spinup or spindown. I will trigger anytime in the UI to go into drive details Within drive details it doesn't detect the details. Screenshot attached. I tried changing 'Smart Controller Type' from Auto to Areca, but that'd didn't seem to help. The field wants me to enter a disk number, but in this case the drive is actually the parity so no valid disk number to use. tower_Device.pdf 1 Quote Link to comment
Lev Posted November 19, 2017 Share Posted November 19, 2017 I also tried unchecking the 'attribute' notifications, but it doesn't apply, the box will just stayed checked. Any more tests you'd like me to perform? Quote Link to comment
bonienl Posted November 19, 2017 Share Posted November 19, 2017 5 hours ago, Lev said: No however I played around in the UI and found some trigger points. @limetech .. It will trigger on ANY disk spinup or spindown. I will trigger anytime in the UI to go into drive details Within drive details it doesn't detect the details. Screenshot attached. I tried changing 'Smart Controller Type' from Auto to Areca, but that'd didn't seem to help. The field wants me to enter a disk number, but in this case the drive is actually the parity so no valid disk number to use. tower_Device.pdf Your Areca controller configuration is incorrect. This is from the smartctl man page: ------ areca,N - [FreeBSD, Linux, Windows and Cygwin only] the device consists of one or more SATA disks connected to an Areca SATA RAID controller. The positive integer N (in the range from 1 to 24 inclusive) denotes which disk on the controller is monitored. On Linux use syntax such as: smartctl -a -d areca,2 /dev/sg2 smartctl -a -d areca,3 /dev/sg3 On FreeBSD use syntax such as: smartctl -a -d areca,2 /dev/arcmsr1 smartctl -a -d areca,3 /dev/arcmsr2 On Windows and Cygwin use syntax such as: smartctl -a -d areca,2 /dev/arcmsr0 smartctl -a -d areca,3 /dev/arcmsr1 The first line above addresses the second disk on the first Areca RAID controller. The second line addresses the third disk on the second Areca RAID controller. To help identify the correct device on Linux, use the command: cat /proc/scsi/sg/device_hdr /proc/scsi/sg/devices to show the SCSI generic devices (one per line, starting with /dev/sg0). The correct SCSI generic devices to address for smartmontools are the ones with the type field equal to 3. If the incorrect device is addressed, please read the warning/error messages carefully. They should provide hints about what devices to use. Important: the Areca controller must have firmware version 1.46 or later. Lower-numbered firmware versions will give (harmless) SCSI error messages and no SMART information. ------- Also install the Dynamix SCSI devices plugin for a proper update of the udev storage rules needed for SCSI controllers, such as Areca. This topic is a bit outdated, but may help (skip steps 1-3) 1 Quote Link to comment
Lev Posted November 19, 2017 Share Posted November 19, 2017 @bonienl thanks for pointing me towards all that! I feel like I'm definitely closer to figuring this out, but rather embarrassed to say I couldn't solve it. There's something more I'm missing because my configuration is different than the examples posted. I'll unpack the details here and what I've tried from your post, maybe you'll see the detail I'm missing. Physical Setup: Areca 1883i dual linked both SAS cables into a Expander Controller:Areca ARC-1883I 1.54 SAS Address 5001B4D44FCCE000 Enclosure ENC#1 Number Of Phys 8 Attached Expander Expander#1[5003048001B55FBF][8x6G] Expander#1:LSI SAS2X28 0e12 SAS Address 5003048001B55FBF Component Vendor LSI Component ID 0221 Enclosure ENC#2 Number Of Phys 30 Attached Expander Controller[5001B4D44FCCE000][8x6G] Details of Controller: Controller:Areca ARC-1883I 1.54 [Clear Error Log] Phy Attached Sas Addr Attached Sas Phy Attached Device Link Rate Attribute Invalid Dword Disparity Error Lost Sync Reset Problem Phy00 5003048001B55FBF 07 Expander#1 6G D 00000000 00000000 00000000 00000000 Phy01 5003048001B55FBF 06 Expander#1 6G D 00000000 00000000 00000000 00000000 Phy02 5003048001B55FBF 04 Expander#1 6G D 00000000 00000000 00000000 00000000 Phy03 5003048001B55FBF 05 Expander#1 6G D 00000000 00000000 00000000 00000000 Phy04 5003048001B55FBF 03 Expander#1 6G D 00000000 00000000 00000000 00000000 Phy05 5003048001B55FBF 02 Expander#1 6G D 00000000 00000000 00000000 00000000 Phy06 5003048001B55FBF 00 Expander#1 6G D 00000000 00000000 00000000 00000000 Phy07 5003048001B55FBF 01 Expander#1 6G D 00000000 00000000 00000000 00000000 Details of Expander: Expander#1:LSI SAS2X28 0e12 [Clear Error Log] Phy Attached Sas Addr Attached Sas Phy Attached Device Link Rate Attribute Invalid Dword Disparity Error Lost Sync Reset Problem Phy00 5001B4D44FCCE000 06 Controller 6G S 00000000 00000000 00000000 00000000 Phy01 5001B4D44FCCE000 07 Controller 6G S 00000000 00000000 00000000 00000000 Phy02 5001B4D44FCCE000 05 Controller 6G S 00000000 00000000 00000000 00000000 Phy03 5001B4D44FCCE000 04 Controller 6G S 00000000 00000000 00000000 00000000 Phy04 5001B4D44FCCE000 02 Controller 6G T 00000000 00000000 00000000 00000000 Phy05 5001B4D44FCCE000 03 Controller 6G T 00000000 00000000 00000000 00000000 Phy06 5001B4D44FCCE000 01 Controller 6G T 00000000 00000000 00000000 00000000 Phy07 5001B4D44FCCE000 00 Controller 6G T 00000000 00000000 00000000 00000000 Phy08 N/A N/A N/A Disabled D 00000000 00000000 00000000 00000000 Phy09 N/A N/A N/A Disabled D 00000000 00000000 00000000 00000000 Phy10 N/A N/A N/A Disabled D 00000000 00000000 00000000 00000000 Phy11 N/A N/A N/A Disabled D 00000000 00000000 00000000 00000000 Phy12 5003048001B55FAC 00 ENC#2Slot 01 6G T 00000004 00000003 00000000 00000000 Phy13 5003048001B55FAD 00 ENC#2Slot 02 6G T 00000004 00000004 00000000 00000000 Phy14 5003048001B55FAE 00 ENC#2Slot 03 6G T 00000004 00000002 00000000 00000000 Phy15 5003048001B55FAF 00 ENC#2Slot 04 6G T 00000005 00000005 00000000 00000000 Phy16 5003048001B55FB0 00 ENC#2Slot 05 6G T 00000000 00000000 00000000 00000000 Phy17 5003048001B55FB1 00 ENC#2Slot 06 6G T 00000000 00000000 00000000 00000000 Phy18 5003048001B55FB2 00 ENC#2Slot 07 6G T 00000000 00000000 00000000 00000000 Phy19 N/A N/A N/A Not Linked T 00000000 00000000 00000000 00000000 Phy20 N/A N/A N/A Not Linked T 00000000 00000000 00000000 00000000 Phy21 5003048001B55FB5 00 ENC#2Slot 10 6G T 00000000 00000000 00000000 00000000 Phy22 5003048001B55FB6 00 ENC#2Slot 11 6G T 00000000 00000000 00000000 00000000 Phy23 5003048001B55FB7 00 ENC#2Slot 12 6G T 00000000 00000000 00000000 00000000 Phy24 N/A N/A N/A Disabled D 00000000 00000000 00000000 00000000 Phy25 N/A N/A N/A Disabled D 00000000 00000000 00000000 00000000 Phy26 N/A N/A N/A Disabled D 00000000 00000000 00000000 00000000 Phy27 N/A N/A N/A Disabled D 00000000 00000000 00000000 00000000 Phy28 5003048001B55FBD 00 SES2 6G D 00000000 00000000 00000000 00000000 Phy29 N/A N/A Virtual Phy Not Linked D 00000000 00000000 00000000 00000000 Quote Link to comment
Lev Posted November 19, 2017 Share Posted November 19, 2017 Continued here... RAID Sets (all three of these trigger the Sense Error in unRAID) - It's the bottom one, Parity_R0_3x3TB that we're interested in. It is my current assigned Parity Disk - The top one 'Parity' is presently not assigned in unRAID as part of the array. - 'Cache' is presently assigned as a UD volume, not my unRAID cache (sorry I had to make this so confusing... I keep moving things around and not renaming them properly) RAID Set Devices Volume Set(Ch/Id/Lun) Volume State Capacity Raid Set # 000 E#2Slot 01 Parity (0/0/0) *NOT THIS ONE* Normal 8002.0GB E#2Slot 02 Cache (0/0/1) *UD volume at the moment* Normal 20003.1GB E#2Slot 03 E#2Slot 04 E#2Slot 05 E#2Slot 06 3x3TB_Seagate E#2Slot 10 Parity_R0_3x3TB (0/0/2) *THIS IS THE ONE* Normal 8002.0GB E#2Slot 11 E#2Slot 12 Be right back with more details. Quote Link to comment
limetech Posted November 19, 2017 Share Posted November 19, 2017 unRAID OS does not support RAID cards operating in anything but pass-through (or JBOD) mode. I realize it would be "nice" for you to run a bunch of drives behind a RAID-5 controller and have unRAID manage it all. However, there a numerous RAID cards out there. Most with proprietary drivers and management interfaces. There might be a tweak here or there we can do to quiet down messages, but don't expect "full support" for these cards. For example, 'spin up', 'spin down' creating message: our workaround: don't use spin-up/spin-down with devices attached to these cards. 1 Quote Link to comment
Lev Posted November 19, 2017 Share Posted November 19, 2017 1 hour ago, limetech said: unRAID OS does not support RAID cards operating in anything but pass-through (or JBOD) mode. I realize it would be "nice" for you to run a bunch of drives behind a RAID-5 controller and have unRAID manage it all. However, there a numerous RAID cards out there. Most with proprietary drivers and management interfaces. There might be a tweak here or there we can do to quiet down messages, but don't expect "full support" for these cards. For example, 'spin up', 'spin down' creating message: our workaround: don't use spin-up/spin-down with devices attached to these cards. Yes, I understand @limetech . Reading what you wrote reminded me of the same thing years ago when I was running unRAID as a VM guest in ESXi. Different issue then but same principal applies, there is supported and unsupported. I've strayed too far. As for the spinup/spin down, that is an action I can do that recreates the 'Sense' message to appear in the log, but it is not the direct cause. It seems and I think this is why we're looking in 'smartctl' .... Because it's the spinup/spindown that is the root cause, it's another function called after that ('smartctl' ?) then queries all the disks again to refresh their state information. It's at this point the 'Sense' message appears in the log. @bonienl here's the output from unRAID for those disks. All three are triggering the sense message. /dev/sdd can continue to serve as the example. root@tower:~# lsscsi -g|grep "Areca" [1:0:0:0] disk Areca Parity R001 /dev/sdb /dev/sg1 [1:0:0:1] disk Areca Cache R001 /dev/sdc /dev/sg2[1:0:0:2] disk Areca Parity_R0_3x3TB R001 /dev/sdd /dev/sg3 [1:0:16:0] process Areca RAID controller R001 - Then I've tried the following command, and I think there is where I'm missing something in the values I'm using. Running this command is not triggering the 'Sense' error, probably because I haven't found the right values root@tower:~# smartctl -a -d areca,1/E2 /dev/sdd smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.13.13-unRAID] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org do_scsi_cmnd_io with write buffer failed code = ffffffff do_scsi_cmnd_io with write buffer failed code = ffffffff do_scsi_cmnd_io with write buffer failed code = ffffffff do_scsi_cmnd_io with write buffer failed code = ffffffff do_scsi_cmnd_io with write buffer failed code = ffffffff do_scsi_cmnd_io with write buffer failed code = ffffffff do_scsi_cmnd_io with write buffer failed code = ffffffff do_scsi_cmnd_io with write buffer failed code = ffffffff do_scsi_cmnd_io with write buffer failed code = ffffffff Read Device Identity failed: Input/output error A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. Let be break this command down further: smartctl -a -d areca,1/E2 /dev/sdd 1/E2 - I'm not sure about the first value 1, I've tried numbers 1 to 30, and all return the same message. As for E2, I think that is correct based on the Expander details I've posted above, not 100% sure /dev/sdd - Correct value. From all the information I posted, do you see what the correct values are I should try? Quote Link to comment
Lev Posted November 19, 2017 Share Posted November 19, 2017 UPDATE: This recreates the logged Sense message. root@tower:~# smartctl -a -d areca,1/E2 /dev/sdd smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.13.13-unRAID] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org do_scsi_cmnd_io with write buffer failed code = ffffffff do_scsi_cmnd_io with write buffer failed code = ffffffff do_scsi_cmnd_io with write buffer failed code = ffffffff do_scsi_cmnd_io with write buffer failed code = ffffffff do_scsi_cmnd_io with write buffer failed code = ffffffff do_scsi_cmnd_io with write buffer failed code = ffffffff do_scsi_cmnd_io with write buffer failed code = ffffffff do_scsi_cmnd_io with write buffer failed code = ffffffff do_scsi_cmnd_io with write buffer failed code = ffffffff Read Device Identity failed: Input/output error A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. This recreates the unRAID log message as follows (notice that sdd is not in the sense messages now) Nov 19 10:06:18 tower kernel: sdd: sdd1Nov 19 10:06:18 tower rc.diskinfo[10195]: SIGHUP received, forcing refresh of disks info.Nov 19 10:06:21 tower rc.diskinfo[10195]: SIGHUP received, forcing refresh of disks info.Nov 19 10:06:24 tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08Nov 19 10:06:24 tower kernel: sd 1:0:0:0: [sdb] tag#0 Sense Key : 0x5 [current] Nov 19 10:06:24 tower kernel: sd 1:0:0:0: [sdb] tag#0 ASC=0x20 ASCQ=0x0 Nov 19 10:06:24 tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00Nov 19 10:06:24 tower kernel: sd 1:0:0:1: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08Nov 19 10:06:24 tower kernel: sd 1:0:0:1: [sdc] tag#0 Sense Key : 0x5 [current] Nov 19 10:06:24 tower kernel: sd 1:0:0:1: [sdc] tag#0 ASC=0x20 ASCQ=0x0 Nov 19 10:06:24 tower kernel: sd 1:0:0:1: [sdc] tag#0 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00Nov 19 10:06:27 tower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08Nov 19 10:06:27 tower kernel: sd 1:0:0:0: [sdb] tag#0 Sense Key : 0x5 [current] Nov 19 10:06:27 tower kernel: sd 1:0:0:0: [sdb] tag#0 ASC=0x20 ASCQ=0x0 Nov 19 10:06:27 tower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00Nov 19 10:06:27 tower kernel: sd 1:0:0:1: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08Nov 19 10:06:27 tower kernel: sd 1:0:0:1: [sdc] tag#0 Sense Key : 0x5 [current] Nov 19 10:06:27 tower kernel: sd 1:0:0:1: [sdc] tag#0 ASC=0x20 ASCQ=0x0 Nov 19 10:06:27 tower kernel: sd 1:0:0:1: [sdc] tag#0 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Quote Link to comment
Lev Posted November 19, 2017 Share Posted November 19, 2017 I'm on to something here. By finding that, I have now set the Partity disk Smart controller to 'Areca' 1 /dev/sdd This has resolved one drive, sdd, from now having the 'sense' messages in the log. The other still logging the message are sdb and sdc. sdb I can simply delete that volume, as it's not in use sdc is in use via UnAssignedDevices. I don't see where in UD to configure the Smart Controller in the same way unRAID does. I'll look harder. Interesting, definitely a step forward here in learning how to bring this towards a full resolution. Quote Link to comment
Lev Posted November 19, 2017 Share Posted November 19, 2017 In the Areca manager I deleted logical volume 'Parity' which in unRAID was an unassigned disk 'sdb' the message is now gone. The only remaining one is 'sdc' which is a UD managed drive. UD has no settings to configure Smart Controller Type. Workaround... I'll move 'sdc' to be managed by unRAID as the Cache drive, where I can set the 'Smart Controller Type. Therefore all Areca managed drives will be managed by unRAID as an assigned disk. There will no longer be any Areca managed disks managed by UD or unassigned by unRAID. RESOLVED! Conclusions/Findings Using Areca managed volumes in unRAID, must set Smart Controller Type on drive details. Reminder: Using ARECA in RAID mode is NOT SUPPORTED. Using Areca managed volumes with UD, no clear way to set Smart Controler Type for a drive. Do not use. Safe Guess: Using ARECA in RAID mode is NOT SUPPORTED in UD @dlandon Many thanks to @limetech, @bonienl and @Enver Quote Link to comment
limetech Posted November 19, 2017 Share Posted November 19, 2017 Glad you got this sorted! Is there an action item in there for us? Quote Link to comment
Lev Posted November 19, 2017 Share Posted November 19, 2017 (edited) 53 minutes ago, limetech said: Glad you got this sorted! Is there an action item in there for us? @limetech Honestly wasn't going to ask since. But... ha... you're question inspired to research for the last 30 minutes... Possible solution found. PROBLEM: The workaround is limiting, as what I need is to define the 'Smart Controller Type' for any disk that is not assigned to the Array. Since disks that are unassigned are not visible in the GUI, there is no way to assign them in the same manner that unRAID supports now. This limits the workaround to only working for Parity or Cache disks, but not for unassigned disks. Possible Solution: UD Plug-In Next seemed like the logical step would be to see if @dlandon could add 'Smart Controller Type' as the UD plug-in has the same GUI device details settings. No luck in his reply, I understand. Possible Actions: unRAID GUI - No. Not sure where an action could be taken in the GUI for sure, because I don't see an easy way to define on a per disk basis, what 'Smart Controller Type' is to a disk that is not in the array. flash/config/smart-one.cfg - Yes? this might be possible for action. Given what I found, this is where 'Smart Controller Type' is stored. Right now I have this: [parity] smType="-d areca" smPort1="10" Disks seem to use [Disk Would it be possible to add this? [sdX] smType="-d areca" smPort1="10" In my example it would be [sdc] as that is my unassigned disk. I'm testing this now to see how it behaves. Will report back if it already works or not. [sdb] smType="-d areca" smPort1="10" Edited November 19, 2017 by Lev typo, fixed it to be sdb Quote Link to comment
Lev Posted November 19, 2017 Share Posted November 19, 2017 @limetech I tested two area's where they may be action that can be taken to remedy. I also noted one related new issue. Two possible actions: (1) /config/smart-one.cfg - Seems viable to add disks by name. Would need change to allow disk name to be handled differently than today. Presently it works on [array disk] and would need to be updated to allow [array disk or disk (ex: sdX)] (2) Global Disk Settings - I saw @bonienl post regarding Global Disk Settings and found that yes this seems viable, however selecting a Default'Smart Controller Type' = 'Areca' may have a defect. The GUI does not then dynamically show the fields needed to define it (since those settings are really at the device level, so this seems to be correct function) However, once I press 'Apply', the GUI refreshes and the selection switch from 'Areca' to 'Automatic' Related new issue While my work-around as detailed previously for my [parity] disk works correctly, only once the array is started. When the array is not started, the logs are filled with the Sense error again for sde, which is my [parity] disk. Seems that the 'Smart Controller Type' is not applied at the per disk level for array disks until once the array has been started. Seeing all these items makes me wonder if the real solution is to apply this at the disk level in /config/disks.cfg, but I don't know. Before I proceed any further, what are your thoughts? Quote Link to comment
bsim Posted January 25, 2018 Share Posted January 25, 2018 I would say to get full support of the cards, a few of the hard codings of generic smart data pulls (in emhttp?) would have to use the per disk interface or the global disk interface settings using the specific drive controller settings. I love Unraid, and it's awesome flexibility...but having a lack of a specific mfg controller support when packages like smartctl have started supporting them (how many years ago? smartctl 5.39 supported Areca!), is a MAJOR issue, left looming is terrible, and negates the entire purpose of the smart statistics attempting to notify of eminent drive failure. For a system that is interested in data integrity, at least following up on smartctl's added support for special controller cards (happened a long time ago) should be followed as hard as possible. I agree that mfg implementation of smart data can be a bit flaky, but with smartctrl now having support, it's time to give the hard coded generic smart data retrieval attempts in unraid another revision. The pages that were added by the few users to support the non-generic smart controllers was a big help, but without core support in unraid, users data is threatened in one more way by not supporting the data points being exposed by every drive manufacturer out there. I agree that the smart data can be a bit hazy for predetermination of problems, but with a few of the backblaze papers out there, there are at least a few of the smart data points that should be at the heart of unraids notifications regardless of whether they carry the caveat of potential false positives! Data integrity seems to be the goal of unraid, harder incorporation of any data to that end, regardless of how heavily weighted the data may be, should be a core of unraid. Thoughts? Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.