JorgeB

Mirror is for redundancy, it won't help with filesystem corruption which is the problem here, there are some recovery options here, see if you can backup anything important then re-format the pool and restore the data.

If you're using SATA disks with interposeres remove them and they will be seen as regular SATA devices, assuming a true HBA is being used.

See here:
 
 

Old disk4 does show some recent issues, other ones look fine, I would suggest doing this, keep old disk4 intact for now and reconnect the new one, then:
 
-Tools -> New Config -> Retain current configuration: All -> Apply
-Check all assignments and assign any missing disk(s) if needed, including the new disk4, replacement disk should be same size or larger than the old one
-IMPORTANT - Check both "parity is already valid" and "maintenance mode" and start the array (note that the GUI will still show that data on parity disk(s) will be overwritten, this is normal as it doesn't account for the checkbox, but it won't be as long as it's checked)
-Stop array
-Unassign disk4
-Start array (in normal mode now), ideally the emulated disk will now mount and contents look correct, if it doesn't you should run a filesystem check on the emulated disk
-If the emulated disk mounts and contents look correct stop the array
-Re-assign disk4 and start array to begin.
 

Because wsdd contains sdd, same as the drive it's filtering.

Main page, click on circle on the left side of the device, the one that changes colors depending on the drive status.
 
4H is not enough for an extend test on an 8TB drive.

Cache2 is showing some SMART issues but should be fine for now, you can run an extended SMART test to confirm, main problem is that the pool is completely full, you need to move/delete some data from there, avoid completely filling up any COW filesystem, like btrfs or zfs.

See below:
 
 

Partition isn't corrupt, so something changed the disk MBR, usually the easiest way to recover is rebuild that disk on top, Unraid will recreate the partition with the correct MBR, you can test by unassigning the disk and starting the array, Unraid will emulate the missing disk and it should mount immediately, assuming parity is in sync, if it mounts and contents look correct just rebuild on top.

Feb 17 23:35:45 Rawpower kernel: BTRFS: device fsid f3246c47-c90d-4662-aef8-0197be2da3f7 devid 6 transid 162676 /dev/nvme0n1p1 scanned by udevd (7431) Feb 17 23:35:45 Rawpower kernel: BTRFS: device fsid f3246c47-c90d-4662-aef8-0197be2da3f7 devid 7 transid 142467 /dev/nvme1n1p1 scanned by udevd (7431)  
Transid is way off for one of the devices, they should be the same for all members of the same pool, besides that the superblock also appears to be damaged:
 
Feb 17 23:37:21 Rawpower kernel: BTRFS error (device nvme0n1p1): super_num_devices 1 mismatch with num_devices 1 found here  
There are some recovery options here you can try but not sure they will work with this kind of damage:
https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=543490
 
 

Reboot.

Check that the default filesystem (settings -> disk settings) is not set to an encrypted one.

Yes.

There's a problem with the cache fileystem, and since data corruption was being detected suggest running memtest before re-formatting it.

It is, see here for a recent discussion about that.

Both pools are currently the same filesystem, using both devices, this means the device wasn't correctly removed from the pool before assign it to the new pool, to fix this you can try this:
 
Stop the array, disable docker/VMs services, unassign the devices from both pools, start array, stop array, assign both devices to the same pool (there can't be a "all data on this device will be deleted" red warning for any pool device) , start array, stop array, unassign one the pool devices, start array so it can be removed from the pool, stop array, you can now assign the removed device to a new pool, start array, format new pool, all should be good now, if it isn't post new diags, you can also re-enable docker/VMs services.

Uninstall de corefeq plugin.

Not sure about gen8, but gen7 came with write cache disable in the BIOS, this will also seriously hurt write performance, check yours.

This is usually hardware related, you can try this to suppress the error.

I forgot that reiser is limited to 16TiB max size, so you'll need to go back to the old disk, convert to xfs, then you can upgrade again.

The NTFS errors from from a UD device, if it's no longer connected reboot to clear them, the CPU utilization is because of this:
 
 
 

For the disk issue see here, NVMe issue is unrelated, it dropped offline:
 
Jan 31 17:46:20 Unraid kernel: nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10 Jan 31 17:46:20 Unraid kernel: nvme 0000:06:00.0: enabling device (0000 -> 0002) Jan 31 17:46:20 Unraid kernel: nvme nvme0: Removing after probe failure status: -19  
Look for a BIOS update, this can also help sometimes:
 
Some NVMe devices have issues with power states on Linux, try this, on the main GUI page click on flash, scroll down to "Syslinux Configuration", make sure it's set to "menu view" (on the top right) and add this to your default boot option, after "append initrd=/bzroot"
nvme_core.default_ps_max_latency_us=0
e.g.:
append initrd=/bzroot nvme_core.default_ps_max_latency_us=0

Reboot and see if it makes a difference.

This is usually hardware related, it can usually be suppressed with this:
 
https://forums.unraid.net/topic/111161-pcie-errors/?do=findComment&comment=1013378
 

If the share folder exists on other disks (even if it's empty) their space will be included, if you run the mover and everything is moved to cache it will stop being used.

You need to do a new config without disk1 and re-sync parity, note that any data there will be gone, though it's unmountable anyway.