JorgeB

That's not about data, it's about unallocated space, the higher the utilization the better for that.

There are still ATA errors with multiple disks on the last diags: Aug 7 19:26:59 Tower kernel: ata2: link is slow to respond, please be patient (ready=0) Aug 7 19:27:03 Tower kernel: ata2: COMRESET failed (errno=-16) Aug 7 19:27:08 Tower kernel: ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Aug 7 19:27:08 Tower kernel: ata2.00: configured for UDMA/133 Aug 7 19:27:08 Tower kernel: mdcmd (36): set md_write_method 1 Aug 7 19:27:08 Tower kernel: Aug 7 19:27:12 Tower kernel: ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Aug 7 19:27:12 Tower kernel: ata6.00: configured for UDMA/133 Aug 7 19:27:13 Tower kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Aug 7 19:27:13 Tower kernel: ata7.00: configured for UDMA/133 Aug 7 19:27:52 Tower kernel: ata6: link is slow to respond, please be patient (ready=0) Aug 7 19:27:55 Tower kernel: ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Aug 7 19:27:55 Tower kernel: ata6.00: configured for UDMA/133 Ideally you fix those before running xfs_repair, if replacing the SATA cables didn't help it could be a power problem, PSU or power cables.

Try adding all those drives to a cache pool to see if they work there, they don't on the array.

Parity swap is known to sometimes, unclear yet why this happens only in some cases, no correctly zero out the extra parity capacity, so the first check will correct that.

There were read errors on disk2 during disk4 rebuild: Aug 7 13:25:18 TaFlix-UNRAID kernel: md: disk2 read error, sector=86476512 Aug 7 13:25:18 TaFlix-UNRAID kernel: md: recovery thread: multiple disk errors, sector=86476336 So some corruption is expected, you can check filesystem but if you have the old disk you should them compare the data.

Switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)). What said that? Cache is about 50% used at the moment. Look at the syslog after a scrub and delete/restore the corrupt files, also a good idea to run memtest.

Single transfer will only use one NIC, did you try simultaneous transfers?

There's nothing in the log, was it after the crash?

User shares can be very slow with many small files, if it's an option make those shares use a single disk then use a disk share instead of a user share.

Problems with the flash drive, try a different USB port, and make sure it's USB 2.0, not 3.0

Please post the diagnostics.

Enable the syslog server and post that after a crash.

With turbo write enable those disks should be able to sustain 100MB/s+ writes.

Array must be started to see all the mounts.

If you didn't reboot yet post the diagnostics, if you did grab them next time it happens.

SMART looks healthy and the extended test passed so the disk is good.

Check filesystem on disk2, before that check/replace cables, there are ATA errors on that disk suggesting a power/connection problem.

That suggests a hardware problem.

If you updated using the GUI you can to Tools -> Update OS and look for the "restore" option, it will show the previous Unraid release installed, I'm just mentioning that because there's a lot of data corruption and you're using a Microserver Gen8 with VT-d enabled, and those are known to be affected by Linux kernel bug that affects all Unraid v6.10 releases except v6.10.3, causing data corruption.

Array disk to array disk will never be fast because of parity, I was referring to reads and writes from the array to another computer.

Still ATA errors with disk9, try swapping cables with a different disk, one that is connected to the onboard SATA. re: fs corruption, those should all be fixed, recommend running xfs_repair (without -n) on all array disks.

Read speed should be the maximum disk read speed at that point, note that disks are much faster in the outer sectors compared to the inner ones. Write speeds can be much faster, assuming no controller bottlenecks, if you use turbo write, at the expanse of all disks spinning up for writes.

Please use the existing plugin support thread: