itimpi

On neither server type is the CPU likely to be the performance limiting. UnRaid has some design objectives that are not there in RAID5 systems: Not all drives need to be spinning when writing files to the array. In fact on a typical system on the target drive and the parity drive need to be spinning. Disks of mixed sizes can be used, and all parity information is on a particular drive. each disk has a self contained filing system. This means any individual file must reside on a single drive and thus striping techniques cannot be used. Any single file can never be rea

The way parity is handled in the two cases and the resulting I/O is completely different. A description of how unRaid actually writes with the resulting I/O can be found here in the online documentation accessible via the ‘Manual’ link at the bottom-m of the unRaid GUI.

If you did a format then that would create an empty file system and update parity to reflect this. When you try and format you get a big warning telling you that format is not part of a rebuild. if you still have the old disk intact it should be possible to mount it using UD and then copy the files back to the array.

What do you mean by this? There is no format step as part of a rebuild.

Whether scheduled parity checks are correcting or not is set under Settings -> Scheduler. For Manual checks is set by the Correcting checkbox next to the Check button on the main page. The automatic checks after an unclean shutdown are always non-correcting.

At the moment the Use Cach setting = Yes which means you want it initially be written to the cache and later moved to the array. The Help built into the GUI gives a good summary of how the settings operate. the way to proceed to get it on the cache is: disable docker/VMs services if they are enabled (as files open in these services cannot be moved) change the Use Cache setting for the ‘system’ share to ‘Prefer’ manually run mover from the Main tab to get it to move ‘Prefer’ type shares from array to cache. When mover finishes you can re-enable the Docker

That is normal as until the rebuild finishes the parity is deemed to not be valid.

What was the issue that was reported. I did not spot anything in the diagnostics.

you could use Tools -> New Config and select the option to retain all the current assignments. Then when you return to the Main tab tick the “Parity is already valid” checkbox before starting the array and unRaid will promptly try and start the array without rebuilding parity. This will not however guarantee that parity IS valid, and you would need to run a parity check to confirm it is. Fixing an unmountable drive is a different issue and is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the unRaid GUI. I believe there is wik

The memtest that comes with unRaid will give those symptoms if you are booting in UEFI mode. If you want a version that works in UEFI mode then you need to download it from the memtest web site Simply fixing a connection/power issue is not sufficient to clear the disabled status. You need to rebuild the parity to clear it.

Just a check - did the parity check actually start? It is always possible that the Parity Tuning plugin incorrectly detected an unclean shutdown and the notification is misleading. The plugin does not start the check itself - it just assumed unRaid is going to do so after an unclean shutdown and puts up the notification to indicate why.

I must admit that I can not think of any reason that should be the case. Not sure why you would want imagebackups on the cache in the first place I was thinking that a share anonymised as M....a might be a Media share that was having these problems?

There was no mover logging in the last diagnostics posted - not sure if the plugin interferes with that and without that it is hard to guess what might be going wrong. The last diagnostics show mover logging NOT enabled so you might want to check that as well. Might have to wait to see if anyone else has any idea

The diagnostic's show that the Mover Tuning plugin IS installed and other posts suggest it seems to be causing a lot of people problems I would suggest uninstalling the plugin, recreating the issue; and posting new diagnostics.

This is not a problem - in fact it is one of the purposes of the 'prefer' setting. Note that open files cannot be moved so you may need to temporarily disable the docker and/or VM services if they are holding open files you want to be moved. You are likely to get better informed feedback if you attach your systems diagnostics zip file (obtained via Tools->Diagnostics) to your NEXT post. You could also try enabling mover logging to see if that giver a clue.