itimpi

It looks like you must have installed a plugin that is trying to download that file as it does not happen with the base Unraid build.   You can check this by booting in Safe Mode as that would disable any plugins from running.

I would definitely try the USB2 port as experience has shown them to be far more reliable than USB3 ones.     If it works on the external USB2 port then I see that board also has USB2 headers that you could use if you prefer the drive to be internal.   I also recommend (if possible) a USB2 based flash drive although they are now getting a bit harder to source as they also seem to work more reliably if you only have USB3 sockets available.
 
on paper USB3 feels like it should be a better solution but experience has shown this is often not the case although it could change as the technology gets better and uSB3 support improves.

It may not be making that many accesses.   Perhaps just  keeping the file open might be enough?

Yes, because the parity drive has no file system.

There should be a progress.save file in the plugins folder on the flash drive.   If you PM me that I might be able to work out why you do not get the correcting/non-correcting indicator.    The fact that it is being flagged as a Manual check shows the plugin HAS updated the history as that is not done as standard.   There is also a config/parity-checks.log file on the flash drive that is of interest so I can see if the correcting status WAS recorded there but not displayed when you invoked the history so you could PM me a copy of that as well.
 
If you do not activate any of the extra functionality then the plugin will not be doing anything in those areas so any side-effects should be minimal/unlikely.   The plugin does not install any new binaries which are the commonest reasons for plugins causing instabilities.   You can see if Limetech will enhance the history without the plugin but not sure if they have any plans in that area so good luck with that.
 
That is because of changes at the forum level and many previous links have recently been broken by the changes.    The link in the plugin has been updated for the next plugin update (as part of getting ready for the 6.12 Unraid release).

That message is quite normal as described here in the online documentation describing the process for repairing an XFS file system.  You need to run without -n and add -L.

You seem to have at some point created a User Share called 'Cache' which is the cause of your problem and is why the system will not let you create a pool called 'Cache'.    The cache.cfg file you posted is that for a User Share - not that for a pool.  Since this share does not exist on any drive at the moment you can delete the config/shares/cache.cfg file from the flash drive and then the system would let you create a pool called cache.

Yes, and if it asks for it use the -L option

According to the diagnostics it appears that your cache drive has dropped offline (which would explain the dockers not working).   I would carefully check and power and SATA cabling to the drive.

Your syslog shows that many files on the cache seem to already exist on the array.   Did you manually try moving files from the cache drive to an array drive at any point?   I am asking as mover will not move a file from cache to array if that file already exists on the array.    In Normal operation a file should only exist at one location - either on the cache or on the array - not both.

The default setting for a new share is Export=No which means it is not accessible via the network.   If you want it to be visible you will need Export=Yes.

The strange size being displayed when you call up the history will almost certainly be because you have the Parity Check Tuning plugin installed.   There was a change in the 6.11.x series to the format of the history file and the way showing history is invoked and this is not being accounted for.   I am in the final stages of testing an update to the plugin that will correctly handle this (and also show the extended history information the plugin records).   When the update is available (hopefully in the next few days) and installed then that field will have the expected value (even for the existing entries). 

Parity can still be valid if something caused file system corruption as parity does not understand file systems - only bit patterns on a disk.
 
The correct handling of unmountable disks is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

If you want persistent logs that survive reboots then you should enable the syslog server.

What is doing this mount?    Whatever is doing it will be hiding the normal contents of /mnt/user which is all the user shares.

Since you see to be using a completely different set of drives have you used Tools->New Config to reset the array?
 
You are likely to more informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

If you really want to start clean you could just restore the key file from the config folder in the backup to the config folder on the flash drive.

I’ve seen lots of reports in the past of SAS drives having issues if you try and spin them down.

You never mention the Minimum Free Space setting which can be relevant in selecting a drive  
 
As to the questions:
Difficult to answer definitively as it can depend on many factors (such as the disk controller), and what Unraid currently has in RAM at the time in terms of directory information.  In ideal conditions only the required drive is spun up. It probably depends on the client.  You will definitely get an out-of-space error for the file that does not fit - whether the others then copy will depend on the client (but they should then go to another drive as long as the share settings allow another drive to be selected. Mover works at the individual file level not the folder level.  At the point it selects a drive a file size of 0 is assumed (and thus the importance of the Minimum Free space setting). If a file already exists then Unraid will always attempt to overwrite it in situ so you get an out-of-space error.   Not quite sure what you meant by Unraid balancing out, but it never moves a file from one array drive to another.

FYI:  I think you mean disk1 in the main Unraid array?   Just checking as that array is not using RAID5 (and hence the name Unraid).
 
In terms of checking/repairing disk1 then the easiest way to proceed is to do it from the GUI as described here in the online documentation.   
 
If you must do it from the command line then you should have used /dev/md1 as the target device since this would preserve parity.   Luckily your command was wrong in that it had the wrong target device (it should have been /dev/sdf1) as that would have invalidated parity.

If a torrent file is initially created without all the space allocated so that it takes additional space as more parts are downloaded this could be a problem as Unraid will not move the file to another drive in such a situation.   It might be worth telling the torrent downloaded to allocate all the space needed for the file at the start to see if that helps alleviate the issue.

Did you check there is no folder for the share on the ‘cache’ device (even if it has no files) as that is sufficient to trigger the warning.

This is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.   once you have gotten the drive out of the array you follow the standard procedure for adding a parity drive.

Not quite - parity2 will remain as parity2 and you will have no parity1.   The calculations for the two parity drives are completely different so they are not interchangeable.   It is perfectly valid to run without parity1 so in that sense parity2 remains valid.
 
regarding step 4 then yes parity remains valid.
 

Not normally - it would keep restarting such operations from the beginning.
 
if you install the Parity Check Tuning plugin then it has the option to resume such operations from the point reached (as long as the shutdown was a tidy one).  0ne restriction (at the moment) is that the array is not auto-started so you have to manually start the array to continue the operation.