JorgeB

Unraid only disables as many disks as there are parity devices.

There's more info below, you can always do a clean install and copy just the needed files from the old one: https://wiki.unraid.net/Upgrading_to_UnRAID_v6

Looks more like a connection/power issue, replace/swap cables to rule them out and you can rebuild on top, just make sure the emulated disk is mounting and contents look correct before doing it.

Disk looks clean, most likely not a disk problem, diags could give more clues.

You can do that, but if you don't find the problem should then still run it in the server as is.

Ideally 24H, but if there's a considerable problem it should be found quickly.

Another NIC, switch, and yes if those don't help a different PC as Unraid, you just need to boot a PC with the Unraid flash drive and have an available disk for testing.

There's likely some hardware issue causing the data corruption, could even be unrelated to the server, like a network problem, but since I don't see any errors on the log you'd need to try various different things, like different source PC, NIC, switch, cables, etc, you can even boot another PC with the Unraid flash and test until you find the problem.

Once a disk is disabled it must be rebuilt.

Cache=prefer moves data from array to cache, you want cache=yes, see the GUI help for more details.

Cache is completely full, free up some space then re-start docker service.

Good to see you back! And hope you're feeling better.

Don't see any errors logged, problem could be the source computer, or some issue with the network.

If it keeps getting corrupt start by running memtest.

Diags are with the array stopped so can't see the problem, but if you can't start it with the cache device assigned you'll likely need to re-format it, there are some recovery options here if needed.

Long test completed wihout error, disk should be OK, at least for now.

You have the GPU bound to vfio-pci, when you add the NVMe device the devices change and you're now binding the NIC, hence why it's not available to Unraid.

870 QVO is QLC, so very slow writes after the small SLC cache is used, you'd likely get much better results with 4 EVO drives.

SMART test passed so disk is OK for now, but you want to keep an eye on these attributes: Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 1 Raw_Read_Error_Rate POSR-K 200 200 051 - 354 200 Multi_Zone_Error_Rate ---R-- 200 200 000 - 66 If they keep climbing there will likely be more errors soon.

Something is using that space, btrfs usage agrees with the GUI, if you're not sure what is a way to find out is to move the files to the array one file or folder at a time.

Diags saved on the flash drive would confirm but there have been a couple of reports where it looks like the shutdown time-out is not being honored, i.e., Unraid forces the shutdown after a couple of seconds even if the set time is much higher, changing the setting (Settings -> Disk Settings) to re-apply it fixes the issue.

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.