• [6.9.2] Parity Drive will not spin down via GUI or Schedule


    SimonF
    • Minor

    Since upgrading to 6.9.2 I cannot spin down parity via GUI, as soon as I spin down it comes back up.

     

    Apr 8 10:18:45 Tower emhttpd: spinning down /dev/sdf
    Apr 8 10:18:58 Tower SAS Assist v0.85: Spinning down device /dev/sdf
    Apr 8 10:18:58 Tower emhttpd: read SMART /dev/sdf

     

    Revert to 6.9.1 issue no longer happens.

     

    I can manually spin down the drive. All other array drives which are also SAS spin down fine.

    root@Tower:~# sg_start -rp 3 /dev/sdf
    root@Tower:~# sdparm -C sense /dev/sdf
        /dev/sdf: SEAGATE   ST4000NM0023      XMGJ
    Additional sense: Standby condition activated by command

     

     

    Also is it possible to get an updated version of smartctl added.

     

    Will continue to do more testing.

     




    User Feedback

    Recommended Comments



    3 minutes ago, SimonF said:

    Yes bonienl was sata drives non Seagate via Adaptec HBA

    Ah yes, should have re-scanned the thread.

    It's really curious why some setups (e.g. mine) do not experience this phenomena at all. My drives are WDC 4TB and WD/HGST 12TB, on an LSI/SM SAS controller. They spin up/down perfectly, same as they did in 6.9.1.

    Link to comment
    14 hours ago, doron said:

     

    Curious: Does anyone have this problem in 6.9.2 or in 6.10.0-rc1 with drives that are not Seagate?

    Trying to narrow down on the root cause.

    Yeah, I have a mix and match between seagate and WD. But still, it is still working for me in 6.10 RC1 but I wonder if this is just because some plugin didn't update yet or why it is. It is mindboggling when something suddenly works and you don't know why.

     

    Edit: Somehow my server has sensed, that I just made that comment and started spinning disks up without any reason again. It's getting really annoying... Come on, please sort this out.

    Edited by RedXon
    Link to comment

    My drives still do not spin down with the new 6.10 RC1 automatically or manually.  Will we be forced to buy a new controller / controllers because the bug can not / will not be addressed?    more information from @limetech would be very helpful.  Especially a timeline to resolution. 

     

      

    Link to comment

    I don't know if a new controller would solve this problem, as I have seen people with different controllers who had or have this problem. So I use two Dell Perc H310 flashed as LSI Megaraid 9211-8i with 12 disks in total. Then I have two parity disks on the onboard Sata connectors. And others just use the onboard connectors and have a similar problem. So I don't know if a controller swap would really solve this problem.

     

    I could try some other stuff but I am currently in a rebuild due to a disk failure so I can only try after this has concluded of course. 

    Link to comment

    If you are using the SAS plugin update to 0.86 which fixes the spin down issue for me. Thanks to @doron with assistance to fix the issue.

    Link to comment
    5 hours ago, SimonF said:

    Changed Status to Solved

    The thread is pretty long and the issue was reported by many users with sata drives. I am not using SAS drives with my Dell H310. I upgraded to 6.92 and had to revert back to 6.91 earlier this year due to this issue. I don't think the original issue is resolved yet. 

    Link to comment

    @limetech Issue for SAS devices is resolved, but some issues for SATA still exist, as I don't have a system with the issue its difficult for me to troubleshoot.

     

    @bonienl The sdspin status process for me was spinning up the disk, are you able to do the following test on your system to see if it is the same root cause or is a different one.

     

    /usr/local/sbin/sdspin /dev/sdx down

    echo $?

    /usr/local/sbin/sdspin /dev/sdx

    echo $?

     

    It should come back as "2" for the second echo.

     

    For 'status'

    0 => operation successful (device is in spun-up state)

    1 => error (spinning state unknown)

    2 => operation successful (device is in spun-down state)

     

    Link to comment

    For me nothing worked, not the plugin, no settings no nothing. I have two servers, one works the other doesn't. The difference of these two is that one is using 9211 cards, the other just onboard sata. And that one has a fairly old install and the other is pretty fresh. 

     

    I have reported it here with my diagnostics, but have not heard something yet.

    So yes, not solved for me. Not even close. And I have no idea what else to try and downgrade seems a little scary to me. 

    Link to comment
    3 hours ago, RedXon said:

     I have two servers, one works the other doesn't. The difference of these two is that one is using 9211 cards, the other just onboard sata.

    Just to be crystal clear: The server that demonstrates the issue is the one with the two 92xx controller(s), whereas the one that doesn't uses onboard SATA?

    Link to comment

    Yes. My main server has two 9211-8i controllers with a total of 12 disks plus 4 SSDs on the onboard controller. It runs on 6.10 RC-1 now because I hoped it would resolve the issue. The server itself is a couple of years old, has been upgraded a couple of times so the flash has been created I think about 3 years ago. It used to spin down but now it's broken for a while and I don't clearly remember when it did to the spindown fine last time. Disks are a mixture of WD Red, Seagate Ironwolf and Seagate Exos.

     

    The other server, the one that does spindown, only uses the onboard SATA Controller of the Asus P10S-M. It only has 3 disks plus SSD, all of which are Seagate Exos. It is running on 6.9.2 and has been installed and set up about a month ago. It has worked fine ever since. 

    Link to comment

    In the "problematic" server, do all of the drives demonstrate this phenomena? Both the Seagates and the WDCs?

    If you try to spin down one of the WDCs, do you also see a "spinning down" and an immediate "read SMART /dev/sdX" in syslog?

     

    Also: from the diag you posted (unless I'm mistaken) it appears as some of the drives on that server are connected via onboard SATA (e.g. sdb). Do these also demonstrate the same problem in the same way?

    Link to comment

    Yeah, the 2 parity drives (sdb and sdc) are attached on the board. I don't know if the behavior is because of that or because they are parity discs but they do spin up frequently but not as fast as the data drives. It could be that they are legitimately spin up because there is some activity. 

     

    All the other drives however spin up fast, within minutes. Regardless of the make of the drives. This is the last time I tried it:

     

    Aug 18 13:13:56 Azeroth emhttpd: spinning down /dev/sdm
    Aug 18 13:13:57 Azeroth emhttpd: spinning down /dev/sdq
    Aug 18 13:13:58 Azeroth emhttpd: spinning down /dev/sdp
    Aug 18 13:13:59 Azeroth emhttpd: spinning down /dev/sdo
    Aug 18 13:14:00 Azeroth emhttpd: spinning down /dev/sdn
    Aug 18 13:14:00 Azeroth emhttpd: spinning down /dev/sdi
    Aug 18 13:14:01 Azeroth emhttpd: read SMART /dev/sdq
    Aug 18 13:14:07 Azeroth emhttpd: spinning down /dev/sdf
    Aug 18 13:14:08 Azeroth emhttpd: spinning down /dev/sdk
    Aug 18 13:14:09 Azeroth emhttpd: spinning down /dev/sdh
    Aug 18 13:14:09 Azeroth emhttpd: spinning down /dev/sde
    Aug 18 13:14:20 Azeroth emhttpd: read SMART /dev/sdf
    Aug 18 13:15:12 Azeroth emhttpd: read SMART /dev/sdn
    Aug 18 13:15:24 Azeroth emhttpd: read SMART /dev/sdo
    Aug 18 13:16:03 Azeroth emhttpd: read SMART /dev/sde
    Aug 18 13:16:40 Azeroth emhttpd: read SMART /dev/sdh
    Aug 18 13:16:50 Azeroth emhttpd: read SMART /dev/sdk
    Aug 18 13:17:41 Azeroth emhttpd: read SMART /dev/sdp
    Aug 18 13:20:56 Azeroth emhttpd: read SMART /dev/sdm
    Aug 18 13:21:21 Azeroth emhttpd: read SMART /dev/sdi

    No other infos in the log.

    Link to comment

    Thanks.

     

    Okay, this looks a bit different from the issue that was reported by others (aka the wild goose 🙂 ).

    Generally speaking, your drives seem to spin back up "a while" after being spun down, rather than "immediately".

    So while e.g. sdq spins up only 4 seconds after being put to sleep, sdm takes 7 minutes, sdp takes 3.5 minutes and sdi also sleep for 7 minutes before waking up.

     

    In this case, I'd look for real disk activity that's happening. Look at the i/o counters, check whether they increase when the disk spins back up, and figure out what activity is taking place. My current guess is that you have something going on that actually reads/writes to your array.

    Link to comment

    It is increasing but I have no way of finding out what it is, as Active Streams show nothing and File Activity also shows nothing. It doesn't seem to be anything running and also no docker directly does something on the disks unless needed. So yeah, I'm at a loss of ideas. That's why I originally started the other thread but it looks like no one has any idea there either. 

    Edited by RedXon
    Link to comment

    I loaded the SAS plug-in and my drives connected to my Areca 1882’s are NOT spinning down. The two party drives connected to the main board are spinning down like they always did.  (The parity drives were never the problem for me)

     

    i bounced the box yesterday to perform a fresh load of the plugins and the system when into a parity check ….  
     

    I paused it and waited and no drives spun down .  
    I tired to manually to spin them down … Not working 

    I resumed the parity check … still running . I will report when it is completed

    As I saw this topic is “solved” should I/we start a new one to continue the problem resolution discussion ?

    Edited by chris0583
    Link to comment
    13 minutes ago, chris0583 said:

    I loaded the SAS plug-in and my drives connected to my Areca 1882’s are NOT spinning down.

    What drives do you have (those that are not spinning down)?

    When you look at the log, are you seeing "spinning down" and immediately thereafter "read SMART" for these drives?

    Link to comment
    2 hours ago, doron said:

    What drives do you have (those that are not spinning down)?

    When you look at the log, are you seeing "spinning down" and immediately thereafter "read SMART" for these drives?

     

    All Segate

     

    image.png.ec073e677a4475c320a1e9a89788772c.png

    image.png

    Link to comment
    3 hours ago, chris0583 said:

    As I saw this topic is “solved”

    I have re-open the thread as forgot some where having issues with SATA also.

     

    Can you povide the output from these commands?

     

    /usr/local/sbin/sdspin /dev/sdx down

    echo $?

    /usr/local/sbin/sdspin /dev/sdx

    echo $?

     

    Once your parity check is complete

     

    Edited by SimonF
    Link to comment
    6 hours ago, chris0583 said:

    All Segate

     

    Your drives are SATA. The SAS Spindown plugin will not do anything for you, unfortunately (will do no harm either) - it deals exclusively with SAS drives.

     

    I'm assuming the screenshots you attached are from a 6.10.0-rc1 system? Please correct me if I'm wrong, this is an important data point.

     

    If the assumption above is correct, then

    (a) This seems to be the exact same issue that started at 6.9.2; apparently it remains in 6.10.0-rc1

    (b) Apparently this does not have to do with the mpt2sas module (its version in 6.9.1 and 6.9.2 is the same, while in 6.10.0-rc1 there's a newer version. Problem did not exist in 6.9.1).

    (c) Need to look for another change that happened between kernels 5.10.21 and 5.10.28.

     

    Meanwhile, would you mind selecting one of the drives that does not have any activity against it, and on an Unraid command shell, issue these commands (replace /dev/sdX with the drive you selected):

    hdparm -y /dev/sdX
    hdparm -C /dev/sdX
    sleep 1
    hdparm -C /dev/sdX

    (yes, the last two hdparm commands are identical)

    and post the output?

     

    Link to comment

    As I also have a problem I cannot identify and can't interpret the result of it I also bite:

    Quote

    Can you povide the output from these commands?

     

    /usr/local/sbin/sdspin /dev/sdx down

    echo $?

    /usr/local/sbin/sdspin /dev/sdx

    echo $?

    First echo is 0, second gives me 2, the disk stays green in the WebUI though. 

     

    Quote

    hdparm -y /dev/sdX

    hdparm -C /dev/sdX sleep 1

    hdparm -C /dev/sdX

    /dev/sdm:
     issuing standby command

    /dev/sdm:
     drive state is:  standby

    /dev/sdm:
     drive state is:  standby

     

    Also, the drive stays green in the WebUI

    Link to comment
    32 minutes ago, RedXon said:

    As I also have a problem I cannot identify and can't interpret the result of it I also bite:

    First echo is 0, second gives me 2, the disk stays green in the WebUI though. 

     

    /dev/sdm:
     issuing standby command

    /dev/sdm:
     drive state is:  standby

    /dev/sdm:
     drive state is:  standby

     

    Also, the drive stays green in the WebUI

    That's standard behavior of the UI (when you spin down a drive using CLI, the UI doesn't immediately "notice" as it's not aware this was done under the hood). The fact that you keep getting a "2" or "standby" with these commands basically means that your drive is indeed spun down.

     

    I would guess that if, instead of using these CLI commands, you'd spin the disk down from the UI by clicking the green button, it will turn grey.

    Link to comment
    13 hours ago, RedXon said:

    As I also have a problem I cannot identify and can't interpret the result of it I also bite:

    First echo is 0, second gives me 2, the disk stays green in the WebUI though. 

     

    /dev/sdm:
     issuing standby command

    /dev/sdm:
     drive state is:  standby

    /dev/sdm:
     drive state is:  standby

     

    Also, the drive stays green in the WebUI

    As doron said looks normal, maybe worth posting diags in a new thread. It may be a plugin/docker or some thing else reading the disks.

    Link to comment



    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.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.