[Plugin] Parity Check Tuning


Recommended Posts

  • 3 weeks later...

Nice plugin, thank you.

 

But the german localisation is... hmmm... how to say... ?

Something between non-existent to even misleading/wrong.

 

It took me quite a time to find out, what some of those translations were meant to mean.

 

I would volunteer to translate all items, if someone could tell me where to find them and where to send them to.

 

Link to comment
4 hours ago, MAM59 said:

Nice plugin, thank you.

 

But the german localisation is... hmmm... how to say... ?

Something between non-existent to even misleading/wrong.

 

It took me quite a time to find out, what some of those translations were meant to mean.

 

I would volunteer to translate all items, if someone could tell me where to find them and where to send them to.

 

https://github.com/unraid/lang-de_DE

Link to comment
4 hours ago, MAM59 said:

Nice plugin, thank you.

 

But the german localisation is... hmmm... how to say... ?

Something between non-existent to even misleading/wrong.

 

It took me quite a time to find out, what some of those translations were meant to mean.

 

I would volunteer to translate all items, if someone could tell me where to find them and where to send them to.

 

Please do work on the translations if you would as this is not something I can do myself.   All I can do is make sure that all the important text is correctly in the master translations file for the plugin.   The text I do not add to the translation file is that output only when logging in TESTING mode as those messages as primarily for me as the developer to resolve problems in the plugin so having them translated would actually be counter-productive if I do not understand them.

 

I need to update the list of phrases on GitHub to make them correspond to the plugin update that I am working on.   However most of the changes are in the help text which is less important, but if you do work on the German translation you might want to keep an eye out for this update to get the translations as complete as possible.

Link to comment

Sorry folks, I don't understand.

@Squid pointed to a very strange file that contains a lot of Eng=Ger phrases, but all seem to be not related to "parity check tuning".

 

and @itimpi does not point to anything.

 

Where is the file with the english phrases for parity check tuning and what is the syntax you need for the translation???

 

(Github does not mean a thing for me, so if it is that what I need, them I'm out, sorry)

 

Edited by MAM59
Link to comment
1 hour ago, MAM59 said:

@Squid pointed to a very strange file that contains a lot of Eng=Ger phrases, but all seem to be not related to "parity check tuning".

There's a folder in that link called parity check tuning.  Within that folder is the files that the plugin actually uses.  You would edit those file(s) accordingly.  You can do it right online

Link to comment

Ah, I found it!

But sorry, I can't do anything, I am not a Github user and I have no plans to become one.

 

But then, the real bad translation "use increments for Handbuch..." is not in there, or is split somehow

grafik.png.01021efc2fecb8c331b52d692360ae86.png

 

 

I guess its the line "Use increments for %s %s=" but I cannot find the Text "Handbuch" somewhere (this means manual (the book) but not "by hand")

so the first %s is wrong and the 2nd one is ok, but mixing languages is bad too.

 

BTW: if "Handbuch" is elsewhere is is likely to be correct there, but not here. This is not a simple matter of replacement, the whole sentence needs to be changed (and it is used 3 times, but needs to be seperate for every instance, like

"Teile geplante Prüfungen auf:"

"Teile manuell erzeugte Prüfungen auf:"

"Teile automatische Prüfungen auf:"

 

(you see: different grammar, although the 2nd %s could be two words "Prüfungen auf")

 

But it already would be ok, if there would be NO Translation at all! If all stays english, its good too, just the mix is really really bad.

 

Link to comment

I have just pushed an update to this plugin that should:

  • fix the issue with Parity Checks not being restarted from the point previously reached after a reboot
  • adds restarting of all the other types of array operations (parity sync, rebuild, clear etc) from the point previously reached after a reboot

if anyone spots any issues with this update then please let me know.

  • Like 2
Link to comment

Can someone tell me what I am doing wrong?  I would like parity check to run once every 2 months - start at 11:30PM each night and run for 12 hours till about 11:30am - then repeat until the whole process is finished.  

 

I have attached what all my settings are.   

 

Right now parity seems to start around 10pm and stops every night at 12:30am.  

 

I have 18TB drives  - so at this pace - it will probably take 3 months to finish a parity check.   

 

Anyone have any ideas?

 

 

screencapture-192-168-1-10-Settings-Scheduler-2022-12-07-15_41_52.png

Link to comment
38 minutes ago, jesseasi said:

Right now parity seems to start around 10pm and stops every night at 12:30am.  

 

I have 18TB drives  - so at this pace - it will probably take 3 months to finish a parity check.   

 

Anyone have any ideas?

 

You have a conflict between the standard Parity Check setting "Accumulation duration" which is set to 14 hours and the Parity Check Tuning setting "Increment Pause" setting to 00:30 (which is causing your parity check to pause 30 minutes after midnight)

 

I suggest you set the Parity Check setting "Cumulative parity check" to "No" and then set the Parity Check Tuning setting "Increment pause" to the time you want it to pause (11:30).   This means all the pausing/resuming is handled only by the Parity Check Tuning plugin.

 

You should also change the Parity Check setting "Day of the week" to a specific day …. The current setting will restart the parity check every day of the 1 week of the selected month.   How do I know this?  Because I made the same mistake when I recently changed from monthly to 2 monthly and the parity check was making no progress each night.

 

I had the luxury of being to able chat with my brother (who is the author of the Parity Check Tuning plugin) to work out what was going wrong.

Link to comment
On 12/5/2022 at 9:25 PM, itimpi said:

I have just pushed an update to this plugin that should:

  • fix the issue with Parity Checks not being restarted from the point previously reached after a reboot
  • adds restarting of all the other types of array operations (parity sync, rebuild, clear etc) from the point previously reached after a reboot

if anyone spots any issues with this update then please let me know.

Thanks for the update. I've long been waiting.

Link to comment
14 hours ago, remotevisitor said:

 

You have a conflict between the standard Parity Check setting "Accumulation duration" which is set to 14 hours and the Parity Check Tuning setting "Increment Pause" setting to 00:30 (which is causing your parity check to pause 30 minutes after midnight)

 

I suggest you set the Parity Check setting "Cumulative parity check" to "No" and then set the Parity Check Tuning setting "Increment pause" to the time you want it to pause (11:30).   This means all the pausing/resuming is handled only by the Parity Check Tuning plugin.

 

You should also change the Parity Check setting "Day of the week" to a specific day …. The current setting will restart the parity check every day of the 1 week of the selected month.   How do I know this?  Because I made the same mistake when I recently changed from monthly to 2 monthly and the parity check was making no progress each night.

 

I had the luxury of being to able chat with my brother (who is the author of the Parity Check Tuning plugin) to work out what was going wrong.

So far so good!  Thank you so much!!!!!

 

 

Link to comment
2 hours ago, MAM59 said:

I have a (maybe stupid?) question about this setting:

grafik.thumb.png.9cea18bf59207e141cef2d919b95862e.png

Why is this warning and should I be concerned?

I even want the pauses just from 11:00am to 2:30pm (mover and external backup running in this period)

 

I don't understand what can be "unusual" with this???

 

This warning is because with the settings you have set in the screenshot then the increment time would be 14 hours and it is unusual for anyone using this plugin to want the increment to be that long.   It is only a warning as common mistake is (as the message indicates) for users to get the pause and resume time the wrong way around.

Link to comment
4 minutes ago, itimpi said:

It is only a warning as common mistake is (as the message indicates) for users to get the pause and resume time the wrong way around.

But the warning reappears all the times if you change one of the time fields.

And I cannot see 14 hours there. it should stop at 12:00 (is that 12:00pm) and restart at 22:00. That makes 10 hours for me.

???

 

Edited by MAM59
Link to comment
6 hours ago, francishe said:

Parity check resumed successfully the next day and so far so good. But I am still bewildered about the following setting:

Increment resume time at 8:30 but it seemed to have restarted at "Resume array operations on next array start" instead of resuming at 8:30 as set. Which one prevails?

The intention is that the array operation should be restarted (priority 1) and then the times of the increments examined and if the time is outside the increment window it should then be paused (priority 2).   Sounds as if I need to look into why the pause is not happening after the restart (to be honest I was concentrating that the restart happened under all the edge conditions I could think of).

Link to comment
7 minutes ago, MAM59 said:

But the warning reappears all the times if you change one of the time fields.

And I cannot see 14 hours there. it should stop at 12:00 (is that 12:00pm) and restart at 22:00. That makes 10 hours for me.

???

 

You are right - it is less than 12 hours so the warning should not occur. :(   I read it wrong knowing what the intention of the warning was.   I need to check the bit of code that tries to calculate the increment length when it spans midnight.   Despite the warning you should find that the pause and resume times work as expected as they are fired independently of each other.

Link to comment
6 minutes ago, itimpi said:

Despite the warning you should find that the pause and resume times work as expected as they are fired independently of each other.

yeah I know, I use it for some months already 🙂

Thats why I am so puzzled about the strange warning. At first it frightended me a bit :-)))

 

(Hint: with these settings, there is no wrap around midnight, you can simply subtract the start time from the end time :-))) )

I recently had a similar function to program for one of my projects, I found out there is no simple "all in one formula" way to solve it. You have to use different codes for the situations with or without wrap.

 

maybe you could use this simple little python function to get the idea:

 

def checkrange(von,bis):
    my_date = datetime.datetime.now()    # Get current datetime
    Hour=my_date.hour
    #print ("Teste", Hour, "auf Interval von",von,"bis",bis)
    if (von < 0 or bis < 0):
        return False

    if (von > bis):
        # wir haben eine tagesueberlappung
        #print ("TagesWrap!")
        if (Hour >= von or Hour < bis):
            return True
        return False
    # hier nur innerhalb des Bereiches
    #print("normaler Bereich")
    if (Hour >= von and Hour <= bis):
        return True
    return False

 

call it with start and end hour, it checks against the current clock

(yeah its not the brightest code, but it works 🙂 )

 

Edited by MAM59
Link to comment
5 minutes ago, itimpi said:

This warning is because with the settings you have set in the screenshot then the increment time would be 14 hours and it is unusual for anyone using this plugin to want the increment to be that long.   It is only a warning as common mistake is (as the message indicates) for users to get the pause and resume time the wrong way around.

At least for me I need it to run that long because I have a 14T parity drive which usually runs for more than 24 hours for a single parity check and my server sleeps in nights. So I want it to do check in the daytime as long as the server runs till poweroff in the midnight. And your app helps. 

Link to comment
5 minutes ago, francishe said:

At least for me I need it to run that long because I have a 14T parity drive which usually runs for more than 24 hours for a single parity check and my server sleeps in nights. So I want it to do check in the daytime as long as the server runs till poweroff in the midnight. And your app helps. 

No problem.    I just need to ensure that the warning is correct, but I need to keep it as a warning just to cater for unusual Use Cases.    Most people want to limit the times the check runs during the day to minimise the impact on daily use, but if you are shutting down overnight (as I do for power saving reasons) then you are forced to use a non-trivial day time slot..
 

Note that if you have a VERY unusual Use Case then the Custom scheduling option is meant to allow for this and when that is used the increment direction is not checked.   It allows for unusual things such as multiple slots in a day rather than one slot a day.

Link to comment
16 minutes ago, itimpi said:

The intention is that the array operation should be restarted (priority 1) and then the times of the increments examined and if the time is outside the increment window it should then be paused (priority 2).   Sounds as if I need to look into why the pause is not happening after the restart (to be honest I was concentrating that the restart happened under all the edge conditions I could think of).

Thanks for your answer. So you mean in my case the parity check shouldn't restart on the array start, ignoring the set time. Anyway it works now. Doesn't matter if the parity check works a little longer than set.

Link to comment
20 minutes ago, itimpi said:

No problem.    I just need to ensure that the warning is correct, but I need to keep it as a warning just to cater for unusual Use Cases.    Most people want to limit the times the check runs during the day to minimise the impact on daily use, but if you are shutting down overnight (as I do for power saving reasons) then you are forced to use a non-trivial day time slot..
 

Note that if you have a VERY unusual Use Case then the Custom scheduling option is meant to allow for this and when that is used the increment direction is not checked.   It allows for unusual things such as multiple slots in a day rather than one slot a day.

Thanks for your advice.

Link to comment
Just now, francishe said:

Thanks for your answer. So you mean in my case the parity check shouldn't restart on the array start, ignoring the set time. Anyway it works now. Doesn't matter if the parity check works a little longer than set.

Not quite.    You should see the parity check being restarted when the array starts, but if that is outside the increment slot time after a short delay it should then be paused until the correct resume time is reached.

Link to comment
3 minutes ago, itimpi said:

Not quite.    You should see the parity check being restarted when the array starts, but if that is outside the increment slot time after a short delay it should then be paused until the correct resume time is reached.

That would be perfect, before which it still works to my purpose.

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.