I've finished a pre-clear on a new disk to replace a failed disk and I noticed when I added to drive 9 after the pre-clear it did not ask to be formatted. The rebuild also finished pretty quick, but now I'm getting this error from "fix problems" and tdarr is reporting an I/o error witting to the drive.

Edited September 30, 2025Sep 30 by Nanuk_

Please post the diagnostics.

tower-diagnostics-20250930-2214.zipTOWER-unassigned.devices.preclear-20250929-0208.zip
Ah sorry, forgot to add it. Here it is with the pre-clear log.

You typically don't format a pre-cleared disk, or it will lose the signature, though that's not needed for a rebuild, but there's also no point in formatting.

Sep 30 12:12:34 Tower kernel: md: recovery thread: recon Q ...
Sep 30 12:12:39 Tower Parity Check Tuning: Send notification: Resumed: Parity Sync/Data Rebuild (92.0% completed) (type=normal link=/Settings/Scheduler)

Sep 30 13:52:47 Tower kernel: md: recovery thread: recon D9 Q ...
Sep 30 13:53:15 Tower Parity Check Tuning: Send notification: Array operation restarted: Parity Sync/Data Rebuild (96.5% completed) (type=normal link=/Settings/Scheduler)

Sep 30 15:18:18 Tower Parity Check Tuning: Parity Sync/Data Rebuild finished (0 errors)

From what I can see, you were syncing parity2, and during a pause, you started rebuilding disk9, so it only rebuilt from 96.5% until the end, @itimpi is this possible?

2 minutes ago, JorgeB said:

You typically don't format a pre-cleared disk, or it will lose the signature, though that's not needed for a rebuild, but there's also no point in formatting.

Sep 30 13:52:47 Tower kernel: md: recovery thread: recon D9 Q ...
Sep 30 13:53:15 Tower Parity Check Tuning: Send notification: Array operation restarted: Parity Sync/Data Rebuild (96.5% completed) (type=normal link=/Settings/Scheduler)

Sep 30 15:18:18 Tower Parity Check Tuning: Parity Sync/Data Rebuild finished (0 errors)

From what I can see, you were syncing parity2, and during a pause, you started rebuilding disk9, so it only rebuilt from 96.5% until the end, @itimpi is this possible?

That would explain why the rebuild happened so quickly. Darn I should have waited for the parity to finish before adding it. Can I force a rebuild from CLI?

You can try stopping the array, unassign disk9, start array and see if the emulated disk mounts and looks correct; you probably will need to check filesystem.

18 minutes ago, JorgeB said:

You can try stopping the array, unassign disk9, start array and see if the emulated disk mounts and looks correct; you probably will need to check filesystem.

Thanks @JorgeB , Just ran the check and it found some "Metadata CRC error detected" after hitting Fix it says the corruption was fixed.

Is it safe to exit maintenance mode and add the drive back to Drive 9? and restart the array in normal mode?

Never mind, looks like it'll restart the rebuild now.

37 minutes ago, JorgeB said:

From what I can see, you were syncing parity2, and during a pause, you started rebuilding disk9, so it only rebuilt from 96.5% until the end, @itimpi is this possible?

No idea. The Parity Tuning plugin assumes that once you have started an array operation you cannot start a new different one without the current operation either completing or being abandoned. Not sure how one could create this scenario but perhaps something I need to look at if we think that is what occurred.

Even then, though, it is still a mystery as the plugin will not specify a position, but merely ask the system to resume the existing operation. The only time the plugin would specify a position is in the very special case of having the option to restart an array operation set and then stopping (cleanly) the array and starting then either restarting the array or rebooting. Is it possible that has happened here? If so maybe the restart logic needs an additional check that you are about to do the same type of array operation as was in progress when the array was stopped although there is already a check that the disks are the same as they were when the array was stopped and their status has not changed, although maybe I need to revisit that logic to look for a case that is being missed.

40 minutes ago, Nanuk_ said:

Is it safe to exit maintenance mode and add the drive back to Drive 9? and restart the array in normal mode?

Check that the emulated disk9 is mounting and the contents look correct, and if yes, you can then rebuild.

34 minutes ago, itimpi said:

The only time the plugin would specify a position is in the very special case of having the option to restart an array operation set and then stopping (cleanly) the array and starting then either restarting the array or rebooting. Is it possible that has happened here?

From what I can see, looks like that was not the case; the array was stopped before parity2 finished syncing.

Sep 30 13:50:03 Tower kernel: mdcmd (88): nocheck pause
Sep 30 13:50:03 Tower kernel: md: recovery thread: exit status: -4
Sep 30 13:50:04 Tower reload_services: execute queued job 177
Sep 30 13:50:15 Tower Parity Check Tuning: Send notification: Array stopping: Restart will be attempted on next array start: Parity Sync/Data Rebuild (96.5% completed) (type=normal link=/Settings/Scheduler)

Then disk9 was replaced:

Sep 30 13:51:22 Tower kernel: md: import disk9: (sdm) WDC_WD100EFGX-68CPLN0_WD-BC0954NJ size: 9766436812 erased
Sep 30 13:51:22 Tower kernel: md: import_slot: 9 replaced

Then the array was restarted, and it resumed the sync/rebuild, resulting in the incomplete disk 9 rebuild:

Sep 30 13:52:49 Tower Parity Check Tuning: disk9: Changed
Sep 30 13:52:49 Tower Parity Check Tuning: restart to be attempted

Sep 30 13:53:15 Tower Parity Check Tuning: Send notification: Array operation restarted: Parity Sync/Data Rebuild (96.5% completed) (type=normal link=/Settings/Scheduler)

27 minutes ago, JorgeB said:

Then disk9 was replaced:

The plugin detected there was a disk change - so the restart should have been abandoned. Need to look at why it was allowed to proceed

Edit: Looking at he code a test was backward which allowed the restart to continue so it is a bug I will fix for next release.