itimpi

You probably also need to run a file system check on disk1 by clicking on it on the Main tab and selecting that option. It has not mounted so presumably has file system level corruption, but you have not provided the system diagnostics so it is not possible to be sure of that.

There is no standard way to do this - the standard recovery always assumes that you are using a disk that is not currently in the array. In your case you are going to have to do something like: copy all the data from the emulated disk2 onto other disks (presumably disk3 in this case). use Tools->New Config to reset the array assign the disks you are keeping as you want them. Any existing data on the disks will be left intact. start the array to commit the changes and to start building parity (as the changes above invalidates parity) based on the current disk set.

I have no idea whether there are any issues passing through the GPU you mention, but I am assuming that you will be able to as otherwise any VM is using an emulated GPU so the sharing point is irrelevant. Only one VM can use a particular hardware resource at a time (although they can share it if they are not running at the same time). If you want both VMs running simultaneously then one would have to be the primary and given the GPU, and the other use an emulated GPU and accessed using either VNC or something like RDP (or an equivalent).

Those look like the right steps. If you are sure that is exactly what you did you should try clicking on the drive in the Main tab and run the option to check the file system. A common mistake (despite the warnings) is to add an additional step of formatting the drive not realizing this is not part of the recovery procedure and will update parity to indicate there is an empty file system on the drive. There is no separate restore step - data should be restored as part of the rebuild. In fact it will be set to what was shown on the emulated drive before the rebuild was done! The rebuild process is not aware of data and is merely working at the physical sector level restoring them to what it thinks should be their current content regardless of whether it is part of a file or not. Copying the data back is probably the easiest way forward if the file system check did not result in your data being shown again.

That almost certainly means that you have connected it to an old disk controller that cannot support drives larger than 2.2TB (effectively 2TB)..

The syslog in the diagnostics shows that you have a corrupt BTRFS file system, so that probably explains your symptoms.

If you click on the folder icon at the end of a line on the shares tab then you will be shown where folders and/or files are located.

Once a drive gets disabled it will stay disabled until you rebuild the disk.

What are the share settings for the files you want to go to that disk? Note that Split Level over-rides Allocation Method on a share if there is any contention between the two for selecting a target drive for files.

Exactly which release were you running? Since you only have a single disk I assume that means that appdata is on an array drive?

They are stored inside the libvirt.img file that is mounted at /etc/libvirt. When mounted the full path to the where they are stored is /etc/libvirt/qemu

Making a VM of "unmounted" disks would be a little silly, or not? Why have unmounted discs? The statement was not about unmounted disks but about disks that are not part of the main array and are managed by the Unassigned Devices plugin! That avoids the overheads associated with writing to the array so gives much better performance.

Yes. It goes in the same location as the ‘go’ file. I am not sure why Limetech do not provide a dummy file as part of the standard release.

Use the 'go' file for commands you want run as part of the Unraid boot process and a 'stop' file for commands to be run when the system is shutting down. The User Scripts plugin is for scripts to be used during normal Unraid operation.

Is the cache drive a SSD? If so do you have the CA Trim plugin installed to do periodic Trim operations on it? Is the drive attached to a motherboard port or one on a HBA?

The OP error was related to waking from sleep - is yours? Also is the system working OK other than logging these errors?

Since this is occurring on multiple drives I would not think it is a SATA cabling problem but it might be on the power side.

Just checking - you do realise that Trim is not supported on SSDs that are in the main array, so their performance can degrade over time as they run out of free cells.

You can only have folders under /mnt/user, and every folder that you have at that level will be treated as a User Share regardless of how they got created. The folder will exist on at least one of your drives. Did you mean to map ‘/media’ to ‘/mnt/user’ or should it have been something like ‘/mnt/user/media’? BTW: You have an incorrect mapping for the ‘cache’ mount point as you have it set to ‘/mnt’ instead of ‘/mnt/cache’. This could result in you copying stuff to RAM which could lead to all sorts of problems.

I could not see a 8TB data disk in the diagnostics you posted! Which is the 8TB drive that has failed?

It sounds as if you have not set a Minimum Free Space value for the cache under Settings->Global Share settings? When the free space on the cache falls below that value then Unraid will start by-passing the cache for new files for shares set to use the cache.

I am only seeing rc3 as well when checking for updates, but Tom mentioned in another thread that rc3 did not fix the issue but rc4 might.

That is where the Dolphin/Krusader dockerr can be used. As I have mentioned earlier in this thread the browser based file managers that give that type of presenation do not seem to be capable of achieving acceptable performance (I have experimented with integrating a couple that are freely available into Unraid)

Is these any chance this change will also fix the slow reads from array when writes happen? If so do you want that to be tested for as well?

Any value other than 0 is a problem! Sometimes it is just the RAM needs reseating so it is worth checking that.