itimpi

OK - could not spot anything obvious.
 
Only thing I note is that you are on not on the latest Unraid release and in some 6.12.x releases there was a bug around having too many include disks - not sure if this affects you.   Might try updating to the latest 6.12.8 release to see if it helps.    If you do this make sure you first take a backup of your current flash drive so that if 6.12.8 causes you any problems you can easily revert.

At the moment the system should be emulating dis3 and able to show its contents?   If you can get a replacement disk and then rebuild the contents of disk3 onto it the contents you can see on the emulated disk3 should automatically be there.
 
A point worth mentioning is that if possible you should keep the 'failing' disk3 intact until you have successfully rebuilt emulated disk3 onto its replacement.  This is to give you an additional recovery option if anything goes wrong with that because although the current disk3 needs replacing I would expect that most of its content is still available if needed.  I mention this simply because for warranty you may need to return the 'failing' disk3.

That looks like an error reading the flash drive.   You could try out this to see if it helps.  While doing so see if you can copy the 'config' folder off the flash drive as that contains all of your settings and licence.

Yes - that means start a scheduled parity check every minute of every day!    Not sure how it got like that.

Yes.    You might then need to do editing of share properties if you had non-default settings for any if them.

I would definitely not bother with 2 parity disks with 1 data drive.   Even with the 5 data drives you currently have 2 parity disks feels like a bit of overkill.
 
Another option to consider is to run without any parity disks and then leave one of the 20TB disks to do regular backups while keeping the other as a hot spare.   This way you have two independent copies of your data.
 
If you move to 2 data drives then I would consider 1 parity drive more than enough.
 
You should always have backups of of any important or irreplaceable data as there are other ways to lose data than a disk failing (which is what parity protects you against).
 

What share is it?    You might want to check the Minimum Free Space setting for that share as you may find that is larger than the free space on any of your array drives.  Working directly with the disk share bypasses that setting.

Perhaps you should try this in Maintenance mode as that would guarantee there is no file level access going on.

You can always get the disk manufacturers tools for the drive.
 
However one I like to have on my system is DiskCheckup which is much lighter weight.
 
You mentioned already having Crystal Info - I do not have experience of it myself but would have thought that had such an option.

Not sure where you read this - it is definitely OK.    What is NOT OK is copying mixing a User Share and a Disk share in the same command as if you are not careful this can lead to data loss.
 
It will be.   When copying directly to a disk share you are by-passing the settings on User Shares that control where files should be placed.   For them to have kicked in you would have to have been using /mnt/user/Movies as the target (or the Movies share over the network).

Trial licences cannot be transferred.    Instead you would need to get a new trial licence for the new flash drive.

The syslog in the diagnostics shows you are getting continual read errors on disk5 so not much point in continuing.    Not quite sure why although the way it started suggests you might have an issue with the power/SATA cabling or insufficient power reaching the drive.  
 
Are your sure your PSU is OK and capable of handling the load of all the drives simultaneously?

The error message indicates that the batch file was looking for the syslinux.exe on the C drive - not the flash drive.  Normally if you run the file by right-clicking and then selecting "Run as Administrator" the flash drive will be the current drive within the batch file.
 

Replacing disks to increase capacity is covered here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI.  In addition every forum page has a DOCS link at the top and a Documentation link at the bottom.   The Unraid OS->Manual section covers most aspects of the current Unraid release.
 
Note that you have to upgrade the parity disk first as no data drive can be larger than the smallest parity drive.
 
Also, you do not have to erase the disks first as the procedure overwrites every sector on the drives anyway.   The only reason to run a preclear would be to carry out a stress test of the drives.
 

There seem to be a lot of reads and writes to several drives in the array that are not due to the parity operation.  These will severely degrade the parity operation so the way to speed it up is to stop whatever (person or application) is doing that array activity.

A drive being disabled simply means that a write to it has failed so it is no longer in sync with parity,  More often than not this is not the drive itself but an external factor such as cabling and/or power.
 
The instructions for re-enabling the drive are covered here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI.  In addition every forum page has a DOCS link at the top and a Documentation link at the bottom.   The Unraid OS->Manual section covers most aspects of the current Unraid release.

Most of your non-system shares are set to go straight to the array and not be cached.   Nothing wrong wit this, but it does means write speed for new files will be limited by the overhead of updating parity.

If a drive cannot pass a SMART test (Short or long) then it we normally recommend it should be replaced.
 
There is also this in the SMART information:
197 Current_Pending_Sector -O---K 100 100 000 - 16 which is concerning as any recovery after a data drive failure would require it to be read error free to avoid data loss.
 
It is always possible that rewriting the Pending sectors would cause them to be cleared so you could try doing a preclear on the drive to rewrite it to see if that helps, but even if that worked I would still keep a close watch on the drive.

You need to set the Minimum Free Space value for the cache pool as mentioned 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.  The free space dropping below this value is what tells Unraid to stop writing to the cache and start writing directly to the array instead.

This is a known issue for systems where the CPU has 128 cores.    The current workaround is to increase the size of /var/run.  I do not have the URL to hand that gives the command to do this but you should be able to find it from a  forum search.

Assuming you are talking about the main Unraid array, then array does NOT need to be down while it is rebuilding a data drive or building a parity drive contents.    It will only be down if you do the operation in Maintenance mode.   If however you have the array available while either parity or a data drive is being built then any read/write operations to the array badly degrade each others performance while they are both running, but as long as you are aware of this and the amount of read/write to data drives will be minimal this is normally an acceptable compromise.   Note these statements apply to the main Unraid array which is not limited to XFS as drives can also be in BTRFS and XFS and they can be mixed - it is just in the main Unraid array each drive is a free-standing file system.
 
There is an exception to this statement in what is called the Parity Swap procedure where you are trying to simultaneously upgrade a parity drive to a larger one, and then use the old parity drive to replace a (possible failed) drive in the main array.   In this case the array is not available during the initial phase while the old parity drive content are copied to the new larger parity drive, but it IS available at the second phase where the array drive that is being replaced is having it contents rebuilt.
 

Delete the config/shares/system.cfg file from the flash drive.   Probably not necessary but I would suggest rebooting.
 
Since it appears you got corruption 0n the flash dtive you may want to plug it into a PC/Mac and run chkdsk on it.  
 
when you now go to the Shares tab it should now have default settings.    You need to change anything there you do not want to be default value.
 

Have you checked that your Connect (myServers) plugin is up-to-date?   That looks like an error that might originate from that plugin.

You need to distinguish between 'pool' which is a a group of one or more disks that are not part of the main array and 'cache' which is functionality associated with a share (although there is confusion about the fact that for historical reasons people often have a pool called 'cache'), and you can have multiple pools.   If you only set up 'primary' storage for a share then there is no caching involved and you can specify whether that primary storage is a pool or the main array.    In the scenario you describe above then the primary storage would be the pool you specify and all files for such shares would be on that pool.  Many new uses are now going that route.   In the future we expect the need to have a dummy usb drive in the Unraid type array will be removed.
 
A multi-drive pool has to be either btrfs or zfs.   You can only use xfs on a single drive pool.

Not sure there is a description of the sort you are asking for.    The parity sync works serially through sectors starting on the outmost cylinders.   As soon as the max sector on a drive has been used that drive has no further part in the parity sync.   In your case the 2TB drive will be first to stop taking part and later the 6TB drive.   The parity sync keeps going until the last sector on the parity drive (at 10TB) has been processed.