JorgeB

That's the kernel version.
 
The call traces mention XFS so check filesystem on all XFS disks, run it always without -n, then reboot and see if it's any better.

SSD is dropping offline, try different cables, probably best also to use the onboard SATA controller instead, since the LSI won't support trim.

The SQUASHFS errors usually mean a bad flash drive, you can try backup and re-formatting or just replacing it, also make sure it's using a USB 2.0 port.

Run an extended SMART test on parity, also need to check filesystem on disk4.

Correct, that could only happen if the disks were previously assigned to a pool, and then later assigned to the array without wiping them first, it can be considered a bug, the current release doesn't allow that, you probably didn't notice but both disks 1 and 3 would show the exact same stats on the GUI, since they would both link to the same pool with the same data.

Yes.
Yes.
Yes.

Sep 26 08:02:18 unraid kernel: BTRFS warning (device sdf1): devid 2 uuid 82b09bec-fe6c-4de2-ad5a-dfe099da7925 is missing Sep 26 08:02:18 unraid kernel: BTRFS error (device sdf1): failed to read chunk root Sep 26 08:02:18 unraid kernel: BTRFS error (device sdf1): open_ctree failed  
This error suggest the pool was not redundant, at least not fully, you can try the recovery options here but most likely they also won't work without the missing device.

It's logged as a disk problem, but SMART test passed, reboot to clear the errors, you can also swap cables with a different disk to rule that out and keep monitoring.

Like mentioned an actual copy is not the same as running a benchmark, I have a similar CPU in one of my servers, and get max 1.5GB/s when copying data with NVMe devices, with Unraid, TrueNAS or Windows.

for disk5 - https://docs.unraid.net/unraid-os/manual/storage-management#rebuilding-a-drive-onto-itself
 
cache - acknowledge current SMART errors and if you get more UDMA CRC errors replace the SATA cable, also same for disk5 SMART warning.

Looks more like a power/connection issue, replace cables/swap slot and try again.

Btrfs is detecting data corruption, start by running memtest.

You have the turbo write plugin installed, and the video shows turbo write enabled, it's faster at the expense of spinning up all disks for writes.

If it's a one time thing you can ignore, if it keeps happening try limiting more the RAM for VMs and/or docker containers, the problem is usually not just about not enough RAM but more about fragmented RAM, alternatively a small swap file on disk might help, you can use the swapfile plugin:
 
https://forums.unraid.net/topic/109342-plugin-swapfile-for-691/

This is normal but according to the diags the pool in online, there will be some data corruption though, you can use -v to see which files are affected, but they will fail to copy, copy anything else you can from /mnt/cache elsewhere and re-format, btw so many issues suggests a hardware problem.

 
pool: cache  state: ONLINE status: One or more devices has experienced an error resulting in data     corruption.  Applications may be affected. action: Restore the file in question if possible.  Otherwise restore the     entire pool from backup.    see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A   scan: resilvered 1.07M in 00:00:00 with 0 errors on Tue Aug 29 22:44:11 2023 config:     NAME           STATE     READ WRITE CKSUM     cache          ONLINE       0     0     0       mirror-0     ONLINE       0     0     0         nvme0n1p1  ONLINE       0     0     0         nvme1n1p1  ONLINE       0     0     0 errors: 2 data errors, use '-v' for a list  
 

Btrfs is detecting data corruption and there are several apps segfaulting, start by running memtest.

You need to export the pool first:
 
zpool export ssd_pool  

It would be my guess.

You will need to try and wipe that device with a different OS, for some reason Unraid cannot do it.

Sep 15 02:16:46 UnraidNAS kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Sep 15 02:16:46 UnraidNAS kernel: ? _raw_spin_unlock+0x14/0x29 Sep 15 02:16:46 UnraidNAS kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan] switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)).

It's logged as a disk problem and the SMART test failed, you should replace the disk.

Delete that snapshot and run a new scrub.

There's an error verifying the partition on your parity disk, 2 of your SATA ports (where parity and cache1 are connected) are in IDE mode and limited to ATA33, change them to AHCI in the bios and try again.

I'm used to seeing that in various diags, so assume it's harmless.

It's normal.