JorgeB

Unrelated but there are issues with both disks connected on the Marvell controller, Marvell controllers are not recommended for Unraid for a long time. LSI HBA doesn't appear to be very happy: Sep 18 18:58:54 SERVERUS kernel: mpt2sas_cm0: fault_state(0x2622)! Sep 18 18:58:54 SERVERUS kernel: mpt2sas_cm0: sending diag reset !! Sep 18 18:58:55 SERVERUS kernel: mpt2sas_cm0: diag reset: SUCCESS Upgrade to latest firmware sine it's running one with known issues, also make sure it's well seated and sufficiently cooled. Something is interfering with mount points: Sep 20 09:54:32 SERVERUS emhttpd: error: get_filesystem_status, 6481: Operation not supported (95): getxattr: /mnt/user/vmicons Rebooting in safe mode should get the shares back, if yes you'll need to see what plugin or setting is causing the problem.

No, and according to Crucial is normal so don't expect one.

That's normal with encryption, first time doesn't know it needs the key. Speed seems OK, if any issues grab and post new diags.

Yes, use only the same disks, though data disk order is not important with single parity. Which SATA port doesn't matter.

It's a hardware problem, it can be the device or the board, assuming it's not on a PCIe adapter, it can also be some firmware/compatibility problem, but once it drops Unraid can't do anything about it.

Correct, if SMART test is successful assign all disks as before, check "parity is already valid" and start the array, if all disks mount correctly run a correcting parity check, if not post new diags.

Assuming all disks are available and disk3 is indeed OK, and passes the extended SMART test, after the new config you just need to assign all disks as before and start the array to begin parity sync, you can even trust parity and then run a correcting check. If I misunderstood and there is one missing disk then this isn't the way to go, in that case the invalid slot command would be the way to go, but you need a new disk of the same size to replace the missing one.

NVMe device dropped offline: Sep 18 23:51:01 Mozart kernel: nvme nvme0: I/O 136 QID 2 timeout, aborting Sep 18 23:51:01 Mozart kernel: nvme nvme0: I/O 137 QID 2 timeout, aborting Sep 18 23:51:01 Mozart kernel: nvme nvme0: I/O 138 QID 2 timeout, aborting Sep 18 23:51:01 Mozart kernel: nvme nvme0: I/O 139 QID 2 timeout, aborting Sep 18 23:51:31 Mozart kernel: nvme nvme0: I/O 136 QID 2 timeout, reset controller Sep 18 23:52:01 Mozart kernel: nvme nvme0: I/O 0 QID 0 timeout, reset controller Sep 18 23:53:33 Mozart kernel: nvme nvme0: Device not ready; aborting reset Sep 18 23:53:33 Mozart kernel: print_req_error: I/O error, dev nvme0n1, sector 14888064 Sep 18 23:53:33 Mozart kernel: print_req_error: I/O error, dev nvme0n1, sector 14888320 Sep 18 23:53:33 Mozart kernel: print_req_error: I/O error, dev nvme0n1, sector 14895648 Sep 18 23:53:33 Mozart kernel: print_req_error: I/O error, dev nvme0n1, sector 14895904 Sep 18 23:53:33 Mozart kernel: nvme nvme0: Abort status: 0x7

Auto check after unclean shutdown is non correct. Aborting a check won't make the GUI show unclean shutdown, not sure what you mean, next time grab diags, they might show something.

I would recommend using the invalid slot command if you want to use a new disk, rebuilding on top of the older one might be a mistake, instead run an extended test on it, and if all OK re-sync parity instead.

Can't replace an existing array disk with a smaller one. SMART looks OK for disk3, though what kind of disk is: Device Model: OOS8000G Serial Number: 00000000 If you really want to replace it you can use the invalid slot command but need another 8TB (or larger) disk.

Not directly but would think so since this issue is very easy to reproduce, unlike the SQL corruption problem.

Not sure if it bypasses any go file edits, since you have a custom one might be worth commenting them out.

You can go to your flashdrive \config\plugins folder and rename the extension on all plugins (or all but on one) from .plg to for example .pl, then reboot, any renamed plugin won't install on boot, then keep renaming then back one by one to .plg (and reboot to install).

There is an rc4, but it doesn't fix the slow array problem.

Didn't fix it for me.

Any LSI with a SAS2008/2308/3008/3408 chipset in IT mode, e.g., 9201-8i, 9211-8i, 9207-8i, 9300-8i, 9400-8i, etc and clones, like the Dell H200/H310 and IBM M1015, these latter ones need to be crossflashed.

x4 it's fine for an LSI, less bandwidth but enough for most HDDs.

That's Asmedia and works fine

Run a memtest and after re-format pool to start over, if there aren't RAM issues and problems persist post new diags at first sign.

Nothing special, just like any other cache replacement, if there's no data there just insert the new devices, if there is there are instructions in the FAQ to replace.

Yes, sorry, I was thinking about M.2 SATA

You did. Supports 6Gbps, 3Gbps SATA based M.2 NGFF 80mm, 60mm, 42mm, 30mm SSD

Don't think so, only explanation that makes sense is there wasn't any data on the sectors Unraid couldn't read, I would expect it would write zeros to those on the rebuilt disk, and if there were no sync errors now it means those sectors were already all zeros before, i.e., no data.