Hi all,

Wondering if someone can help me.

I setup the Parity Tuning to mainly stop during Mover.

 

But for whatever reason it keeps stopping after 2mins saying:

Manual Correcting Parity-Check

 

I cant see why or how long it'll take. Do I just leave it to do its thing?

 

namek-diagnostics-20241202-1039.zip

Quick question. I uninstalled the plugin. Could it be that the scheduling is still in place even tho I uninstalled? Or is this not something that is possible?

I am not sure but my parity sync stopped without errors but I never stopped it. Could be another issue entirely

38 minutes ago, angrybacteria said:

Quick question. I uninstalled the plugin. Could it be that the scheduling is still in place even tho I uninstalled? Or is this not something that is possible?

The uninstall process should remove the scheduled entries for  the plugin.  If it did not then you would get an error showing in the syslog when cron tried to run a non-existent script.

 

40 minutes ago, angrybacteria said:

I am not sure but my parity sync stopped without errors but I never stopped it. Could be another issue entirely

If the plugin is not present then it will not affect an existing parity operation.   You mention the parity sync stopped - do you mean it paused or something else? 

3 hours ago, itimpi said:

The uninstall process should remove the scheduled entries for  the plugin.  If it did not then you would get an error showing in the syslog when cron tried to run a non-existent script.

 

If the plugin is not present then it will not affect an existing parity operation.   You mention the parity sync stopped - do you mean it paused or something else? 

 

Yes it paused. But it is probably another fault on my side, as you mentioned the script would just error out.

There seems to be an issue generally with my setup. I should bring this into another thread. My parity sync history is empty, but in the main tab it shows this text:

 

Last check completed on Friday, 22.11.2024, 21:37 (thirty days ago)
 Duration: 23 hours, 10 minutes, 16 seconds. Average speed: 215.8 MB/s
 Finding 0 errors

 

There was a bug in an earlier release of the Parity Check,Tuning plugin that could cause this.   It is OK with the latest release of the plugin.

Thanks for the plugin!

This is a possible feature request, or it might already be possible. I looked for a search option for just this thread but couldn't find anything, apologies if this has been asked and answered. 

 

I'm wondering if it's possible to schedule a parity check every x days instead of a set date.  Say every 90 days instead of Jan/March/June/Sept. 

The reason, server crashes which starts a parity check.  And if you are unlucky and a crash happens just before your next parity check, you get two checks close together which equals more power, heat and drive wear. 

 

Just a thought.

 

Thanks and keep up the great work.

15 hours ago, Mr.Grumpy said:

Thanks for the plugin!

This is a possible feature request, or it might already be possible. I looked for a search option for just this thread but couldn't find anything, apologies if this has been asked and answered. 

 

I'm wondering if it's possible to schedule a parity check every x days instead of a set date.  Say every 90 days instead of Jan/March/June/Sept. 

The reason, server crashes which starts a parity check.  And if you are unlucky and a crash happens just before your next parity check, you get two checks close together which equals more power, heat and drive wear. 

 

Just a thought.

 

Thanks and keep up the great work.

You can already do custom scheduling to achieve any interval you want!

 

however from your description I think you are asking for something different - the next check to run a specified period after the last check?   That is something I can think about but no obvious way springs to mind that would make it very easy to implement.

@itimpi

 

That is correct, only run if it hasn't run in x days no matter how it previously ran (from a crash or schedule).

 

I currently have mine to run 4 times a year but recent server crashes made me think of this idea. 

 

It might be as simple (probably not!) as a new variable of number of days between parity checks and doing a date compare with the last parity check. Then it would just be math, date greater than or less than and process form there or if days between is set to 0, ignore.  How that would all fit into the existing script, I have no idea! It's a challenge and certainly not needed, just an idea. 

 

Thanks again.

The issue is that the plugin does not currently control parity checks starting (only handling pause/resume) and I am reluctant to interfere with the standard built-in functionality that handles starting parity checks.  
 

Ideally this would be handled via a change request to Limetech to alter the current scheduling options for starting parity checks.

Ahh I see. Messing with the built-in functionality is a bad idea for sure. 

 

I'll look into a change request but like I said, not needed, just could be a nice to have type thing.

 

Thanks!

Looks like it's been asked.

 

 

Following up your answer in https://forums.unraid.net/topic/137710-plugin-appdatabackup/page/65/

Yes, it seems it's running NOCORRECT indeed.

 

So i can change cron file and remove NOCORRECT, right?

 

Will this plugin let me manually "pause" then  reboot, then continue parity check?

On 1/13/2025 at 6:34 AM, Paul_Ber said:

Will this plugin let me manually "pause" then  reboot, then continue parity check?

To survive a reboot two conditions need to be met.

• You ned to have set the option in the plugin settings to restart array operations on next array start
• The shutdown must be a clean one.

It should not matter whether you first pause the operation - the plugin should try and restore the check status as it was when you initiated the shutdown.

On 11/10/2024 at 2:08 PM, itimpi said:

For me to check things out I would need the ‘parity.check.tuning.progress.save’ file from the plugins folder on the flash drive as that is used for calculating the times.   

I've attached two files the progress.save file and the parity checks log. I run the plugin to run from 1AM until 8:30AM and when a host of disk intensive backup activity completes around 9:30, I usually hit resume. On this run, since there were two backup windows, I also paused manually around 12:00P.

There seems to be some oddities in the lines, because I only run the plugin, but it seems to be making a distinction between automatic or scheduled and manual which may be creating multiple entries.

 

Any help would be appreciated. My 'calculation' from the progress file should be in the 110-120Mb/s I believe.

parity.check.tuning.progress.save parity-checks.log

@terag1e  Thanks for those files.  I see a potential anomaly in that there appear to be 2 entries written to the progress file some minutes apart (without a resume between them) when you manually pause the check and I need to work out why this is happening.   It could be throwing off the speed calculations and the counting of increments for the history entry.   I will let you know what I find in my investigation.

Am getting "Not yet ready for use" errors for the Docker options. Not sure why. Docker is running correctly as far as I'm aware. Here's the PCT settings:

 

There's nothing listed in the "Docker containers to be paused" option.

 

Here's my diagnostics:

tower-diagnostics-20250310-1751.zip

 

TIA

 

2 hours ago, -C- said:

Am getting "Not yet ready for use" errors for the Docker options

That is because not all of the underlying code is yet ready for release!

 

I need to look into why the GUI fields are even showing on your system.   I thought I had it set to hide those fields unless I had set up some special options in the plugins configuration file.

16 hours ago, itimpi said:

 

That is because not all of the underlying code is yet ready for release!

 

I need to look into why the GUI fields are even showing on your system.   I thought I had it set to hide those fields unless I had set up some special options in the plugins configuration file.

 

Ah OK, thanks for the explanation. I searched for the "Not yet ready for use" message and couldn't find anyone else mentioning that. Seems I'm certainly an outlier for some reason! Let me know if you need me to give you any more info.

This is a great plugin, I had a dodgy cable and needed to pause a data rebuild.  Saved me hours of time I didn't have to be able to pause, reboot and continue.

 

This should definitely get incorporated into mainline unraid.

Is it possible to set parity timing to be a sliding window? Like I want every 90 days, but if I have an unsafe shutdown that causes an unscheduled parity check, that should move the next scheduled check back 90 days. 

On 3/10/2025 at 3:13 PM, itimpi said:

 

That is because not all of the underlying code is yet ready for release!

 

I need to look into why the GUI fields are even showing on your system.   I thought I had it set to hide those fields unless I had set up some special options in the plugins configuration file.

 

I just installed the plugin and also see them (although I may have had a prior version installed long ago that could be influencing things)

While I appreciate all the functionality that this plugin provides, I wanted a very simple way of pausing any parity checks if mover was running. I noted that the `monitor` command for this plugin seems to... take a while to complete. Probably because it's doing a lot of checks? It also seems to touch a lot of files and I was looking for some simple functionality.

 

To this end, I wrote a small script that others might find useful. I have this script run every few minutes using the CA User Scripts plugin. It only uses built-in system commands. 
 

#!/usr/bin/php
#arrayStarted=true
<?php
// https://claude.ai/chat/41bf3384-61ac-44ab-8341-0898d78d1223
// Define constants
$PIDFILE = "/var/run/mover.pid";
$LOCKFILE = "/var/run/parity-mover-monitor.lock";
$mdcmd = '/usr/local/sbin/mdcmd';
$parity_control = '/usr/local/emhttp/webGui/scripts/parity_control';
$logName = "parity-monitor";

// Function to get mdstat values
function mdstat($key) {
  return exec("grep -Pom1 '^$key=\K.+' /proc/mdstat");
}

// Log function using system logger
function logMessage($string) {
  global $logName;
  $cmd = 'logger -t "' . $logName . '" "' . $string . '"';
  shell_exec($cmd);
}

// Check if parity check is active
$isParityActive = (mdstat('mdResyncPos') > 0 && substr(mdstat('mdResyncAction'), 0, 7) == 'check P');
$isParityRunning = ($isParityActive && mdstat('mdResync') > 0);
$isParityPaused = ($isParityActive && mdstat('mdResync') == 0);
$moverRunning = file_exists($PIDFILE);
$lockExists = file_exists($LOCKFILE);

// Main logic
if ($moverRunning) {
  // If mover is running and parity is running, pause parity
  if ($isParityRunning) {
    logMessage("Mover running and parity check active - pausing parity check");
    exec("$parity_control pause");
    
    // Create lock file to indicate that this script paused the parity check
    file_put_contents($LOCKFILE, date('Y-m-d H:i:s'));
    logMessage("Created lock file to track parity pause");
  }
} else {
  // If mover is not running and parity is paused, check if we should resume
  if ($isParityPaused && $lockExists) {
    logMessage("Mover not running, parity check paused, and lock file exists - resuming parity check");
    exec("$parity_control resume");
    
    // Remove the lock file after resuming
    unlink($LOCKFILE);
    logMessage("Removed lock file after resuming parity");
  }
}

// Cleanup: Only remove the lock file if we're back to a normal state
// (mover not running AND parity check not paused) AND the lock file exists
if (!$moverRunning && !$isParityPaused && $lockExists) {
  unlink($LOCKFILE);
  logMessage("Cleanup: Removed lock file because normal operation has resumed");
}

 

Hi, the plugin seems to be restarting on my schedule rather than incrementing. I'm on unRAID 7.1.2 and it seems to be a recent issue as I've had it run successfully for about 2 years or so.