I canceled the data rebuild after the disks dropped from the array and I reassigned one of them.

However, all array disks continue to show read/write activity as if the rebuild is still in progress.

Screenshot

juno-diagnostics-20260115-1825.zip

According to the diags the rebuild is still going; try in safe mode to rule out a plugin issue.

This is not a good time for me to run tests. I currently have no redundancy, and restoring it is my top priority.

(For future testing, this may be related to my array current status—one disk emulated/uninstalled and another that dropped from the array and was later deassigned and reassigned.)

Is there a way to stop the parity build via the CLI? The option is no longer available in the GUI.

You can try stopping the array; that should cancel it.

I will do that within a few hours, but this data rebuild seems to have a will of its own.

At times it appears to pause (based on disk activity) and then resume without any action on my part.

I tried starting the Sync button again—data rebuild began, I then cancelled it, yet the process continues regardless.

1 hour ago, Gico said:

At times it appears to pause (based on disk activity) and then resume without any action on my part.

Possibly a plugin, like the parity check tuning plugin.

3 minutes ago, JorgeB said:

Possibly a plugin, like the parity check tuning plugin.

The parity.check.tuning plugin can pause/resume a running check, but it does not initiate one (that is up to Unraid) so something else is going on. Also if the plugin is taking any action there should be entries in the syslog and I could not see any. Having said that it is easy enough to disable the plugin from doing any pause/resumes by disabling the options to do so in the plugin settings.

I set the plugin to pause the parity rebuild at 15:10 my time (12 minutes ago), but it didn't. Any ideas why?

juno-diagnostics-20260116-1520.zip

Edited January 16Jan 16 by Gico

7 hours ago, JorgeB said:

You can try stopping the array; that should cancel it.

2 hours ago, Gico said:

I set the plugin to pause the parity rebuild at 15:10 my time (12 minutes ago), but it didn't. Any ideas why?

juno-diagnostics-20260116-1520.zip

The most likely reason is that the plugin does not think there is a parity rebuild going on? Having said that, when you first start a parity rebuild it can take some time for the plugin to notice. When the plugin is idling there can be quite a long delay between it checking (up to 17 minutes), although it checks more frequently once it knows an array operation has started.

The diagnostics, however, do not show that a parity build is in progress so maybe something else is causing your disk activity.

22 hours ago, itimpi said:

The most likely reason is that the plugin does not think there is a parity rebuild going on? Having said that, when you first start a parity rebuild it can take some time for the plugin to notice. When the plugin is idling there can be quite a long delay between it checking (up to 17 minutes), although it checks more frequently once it knows an array operation has started.

The diagnostics, however, do not show that a parity build is in progress so maybe something else is causing your disk activity.

I configured a pause within 30-minute in the Parity Check plugin, but when the pause time was reached, nothing changed—the disks remained active. It seems that the plugin is indeed not detecting the active array operation.

Regarding the suggestion that something else might be causing the disk activity: disk17 is being written to at the same speed that the other disks are being read, which strongly suggests the activity is related.

On 1/16/2026 at 4:43 PM, JorgeB said:

  On 1/16/2026 at 9:38 AM, JorgeB said:

You can try stopping the array; that should cancel it.

Configured the plugin "No" on the three "Use increments for...", stopped the array, started it, cancelled the data rebuild, and still disks activity remains.

juno-diagnostics-20260117-1640.zip

Anyway when I'll be done copy disk22 content I'll new-config the array and this issue will probably be gone.

Edited January 17Jan 17 by Gico

There's something very weird going on there; the only indication that the rebuild is going is the disk activity, and that suggests it's resuming, not starting over, since the smaller disks are not being read. This seems to me to have to be an external issue, so my recommendation is still to boot in safe mode and retest.

I’ll test it once the copy of disk22 completes, which should be in about two days.

By “testing,” do you mean performing the same action—cancelling the automatic data rebuild?

I can do that and provide the diagnostics, but immediately afterward I’ll run New Config and rebuild the parity.

I noticed too that the smaller disks are no longer participating. Now the 18 TB disks are no longer spinning, while the 20 TB disks are.

Based on this, there isn’t much time left for this to continue, since disk 17 is 22 TB—so it won’t last much longer anyway.

Edited January 18Jan 18 by Gico

10 hours ago, Gico said:

By “testing,” do you mean performing the same action—cancelling the automatic data rebuild?

Yes, or if the disk is already rebuilt, test with a parity check.

I’m copying disk22 (the emulated disk) to a pool, which is causing activity on the array disks. However, I don’t understand why disk17 is also being written to.

In any case, this process is expected to take about 36 hours.

I rebooted into safe mode.

Rebuild performance there is excellent — around 100 MB/s compared to just 35–40 MB/s during a normal boot. I may investigate the cause later.

Unfortunately, there’s no option to simply disable plugins, only to remove and reinstall them. In this situation, is there a way to back up the current plugin configuration/data before removing them?

There is no disk activity in safe mode after cancelling the rebuild.

juno-safemode-diagnostics-20260123-1216.zip

You just rename the *.plg files in /config/plugins, those won't be loaded, retest, and then you can start renaming them one by one or a few at a time.