JorgeB

Better to reformat that to attempt a repair, note that checksum errors might indicate a hardware problem.

Disable UEFI boot, memtest only works under legacy BIOS/CSM.

If it doesn't show up on the BIOS it also won't show up for Unraid, might be the 3.3v issue, google "wd sata pin 3.3v", if it's not that it might be DOA.

Any device can have issues at anytime, it's not that unusual.

It's a known issue with Samsung SSDs and some AMD controllers. It's already disable by default (Setting -> Disk Settings)

Not impossible, but never heard of that, and most users including myself use this firmware.

Because of the spam the log goes from: May 3 07:08:39 Tower kernel: ata2.00: status: { DRDY } May 3 07:08:39 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED May 3 07:08:39 Tower kernel: ata2.00: cmd 60/40:88:c8:b6:5e/00:00:3d:00:00/40 tag 17 ncq dma 32768 in May 3 07:08:39 Tower kernel: res 40/00:58:c8:9c:5e/00 to May 4 04:40:14 Tower rsyslogd: [origin software="rsyslogd" swVersion="8.1908.0" x-pid="1416" x-info="https://www.rsyslog.com"] rsyslogd was HUPed May 4 05:00:01 Tower crond[1613]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null And it's missing most of the first check, not showing any corrections, it does show a lot of errors on ATA2 (disk1) so also replace cables on that disk and do the 2 consecutive checks.

It failed a SMART test, though it was a few power on hours ago, you can run another one and if it's still failing it needs to be replaced.

Not unless you're using reiserfs, which you shouldn't, assuming XFS best bet is a deleted file recovery util like UFS explorer.

Yep, you'll need to first delete existing partition and then format, since it's a new fs it won't confuse Unraid, even if still btrfs.

The unassigned disks are confusing Unraid, since they are btrfs and are clones of existing disks it thinks they are part of the pool, just disconnect (or wipe) them and the pool should mount normally.

Most kikely a hardware issue, start with memtest.

Several apps segfaulting, start by running memtest.

It's a PCIe x1 controller.

They were corrected, most likely parity wasn't valid, but if you get more errors on the next check there might be a problem.

No way to know without the diags.

Not sure I understand, you should run iperf between Unraid and your desktop, and you desktop should be using a LAN cable, pointless trying to fix low wi-fi speeds. VM speeds might be affected by other issues, so first it should be tested with a separate desktop.

This suggests a network problem, run an iperf test (single stream).

No.

It got disabled before this boot so we can see what happened, run an extended SMART test and if OK re-sync parity.

It doesn't, but try writing directly to the array to see if the speed is the same or better.

Backup any data still on that disk, format it, restore data or Move data from that disk to other array disks if there's space, format it, continue using it normally.

Parity doesn't help with filesystem corruption, it helps when a disk fails.

IMHO there's no much point in rebuilding, just formatting to create a new filesystem. Yes, but I would recommend trying one thing at a time or you'll don't know what fixed it, if it does indeed fix it.

Replace/swap both cables (power + SATA) on disk7 and try again.