[Plugin] Parity Check Tuning


308 posts in this topic Last Reply

Recommended Posts

10 minutes ago, itimpi said:

This is implicit if I know how much time each increment was actually running for :)

 

Not understand, you know each increment start and end time. But I not sure if you could got the actual sector which have process. If both parameter ( sector process and time duration ) could be get, then nice to show speed figure in each increment by that calculation. I notice some record speed show "unavailable" and I don't understand too.

Link to post
  • Replies 307
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Parity Check Tuning plugin   The Parity Check Tuning plugin is  primarily designed to allow you to split a parity check into increments and then specify when those increments should be run.

i have been working through all cases where this can happen in the code and I think I now have them all fixed in the version running on my test server.  There was a number of places in the code where

I have just pushed what I hope is the ‘fixed’ version of the plugin to GitHub.    Let me know if you notice any further anomalies/bugs.

Posted Images

6 minutes ago, Vr2Io said:

 

Not understand, you know each increment start and end time. But I not sure if you could got the actual sector which have process. If both parameter ( sector process and time duration ) could be get, then nice to show speed figure in each increment by that calculation. I notice some record speed show "unavailable" and I don't understand too.

At the moment there is no place to sensibly report the speed of each individual increment (although I have all the required information).   It does not seem right to add each individual increment to the parity history which has always recorded the detail for a single run.
 

one thing that occurs to me is that at the moment the History button on the plug-in Settings page just shows the same information that is on the History button on the Main page.  This could be changed (Or an extra button added) to display the history in a more detailed form including individual increment details. The question is what value this would add to decide if it is worth investing the time to implement such a feature.

Link to post

Got it, I misunderstand currently record each increment, but just not. My bad.

 

For add more detail or extra button, I haven't much comments, yes or no also fine, I agree implement or not depends on the actual value.

Link to post

Hello,

 

My server recently crashed, and I decided to do a parity check manually, I paused the check at about 3% thinking that the Parity Check Tuning will resume the parity at the schedule time (at night) but it never did.

I wonder if the parity check tuning ONLY works with the scheduled time on the parity check settings?
Below are my settings for the normal parity check:

image.png.69e73159240225e2fea15019d9b2be39.png

 

Is there any possibility that you can include the plugin to check manual parity check "start" or "pause", and then continue doing its work at the programmed time? This can be a good feature.

 

Thanks.

Link to post
24 minutes ago, hrv231 said:

Hello,

 

My server recently crashed, and I decided to do a parity check manually, I paused the check at about 3% thinking that the Parity Check Tuning will resume the parity at the schedule time (at night) but it never did.

I wonder if the parity check tuning ONLY works with the scheduled time on the parity check settings?
Below are my settings for the normal parity check:

image.png.69e73159240225e2fea15019d9b2be39.png

 

Is there any possibility that you can include the plugin to check manual parity check "start" or "pause", and then continue doing its work at the programmed time? This can be a good feature.

 

Thanks.


Have you enabled the option in the plug-in settings to apply pause/resume to manually started checks in addition to the automatically started ones?   The default setting is to not do so.
 

If you have and it is not happening then this is a bug that would need looking at.


 

Link to post
1 hour ago, itimpi said:


Have you enabled the option in the plug-in settings to apply pause/resume to manually started checks in addition to the automatically started ones?   The default setting is to not do so.
 

If you have and it is not happening then this is a bug that would need looking at.


 

My bad, it was set to NO.

Thank you for your time and all the help you bring to this forum!

Link to post

Reporting on some unexpected behavior.

 

Unraid version 6.8.3

Parity Check Tuning version 2021.01.19

 

See screenshot for my settings.

 

What happened

Parity check started early this morning as it was the 1st of the month. However, it's now 9am and the check is still going. I would've expected it to be paused.

 

This is the first time I've noticed this happening. Since my initial installation of the plugin, I haven't changed its settings. I've always had it set up this way and it's been fine.

 

2021-02-01 08_57_21-Tower_Scheduler.png

Link to post
14 minutes ago, blackf0rk said:

Parity check started early this morning as it was the 1st of the month. However, it's now 9am and the check is still going. I would've expected it to be paused.

Same symptoms here.

Link to post

I can only get my parity check to pause if i set "Use Increments for Unscheduled Parity Check:" to yes. Despite it being a scheduled event, I'm not sure why it won't pause unless setting this option to yes. I'm on Stable unraid with the latest plugin version.

Link to post

I will try and work out if there is a reason that checks may not be pausing.    If anyone is able to enable the “Testing” level of logging and can then let me have the syslog covering the period it will give me more to work with.   In addition the various ‘parity.tuning.*’ style files in the plugin’s folder on the flash drive might help.

 

It is possible I have already inadvertently fixed whatever is causing this behaviour as I have done a major re-factoring of the code internal to the plug-in as part of getting ready to release the first version of what I am calling the “Parity Problems Assistant” option.     This gives the ability to do partial parity checks over a user defined range to help those who get errors reported during parity checks.  

Link to post

Thanks for those files.    I can see from the .cron file that the cron job entry that should have been scheduled for scheduled pause/resume seems to not be present even though the .cfg file shows it is configured at the plugin settings.     This also shows why enabling unscheduled checks “appears” to sort of work as that is being picked up by a monitor task that runs once an hour.   I say “appears” as it would not run exactly at the time set in the settings for pause/resume as it would if the cron entries were correct.
 

That gives me enough information to make sure that the problem will not be present in my next update.

 

EDIT:  I have just done a test on my development 6.8.3 system and if you go into the plugin settings and make a change (can then change it back) and hit Apply you should get the correct entries in the parity.tuning.cron file.    If would like to know if that has worked for anyone currently getting unexpected behaviour.

Link to post

I'm puzzled by the notifications I found on my Dashboard this morning: a report that the parity check has concluded successfully, immediately followed by an error message from Parity Check Tuning that the parity check was aborted. (I am assuming that notifications are stacked newest uppermost.)

 

My guess is that Parity Check Tuning is assuming that if it is set to run in increments of (say) three hours, any cessation of the parity check short of that time is "an abort". If this is right, unless the whole parity run mod 3 isn't exactly zero we're always going to see this "abort" notice.

 

Can this be right? Please sanity check the conjecture from a relative newbie.

 

-- 

Chris

Parity Check Aborted.png

Link to post
17 minutes ago, bidmead said:

I'm puzzled by the notifications I found on my Dashboard this morning: a report that the parity check has concluded successfully, immediately followed by an error message from Parity Check Tuning that the parity check was aborted. (I am assuming that notifications are stacked newest uppermost.)

 

My guess is that Parity Check Tuning is assuming that if it is set to run in increments of (say) three hours, any cessation of the parity check short of that time is "an abort". If this is right, unless the whole parity run mod 3 isn't exactly zero we're always going to see this "abort" notice.

 

Can this be right? Please sanity check the conjecture from a relative newbie.

 

-- 

Chris

Parity Check Aborted.png

 

I got the same notification. Strange.

Link to post
3 hours ago, bidmead said:

I'm puzzled by the notifications I found on my Dashboard this morning: a report that the parity check has concluded successfully, immediately followed by an error message from Parity Check Tuning that the parity check was aborted. (I am assuming that notifications are stacked newest uppermost.)

 

My guess is that Parity Check Tuning is assuming that if it is set to run in increments of (say) three hours, any cessation of the parity check short of that time is "an abort". If this is right, unless the whole parity run mod 3 isn't exactly zero we're always going to see this "abort" notice.

 

Can this be right? Please sanity check the conjecture from a relative newbie.

 

-- 

Chris

Parity Check Aborted.png


this is much more likely to be a coding in the plugin where it is incorrectly saying it is aborted when it is not!

 

it is only recently that the plug-in has even tried to generate a message at the end of the parity check.   The idea is that it will be more correct than the Jnraid generated one.    I am trying to stop both notifications coming out but if the plug-in one is misleading it may be better in the short term that they both come out.

 

I would be interested in some feedback in what the parity history is saying for that particular check.   I think there is a good chance it will actually be correct.

Link to post
2 minutes ago, itimpi said:


this is much more likely to be a coding in the plugin where it is incorrectly saying it is aborted when it is not!

 

it is only recently that the plug-in has even tried to generate a message at the end of the parity check.   The idea is that it will be more correct than the Jnraid generated one.    I am trying to stop both notifications coming out but if the plug-in one is misleading it may be better in the short term that they both come out.

 

I would be interested in some feedback in what the parity history is saying for that particular check.   I think there is a good chance it will actually be correct.

At least in my instance, the parity history looks like it finished the parity check, but also has an aborted message (when it paused). Strange. 



 

sc.PNG

Edited by Schwiing
Link to post
8 minutes ago, Schwiing said:

At least in my instance, the parity history looks like it finished the parity check, but also has an aborted message (when it paused). Strange. 



 

sc.PNG


In principle the standard Unraid generated entry should be replaced by the plugin one that has more information.

 

All the logic for both generating the notification and updating the history is contained in a single function so that looks like what I need to focus on - obviously managed to break something in the logic in a recent update.

Link to post

Hello,

 

I can confirm that my scheduled parity check did not pause either. I changed the settings and then back, the .cron look correct but it did not pause anyway.

 

It did however pause correctly if I set "Use increments for Unscheduled Parity Check" to Yes.

 

Edit: I'm on Unraid 6.8.3 and Parity Check Tuning 2020.05.11

Edited by makkish
Link to post
54 minutes ago, makkish said:

Hello,

 

I can confirm that my scheduled parity check did not pause either. I changed the settings and then back, the .cron look correct but it did not pause anyway.

 

It did however pause correctly if I set "Use increments for Unscheduled Parity Check" to Yes.

Yep, same here. That has been my temporary workaround for now, despite not wanting that behavior long-term.

Link to post

Reporting similar issue here with the 2021.01.19 Version:

 

Last check completed on Fri 05 Feb 2021 07:08:36 AM EST (yesterday), finding 0 errors.
Duration: 1 day, 6 hours, 38 minutes, 30 seconds. Average speed: 126.9 MB/sec


Parity Check Tuning: 06-02-2021 00:15
[MEDIATOWER] Correcting Parity Check aborted (0 errors) 0% completed
Elapsed Time Unavailable, Runtime Unavailable, Increments 1, Average Speed nanB/s

Link to post
13 minutes ago, a12vman said:

Reporting similar issue here with the 2021.01.19 Version:

 

Last check completed on Fri 05 Feb 2021 07:08:36 AM EST (yesterday), finding 0 errors.
Duration: 1 day, 6 hours, 38 minutes, 30 seconds. Average speed: 126.9 MB/sec


Parity Check Tuning: 06-02-2021 00:15
[MEDIATOWER] Correcting Parity Check aborted (0 errors) 0% completed
Elapsed Time Unavailable, Runtime Unavailable, Increments 1, Average Speed nanB/s


i have been working through all cases where this can happen in the code and I think I now have them all fixed in the version running on my test server.  There was a number of places in the code where regressions had crept in as I tried to tidy up he code to make it easier to maintain.   I have also been putting in some effort to make sure that notifications are more meaningful.    
 

I should be releasing a new version incorporating all my fixes (as well as new functionality) in the next few days.

  • Like 3
  • Thanks 1
Link to post

FI have just put out a new release.  I think I have fixed all the issues reported against the last few releases and (hopefully) not introduced any new ones.

 

For those running unRaid 6.9.0 rc2 (or later) this release also includes the first version of the Parity Problems Assistant (under the Tools tab) .  Anyone running 6.8.3 will still have the entry but on selecting it will get the message about the required minimum unRaid release to use this feature.

 

I will be interested in whether users think that the Parity Problems Assistant looks like something that would prove to be of use and feedback is welcomed.    I have some ideas for improving its usability but thought I should get some feedback on what has been done so far before spending too much effort on taking it further.

 

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.