14 hours ago, Szene said:

Im running the current latest stable version 6.12.11.

I’ll do some checking against the 6.12.11 release in case something changed there and Unraid now defaults to logging in the history when the check starts rather than finishes.    

The History button does not display any content. The data is still there in /boot/config/parity-checks.log.  I checked the system log and found the latest entries for Parity Check Tuning which indicated:

 

Aug 5 10:21:00 Tower Parity Check Tuning: ERROR: Unexpected number of fields (4) in parity-check.log on line 1:

Aug 5 10:21:00 Tower Parity Check Tuning: ERROR: Unexpected number of fields (4) in parity-check.log on line 2:

Aug 5 10:21:34 Tower Parity Check Tuning: ERROR: Unexpected number of fields (4) in parity-check.log on line 1:

Aug 5 10:21:34 Tower Parity Check Tuning: ERROR: Unexpected number of fields (4) in parity-check.log on line 2:

 

The last few lines of parity-checks.log

2024 Aug  5 03:14:06|132684|120.6 MB/s|0|0|check P|15625879500|341486|3|Scheduled Non-Correcting Parity-Check

 

And the lines in the system log associated with parity check tuning:

Aug 5 03:18:21 Tower Parity Check Tuning: Scheduled Non-Correcting Parity-Check finished (0 errors)

Aug 5 03:18:21 Tower Parity Check Tuning: Elapsed Time 3 day, 22 hr, 51 min, 26 sec, Runtime 1 day, 12 hr, 51 min, 24 sec, Increments 3, Average Speed 120.6 MB/s

Aug 5 03:18:21 Tower Parity Check Tuning: Send notification: Scheduled Non-Correcting Parity-Check finished (0 errors): Elapsed Time 3 day, 22 hr, 51 min, 26 sec, Runtime 1 day, 12 hr, 51 min, 24 sec, Increments 3, Average Speed 120.6 MB/s (type=normal link=/Settings/Scheduler)

 

 

The parity check tuning plug-in appears to be working. The task completes and entries are placed in the system log. However, something seems incorrect with the entries in parity-checks.log.

 

I can attach the actual logs and/or settings if needed. I would really like getting the history back to being displayed if possible.

Hi there,

 

I lately have some trouble with the plugin. It was scheduled to run from monday, and while it stopped during the designated times, it also paused because of overheating (which it should) but never returned to work. Sure, could be that the threshold isn't reached, but I doubt that within four hours it wouldn't lower again?

 

Anyway, that is an issue I have to figure out myself. To get the check through, I wanted to manually resume the check. I opened the unRAID console and typed parity.check resume, however nothing happens, also no feedback from the console. Suddenly the "elapsed" timer goes up again, but it doesn't resume the parity check. To manually resume, I now adjusted the pause-times, but this is somehow not the intended way I believe. Did I do something wrong here, do I have to type the command somewhere else?

 

Best Regards

2 hours ago, CameraRick said:

Hi there,

 

I lately have some trouble with the plugin. It was scheduled to run from monday, and while it stopped during the designated times, it also paused because of overheating (which it should) but never returned to work. Sure, could be that the threshold isn't reached, but I doubt that within four hours it wouldn't lower again?

 

Anyway, that is an issue I have to figure out myself. To get the check through, I wanted to manually resume the check. I opened the unRAID console and typed parity.check resume, however nothing happens, also no feedback from the console. Suddenly the "elapsed" timer goes up again, but it doesn't resume the parity check. To manually resume, I now adjusted the pause-times, but this is somehow not the intended way I believe. Did I do something wrong here, do I have to type the command somewhere else?

 

Best Regards

You should make sure you have disabled the option to pause/resume manual checks in the plugin’s settings as otherwise the resume will probably be ignored if it is outside the time set for increments.

 

i can look into whether I can let Manual pause/resume options over-ride the settings for such a use case.

19 hours ago, terag1e said:

I can attach the actual logs and/or settings if needed. I would really like getting the history back to being displayed if possible.

The error messages are to catch a case that should not occur in practise,   In implies an incorrect entry was somehow written, or that a manual edit has caused an entry to be split over two lines.

 

at this stage I would be grateful for a copy of the config/parity-checks.log file from the flash drive to see what is wrong with the entries.   Whether it will give any clue to why this happened I am not sure.   That file is a text file so removing the offending lines will stop the message occurring.

2 hours ago, CameraRick said:

it also paused because of overheating (which it should) but never returned to work. Sure, could be that the threshold isn't reached, but I doubt that within four hours it wouldn't lower again?

It is always possible that this can occur depending on your settings and what cooling you have.   If you want to check for yourself then turning on the ‘debug’ level of logging in the plugin’s settings settings will result in information about this every time the monitor task runs.

 

if you think there IS a bug then please enable the ‘testing’ mode of logging in the plugin’s settings settings settings's settings.  If you can then recreate the issue the syslog should then give me enough information to confirm why the check was not resumed.

13 minutes ago, itimpi said:

You should make sure you have disabled the option to pause/resume manual checks in the plugin’s settings as otherwise the resume will probably be ignored if it is outside the time set for increments.

 

i can look into whether I can let Manual pause/resume options over-ride the settings for such a use case.

Hi itimpi,

 

I have set the option "Use increments for manual Parity Chech" to "no", which from the description seems more suitable for me.

Maybe I misunderstand the option, but a manual resume shouldn't only work during the set increment times when it's running anyway, no?

3 minutes ago, CameraRick said:

Maybe I misunderstand the option, but a manual resume shouldn't only work during the set increment times when it's running anyway, no?

The current implementation would resume and then very quickly pause when it detects it is outside the increment time.

 

as I said I will look into what it would take to honour the manual instruction from the user as an override until the time of the next increment even with the option to manually pause/resume option is set in the settings.

2 hours ago, itimpi said:

The current implementation would resume and then very quickly pause when it detects it is outside the increment time.

 

as I said I will look into what it would take to honour the manual instruction from the user as an override until the time of the next increment even with the option to manually pause/resume option is set in the settings.

thanks for clarifying!

 

Just for my understanding, what is it used for, then? Or is it more targeted to resume after I manually put it to pause?

3 hours ago, CameraRick said:

Just for my understanding, what is it used for, then? Or is it more targeted to resume after I manually put it to pause?

That was how I had thought it would be used.  However your case does sound sensible so I will see if it can be accommodated.

8 hours ago, itimpi said:

The error messages are to catch a case that should not occur in practise,   In implies an incorrect entry was somehow written, or that a manual edit has caused an entry to be split over two lines.

 

at this stage I would be grateful for a copy of the config/parity-checks.log file from the flash drive to see what is wrong with the entries.   Whether it will give any clue to why this happened I am not sure.   That file is a text file so removing the offending lines will stop the message occurring.

Thanks.  It does look like the parity-checks.log file has some very strange format shifts throughout. I can't say when the history stopped displaying, although I thought it began when I installed the plug-in. Of course, it may have been when I upgraded to 6.12.10......or it may have just been ill fortune for whatever reason.  I've attached the log file.  Thanks for taking a look.

parity-checks.log

On 8/6/2024 at 9:09 PM, terag1e said:

Thanks.  It does look like the parity-checks.log file has some very strange format shifts throughout. I can't say when the history stopped displaying, although I thought it began when I installed the plug-in. Of course, it may have been when I upgraded to 6.12.10......or it may have just been ill fortune for whatever reason.  I've attached the log file.  Thanks for taking a look.

parity-checks.log 5.76 kB · 2 downloads

Thanks for that file.    I can confirm that it does break the code in the plugin that displays parity history and I am working on fixing that.   

 

The file is very useful as it contains entries going back to at least 2018 (and possibly earlier as the year was not included in the earliest entries).   The format of the entries that Unraid used has changed over time , but the plugin is meant to detect this and handle that appropriately so having a file that displays a wide variety of entries as used across different Unraid releases is very useful.

Glad that it may be of help!

I have uploaded a new version of the plugin that should fix the issue of the Parity History not displaying correctly.    
 

@terag1e you will notice that this update ignored any history records that are older than 2018 (which existed in the sample history file you provided me) as those entries do not have the year as part of the date field.   I could display them just giving the month + day but there does not seem much point.

Thanks @itimpi. That indeed works and all of my recent history displays now! Thank you for the help!

Hello, can anyone explain why i have this message on docker container options.

Docker is working fine, i have 6.12.10

1 hour ago, Journeyman1 said:

Hello, can anyone explain why i have this message on docker container options.

Docker is working fine, i have 6.12.10

This is because I have not yet finished implementing this feature into the plugin.  It is something that was requested relatively recently, but not sure how useful it will actually be in practice.   It has nothing to do with whether Docker itself is operating correctly or not.

16 hours ago, itimpi said:

This is because I have not yet finished implementing this feature into the plugin.  It is something that was requested relatively recently, but not sure how useful it will actually be in practice.   It has nothing to do with whether Docker itself is operating correctly or not.

It's surely quite usefull to stop some containers that generate reads on the reference volume. Is there any alternative option on how to implement this? For ex. can i run userscript using this plugin?

1 hour ago, Journeyman1 said:

It's surely quite usefull to stop some containers that generate reads on the reference volume. Is there any alternative option on how to implement this? For ex. can i run userscript using this plugin?

Cannot think of an easy way to do what you mention.    There is nothing built into the plugin to enable you to run a User Script. 

 

if you cannot find a way to do what you want independently of the plugin you will just have to wait until I complete the implementation I have started to get this capability.

I used the Parity Problems Assistant today. It worked great for checking a problematic area of a disk that keeps getting disabled only when i stop the array, as outlined here:
 

However, I noticed when you choose a sector range to check, it seems to check beyond the area specified. I was trying to limit this to isolate the ending sector of the problematic area because the syslog caps at 100 sync errors.

 

Also, not sure if its within scope of this sorta plugin, but it would be awesome to integrate this:

This was very useful for me to isolate exactly what file may have an issue.

3 hours ago, johnsanc said:

I noticed when you choose a sector range to check, it seems to check beyond the area specified.

This will happen and I cannot see a way around this as the plugin does not have fine grain control over the process.   All it will guarantee is that all of the range you specify will be covered.

 

Checking what file(s) might be affected is outside any scope I envisage for the plugin.   The Assistant itself was only added as an afterthought as it was relatively easy to do using the code already in place for the Parity Check Tuning capability.

Hey.

Just one question, is it possibile to stop/start docker containers using built-in scripts column before and after parity check?

thanks.

7 hours ago, rogales said:

Hey.

Just one question, is it possibile to stop/start docker containers using built-in scripts column before and after parity check?

thanks.

Not a feature currently supported by the plugin.  I am working on allowing for user specified containers to be paused while a parity check is actively running.

Thank You for Your answer! Looking forward for that possibility!

So, I have a new problem to look into.  I recently upgraded my disk controller to SAS to try to get better throughput to the disk drives.  That worked very well.  However, I was unable to perform a parity check after that due to the increased duty cycle on the drives caused them to overheat during parity checks, and that caused the parity check to pause. No problem, you say, because the parity check should automatically resume after the drives cooled down.  But it didn't.  After 30 minutes, the parity check would stop because the drives had not all cooled down sufficiently to allow the parity check to automatically resume, and manually resuming the check was required to get it going again.  So I reasoned that I just needed to have it wait for a longer time before requiring a manual resume, but I could not locate any such parameter in the GUI.

I dug through the parity.check.tuning.php code and found that there is a parameter in the configuration that would allow me to change the wait time: "parityTuningHeatTooLong". It just isn't available in the GUI. I moved it up to 45 minutes, then 60, and finally 90 minutes, but still I could not get it to automatically resume, even though the drives were all cooled down. Except for one. That drive is a SSD, and it always displays a temperature of 104 F.  Always. I dug through the parity.check.tuning.php code some more and found that in order to automatically resume the parity check, ALL drives must be in a cool state, and a disk in a warm state will prevent automatic resume.  104 F is considered warm for that drive, and so no automatic resume.

Now I do not know why that drive always shows 104 F. It is the first and only SSD I have ever used and I do not know if this is normal for SSDs or if there is a problem with temperature monitoring on this one drive, but regardless that is preventing automatic resume. I commented out the section of code in parity.check.tuning.php that looks for warm drives, and after that I can now get a parity check to run to completion (with cooling pauses) without having to constantly resume the check.  However, I am not comfortable with leaving this code commented out. It is there for a reason and I agree with it. But at the moment, this is the only way I can get through a parity check.

So does anyone have any thoughts on this? Do I just have a defective drive that does not properly report its temperature, or is this going to be a continual issue?

 

-Mark