JorgeB

Do you mean the NVMe device drops offline? That would be a different issue.

The is from mcelog, not Unraid, you can ignore, fixed for v6.11.

You have 30 days from the activation day, then it can be extended twice for 15 days each time.

Post new diags after checking the cables to see if there are still issues. A good quality single rail 550/600W PSU is enough for that, Corsair and Seasonic for example are usually well regarded, though avoid the cheapest models, go for a gold model.

Everything looks good so far.

This is usually a flash drive problem.

Reformat the flash drive, make sure it's using a USB 2.0 port, and if you get more issues replace it.

Don't think so, especially for once a week. It is.

Run again without -n or nothing will be done, if it asks for it use -L.

Check filesystem on disk5.

It should discard and free any unused space when you run trim in the VM OS.

Everything looks good in the beginning, then there's nothing else due to log spam: Aug 7 14:27:17 Ironhide kernel: vfio-pci 0000:0c:00.0: BAR 1: can't reserve [mem 0xb0000000-0xbfffffff 64bit pref] ### [PREVIOUS LINE REPEATED 1082469 TIMES] ###

There's something reading from disk5, for better parity array performance you want to do one thing at a time.

It's not logged as a disk problem, and SMART looks good, most likely power/connection issue.

Possibly, using wipefs to delete just that info, but it's something I've never tried, so cannot help with.

That is just the syslog, and it's being heavily spammed, reboot and post the complete diags after array start.

This suggest the drive was previously used with Linux RAID and not properly wiped before using it with Unraid, it should still mount with Unraid, in the array or pool.

@ilarionsplit you post here, as mentioned there FAQ thread is not for questions. It works with btrfs or xfs, which filesystem are you using?

If you only get 10MB/s with turbo writes please post the diagnostics.

Power down, run chkdsk on the flash drive (or re-format) and boot again, if you see flash drive errors again replace it.

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.