JorgeB

It's not just the RPMs, the less different sizes you have in the array the faster it will be for a check/rebuild.

It's showing some issues, but since the SMART test passed it's OK for now.

Yes, if the procedure is interrupted it needs to start over from the beginning.

A reboot doesn't usually help.

Cache device dropped offline: Feb 1 02:19:26 untheran kernel: nvme nvme0: I/O 98 QID 4 timeout, aborting Feb 1 02:19:26 untheran kernel: nvme nvme0: I/O 99 QID 4 timeout, aborting Feb 1 02:19:30 untheran kernel: nvme nvme0: I/O 192 QID 5 timeout, aborting Feb 1 02:19:30 untheran kernel: nvme nvme0: I/O 193 QID 5 timeout, aborting Feb 1 02:19:30 untheran kernel: nvme nvme0: I/O 194 QID 5 timeout, aborting Feb 1 02:19:56 untheran kernel: nvme nvme0: I/O 14 QID 0 timeout, reset controller Feb 1 02:19:56 untheran kernel: nvme nvme0: I/O 98 QID 4 timeout, reset controller Feb 1 02:22:59 untheran kernel: nvme nvme0: Device not ready; aborting reset, CSTS=0x1 Feb 1 02:22:59 untheran kernel: nvme nvme0: Abort status: 0x371 ### [PREVIOUS LINE REPEATED 4 TIMES] ### Feb 1 02:25:00 untheran kernel: nvme nvme0: Device not ready; aborting reset, CSTS=0x1 Feb 1 02:25:00 untheran kernel: nvme nvme0: Removing after probe failure status: -19 Feb 1 02:27:00 untheran kernel: nvme nvme0: Device not ready; aborting reset, CSTS=0x1 Try power cycling the serve to see if it comes back.

Since this is about the plugin if there are more issues please use the existing plugin support thread.

SMART is failing be because it's past its predicted life: Percentage Used: 101% Doesn't mean the device is failing, I have an NVMe currently at 119% and still going strong.

Looks more like a controller problem, you're using a SASLP/SAS2LP and those have been known to drop disks without a reason, though that disk is quite old and showing some issues, still recommend replacing it with an LSI HBA.

If it doesn't show up it's a hardware issue, try a different slot to test, even if you need to remove another card.

Disk looks mostly OK, assuming the emulated disk is mounting correctly rebuild on top, still recommend replacing/swapping cables to rule them out if it happens again to the same disk.

Yep, after re-creating just restore the backup config folder.

There isn't, looks more like a cable/connection problem.

Then try virtio

Diags are after rebooting so we can't see what happened, but disk2 appears to be having issues, you should run an extended SMART test, if OK do a new config with it and old disk1 (assuming still available) and re-sync parity, if not OK do a new config without disk2 (or suing a new disk), since it has no data.

Disk dropped offline so there's no SMART, check/replace cables and post new diags.

This means data corruption, usually the result of bad RAM (or with Ryzen just overclocked RAM), note that xfs won't catch this, but it still might be happening.

No issues logged, could be a hardware problem, one thing you can try it to boot the server in safe mode with all docker/VMs disable, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one.

If the same disk keeps failing and ruled out cables it's likely a disk problem, you can also try using it with a different controller if not done yet.

Backup then redo old flash.

Likely one of these: Appdatada is using a lot of disks, including dis5, and split level is set to 2 Share name that starts and ends with a T is also using disk5 and split level is set to 3.

That's it, or tail the syslog.

After array start please.

Are you using virtio-net or virtio for the VM NIC? Virtio can be faster in some cases, but can also spam the log with unexpected GSO errors.