JorgeB

You still need to convert to raid1, with 6.8.3 there's a GUI option on the cache page.

OK, unlike the previous diags we can now see that it's a problem with the SATA controller: Mar 24 13:50:07 Obsidian kernel: ahci 0000:45:00.0: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x000007fffff80000 flags=0x0020] Mar 24 13:50:07 Obsidian kernel: ahci 0000:45:00.0: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x000007fffff80180 flags=0x0020] Mar 24 13:50:07 Obsidian kernel: ahci 0000:45:00.0: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x000007fffff80280 flags=0x0020] Unfortunately this issue is rather common with Ryzen boards, I've seen it many times before on the forum, disabling IOMMU might help, but likely not practical for you, BIOS update or newer kernel might also help, e.g. you can try v6.9-beta1, if that still doesn't help only a different board or adding a HBA.

OK, then I would keep the disk for now and give it a second chance, but any more errors in the near future replace.

With SMB.

Are the read errors before or after the SMART test? Extended SMART test passed so disk should be fine for now, but if the errors are after best to replace it.

Do you get the same speed copying to the array and cache? Also try copying directly to a disk share, enable disk shares (Settings - Global Share Settings) the copy to \\tower\disk1 and/or \\tower\cache

Disk9 is failing, since there's no parity best bet is using ddrescue, then fix filesystem if still needed.

Many users have Linux VMs, including myself, if you want help you'll need to post more details of your problem, starting with the distribution you are trying to install and the problem you have, and it should be posted on the KVM forum.

Little less bandwidth but it works, as long as it's supported.

You can click on your avatar then "find content"

You previous post wasn't deleted, it was split to the correct forum:

We'd need the the diags to see the problem, but most likely filesystem corruption.

Please use the appropriate docker support thread:

Seems the user share overhead is higher than normal, though speeds still seam on the low side even when using disk shares, so likely something else at play here.

Unraid will create a network.cfg if a NIC is detected, and like mentioned it's not being detected, like if the NIC doesn't exist, this is a hardware issue, try a CMOS reset on the board, if still nothing you'll need an add-on NIC.

Yes, that looks much better, try in the other direction now, use -R on the client.

BTW, you can also test to \\tower\cache, this should also be much faster than before, because it's bypassing Unraid share system, but while it's normal to see a difference in performance here it's not normal to see such low speeds writing to the user shares.

The initial high speed is while it's being cache to RAM, limited by network/source device, then it's limited by the actual device speed, 55-80MB/s is still slow for those disks with turbo write enable, they should be handle around 200MB/s when empty, if you can connect the disks to the onboard SATA ports and repeat the test.

Nothing jumps out, try enabling disk shares (Settings -> Global Share Settings), then transfer directly to a disk, e.g. \\tower\disk1, see if there's any difference.

Try with different NIC/cable/switch/another source computer, etc

Start a copy to the array and grab diags during it.

That's very slow, you're only getting 1Mbit/s

First use only -v (lower case), but if it asks for it add -L

You still need to check the filesystem on the emulated disk.

Are you using perf3 on Ubuntu? Older iperf1 or 2 not compatible with 3.