JorgeB

Then it suggest it's still a network problem, despite the iperf results.

Share type won't matter, if they were grabbed during a transfer it suggests that the disks are writing in faster bursts than the speed you're seeing, and at the time the diags were saved they weren't writing, they were waiting for data. At the time the diags were saved disks was writing at 100MB/s+, suggesting that it's not a disk problem. Try this, copy that same large file to cache and then using Windows explorer (assuming you're using Windows 10) transfer from the cache share to a disk share, you need to have disk shares enable, then transfer from \\tower\cache to e.g. \\tower\disk1, transfer won't use the network, it will be done locally, see what speed you get with that.

That's normal, it's in the release notes, you need to re-assign it.

While there was a problem it's expected that every check will find errors, after the problem is fixed first one will still find some, next ones should not find any.

Which is it?

It's normal for the first check after the issue is fixed to still find errors, next ones should not find any.

Check the System Event Log in the BIOS or over IPMI if available, it might have more info on the affected DIMM.

That's obviously not normal, diagnostics grabbed after a problem might give some clues.

Macvlan call traces are usually the result of having dockers with a custom IP address, more info below. https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/

So are most SATA disks, still too hot, you should keep them under 40C, 45C tops. Power on hours can't be changed, unless there's some firmware issue they are correct.

Delete and recreate the docker image, and make it smaller, 200GB is too much.

Delete and re-create the docker image.

Do you mean new to you? Disk is very far from new, it's also running very hot. Diags are after rebooting so we can't see the error but wait for the result of the long test, though I would strongly recommend to improve cooling.

See turbo write for better write speeds, but note that having two users writing at the same time will still slow down Unraid a lot, Unraid doesn't stripe disks, so it can never perform as well as RAID soltutions, it does have other advantages though.

Please post the diagnostics: Tools -> Diagnostics

That disk appears to be failing, and xfs failed to format it correctly.

If you mean disk5, yes it appears to be failing, but there's no recent SMART test, run an extended test.

One only.

It's not being detected, try connecting it to a different controller/port and/or using new cables.

du isn't reliable with btrfs, space used on the GUI is correct, note that if you have for example a vdisk on cache the file can bloat way beyond the reported used space, this can help with that.

According to the diags there's 0 array activity.

This now suggests a device limit, after the RAM cache is exhausted, enable turbo write, write directly to one of the disks and grab the diags after it slows down, then post them here.

Click on that disk (with the array stopped) and change fs to xfs.

Disk2 only shows filesystem corruption, not ATA errors, that should be fixable by checking filesystem: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui

Yes, but still a clear issue, I would start with trying to fix that, try a different NIC, cable, switch, source PC, etc