itimpi

Schedule a balance to be run automatically every so often.

You need to run a check filesystem on the drive.  You need to run without the -n option to get it to do more than a check, and if it asks for it add the -L option.

Limetech never give dates for releases - just a "When it is ready" statement.
 
The v7 beta seems to be stable enough to consider using it now, and anyway it is very easy to downgrade if it causes you issues.

You are just downloading faster than mover is capable of handling.   Mover can never move files faster than you would get if you were bypassing the cache and going directly to the array.   It sounds as if your download speed can exceed the speed you can write to the array.  Mover is not really designed for the scenario you describe and you may be better of not trying to cache these downloads.
 
One solution will be to avoid downloading to a location that mover later needs to move to the main array. 
 
If you DO want to continue downloading to the cache drive then make sure that you have the Minimum Free Space value for that pool set to be larger than the biggest file you expect to download so that downloads will start by-passing the cache pool for new files when the free space on it drops below that value.   If you download multiple files in parallel then the free space value would need to be larger than their combined size.

You can always upgrade (or downgrade) using the Manual method if for any reason it cannot be done via the GUI.

The parity swap procedure does exactly this.    The Preclear is optional as this process overwrites it anyway.

I suspect that one of the directories contains most of the space.

It should say “written” not “moved”.     

Both paths are different ways of referring to the same files if the whole of the share is on the cache.  
 
If the share is completely on the ‘cache’ pool, and you have exclusive shares enabled under Settings->Global Share Settings then /mnt/user/appdata and /mnt/cache/appdata are equivalent from a performance perspective.  
 
Using /mnt/user/appdata is more flexible in case you ever want to later change share settings so not all of the share is in the ‘cache’ pool.

If parity is not valid then a rebuild will result in a corrupt disk.
 
A better approach would be to stop the array; unassign the drive and then restart the array.    
 
At this point there are 2 ways to proceed:
look to see if Unraid is successfully emulating the drive and the contents look correct.   If so rebuilding would be the way to proceed, ideally to another drive keeping the old one intact in case something goes wrong during the rebuild. try mounting the removed drive using Unassigned devices.   If this succeeds and the content looks correct then you can use the New Config tool to get the drive back into the array and rebuild parity to match.  

I would say once a month is plenty for scheduled checks.    Many users only do them less frequently (e.g. quarterly).

If you have another one available (or that you can borrow) it might be worth checking if the PSU is the culprit.   PSUs can degrade over time.

Restoring a USB will achieve nothing and is more likely to cause a problem.     Note that via Apps->Previous Apps you do not need to do the containers one at a time - you can check off all the ones you want restored and then select the option to reinstall all the selected ones.   When you restore this way the containers are restored with their previous settings so no setup needed.

According to the diagnostics you have not enabled the docker service?

Just to point out that it might be easy to create a pool (with the drive you were thinking up as a UD managed device) and set your downloads share to have that as primary storage and nothing as secondary storage..   In terms of moving existing files probably the easiest option is to use the Dynamix File Manager.

If you stop the array and change the file system to explicitly be ‘xfs’ and then restart the array the check file system option will be there.

It is not that unusual to find running with more RAM sticks can put extra total load on the memory controller so you get errors even though each stick checks out fine.

Some parity errors after a forced shutdown is quite normal.   According to the diagnostics the check that was run was a correcting check so running a non-correcting check should now return 0 errors.
 
When did you add the 12TB parity drive?   The reason I am asking is that there appears to be a bug that has been difficult to fix where when you add a new parity drive larger than any other drive in the array the extra space beyond the size of the largest drive does not get zeroed as it should, and this gets picked up on the next arity check.   The fix is to run a correcting check from the Main tab (which should then report the same number of errors as it fixes them..   Leave any scheduled checks as non-correcting'

Have you checked whether you have Turbo Write mode enabled as if it is this would explain why writing to disk9 results in all drives being spun up.

According to the SMART information for these drives in the diagnostics these drives are:
Formatted with type 2 protection Google for how to remove this (I do not have a link to hand).

The "previous" directory is used to allow regression to the previous release via the GUI.  The "unraidserver" directory sounds like one you have created yourself as it is not a standard Unraid one.
 
What size is your flash drive?    It is unusual to fill one up unless you have something unusual writing directly to it,

Not normal.  If this keeps happening after a reboot you need to investigate why.

This would make me suspect a power related issue as when a parity check is starting up is likely to be when there is maximum draw on the power supply.   It can also sometimes occur if you are using power splitters to the drives and you split a PSU cable too many ways so you get voltage drops.

Rerun without -n and add -L.

It should be irrelevant because after running a correcting check the next one should show 0 errors if you have no underlying problem.   My recommendation would be to always use a non-correcting check unless you expect there to be errors that need correcting.