JorgeB

Depends on the number and type of devices connected, this will give you a good idea of the performance of both: https://forums.unraid.net/topic/41340-satasas-controllers-tested-real-world-max-throughput-during-parity-check/

The please post new diags and the output of: btrfs fi usage -T /mnt/disk1

Do this: with the array stopped click on disk18 and change the fs from auto to xfs, then start array and post new diags.

This was disk5 in the diags posted: Sep 25 22:56:48 Cube kernel: md: import disk5: (sdh) WDC_WD30EZRX-00AZ6B0_WD-WMC070040204 size: 2930266532

Disk3 is failing to initialize, replace cables and/or try a different controller: Oct 15 15:53:41 Tower45TB kernel: ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Oct 15 15:53:41 Tower45TB kernel: ata2.00: failed to read native max address (err_mask=0x1) Oct 15 15:53:41 Tower45TB kernel: ata2.00: HPA support seems broken, skipping HPA handling Oct 15 15:53:41 Tower45TB kernel: ata2.00: READ LOG DMA EXT failed, trying PIO Oct 15 15:53:41 Tower45TB kernel: ata2.00: failed to get NCQ Send/Recv Log Emask 0x1 Oct 15 15:53:41 Tower45TB kernel: ata2.00: failed to get NCQ Non-Data Log Emask 0x1 Oct 15 15:53:41 Tower45TB kernel: ata2.00: ATA-9: WDC WD102KFBX-68M95N0, VCGAJHLM, 83.00A83, max UDMA/133 Oct 15 15:53:41 Tower45TB kernel: ata2.00: 19532873728 sectors, multi 16: LBA48 NCQ (depth 32), AA Oct 15 15:53:41 Tower45TB kernel: ata2.00: failed to get NCQ Send/Recv Log Emask 0x1 Oct 15 15:53:41 Tower45TB kernel: ata2.00: failed to get NCQ Non-Data Log Emask 0x1 Oct 15 15:53:41 Tower45TB kernel: ata2.00: configured for UDMA/133

If you haven't yet take a look here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173

Was disk18 ever formatted? According to the log there's no valid filesystem.

Looks more like a power/connection problem, try replacing the cables.

Download pool filesystem is corrupt, best bet is to backup and reformat.

If you still need help with this post current diags.

This suggests a partition problem, not a filesystem problem, please post output of: fdisk -l /dev/sdX

Look for "Power Supply Idle Control" (or similar) in the BIOS and set it to "typical current idle" (or similar).

That model shouldn't need the iommu workaround.

Is the issue only upload or also download? Did you ran iperf the other way?

Most likely, you can try it in a different controller, if issues persist replace or ignore, if there aren't any apparent issues.

If it started crashing without any changes it suggests a hardware problem, start by running memtest.

Screenshot doesn't show everything, you can enable syslog server and post that log after a crash.

Or at least disable hard links : Settings > Global Shares Settings -> Tunable (support Hard Links): no

Wasn't it one array disk and one unassigned disk? But anyway, if accessing disk1 accessed a different unassigned (or assigned) disk they were almost certainly part of the same pool, but if it's fixed now it's not possible to confirm, we'd need to see before doing this: Because doing this wiped that device.

What HBA and enclosure?

External SAS, it also works with SATA devices.

Sounds like both disks were previously part of a btrfs pool, and if you did a new config the array disk wouldn't be cleared, you'd need to wipe one of the devices (or both) before use in the array.

Please start a new thread in the general support section, don't forget to include the diagnostics (after array start).

Try disabling NFS, if you can use SMB instead.

Just a reminder that you can't interrupt the procedure after the copy and before pressing start by rebooting or powering down, or you'll need to start over the procedure from the beginning.