JorgeB

That to me it suggests some kernel compatibly issue with your board, I would wait for a newer release with a newer kernel and try again.

Remove the gateway from eth1 and try again.

Disks are empty, that suggests something (or someone) deleted the data, is the server directly exposed to the internet?

Might as well update.

Disk is not generating a complete SMART report, so it might be a disk issue, swap cables/slot with a different disk just to rule that out.

Try a different USB port (ideally in a different controller), also make sure it's a USB 2.0 port if available.

Disk dropped offline, this is usually a power/connection problem, if SMART is OK I would replace both cables and try again.

Rebooting will clear the log, of course if the USB messages continue it will fill up again quickly.

Assuming no PCIe bottlenecks a 9201-16i is good for around 165MB/s with 16 devices, so it will limit speeds with modern disks, usually capable of around 200MB/s to 250MB/s in the outer tracks, using two 92xx-8i controllers would have no such limit, again assuming no PCIe bottlenecks.

And no ATA errors in the syslog so far during a check?

Please post new diags.

Images type files especially, like docker image or any vdisks can grow with time if not being trimmed, for Windows vidks you can use unmap, another option is to move everything to the array, during the move check what was using the space, then move back the images with cp --sparse=always.

We don't recommend USB for array/pool devices, for multiple reasons, including performance. As to if you can move the disk inside and Unraid will accept it, it depends on the USB bridge used, worst case you can do a new config and check parity.

It really depends on the controllers, board, devices, etc.

Everything looks good so far, but the pool is not redundant, likely due to a bug in older Unraid releases when the pool was created, type in the console: btrfs balance start -mconvert=raid1 /mnt/cache Then run a scrub.

Is the 10GbE NIC eth0? It's fine if it's not eth0 and everything else connected to it supports jumbo frames.

That issue should be fixed on v6.11.1

Enable the syslog server and post that after a crash.

Pool was working correctly but one of the devices dropped offline: Oct 8 02:41:06 UnCRATE kernel: ata1.00: revalidation failed (errno=-19) Oct 8 02:41:06 UnCRATE kernel: ata1.00: disabled Oct 8 02:41:06 UnCRATE kernel: sd 1:0:0:0: rejecting I/O to offline device Oct 8 02:41:06 UnCRATE kernel: blk_update_request: I/O error, dev sdi, sector 71914232 op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 0 Oct 8 02:41:06 UnCRATE kernel: BTRFS error (device sdi1): bdev /dev/sdi1 errs: wr 1, rd 0, flush 0, corrupt 0, gen 0 Oct 8 02:41:06 UnCRATE kernel: blk_update_request: I/O error, dev sdi, sector 71914248 op 0x1:(WRITE) flags 0x8800 phys_seg 1 prio class 0 Oct 8 02:41:06 UnCRATE kernel: BTRFS error (device sdi1): bdev /dev/sdi1 errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 Oct 8 02:41:12 UnCRATE kernel: ata1: hard resetting link Check replace cables for sdi then post new diags.

I would give a 2nd chance, if you get similar issues again then best to replace it.

This is the problem, especially with existing disks, you can add them as single volumes but might lose the data there, you should use a true HBA.

You can do the parity swap procedure for both disks at the same time but like mentioned you should post the diags first.

There are issues with 3 disks, so parity cannot emulate them all, almost simultaneous errors like these are usually the result of power/connection issues, power down, check/replace cables on the problem disks and post new diags after array start.

Nothing relevant logged, could be this issue:

No, you cannot do that since there are two more invalid disk, you force enable parity2 to see if both disabled disks can still be emulated correctly, if yes you can then rebuild them. This will only work if parity is still valid: -Tools -> New Config -> Retain current configuration: All -> Apply -Check all assignments and assign any missing disk(s) if needed. -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 disks 6 and 8 -Start array (in normal mode now), ideally the emulated disks will now mount and contents look correct, if they don't post new diags -If the emulated disks mount and contents look correct stop the array -Re-assign disks 6 and 8 and start array to begin rebuilding.