Jump to content

magg1e16

Members
  • Posts

    6
  • Joined

  • Last visited

Posts posted by magg1e16

  1. Thanks for your work on this! It's been such a great help.

     

    I would appreciate some insight into what I'm doing wrong.

    I installed git through the console from the Docker Containers page

    I then attempted to run the following code within a notebook:

    import sys
    !{sys.executable} -m pip install git+git://github.com/okpy/ok-client

     

    But I get the below error:

    ERROR: Command errored out with exit status 1: git clone -q git://github.com/okpy/ok-client /tmp/pip-req-build-xyzkbync Check the logs for full command output.

     

    I couldn't find the log file and when I ran the same code within the web version of jupyter notebooks, it installs as expected without error.

    Is this a docker limitation? Or did I miss a very key step?

     

    Thank you in advance

     

    EDIT:

    In case anyone else runs into this issue, run 'git --version' within the console from the Docker Containers page. This command told me that I did not have a required package installed. After installing said package and running 'git --version', I was provided the installed git version and the above code now executes properly.

  2. 7 hours ago, doron said:

    I presume the plugin is installed?

    Yes, plugin installed. I should correct my statement and say there were no further lines referencing SAS Assist after initial install/initialization

    Unless I've missed a really key set-up step, I don't have the option to spin down the UD SAS HDD. Hovering over the balls don't produce a tool-tip.

    I believe Unraid 6.9.0 uses emhttpd to spin-down UD HDD, so maybe if I were to upgrade I would be able to click to spin down?

     

    I did both tests, in case that's helpful

     

    # sg_start -rp3 /dev/sdb && sdparm -C sense /dev/sdb
        /dev/sdb: SEAGATE   ST33000650SS      0003

    sas-util-out

  3. 15 hours ago, doron said:

    Thanks for the kind words. What we've been seeing is kind of hit and miss, so no strict verdict re a certain series of HDDs; you may want to just try.

    Re the specific issue, some of the Seagate documentation seems to imply that power mode 3 (the mode we're setting the drive into) is implemented as needing an explicit command to spin the drive back up. This does not jive too well with how Unraid is expecting things to behave (basically, it is expected that a subsequent i/o to the drive will implicitly spin it back up). 

     

    Bottom line, you may want to give it a try and see.

     

    You can also use the provided sas-util (bundled with the plugin at /usr/local/emhttp/plugins/sas-spindown/sas-util, or you can take it from here), with the parameter "test", to try and predict how things will work. (Unfortunately, even this test is not 100% accurate - I have at least one happy camper whose SAS drives merrily spin down and up with the plugin, but still fail the test...). If you do, please post (or pm) the resulting file.

     

    Happy 2021!

    After reading this thread, I should have realized that just testing it was the best way to know.
    In case it's useful, I'm on Unraid 6.8.3 using Unassigned Devices + ZFS with my SAS drives, no SAS drives in Unraid array.

     

    I ran "sg_start -r --pc=3 /dev/sdb" last night, waited a bit and ran  


    # sdparm --command=sense /dev/sdX
        /dev/sdX: SEAGATE   ST33000650SS      0003


    Didn't look like the spin-down occurred. I didn't see anything in System logs with SAS Assist, spin down
    Checked system log again this morning and nothing new, but the drive did spin down (gray balled) and I get the below when I checked this morning

     

    #  sdparm --command=sense /dev/sdb
    open error: /dev/sdb [read only]: No such file or directory
    # sg_start -r --pc=0 /dev/sdbsas-util-out
    sg_start failed: No such file or directory

     

    So, the drive did spin down sometime last night, but spin-up failed and I didn't see anything in system logs.

     

    EDIT: I restarted my computer (after re-attaching all the cables) and the drive successfully came back online

    "/usr/local/emhttp/plugins/sas-spindown/sas-util test" output attached, matches my findings that spin-down request wasn't followed

     

  4. On 10/6/2020 at 9:20 AM, doron said:

    This manual for this drive (in fact, the entire Constellation ES.3 series) seems to indicate (sec 6.1) that an explicit NOTIFY needs to be sent to the device to recover from the spindown mode we're sending the device into (Standby_Z). 

    This is in contrast with other devices tested (e.g. WD/HGST) that automatically spin up when sent to this state.

     

    Has anyone seen positive results with this drive and this plugin?

     

    We might end up having to enumerate the drive types where this works well vs. those that fail, and build a white list in the plugin. Nasty 😞

     

    Can I get brief messages here from anyone who's using (or tried using) the plugin, reporting success/failure? Just a one liner with:

    <HDD Model> <Success/Failure> (<optional comment>)

    would be great. Example;

    
    HUH721212AL4200  Success

    PM would also work if you don't want to post. Thanks!

    @doron this plugin looks amazing, great work!

    I have Constellation ES.2 series SAS HDD, documentation has the same note about requiring explicit NOTIFY being sent to device to recover from spindown

    Is this something outside the scope of this plugin? I don't really understand what the explicit NOTIFY entails.

    Thanks again and happy holidays

×
×
  • Create New...