JorgeB

Please post the diagnostics, you can get them by typing "diagnostics" in the console.

If you're not used to the CLI you can use midnight commander (mc on the console).

btrfs errors are from the docker image, best to delete and recreate, should be unrelated to current issue, but note that the mover is very inefficient moving lots of small files, best to do it manually.

See here for some benchmarks:

You're welcome. Which one was it?

LSI firmware is very old, try again after updating to latest.

I forgot to mention, you can't do this on the mdX device, it will always return 1, even for an SSD, there shouldn't be many users with SSDs in the array, but if you want to check it you need to do it on the sdX devices.

You can also enable UEFI boot in Unraid, just rename EFI- to EFI in the flash drive.

Pausing usually means out of space, please post the diagnostics.

Memtest can't find errors with ECC RAM (unless you disable ECC in the BIOS), look at the system/IPMI event log, there should be more info there, including the affected slot.

You could do that manually but array would need to be offline during that, so probably better to just re-sync it.

Delete all the partitions from the SSD, you can do that with UD, then re-add to cache and re-format.

Flash drive is still dropping offline: ct 21 00:40:57 Tower kernel: usb 1-12: reset high-speed USB device number 2 using xhci_hcd Oct 21 00:40:57 Tower kernel: usb 1-12: device firmware changed Oct 21 00:40:57 Tower kernel: usb 1-12: USB disconnect, device number 2 Oct 21 00:40:57 Tower kernel: print_req_error: I/O error, dev sda, sector 20088 Oct 21 00:40:57 Tower kernel: Buffer I/O error on dev sda1, logical block 18040, lost async page write Oct 21 00:40:57 Tower kernel: print_req_error: I/O error, dev sda, sector 42090 Oct 21 00:40:57 Tower kernel: Buffer I/O error on dev sda1, logical block 40042, lost async page write

Most likely, disable/uninstall all plugins and boot in normal mode, if still OK then start installing them one by one.

You'll either need to rebuild both disks or re-sync parity without them, time it takes should be similar.

VMs are not my strong suit, best bet is to make a new post about that in the KVM forum.

Strange part is that the errors stat before array start, try booting in safe mode.

That doesn't matter, if another disk fails you'll still be unable to rebuild it.

You should upgrade to latest beta, newer kernel might help with the NVMe dropping issue.

Unlikely to be a device problem. Is this the first boot after adding the nvme_core line? If yes try removing it, though it never caused NVMe to go undetected before, but I guess it could.

Are those large files?

Enable speed stats on Unraid and check speeds there, but Windows speeds should be accurate, Unraid speeds can also go up and down, I can only see the speed at the moment the diags were captured. Toggle is on the top-right:

Diags show writes going to disk1 at about 30MB/s, that about right for array disk to disk transfer.

You could use: cat /sys/block/<device>/queue/rotational 0 output is an SSD, 1 is HDD

Array disk to disk transfers never were very fast with Unraid, worse since it's not possible to use turbo write, still 5MB/s is on the low side, unless it's mostly small files, if you're using Widows 10 SMB is fine since the transfer is still done locally, you can post the diags during a transfer to see if there's anything there.