[Plugin] Parity Check Tuning

[Vr2Io 205]

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.

[itimpi 970]

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.

[Vr2Io 205]

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.

[hrv231 0]

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:

 

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.

[itimpi 970]

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:

 

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.

 

[hrv231 0]

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!

[itimpi 970]

1 minute ago, hrv231 said:

My bad, it was set to NO.

 

Glad to hear that there is not (yet anyway) a bug I need to fix

 

[blackf0rk 0]

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.

 

[jonathanm 1305]

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.

[Schwiing 0]

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.

[itimpi 970]

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.  

[Schwiing 0]

This time it worked. Strange. Attached the log + parity tuning files.

Parity.zip

[itimpi 970]

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.

[I_TheRenegade_I 1]

6 hours ago, jonathanm said:

Same symptoms here.

Yup, same here. I have mine set to run the 1st Monday of the month, and its been running for 14 hours now. Was supposed to stop after 8 (at 8am)

Maybe the plugin hates February?

[bidmead 4]

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

[Schwiing 0]

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

 

I got the same notification. Strange.

[jonathanm 1305]

Same notification on both 6.8.3 and 6.9.0 rc2 if that helps troubleshooting.

[itimpi 970]

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

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.

[Schwiing 0]

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. 



 

Edited February 2 by Schwiing

[itimpi 970]

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. 



 

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.

[makkish 1]

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 February 2 by makkish

[Schwiing 0]

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.

[a12vman 1]

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

[itimpi 970]

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.

[itimpi 970]

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.