Jump to content
itimpi

[Plugin] Parity Check Tuning

92 posts in this topic Last Reply

Recommended Posts

For general reference the diagnostic information that @vw-kombisupplied showed that the plugin is not updating the history correctly when errors were reported/corrected during the parity check.  The history will always show 0 errors until I issue a corrected version of the plugin. 

Share this post


Link to post
Posted (edited)

The plugin should low update the error count in the parity history for any future checks.

 

In addition I have exposed some functionality at the CLI level that some may find helpful.   

Usage: parity.check <action>
where action is one of
  pause            Pause a rumnning parity check
  resume           Resume a paused parity check
  check            Start a parity check (as Settings->Scheduler)
  correct          Start a correcting parity check
  nocorrect        Start a non-correcting parity check
  status           Show the status of a running parity check
  cancel           Cancel a running parity check

I would be interested any feedback on this feature.

Edited by itimpi

Share this post


Link to post

Has the statistics report (time, speed, etc) been updated to carryover after a pause, or is it still just for the currently running check?

 

Just trying to keep track of the changes.😁

Share this post


Link to post
13 minutes ago, wgstarks said:

Has the statistics report (time, speed, etc) been updated to carryover after a pause, or is it still just for the currently running check?

 

Just trying to keep track of the changes.😁

Not quite sure what you are asking?   If you are talking about the parity history then the plugin has always updated it to be correct for the run as a whole - not just the last increment.   It was already doing this for duration, speed etc, but there was a bug (now fixed) where this was not being done for the error count.  

 

While writing this it has just occurred to me that the parity check history does not currently show whether a run was correcting or non-correcting - would it be useful to have this displayed in the history as well? It should be an enhancement I could make to the plugin easily enough.

Share this post


Link to post

I know that originally if a check was paused the elapsed time would reset to zero after the check was resumed. I had assumed this would also effect the averaged speed, but that may be a mistake on my part, and possibly this has all been corrected already.

Share this post


Link to post
11 minutes ago, wgstarks said:

I know that originally if a check was paused the elapsed time would reset to zero after the check was resumed. I had assumed this would also effect the averaged speed, but that may be a mistake on my part, and possibly this has all been corrected already.

you need to distinguish what the core Unraid system does and what the plugin does.    Core Unraid seems to reset for each increment, but when the plugin is handling the pause/resume process it keeps track of how each increment went and then on completion it calculates the figures for the run as a whole and this is what ends up in the history.

Share this post


Link to post
17 minutes ago, wgstarks said:

that may be a mistake on my part,

Well then, I was correct. It was a mistake on my part.😀

 

Thanks for the explanation. I know there isn’t much the plugin can do to correct the core functionality, and honestly, the stats for a running check have never been very accurate due to the speed changes across the disk itself (and I’m sure many other factors).

Share this post


Link to post

So far this seems to function as expected. I have issues with heat, particularly during parity checks, on my system and have enabled that feature as well to see if it will help. 

Share this post


Link to post
47 minutes ago, jmcconathy said:

So far this seems to function as expected. I have issues with heat, particularly during parity checks, on my system and have enabled that feature as well to see if it will help. 

I will be interested to see how well this works.   My tests were a little artificial as my system does not suffer from heat problems.

 

if you have any problems then please enable the debugging log option in the plugin settings and then let me have a copy of the syslog so that I can see what is going on.

Share this post


Link to post

Hi there. Thanks for your time creating this plugin, I'm excited to try it out. My current parity checks only take about 10 hours, but I'm looking at upgrading to some bigger drives this fall, so this plugin should come in handy.

 

Based on my settings in my screenshot, I'm expecting the parity check to start Sept 30th (last day of the month) at 10pm, then pause at 4am on Oct 1st, then resume Oct 1st at 10pm, and repeat until finished. Does that look right?

parity_tuning1.png

Share this post


Link to post

Yes - you should get the behaviour you want.   In this case the check should finish during the second increment if there are no problems.   With bigger drives you would get more increments as the total execution time increases.

Share this post


Link to post
On 9/29/2019 at 6:20 AM, itimpi said:

Yes - you should get the behaviour you want.   In this case the check should finish during the second increment if there are no problems.   With bigger drives you would get more increments as the total execution time increases.

Worked perfectly, thanks!

Share this post


Link to post

I just finished using this plugin to split up a monthly parity check. I have my normal parity check schedule set to correct errors, however, both the notifications during the parity check and the parity.check.tuning.progress.save file are showing non-correcting parity checks.

 

paritychecksettings.png

 

type|date|time|sbSynced|sbSynced2|sbSyncErrs|sbSyncExit|mdState|mdResync|mdResyncPos|mdResyncSize|mdResyncCorr|mdResyncAction|Description
STARTED|2019 Oct 20 00:00:01|1571544001|1570408676|1570493018|0|0|STARTED|0|0|7814026532|0|check P|Non-Correcting Parity Check|
PAUSE|2019 Oct 20 07:30:01|1571571001|1571544001|0|0|0|STARTED|7814026532|2851442360|7814026532|1|check P|Non-Correcting Parity Check|
RESUME|2019 Oct 21 00:00:06|1571630406|1571630401|0|0|0|STARTED|7814026532|2851930044|7814026532|1|check P|Non-Correcting Parity Check|
PAUSE|2019 Oct 21 07:30:01|1571657401|1571630401|0|0|0|STARTED|7814026532|5397770972|7814026532|1|check P|Non-Correcting Parity Check|
RESUME|2019 Oct 22 00:00:06|1571716806|1571716801|0|0|0|STARTED|7814026532|5398227420|7814026532|1|check P|Non-Correcting Parity Check|
COMPLETED|2019 Oct 22 07:30:01|1571743801|1571716801|1571741144|0|0|STARTED|0|0|7814026532|1|check P|Non-Correcting Parity Check|

 

Share this post


Link to post

I’ll check this out.    Showing the type of the parity check in the history is a recent addition to the plugin and it is possible it could be getting it wrong.  
 

Note that the plugin specifically does NOT use the configured setting but attempts to derive it from other sources during the parity check.   This is because there are scenarios under which the check cannot do exactly what is scheduled and it silently runs a reduced variant of the check.

 

EDIT:  Found the cause - silly mistake on my part.   Will check out the fix and then release an updated plugin

Edited by itimpi

Share this post


Link to post

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
Reply to this topic...

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