• Since update to 6.9.1 from 6.8.3 powerdown restarts with a parity check and parity check is slow.


    Rudder2
    • Closed Annoyance

    Ever since I upgraded from 6.8.3 to 6.9.1 if I shutdown the server with the /usr/local/sbin/powerdown or reboot the server with /usr/local/sbin/powerdown -r when the system reboots it always performs a parity check like it didn't cleanly shutdown.

     

    Also, my Parity check average is 66 MB/s instead of 116 MB/s like it was on 6.8.3.

    • Like 1



    User Feedback

    Recommended Comments

    56 minutes ago, Rudder2 said:

    So what about the Parity Check being 50% of the speed since the update?

     

    In order to avoid having to guess why don't you post your diagnostics?

     

    Link to comment
    20 minutes ago, John_M said:

    In order to avoid having to guess why don't you post your diagnostics?

    Figured it happened during the update so y'all would know what you did that could of caused that...

     

    14 minutes ago, JorgeB said:

    Downloaded during a parity check please.

     

    Parity check will start Thursday Evening if it doesn't start with the automated reboot like it has been.  Will do it Friday AM so Parity Check has been running 12 hours or so.

     

    I wouldn't of EVER downloaded a Diagnostics with a Parity check running till you asked for it.  Never would of crossed my mind because I try to not do anything with my server, other than the automated stuff which I have non critical stuff not happen during Parity Check or Rebuild. 

    Link to comment

    unRAID usually works.  When it doesn't I know Linux so usually can fix it myself.  I've very rarely had a problem since I started running unRAID the July of 2014 so I'm not verse on getting help...Sorry about that...Would think that this is a testament to the quality LimeTech offers unRAID as a Server OS.

    Link to comment
    On 3/18/2021 at 2:44 AM, JorgeB said:

     

    On 3/21/2021 at 9:25 AM, Rudder2 said:

    I just tried this.  Will see how it works when I have my automated restart Wednesday AM.

     

    So what about the Parity Check being 50% of the speed since the update?

    I can confirm that this worked for fixing the Parity Check after clean shutdown. 

     

    I will gather the Diagnostic Data Friday AM and upload it to see if we can figure out why my Parity check is now ~50% the speed after updating from 6.8.3 to 6.9.1.

    Link to comment
    On 3/21/2021 at 10:25 AM, John_M said:

     

    In order to avoid having to guess why don't you post your diagnostics?

     

    Here's the Diagnostics 10 Hours in to the Parity Check running on 6.9.1.  On 6.8.3 the Parity Check would be complete in 4 hours...It won't be...It's estimating 13 more hours to go when it use to only take 14 HRS and 30 Minutes.

    image.thumb.png.ff39c8bc3740eb4ea1b03e9dbb4dd6f4.png

    image.png.e5188ba0254556ecc0629250987463d3.png

    rudder2-server-diagnostics-20210326-0913.zip

    Link to comment

    Nothing jumps out, on the console please type:

     

    lspci -vv > /boot/lscpi-vv.txt

     

    Then attach the file here.

    Link to comment
    1 hour ago, JorgeB said:

    Nothing jumps out, on the console please type:

     

    
    lspci -vv > /boot/lscpi-vv.txt

     

    Then attach the file here.

    This is what I got:

    # lspci -vv > /boot/lscpi-vv.txt
    pcilib: sysfs_read_vpd: read failed: Input/output error
    pcilib: sysfs_read_vpd: read failed: Input/output error
    pcilib: sysfs_read_vpd: read failed: Input/output error

    Link to comment
    2 minutes ago, JorgeB said:

    That's weird, did you copy/paste? If yes don't, sometimes the forum introduces extra characters.

     

    Just typed it instead of coping and pasting and received the same result.

     

    Link to comment

    It's a problem with saving the file.  I can copy and paste the screen print...

     

    Nevermind...It's truncated.

    Edited by Rudder2
    Link to comment

    All the LSI controllers are linking at normal speed/with so it's not that, there's a high load on the server though, if you shutdown all dockers/VMs does it help?

    Link to comment

     

    1 hour ago, JorgeB said:

    All the LSI controllers are linking at normal speed/with so it's not that, there's a high load on the server though, if you shutdown all dockers/VMs does it help?

    Stopped VM and all containers without a change in Parity Check Speed.

    Link to comment

    No idea them, sometimes a little slowdown with a new release is normal, but not like that, lets see if other users with similar hardware have the same issue.

    Link to comment
    9 hours ago, Excessus said:

    I've got the same reduction in parity checks.  Sitting around 90 megs/sec vs 160 before.

    Please post the diagnostics to see if there's any common hardware.

    Link to comment
    7 hours ago, JorgeB said:

    Also check this:

     

    Preliminary check makes me think this might of been the problem.  I will report back Friday when my Parity Check Starts.  I just created a user script to issue "echo active > /sys/devices/system/cpu/intel_pstate/status" command every Wednesday @0500, 30 minutes after my automated reboot, to see how it works, I don't like messing with the GO file unless I have to.

     

    My CPU was locked at 1200 MHz instead of being able to go to 3000 MHz as needed. I noticed my Gaming VM, Web UI, and SMB shares were sluggish but didn't think much of it till I read that thread you posted.  After running "echo active > /sys/devices/system/cpu/intel_pstate/status" from the SSH Terminal  my WebUI, Gaming VM, and SMB shares are snappy again. 

     

    I have the Tips and Tricks plugin installed and my only CPU governor options are Power Save, Performance, or Scheduled.

    Edited by Rudder2
    Link to comment
    On 3/29/2021 at 6:41 AM, JorgeB said:

    Also check this:

     

    I can confirm this is the problem.   Issuing "echo active > /sys/devices/system/cpu/intel_pstate/status" command fixed the parity check speed problem also.  I've also noticed my server idles @ 10% instead of 35% after issuing the command.  Guess this command goes in to the GO file.

    Screenshot_20210402-090659_Brave.png

    Link to comment

    Yup, it's for sure was the power save governor issue. Thank you for your help. Never would of figure this out on my own.

    Screenshot_20210403-191350_Brave.png

    Link to comment

    Changed Status to Closed

     

    Linux Kernel issue, not an unRAID issue.

    Edited by Rudder2
    • Like 1
    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.