[Plugin] Parity Check Tuning


Recommended Posts

12 hours ago, CS01-HS said:

Just a heads up.

 

I saw repeated errors in the log file after updating to 2021.09.10:

Sep 10 19:14:02 NAS crond[1762]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Sep 10 19:21:01 NAS crond[1762]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Sep 10 19:28:01 NAS crond[1762]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Sep 10 19:35:01 NAS crond[1762]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Sep 10 19:42:01 NAS crond[1762]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Sep 10 19:49:01 NAS crond[1762]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Sep 10 19:56:01 NAS crond[1762]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
Sep 10 20:00:01 NAS crond[1762]: exit status 255 from user root /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null

 

Running manually I got this error for every function defined in Legacy.php:

# /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor"
<script>if (typeof _ != 'function') function _(t) {return t;}</script>
Fatal error: Cannot redeclare parse_lang_file() (previously declared in /usr/local/emhttp/plugins/parity.check.tuning/Legacy.php:6) in /usr/local/emhttp/plugins/dynamix/include/Translations.php on line 46

 

I fixed it (?) by removing the functions from Legacy.php.

 

NOTE: This is with v6.10.0-rc1

 Can confirm, seeing the same on 6.10.0rc1

Link to comment

I get the following error when stopping my array:

Array Stopping•Fatal error: Cannot redeclare _() (previously declared in /usr/local/emhttp/plugins/parity.check.tuning/Legacy.php:6) in /usr/local/emhttp/plugins/dynamix/include/Translations.php on line 19

 

image.png.5e66199a50432f0bf1fb19dd650666f2.png

 

image.png.77e597066c1b8ddf48e5110d102bf7a3.png

 

I would change the function name but I don't know the rest of your code and don't want to screw up any calls to that function.

 

Edited by DemoRic
Link to comment

As with DemoRic above, I get the following error: "Fatal error: Cannot redeclare _() (previously declared in /usr/local/emhttp/plugins/parity.check.tuning/Legacy.php:6) in /usr/local/emhttp/plugins/dynamix/include/Translations.php on line 19" although I get it once the Array is started and I'm logged into the dashboard (not only when the array is stopping). I don't think I got it before installing v2021.09.10.

Link to comment
2 hours ago, rragu said:

As with DemoRic above, I get the following error: "Fatal error: Cannot redeclare _() (previously declared in /usr/local/emhttp/plugins/parity.check.tuning/Legacy.php:6) in /usr/local/emhttp/plugins/dynamix/include/Translations.php on line 19" although I get it once the Array is started and I'm logged into the dashboard (not only when the array is stopping). I don't think I got it before installing v2021.09.10.


Currently looking at tidiest way to eliminate that happening without breaking the multi-language support.

 

Link to comment
23 hours ago, rragu said:

As with DemoRic above, I get the following error: "Fatal error: Cannot redeclare _() (previously declared in /usr/local/emhttp/plugins/parity.check.tuning/Legacy.php:6) in /usr/local/emhttp/plugins/dynamix/include/Translations.php on line 19" although I get it once the Array is started and I'm logged into the dashboard (not only when the array is stopping). I don't think I got it before installing v2021.09.10.

Hi, I'm also getting this error:

Fatal error: Cannot redeclare _() (previously declared in /usr/local/emhttp/plugins/parity.check.tuning/Legacy.php:6) in /usr/local/emhttp/plugins/dynamix/include/Translations.php on line 20

But I have just upgraded my parity drive to a larger one! Everything seems to be working though and I've tried removing and reinstalling the plugin. I'm running Unraid 6.10.0rc1.

Cheers,

Tim

Link to comment

There were various recent reports of error messages appearing in the GUI and/or syslog generated by recent plugin updates (although the functionality appeared to still work) as I tried to improve the multi-language support.  I have just pushed an update that I think fixes all of these but please let me know if any still occur that need me to look at them.

  • Thanks 1
Link to comment
1 hour ago, itimpi said:

There were various recent reports of error messages appearing in the GUI and/or syslog generated by recent plugin updates (although the functionality appeared to still work) as I tried to improve the multi-language support.  I have just pushed an update that I think fixes all of these but please let me know if any still occur that need me to look at them.

Hello. After the latest update I am getting a similar Warning as I was before. The location is a bit different but wanted to share what I am getting.

 

Warning: session_start(): Cannot start session when headers already sent in /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.helpers.php on line 115

 

This is on version 6.9.2

Link to comment
2 hours ago, Defuse said:

Hello. After the latest update I am getting a similar Warning as I was before. The location is a bit different but wanted to share what I am getting.

 

Warning: session_start(): Cannot start session when headers already sent in /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.helpers.php on line 115

 

This is on version 6.9.2


I can see where that message could originate from in the code - but I am not sure why.    Where are you seeing this message (GUI, syslog etc) and if the GUI on what page.   I did not see it when testing - but maybe I am not looking in the right place?   I need to be able to replicate the issue to be able to work on it (and know if I have fixed it). Also if it is the GUI what browser are you using?

Link to comment
2 minutes ago, itimpi said:


I can see where that message could originate from in the code - but I am not sure why.    Where are you seeing this message (GUI, syslog etc) and if the GUI on what page.   I did not see it when testing - but maybe I am not looking in the right place?   I need to be able to replicate the issue to be able to work on it (and know if I have fixed it). Also if it is the GUI what browser are you using?

It shows up in Settings > Scheduler.

 

Interestingly. I started checking this out because I had an upcoming parity check scheduled and wanted to make sure that the settings were correct as this was the first time I was using your scheduling plugin. When I originally set it up I did not see any warnings. The parity check started, there was an update to the parity check scheduler plugin which I performed while the parity check was paused because of the schedule enforcement that I had set. After the update this warning presented itself.

 

The parity check finished later that day but I never received a notification of that until I updated the plugin again earlier today. I thought that timing was a bit odd so I thought I would share. I have also attached a screenshot of the message as I see it. 

Capture.PNG

Link to comment

I need to try and work out why I did not see the same message on my 6.9.2 system when testing.    I have just gone back to that system and this time that message IS being displayed which is weird.
 

In theory the code line that precedes the session_start() should mean that function should only be called if needed but that is obviously not always working as expected.  I Will work on correcting it on my system, but I will also add some diagnostic logging around that bit of code to help me get more information about why my check on whether the function is needed is not always working.

Link to comment

I'd like to run an hour of parity check every week on Tuesday mornings.

 

I've set the increment resume time as: 0 5 * * 2

and the pause time as: 0 6 * * 2.

 

I am unsure what to use for the scheduled parity check. With 12tb drives, I'd need to start about two parity checks a year.

 

If I use the same as the increment resume time (eg: 0 5 * * 2), will the parity check reset to 0% each time?

 

Also, if I start a parity check using a script (parity.check nocorrect), is it considered a scheduled, manual or automatic check?

Edited by srirams
Link to comment
18 hours ago, srirams said:

I am unsure what to use for the scheduled parity check. With 12tb drives, I'd need to start about two parity checks a year

It is really your decision as to how long increments should be, and therefore what the elapsed time should be as the number of increments can be approximately derived from the time the check would take if no increments were involved and dividing by increment length.  I say approximately as any other disk activity going on at the same time as a check can slow it down thus potentially increasing the number of increments.

 

I see you are using the ‘custom’ option to get the increment schedule you want rather than the default of daily..  Would you see any good reason to add other repeat intervals to avoid using the ‘custom’ option?   I had avoided doing this as I wanted to keep the GUI simple and daily seemed what the vast majority of users would want.  I then and added the ‘custom’ option to cater for special needs (and it helps me with testing).

 

18 hours ago, srirams said:

f I use the same as the increment resume time (eg: 0 5 * * 2), will the parity check reset to 0% each time

The check will not reset to 0 as the plugin does not start the parity check itself, but merely pauses and resumes one started by the system.  
 

I am not sure what the behaviour will be if both pause and start time are identical as it will depend on exactly the order the pause and resume get executed as to whether a check is left running or paused.  I think I will add a check to the GUI that the Pause and Resume times are not identical as it could mean that behaviour is unpredictable, and I cannot think offhand of a Use Case where it makes sense (but you are welcome to suggest one).

 

18 hours ago, srirams said:

if I start a parity check using a script (parity.check nocorrect), is it considered a scheduled, manual or automatic check?

I am not sure I tested this but it should be treated as a manual check because it was not initiated by a cron entry.  I will add a check for that to my test checklist though to make sure it is.

 

For reference Automatic checks are the sort that are started automatically by the system after an unclean shutdown is detected and if any other type of check gets flagged as Automatic this is a bug in the plugin that would need investigating and correcting.

 

Link to comment
On 9/15/2021 at 4:44 AM, itimpi said:

I need to try and work out why I did not see the same message on my 6.9.2 system when testing.    I have just gone back to that system and this time that message IS being displayed which is weird.
 

In theory the code line that precedes the session_start() should mean that function should only be called if needed but that is obviously not always working as expected.  I Will work on correcting it on my system, but I will also add some diagnostic logging around that bit of code to help me get more information about why my check on whether the function is needed is not always working.

 

I recently started using the plug-in again and had the warning re "Cannot start session..." I'm also on 6.9.2. Here's a screenshot:Parity_check_settings.thumb.PNG.ddbe675ce89877e0d7c3881c9a08bb3a.PNG

 

I thought that with these settings my parity check would start early this morning (17th) at 1 am and pause at 9 am, but although it did start, it's now around 12 noon here and it's still running. Not sure if this is a result of the warning or an incorrect setting.

 

Link to comment
2 hours ago, sonofdbn said:

 

I recently started using the plug-in again and had the warning re "Cannot start session..." I'm also on 6.9.2. Here's a screenshot:Parity_check_settings.thumb.PNG.ddbe675ce89877e0d7c3881c9a08bb3a.PNG

 

I thought that with these settings my parity check would start early this morning (17th) at 1 am and pause at 9 am, but although it did start, it's now around 12 noon here and it's still running. Not sure if this is a result of the warning or an incorrect setting.

 

 

That is what I would expect as long as the check was started as a scheduled one.  Not sure where you are located but I assume somewhere far east or Australia if it is already 12 noon?

 

If you go to config/plugins/parity.check.tuning on the flash drive what files do you see as that may give a clue as to what type of check the plugin thinks is running.  The contents of the .cron file might also be useful to check that the scheduled entries for pause ant resume appear to be correct.

 

BTW:  If you want to run one increment a day then the 'daily' frequency option is easier to use and less error prone that the 'custom' one although I admit your 'custom' entry looks OK.

Link to comment

Looks like the previous update may have messed up setting cron settings correctly.   I have just pushed an update that corrects this and as far as I can see eliminates all plugin related warning/error messages from GUI and syslog.

 

Please report if anything still seems to be wrong after updating to today’s release.

 

 

Link to comment

So I have my daily schedule set for increment resume/pause parity so it never disrupts server use, but I'm curious if it's possible to manually resume when I know it will be unused outside of the daily schedule?

 

Right now if I click resume and after the increment pause time, if I hit pause again, it will resume in the next 5(?) minute interval. The good thing is that when I hit resume manually outside of the scheduled time, it will pause if there is overheating, which could be tricky to implement correctly if the my requested feature is added.

 

For context, during summer here the top drive heats up beyond the threshold frequently during the increment resume period (overnight) because I don't run the AC much at night, and thus it can take weeks to finish a check. While I'll be addressing the cooling likely, it'd still be nice manually continue parity checking at will.

 

I have not tried adjusting the increment pause time to, say, 1 minute after I want to stop my manual run, but ideally I would just keep my normal increment pause time and not have to adjust it for ad-hoc sessions.

Edited by robobub
Link to comment
8 hours ago, robobub said:

So I have my daily schedule set for increment resume/pause parity so it never disrupts server use, but I'm curious if it's possible to manually resume when I know it will be unused outside of the daily schedule?

 

Right now if I click resume and after the increment pause time, if I hit pause again, it will resume in the next 5(?) minute interval. The good thing is that when I hit resume manually outside of the scheduled time, it will pause if there is overheating, which could be tricky to implement correctly if the my requested feature is added.

 

For context, during summer here the top drive heats up beyond the threshold frequently during the increment resume period (overnight) because I don't run the AC much at night, and thus it can take weeks to finish a check. While I'll be addressing the cooling likely, it'd still be nice manually continue parity checking at will.

 

I have not tried adjusting the increment pause time to, say, 1 minute after I want to stop my manual run, but ideally I would just keep my normal increment pause time and not have to adjust it for ad-hoc sessions.

You can do any manual pause/resume that you like and the plugin will not care.    With the scheduled ones there is a specific task kicked of at the scheduled time to attempt the required action.   If the action is not appropriate (e.g. pause an already paused check) then that task simply exits taking no action.

 

Note that you can use the temperature related pause/resume in addition.  If this is active then a ‘monitor’ task is run reasonably frequently to see if a temperature related pause/resume is appropriate.    That way if you are having temperature related issues you could get pause/resumes happening within the time period for the scheduled pause/resume, or if you have started the check manually at any time.

Link to comment
12 hours ago, itimpi said:

You can do any manual pause/resume that you like and the plugin will not care.    With the scheduled ones there is a specific task kicked of at the scheduled time to attempt the required action.   If the action is not appropriate (e.g. pause an already paused check) then that task simply exits taking no action.

 

Note that you can use the temperature related pause/resume in addition.  If this is active then a ‘monitor’ task is run reasonably frequently to see if a temperature related pause/resume is appropriate.    That way if you are having temperature related issues you could get pause/resumes happening within the time period for the scheduled pause/resume, or if you have started the check manually at any time.

This doesn't appear to be working correctly. My parity check just finished, but next month I can get some DEBUG/TESTING level logs, but as I mentioned I resumed a check outside of the increment hours and then manually paused it, but it automatically resumed. I can confirm again as before that it did automatic pause/resume between manually resuming and manually pausing which is nice.

 

 

Plugin version: 2021.09.17 (appeared on older versions, but I manually updated and it still occurred)

Increment frequency: Daily

Increment Resume time: 4:00 am

Increment pause time: 12:00 pm

 

 

Manually resumed at ~1pm. Manually paused at ~3pm. Resumed shortly thereafter, unsure of the drive temperatures at that time.

 

Link to comment
4 hours ago, robobub said:

This doesn't appear to be working correctly. My parity check just finished, but next month I can get some DEBUG/TESTING level logs, but as I mentioned I resumed a check outside of the increment hours and then manually paused it, but it automatically resumed. I can confirm again as before that it did automatic pause/resume between manually resuming and manually pausing which is nice.

 

 

Plugin version: 2021.09.17 (appeared on older versions, but I manually updated and it still occurred)

Increment frequency: Daily

Increment Resume time: 4:00 am

Increment pause time: 12:00 pm

 

 

Manually resumed at ~1pm. Manually paused at ~3pm. Resumed shortly thereafter, unsure of the drive temperatures at that time.

 

 

Any chance of zipping up the contents of the config/plugins/parity.check.tuning folder on the flash drive and letting me have the result? Might help with recreating your scenario for testing purposes to see if I can spot why things did not work as expected for you.

Link to comment
11 hours ago, robobub said:

This doesn't appear to be working correctly. My parity check just finished, but next month I can get some DEBUG/TESTING level logs, but as I mentioned I resumed a check outside of the increment hours and then manually paused it, but it automatically resumed. I can confirm again as before that it did automatic pause/resume between manually resuming and manually pausing which is nice.

 

 

Plugin version: 2021.09.17 (appeared on older versions, but I manually updated and it still occurred)

Increment frequency: Daily

Increment Resume time: 4:00 am

Increment pause time: 12:00 pm

 

 

Manually resumed at ~1pm. Manually paused at ~3pm. Resumed shortly thereafter, unsure of the drive temperatures at that time.

 


I tried to recreate your symptoms but have so far not succeeded?

 

one thing that occurred to me is there any chance a temperature related pause could have been active at the time the scheduled pause should have happened?   If so maybe the plugin is getting confused, and resuming when the temperatures return to good values when it should not?    It is surprisingly hard to set this up as robust test scenario that works correctly which is why I thought it was worth asking first before trying to simulate that specific set of circumstances.

Link to comment

I tried to recreate your symptoms but have so far not succeeded?
 
one thing that occurred to me is there any chance a temperature related pause could have been active at the time the scheduled pause should have happened?   If so maybe the plugin is getting confused, and resuming when the temperatures return to good values when it should not?    It is surprisingly hard to set this up as robust test scenario that works correctly which is why I thought it was worth asking first before trying to simulate that specific set of circumstances.
Ah, thanks for giving it a shot. It's certainly possible any number of things could've happened. I wouldn't spend much more time trying to reproduce it until I get actual logs which should tell us what really happened
Link to comment

I'm having a similar issue with the error:

 

Fatal error: Cannot redeclare _() (previously declared in /usr/local/emhttp/plugins/parity.check.tuning/Legacy.php:6) in /usr/local/emhttp/plugins/dynamix/include/Translations.php on line 19.

 

For me it's showing at the bottom of the page. I'm running the latest version of the plugin.

 

array error message.png

Link to comment
On 9/20/2021 at 4:13 PM, thunderclap said:

I'm having a similar issue with the error:

 

Fatal error: Cannot redeclare _() (previously declared in /usr/local/emhttp/plugins/parity.check.tuning/Legacy.php:6) in /usr/local/emhttp/plugins/dynamix/include/Translations.php on line 19.

 

For me it's showing at the bottom of the page. I'm running the latest version of the plugin.

 

array error message.png

I was not able to recreate this issue, but I 'think' the update I have just pushed should have fixed this issue.  If it has not can you give me:

  • Version of the plugin you are running (as a check)
  • Version of Unraid you are running
  • What browser (and it's version) on what OS (if not Unraid GUI mode one) you are using
  • Your system's diagnostics zip file covering an occurrence of this issue

 

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