• [SOLVED] Parity Check way slower with RC2 than RC1.


    matty2k
    • Closed

    Not sure if this issue is related to RC2, but I realized, that my last parity check while on RC1 was a lot faster than may recent parity check on RC2.

    I have attached the diagnostics too, but do not experiencing any problems. Array configuration did not change. All drives are still the same. Some more data is now stored on the drives, but not double (what also would not significantly influence the time).

    Actually I only set up syslog server and storing syslog on USB flash for investigating two reboots in the past.

    I have also realized decreased speed when copy data with krusader from disk share to diskshare.

     

    image.thumb.png.53ae816aa9dee0cd0587fab49bdb8d37.png

    nasa-diagnostics-20211214-1934.zip




    User Feedback

    Recommended Comments

    250MB/s average speed is impossible with the currently assigned array devices, it's most likely the result of an 8TB rebuild and an old bug, speed shown considers the full parity size vs the actual size rebuilt.

    Link to comment

    100MB/S is realistic depending on the type of drives your are using.

     

    One other factor that can screw the displayed speed of the check is pausing the check. I think it only considers the time after the check was resumed but still the complete capacity.

    It looks like that's what happen to you from the picture.

     

    Here is an example from my history:

    image.thumb.png.ef3aa040b7362f1e063c6d7d794afdd3.png

    Link to comment

    When the parity check is paused midway, it will show the duration and speed calculation from the point it is resumed.

    This results in an incorrect number, which is the case here.

     

    My parity-check log shows rc2 achieves the same speed as earlier versions (including rc1).

     

    Link to comment
    1 hour ago, bonienl said:

    Next Unraid version will have the correct values when parity check is paused and resumed.

    Just for interest will this be for the whole run or just the last increment?  Just asking to see if I might need to revisit the code in the Parity Check Tuning plugin that tries to give the correct values for the run as a whole.

    Link to comment

    The GUI keeps track of pause and resume times, it uses these together with the existing vars to calculate the correct duration and speed.

     

    This won’t affect your plugin.

     

    Link to comment
    1 hour ago, JorgeB said:

    would it be possible to also fix this long standing bug?

     

    You have the memory of an elephant :)

    Seems simple, but isn't straightforward to solve. I put it on my todo list!

    • 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.