WD drives showing as unknown

phillxnet · July 22, 2018, 11:03am

@cferra Welcome to the Rockstor community, and thanks for helping to support Rockstor development via a stable subscription.

I’m assuming here you are referring to the drives “Power Status” column entry. It’s the only “unknown” Web-UI column entry on the Disks page that comes to mind, ie:

unknown-power-status

If so this is simply a default state if a certain hdparm command returns an error or a result which is not ‘understood’. The code in question is the following:

github.com

rockstor/rockstor-core/blob/master/src/rockstor/system/osi.py#L1365-L1398


      
          def system_reboot(delta="now"):
              # New delta param default to now used to pass a 2 min delay
              # for scheduled tasks reboot/shutdown
              try:
                  cmd = [SHUTDOWN, "-r", delta]
                  o, e, rc = run_command(cmd)
              except CommandException as e:
                  # Catch / log harmless -15 return code - command executes as expected.
                  if e.rc == -15:
                      logger.info("Ignoring rc=-15 from command ({}).".format(cmd))
                      return e.out, e.err, e.rc
                  # otherwise we raise an exception as normal.
                  raise e
              return o, e, rc
          
          
          def system_suspend():
              # This function perform system suspend to RAM via systemctl
              # while reboot and shutdown, both via shutdown command, can be delayed
              # systemctl suspend miss this option

This file has been truncated. show original

Clicking on the “show original” will give the entire rather short code snippet that deals with the “Power State” column entry text.

This is not really a concern as it just means the output of the following command, as executed with your drives by-id name, was interpreted as ‘unknown’:

hdparm -C -q device-by-id-name-with-path

An example for a virtio drive with serial = “serial-6”:

hdparm -C -q /dev/disk/by-id/virtio-serial-6 
 drive state is:  unknown

It would also be helpful to see what the return code was from that command: ie directly after executing the hdparm command if you could then execute the following command:

echo $?
25

We see here that a return code of 25 was recorded from the hdparm command on a virtio device. The indicated source code classes any error output “len(err) !=1” as an unknown state, this error text is normally part of the command output if I remember correctly.

We may have an opportunity to improve this columns scope here (ie for your drives through LSI controller ‘unknown’ issue); or it may just be that hdparm can’t handle this scenario. We do have a related issue open for the scenario where we also use hdparm which is known not to be able to set drive power down settings (the related use of hdparm) when the drive is behind a raid controller:

github.com/rockstor/rockstor-core

extend custom smart parameter support

opened 02:42PM - 28 Jun 16 UTC

phillxnet

enhancement

Currently -d and -T options are supported; however in some instances it may be u…seful to support the: "--set" parameter such as to provide a work around for those drives where the hdparm command is unable to set spin down times due to certain LSI controllers not implementing this function of hdparm. N.B. The --set variant is suggested to avoid the ambiguity of it's short variant "-s" which is a shared short reference with the --smart option. Note that additional documentation within the Web-UI will be required so as not to confuse this 'work around' with the main drive spin down feature. Ie indicate that the "--set standby,60" type options should only be added where an "unknown" is displayed in the 'Power Status' column on drives attached to a raid controller for example. N.B. this setting in the context of raid controller custom smart options shares the need to have a custom device name and controller port specified; such as with other LSI specific custom SMART options. Eg: ``` smartctl -d 3ware,1 --set standby,120 /dev/twl0 ``` For port 1 attached device on the first LSI controller (/dev/twl0 type). This needs further investigation / testing as the custom SMART options as currently implemented are applied on every smart call and it needs to be determined if this call itself causes the drives to spin up. In which case it's facility is negated by the poling used in determining basic smart support / status. In which case a move to event driven drive state change would be required first. Input validation could be extended akin to the existing mechanisms with absolute "--set" parameters checked against an array as per the current checks ie: ``` var standbyOptions = ["standby,off", "standby,0", "standby,12", "standby,60", "standby,120", "standby,240", "standby,241", "standby,242", "standby,244", "standby,248", "standby,253"]; ``` and the consequent isStandbySwitch(option) function and isNotStandbyOption(option) function in:- src/rockstor/storageadmin/static/storageadmin/js/views/smartcustom_disks.js

Your drives by-id names can be listed via:

ls -la /dev/disk/by-id/

and are the names displayed in the Name column of the Disks page, remember to supply the path.

This is a currently not a directly related issue, ie hdparm is used for the Power Status and APM columns where as smartctl is used to establish if we can gain smart info for use in the pages that appear when you click on a drives names: as shown in our S.M.A.R.T doc section. If the smart column doesn’t show as “Not supported” and the smart pages show up ok then it would seem you don’t need custom smart options.

We have had a recent improvement on drive name validation which may affect your chosen custom smart options; see issue:

github.com/rockstor/rockstor-core

missing validation for megaraid custom smart option raid dev target

opened 09:30PM - 29 Jun 18 UTC

closed 12:42PM - 11 Jul 18 UTC

phillxnet

enhancement

Thanks to forum member coreybrett in the following forum thread for highlighting… this issue. When the following custom smart option for megaraid is entered "-d megaraid,0 /dev/sda" an input validation error is received. On initial inspection this appears to be down to an omission in the raidTargetRegExp variable defined within: src/rockstor/storageadmin/static/storageadmin/js/views/smartcustom_disks.js ie: ``` // RegExp patters for the following RAID target devices: // 3ware /dev/twe, /dev/twa, /dev/twl followed by 0-15 // Areca sata /dev/sg[2-9] but for hpahcisr and hpsa drivers /dev/sg[0-9]* (lsscsi -g to help) // so we still have an issue there. // HP Smart array with cciss driver uses /dev/cciss/c[0-9]d0 var raidTargetRegExp = [/\/dev\/tw[e|a|l][0-9][0-5]{0,1}$/, /\/dev\/sg[0-9]$/, /\/dev\/cciss\/c[0-9]d0$/]; ``` It is proposed that the indicated regex variable raidTargetRegExp be extended to accommodate the megaraid legitimate sda / sdb type dev names. Please update the following forum thread with this issues resolution: https://forum.rockstor.com/t/configure-smartmontools-for-dell-perc-h700/4923 Note that a caveat of the proposed approach is that we assume sda / sdb dev name stability in this context.

which has been initially addressed by pull request:

github.com/rockstor/rockstor-core

missing validation - megaraid custom smart option raid dev target. Fixes #1942

rockstor:master ← phillxnet:1942_missing_validation_for_megaraid_custom_smart_option_raid_dev_target

opened 06:30PM - 06 Jul 18 UTC

phillxnet

+18 -6

Adds previously missing '/dev/sd[a-z]' raid target device regex. This type of de…vice is a valid target for megaraid, aacraid, and hpt drivers. Summary: - Add /dev/sd[a-z] regex (as above). - Add code comments for the above. - Add convenience raid target device regex of 'autodev': explicitly substitutes current disk by-id name (full path). Considered more robust than the above 'hard wired' device name option. - Enhance custom S.M.A.R.T options pre-processor, get_dev_options(), to handle the above 2 additional raid target device options. - Document the 'autodev' option on the "Add drive specific custom S.M.A.R.T options" page. - Improve / correct html formatting on the "Add drive specific custom S.M.A.R.T options" page. Fixes #1942 @schakrava Ready for review. Tested by observing the resulting smartctl command line post pr: -d megaraid,0 /dev/sda results in expected: /usr/sbin/smartctl -c -d megaraid,0 /dev/sda and: -d megaraid,0 autodev results in expected: /usr/sbin/smartctl -c -d megaraid,0 /dev/disk/by-id/ata-QEMU_HARDDISK_bcache-bdev-1 Caveats. The 'autodev' option is actually redundant given our existing input validation for custom smart options allows for no target raid device; and results in the same behaviour. However it was though more proper to add this options as future improvements in input validation may remove this 'loop hole' and the 'autodev' option's function is explicit. Testing note: The tests performed were strictly syntactic as no megaraid, hpt, or aacraid hardware was available at the time of development. However our existing S.M.A.R.T custom options have so far behaved as expected when directed to by-id names, but this is not a guarantee that the same is true for the given raid drivers target device parameter.

which was merged as part of Rockstor version 3.9.2-30 so fairly recently.

Looks like this may have impact on our parsing of LSI dev names also. The original forum member reporter of the megaraid dev parsing issue, @coreybrett, has yet to confirm the effectiveness or otherwise of these recent changes to the dev name parsing in our custom smart options re the megaraid option:

Hope that helps and lets see what your hdparm command is returning for those unknown / active drives, ie you could test the hdparm command for the drives while they are either unknown or active (if I have understood your description correctly).