JorgeB

It won't hurt. No, you can have a redundant pool, but would need another device.

First I would not recommend using an NVMe device on a disk array as writes are going to be limited by parity, you can use it as a UD device or with the new beta on its own "pool", log is being spammed with unrelated errors and I don't see where the NVMe dropped, but this can sometimes help with some: Some NVMe devices have issues with power states on Linux, try this, on the main GUI page click on flash, scroll down to "Syslinux Configuration", make sure it's set to "menu view" (on the top right) and add this to your default boot option, after "append" and before "initrd=/bzroot" nvme_core.default_ps_max_latency_us=0 Reboot and see if it makes a difference.

You need to run xfs_repair without -n or nothing will be done, if it asks for it use -L also.

Check all connections, including power.

One of your cache devices dropped offline previously: Jul 21 17:19:45 UNRAID kernel: BTRFS info (device nvme0n1p1): bdev /dev/sde1 errs: wr 508143002, rd 191759497, flush 5698788, corrupt 0, gen 0 You need to run a scrub and check that all errors are corrected, see here for more info, you'll also need to re-create the docker image.

The other way to resolve this is to rebuild one drive at a time with the new controller, so Unraid can re-create the partitions correclty.

Best bet is to backup cache data and re-format the pool.

Parity can't usually help with filesystem corruption, and it won't if it's 100% in sync, but because of the HBA problem it might not be, so you can try, stop the array, unassign disk5, start the array, if disk5 is still unmountable run xfs_repair on the emulated disk (it's also md5), if that doesn't work best bet is to ask for help on the xfs mailing list or to use a data recovery program like UFS explorer.

You assume right. WD Helium models are all CMR, also any WD 8TB or larger model is also always CMR, at least for now.

Make sure the BIOS is up to date, the option is called "power supply idle control" or similar, if you can't find it disable C-States globally. You're also overclocking the RAM, respect the max officially supported speeds for your config.

Possibly a bug, unless the enable cache setting is now also on another place, edit /boot/config/shares.cfg and change: shareCacheEnabled="no" to "yes"

Start here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173

That setting is no longer there, it's set on a share by share basis:

You should disable the mover logging so it doesn't spam the syslog.

Disk looks fine, most likely an issue with the SASLP, since they are known to drop drives without a reason, could also be a cable/connection issue.

Update UD and reboot.

Can't find them, either missed them or they are not there since there are several hours missing because of all the log spam, disk looks healthy, would recommend replacing/swapping cables to rule them out and rebuild on top.

First thing you need to do is to make your server not internet facing, now let me see if I can find the disk errors in the middle of all those login attempts.

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=480421

Try it on a different controller if possible, like the onboard SATA ports.

Please post the diagnostics: Tools -> Diagnostics

Yes if the filesystem was fixed, you can also reboot to see if there aren't any more errors.

Problem first starts with the cache filesystem, then the docker because it's on cache. Possibly there's something using the cache at that time, like the mover.

Check filesystem on disk3.

There's filesystem corruption on the cache pool, best bet is to backup any important data there and re-format the pool.