JorgeB

Yes. Yes, if there is available continuous space on the filesystem.

Cables like that should be very difficult to find, you could use something like this: then Though total length from HBA to drives should be max 1 meter, assuming SATA drives without a SAS expander on the backplane.

1. If you have good backups, raid0 is fine. 2. IIRC you can now reflink with NODATACOW, you do still lose checksums, I use COW for all my VMs, and they perform fine, though would not be recommended if they were on a spinner, I think it's fine for SSDs.

Pretty sure LSI HBAs won't work with SATA port multipliers, even if they did it wouldn't be recommended, they do work with a SAS expander, internal or external, and those can use SATA devices, though it would mean a new enclosure.

Assuming both disk are of the same size and split level setting allowing it will start writing to disk2 once disk1 gets over 75% used. https://wiki.unraid.net/Un-Official_UnRAID_Manual#High_Water

Disk looks healthy, replace/swap cables to rule them out and rebuild on top, or use a new disk if you want to play it safer.

It's safe to start but cache likely won't mount and will need to be re-formatted.

Look for a BIOS update, this looks like a hardware problem/compatibility issue.

You can try this to see if it catches anything, booting in safe mode with all dockers/VMs off is also worth trying.

That suggests the USB link is the bottleneck, like it's using USB 2.0 instead of 3.0, 35MB/s is about write for USB 2.0, though correct speed is detected during initialization, at least for the USB controller, can't see the actual link speed with the USB devices, try different cable/port to see if it makes any difference. Also, CPU is overheating and throttling down: Feb 24 20:57:42 BlackBox kernel: CPU7: Core temperature above threshold, cpu clock throttled (total events = 27) Feb 24 20:57:42 BlackBox kernel: CPU3: Core temperature above threshold, cpu clock throttled (total events = 27) Feb 24 20:57:42 BlackBox kernel: CPU6: Package temperature above threshold, cpu clock throttled (total events = 28) Feb 24 20:57:42 BlackBox kernel: CPU4: Package temperature above threshold, cpu clock throttled (total events = 28) Feb 24 20:57:42 BlackBox kernel: CPU0: Package temperature above threshold, cpu clock throttled (total events = 28) Feb 24 20:57:42 BlackBox kernel: CPU5: Package temperature above threshold, cpu clock throttled (total events = 28) Feb 24 20:57:42 BlackBox kernel: CPU2: Package temperature above threshold, cpu clock throttled (total events = 28) Feb 24 20:57:42 BlackBox kernel: CPU1: Package temperature above threshold, cpu clock throttled (total events = 28) Feb 24 20:57:42 BlackBox kernel: CPU3: Package temperature above threshold, cpu clock throttled (total events = 28) Feb 24 20:57:42 BlackBox kernel: CPU7: Package temperature above threshold, cpu clock throttled (total events = 28)

Unfortunately that's very likely, whatever happened it happened before the first rebuild you attempted, the filesystem was already corrupt at that time, but without prior logs can't guess why, most likely parity wasn't 100% valid. You could try a file recovery utility, like UFS explorer, but difficult to guess how successful it would be, they do have a trial if you want to give it a shot.

Feb 23 17:14:00 Pangu kernel: sd 9:0:0:0: Power-on or device reset occurred ... Feb 23 17:15:37 Pangu kernel: sd 9:0:3:0: Power-on or device reset occurred These errors suggest a connection/power issue, and since you had already replaced/swapped the SATA cables power was the more likely culprit.

Macvlan call traces are usually related to dockers with a custom IP address:

The problem isn't the WD disks, it's the Marvell controller they are connected to, this can sometimes help. P.S. Your flash drive is showing some read errors: Feb 24 14:02:33 Tower kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Feb 24 14:02:33 Tower kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x3 [current] Feb 24 14:02:33 Tower kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0 Feb 24 14:02:33 Tower kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 2b 82 00 00 91 00 Feb 24 14:02:33 Tower kernel: print_req_error: critical medium error, dev sda, sector 11138 Feb 24 14:02:33 Tower kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Feb 24 14:02:33 Tower kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x3 [current] Feb 24 14:02:33 Tower kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0 Feb 24 14:02:33 Tower kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 2b 82 00 00 01 00 Feb 24 14:02:33 Tower kernel: print_req_error: critical medium error, dev sda, sector 11138 Feb 24 14:02:33 Tower kernel: FAT-fs (sda1): FAT read failed (blocknr 11136) Try chkdsk first, but it might be failing.

They don't, at least not AFAIK, they should use the general settings, the ones from settings -> disk settings

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=781601

Locking since OP re-posted on the correct thread.

Please use the plugin's support thread:

Try enabling disk shares (settings -> global share settings) and then copy directly to \\tower\cache, see if that makes any difference.

cd /boot/config

If you mean after xfs_repair is done just start the array normally, disk should mount now.

Looking at the stats both devices are having issues, likely dropping offline, so once it comes back online btfs brings the filesystem up to date, and hence the "read error corrected" info, see here for more info on how to better monitor the pool. Since no cables are involved it's not likely a connection issue, look for a bios update, also 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" nvme_core.default_ps_max_latency_us=0 Reboot and see if it makes a difference.

Sorry, taking a second look I see that board doesn't have a Marvell controller onboard, many of those Asrock rack models have and I assumed that was one of them, so it's an addon controller you're using, you could replace that with a different one, an 8 port LSI HBA or a JMB585 if 4/5 ports are enough. The 6 onboard SATA ports are from the Intel chipset and perfectly safe to use.

The errors are for the life of the filesystem, see the link above how to reset them.

Lucky, but it's usually just a question of time running into issues with that controller.