[Plugin] Parity Check Tuning

[JasonK]

Just installed the plugin.  Changed the settings to below:

 

 

Started a manual parity check (it's not 10:46 local time) - and the check is running....it's not paused until 00:00 tomorrow morning:

 

 

Did I miss a setting/configuration/something somewhere?

 

Thanks!

[itimpi]

Not sure what question you are asking?   There can be a delay (up to 15 minutes) before the plugin runs its idling monitor task and notices that a Manual check has been initiated.

 

if you want it to only run the Manual check between the increment times specified then hit the Pause button and let the plugin take over Resume/Pause activity.

[JasonK]

2 hours ago, itimpi said:

Not sure what question you are asking?   There can be a delay (up to 15 minutes) before the plugin runs its idling monitor task and notices that a Manual check has been initiated.

 

if you want it to only run the Manual check between the increment times specified then hit the Pause button and let the plugin take over Resume/Pause activity.

Thanks for the reply!  After reading your comment of "...up to 15 minutes" I went ahead and started another manual parity check...It never did pause it:

 

 

I've manually paused it and will see if the plugin kicks it off at midnight and runs til 6am (per it's settings).

 

Thx

[itimpi]

7 hours ago, JasonK said:

Thanks for the reply!  After reading your comment of "...up to 15 minutes" I went ahead and started another manual parity check...It never did pause it:

 

 

I've manually paused it and will see if the plugin kicks it off at midnight and runs til 6am (per it's settings).

 

Thx

It would not pause it until the Pause time came up.    This is a deliberate decision as it is easy to manually pause it just after starting it and more often than not if you start it manually you WANT to leave it running until the increments start kicking in. 

[JasonK]

4 hours ago, itimpi said:

It would not pause it until the Pause time came up.    This is a deliberate decision as it is easy to manually pause it just after starting it and more often than not if you start it manually you WANT to leave it running until the increments start kicking in. 

Gotcha.  Thanks again for the info.  After pausing last night, plugin kicked it off at midnight as expected as well as paused it at 6am as expected.

 

Thanks!

[aim60]

Just an FYI

 

Getting a lot of these in the syslog

 

Jan 30 12:36:21 Tower7 Parity Check Tuning: ERROR: marker file found for both automatic and manual check P Q

 

I had an unclean shutdown.  The array is set to not auto-start.  After power cycling the server, I unchecked the box to correct parity, before starting the array.  A correcting parity check started anyway.

 

Unraid 6.11.5, Parity Check Tuning 2023.12.08 

tower7-diagnostics-20240130-1358.zip

[itimpi]

It is due to the fact that you had an unclean shutdown while a manual check was running and the plugin does not clear the state information for the manual check after the reboot.  This should auto-fix itself when the automatic check finishes, but if you want to stop it immediately you can delete the party.check.tuning.manual file in the plugins folder on the flash drive.   

 

This issue is fixed for the next time I issue a plugin update but it did not seem urgent to get an update out so I am sitting on that fix.   Unless an urgent issue arises I would like to wait until Unraid 6.12.7 (or even beta 6.13 beta) come out to check that they are not going to require changes to the plugin.

[psikic]

I'm new to using this plugin.  Is there a way to run a script just before each time parity check runs, and then have a script that runs when it is finished?  I'd like to start/stop a docker container that would slows the parity check down when it is running.

[itimpi]

31 minutes ago, psikic said:

I'm new to using this plugin.  Is there a way to run a script just before each time parity check runs, and then have a script that runs when it is finished?  I'd like to start/stop a docker container that would slows the parity check down when it is running.

Not a feature that the plugin supports I am afraid although it is something that could be considered as a future enhancement.
 

i might also think of the ability to provide a list of docker containers that should not be actively running while a parity check is running.  This might avoid the need for any scripts and easier to implement robustly.  Probably a pause/resume option rather than a stop/restart approach would be best.  Having said that if the ‘appdata’ and ‘system’ shares are completely on a pool then the interaction with the parity operation might be minimised or negligible.

 

 

[BrennstoffBernd]

Hey there - I hope that my question wasn't answered in earlier posts and I didn't find it.

 

Just to be clear, what the option "Resume array operations on next array start" provides and not provides:

--

1. The following operation is possible and working for me:

- Pause a manual parity check

- Stop the Array

- Get a notification ("Restart will be attempted on next array start")

- Start the Array again and resume the previous parity check

2. What's not working - shutdown the Server and resuming the check:

- Pause a manual parity check

- Stop the Array

- Get a notification ("Restart will be attempted on next array start")

- Shutdown the Server

- Start the Server

- Start the Array

- No "Resume" function/button is provided, parity check will start from the beginning

--

 

Is the pause-state lost, once the Server is shutdown or restarted?

 

Thank you!

[itimpi]

1 hour ago, BrennstoffBernd said:

Is the pause-state lost, once the Server is shutdown or restarted?

 

The resume should be automatic if you give it a few minutes with no user action required.

 

If it is not then please enable the Testing mode logging in the plugin and then after recreating the error post your system's diagnostics.    That should give enough information for me to work out why you are not getting the check automatically restarting..

[BrennstoffBernd]

On 2/12/2024 at 12:32 PM, itimpi said:

 

The resume should be automatic if you give it a few minutes with no user action required.

 

If it is not then please enable the Testing mode logging in the plugin and then after recreating the error post your system's diagnostics.    That should give enough information for me to work out why you are not getting the check automatically restarting..

 

Thanks for the quick reply!

 

I've just let the complete check once finished and then recreated the issue describe in number 2:

- Set log output to "testing mode"

- Started manual parity check until ~0.1% was reached

- Pause the manual parity check

- Stop the Array

- This time I've got two notifications after stopping the array (see attached screenshot)

- Shutdown the Server

- Start the Server

- Start the Array

- No "Resume" function/button is provided and also after waiting for about 5 to 10 minutes, no automatic start was scheduled

 

Also please see the diagnostics logging in the attached files.

 

Thank you in advanced.

galaxy-diagnostics-20240213-1658.zip

[itimpi]

@BrennstoffBernd 

 

Looking through the diagnostics it seems there is no restart information present when the system starts back up which surprised me in light of the fact that you previously got the message that a restart would be attempted.

 

It might be necessary to get the syslog server enabled (with the mirror to flash option) and then repeat the exercise so that I can also see what happened during the closedown process as well as what happened after the restart.   Just for interest have you tried simply trying to shutdown the server without first pausing the parity check?  

 

I am going to have another go at trying to reproduce your symptoms at my end by trying to follow the exact sequence of steps you have outlined.

[BrennstoffBernd]

@itimpi

Sounds good - thanks for the first check.

Additional: As a "partial workaround" it went completely fine, when not shutting down the server but putting it to sleep (s3).

 

I've tried to re-create the exact process after enabling the syslog server (mirror to flash & local cache drive). Is it enough to export the diagnostics like last time? If so, it is attached.

 

Also attached two screenshots. One for the notification (this time only the one message) and the other one as a side note that it is stated as "Last check incomplete on Tuesday, 13.02.2024, 18:02 (today) | Error code: aborted" after the boot process of the server finished and the array is started all over again.

 

I've turned the syslog server off, once I've finished writing this comment.

Thank you!

 

galaxy-diagnostics-20240213-1816.zip

[itimpi]

@BrennstoffBernd

In theory that was fine as it includes the syslog leading up to the shutdown, but was the Testing mode logging active in the plugin settings when you did this last test?  I could not see any of the extra diagnostic information that the Testing mode generates.

[BrennstoffBernd]

@itimpi
Oh no, you're right. I'm sorry, I've switched back to basic logging.

 

The new one should now provide testing mode and syslog.

 

galaxy-diagnostics-20240214-1017.zip

[itimpi]

1 hour ago, BrennstoffBernd said:

The new one should now provide testing mode and syslog.

Thanks for those diagnostics.   I think I now see the issue and can see where the restart state is getting lost.   If I am correct then if you simply hit shutdown/reboot rather than stopping the array first the restart information will not be lost and the operation should restart on starting the array after the next reboot.

 

However the sequence you are following is perfectly valid so I need to do some slight rework so that the restart information is not lost when following your sequence.  I think the fix is quite easy but I need to test it out to make sure I have not inadvertently broken something else in making it as tracking the state can at times be a little tricky because of interactions between the plugin and Unraid's built-in array operation handling.

[BrennstoffBernd]

3 hours ago, itimpi said:

If I am correct then if you simply hit shutdown/reboot rather than stopping the array first the restart information will not be lost and the operation should restart on starting the array after the next reboot.

I will give this special case a try these days and keep you up to date.

Thanks for digging and analyzing my problem.

[itimpi]

13 minutes ago, BrennstoffBernd said:

I will give this special case a try these days and keep you up to date.

Thanks for digging and analyzing my problem.

No rush as I should soon be ready to release an update that correctly handles your case.

[itimpi]

@BrennstoffBernd

I have just uploaded a plugin update that should fix the problem you encountered on getting array operations to restart.

 

BTW:  You do not need to pause the operation before stopping the array or using shutdown/reboot.   If you do then the plugin will attempt to pause it after restarting the operation which may not be what you want?

 

[isvein]

Would it be possible to have an option for shutting down all docker containers while parity check is running and start them up when done?

[itimpi]

6 hours ago, isvein said:

Would it be possible to have an option for shutting down all docker containers while parity check is running and start them up when done?

I have thought about it but not sure how easy that will be to do in a way that will not have issues.

 

Has anyone looked at whether the docker containers can simply be paused rather than stop and restart?    That would be much easier to implement.   Using this type of solution it might be easy enough to be selective about which ones to pause as you would normally only be interested in ones that do array access.

 

Having said that I think most people do not want docker containers to be unavailable for the length of time parity checks take.

 

[BrennstoffBernd]

On 2/15/2024 at 3:33 PM, itimpi said:

@BrennstoffBernd

I have just uploaded a plugin update that should fix the problem you encountered on getting array operations to restart.

 

BTW:  You do not need to pause the operation before stopping the array or using shutdown/reboot.   If you do then the plugin will attempt to pause it after restarting the operation which may not be what you want?

 

Sorry for the late reply. I've updated the Plugin and once again checked the same process, which I have listed above.

After the restart, it was reported that the check could be continued. However, it started again at 0% after pressing the "Resume" button. I let it run to about 0.3% before I performed the restart.

[itimpi]

1 hour ago, BrennstoffBernd said:

Sorry for the late reply. I've updated the Plugin and once again checked the same process, which I have listed above.

After the restart, it was reported that the check could be continued. However, it started again at 0% after pressing the "Resume" button. I let it run to about 0.3% before I performed the restart.

As before I would need diagnostics with testing mode logging enabled to see why.   In my testing the sequence you mentioned worked fine after the update.

[BrennstoffBernd]

4 hours ago, itimpi said:

As before I would need diagnostics with testing mode logging enabled to see why.   In my testing the sequence you mentioned worked fine after the update.

Now I've got the logs
I've paused the check at 0.6% and after the restart it would start all over by 0.0% (screenshot of the notification also attached).

Thank you in advanced!

--
Edit (18:09): I've tried it without stopping the array and directly shutting down and restarting the server. Then it works - it automatically continued the check at around 0.6%.
--

galaxy-diagnostics-20240308-1745.zip

Edited March 8 by BrennstoffBernd