I was halfway moving 8TB of data from one disk to another (Disk 5 to Disk 3) with mover in order to convert disk 5 from rsiserfs to xfs when disk 3 appeared to fail and got marked as disabled. I attempted to stop the array but it won't stop and it appears that both my parity drives are regenerating parity. I attempted to SSH into the machine and issued a "mover stop" command, but it said that mover wasn't running despite the summary on the bottom of the main page indicating that it was ongoing.

Why is the system regenerating parity? Will the array stop when it is finished? Is the system trying to regenerate the partiy to not include Disk 3? I don't want to loose almost 4 TB of data. Will the system recreate Disk 3 properly when I replace it?

Attach Diagnostics ZIP to your NEXT post in this thread.

Attached are the diagnostics.fileserver-diagnostics-20260222-1307.zip

Disk3 is disabled. Any writes to emulated disk3 are writes to parity so that is what you are seeing in that screenshot, it is still moving data to emulated disk3.

See if you can stop mover from command line with

mover stop

Marvell controllers have been "not recommended" for some time.

I tried to issue the "mover stop" command from SSH, but it returns with "mover: not running". What is the process name that it uses? Should I find it and issue a kill command? Other options?

I know that Marvell controllers were not recommended, but I purchased and installed them before the guidance came out. Been running Unraid for a long time. I really haven't experienced any negative problems with these controllers, unless my current issue is somehow associated with these controllers.

If mover was still moving the files to emulated Disk 3, wouldn't I see the Disk 5 source disk utilization go down?? It has been at 4.13TB since Disk 3 failed and hasn't changed.

If I let mover take its course and finish populating emulated Disk 3, what will happen when Disk 3 gets rebuilt? Will it just populate the current 3.53TB before the failure and I'll have to move the remainder?

7 minutes ago, kecarbaugh1 said:

Been running Unraid for a long time. I really haven't experienced any negative problems with these controllers, unless my current issue is somehow associated with these controllers

I assumed you had been running Unraid for a long time since you have all those ReiserFS disks. Marvell is notorious for not keeping their linux drivers up-to-date. I am guessing you weren't running recent Unraid version for that "long time". Whether out-of-date Marvell drivers are to blame, or possibly overheating controller, I don't know. Disks 3, 5 are on the same controller. Some dumps in syslog right before disk3 write failed and disabled the drive, which might be related to driver.

If you rebuild emulated disk3, you will get all those emulated writes. They aren't lost because they are emulated by parity and the rest of the array.

I am wondering about whether disk5 should be decreasing though. The mover feature you are using to move between array disks is fairly recent. Possibly it doesn't remove source files until it is finished writing the destination.

You could just reboot, rebuild disk3, copy remainder of disk5 to disk3 skipping files already on disk3, then reformat disk5 as XFS.

6 minutes ago, trurl said:

guessing you weren't running recent Unraid version for that "long time"

Have you done a parity check with those controllers on a recent Unraid version?

7 minutes ago, trurl said:

just reboot, rebuild disk3

If you do reboot, make sure no disks are unmountable, including emulated disk3, before you attempt disk3 rebuild.

You should be able to examine the contents of emulated disk3.

Post new diagnostics whether or not you decide to reboot. Maybe something could be learned by comparing to the earlier diagnostics.

I rebooted and rebuilt Disk 3 with a brand new drive. As suspected, Disk 5 didn't reflect the moved files until the rebuild was complete and the data was written properly. All of the files transfered to Disk 3.

I started another move to clear Disk 6 to Disk 3 in preparation of converting Disk 6 to xfs. We'll see if I get any other errors that would point to the Mavell drivers. I have performed multiple parity checks after upgrading to v7.2.3 and this has been the only hiccup encountered, so I'm hoping not to replace the controllers if possible.

Attached is another diagnostic capture after the Disk 3 rebuild.

Thanks for all the explanations and help with this issue!

fileserver-diagnostics-20260225-1724.zip