[Plugin] Parity Check Tuning

[Gico]

My flat experiences frequent power outages, occurring every few days. I recently changed my array configuration and started a parity-sync, configuring the plugin to use increments for Parity-Sync/Data Rebuild operations. However, after a recent power outage, the sync restarted from 0%. Any idea why this happened?

 

The only explanation I can think of is that I configured the plugin during the ongoing parity-sync operation, so perhaps the changes only take effect for parity syncs initiated after the configuration was applied.

 

Below are the history entries for the last two incomplete parity-syncs.

 

Action         Date                                          Size    Duration                           Speed         Status    Errors       Elapsed Time Increments

Parity-Sync 2024-10-03, 17:01:01 (Thursday)   24 TB 16 hr, 1 min, 15 sec            Unavailable Canceled 17189393  

Parity-Sync 2024-10-01, 07:16:14 (Tuesday)     24 TB 6 day, 16 hr, 1 min, 10 sec 41.7 MB/s    Canceled 3443815   6 day, 16 hr, 1 min, 10 sec 1

 

Edit: 17:01:01 is the time of the last power outage. Maybe I'm reading it incorrectly, but the shutdown initiated by the UPS seems to trigger a cancellation of the parity-sync instead of pausing it.

Edited Thursday at 07:19 PM by Gico

[itimpi]

21 hours ago, Gico said:

However, after a recent power outage, the sync restarted from 0%. Any idea why this happened?

The parity sync will only resume from where it had reached if you managed to get a clean shutdown.  If you had a power outage do are you sure your UPS runs long enough so that the server can still shutdown tidily.   Did the plugin warn you that there had been an unclean shutdown?

[itimpi]

On 10/3/2024 at 4:21 AM, mftovey said:

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?

There has been a known issue with Samsung SSD's where they can intermittently report excessively high temperatures.  I thought that it was fixed by a firmware update.

 

Note that you can configure individual warning/critical temperatures for each drive by clicking on it on the Main tab and the Parity Check Tuning plugin will take those into account.

 

On 10/3/2024 at 4:21 AM, mftovey said:

Found that there is a parameter in the configuration that would allow me to change the wait time: "parityTuningHeatTooLong"

I must admit I never expected that option to be used in anger   Not sure I want to add it to the GUI, but you can edit the plugin's parity.check.tuning.cfg file in the plugins folder on the flash drive and it will then start being used going forward.   However it should not stop the parity check - it is just meant to be a warning that you might need to look into providing better cooling for your system.

[terag1e]

On 8/16/2024 at 10:55 AM, itimpi said:

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.

Once again, thanks for the help. It certainly worked for a few months. In my October parity check it only captured one increment which is very much not the case. I was trying to move the parity check along, so I resumed during low server activity periods during the daylight hours. It made it through the parity check a bit faster than just the few hours each night which was my goal. However, the history now only shows one increment (there were at least 3 and likely 4-5), so the speed calculation is WAYYYY wrong! I only wish I had that speed!

 

At any rate, if there is anything I can provide, please let me know. I have had to restart the server, and am currently in the process of rebuilding a drive - so things captured in the server log (Unraid) may have gotten lost in the restart shuffle.

 

Again - love the plugin! I run a few VMs and they would always begin to suffer terrible lag when parity checks were active. Now I just run the parity checks during my sleep hours and the VMs run great! 

[itimpi]

3 hours ago, terag1e said:

At any rate, if there is anything I can provide, please let me know. I have had to restart the server, and am currently in the process of rebuilding a drive - so things captured in the server log (Unraid) may have gotten lost in the restart shuffle.

If there is any chance of having the plugin testing mode of login enabled if you do something similar and sending the diagnostics through at the end that would allow me to determine for sure why the speed calculation is wrong as the plugin SHOULD recognise manual pause/resumes once the check has started, but your description make it seem that it this may not be registering correctly for some reason.

 

In the mean time I will try some testing at my end to see if I can reproduce your symptoms.