JorgeB

Yes, that will do to have one array device.

Also please post new diags is a parity check begins after booting, that will confirm if it's because an unclean shutdown. You're right of course, my bad, only took a quick look at the syslog and assumed it was cache. Depends how the data was recovered, if the vdisk was copied normally from the device, even if using one of recovery mount options it will be OK since any corruption would be detected by btrfs, if it was recovered with btrfs restore it might be corrupt since that option is a last resort and it doesn't verify checksums.

It won't hurt to try.

In the syslog you can see which drive corresponds to the ATA#

Looks like you have the file integrity plugin installed.

Some observations: -CRC errors are a connection problem, usually the SATA cable, no need to replace the disk, replace the cable. -Parity check will run after an unclean shutdown, most likely what's causing them -cache filesystem is corrupt, you need to re-format cache, note that you're overclocking the RAM and that's a known issue with AMD, even can in same case cause data corruption, see here for more info.

You need to format the disk in Unraid before use, next to array start/stop buttons.

Yes, it's a known btrfs bug, fixed on kernel 5.7.11

No. Don't understand the question, cache has nothing to do with array parity, but raid0 should be faster, though if using gigabit network might be the bottleneck even with a single device.

The add-on SATA controller uses a SATA port multiplier and those are not recommended, though doubt it's the reason for the current issues, but if you can test without it do it.

I don't know that model, complete diags would give more info.

That suggest an incompatibility problem with the board, not much you can probably do, try enabling/disabling opt ROM boot support (or similar option) in the BIOS, also try booting UEFI if booting CSM, or vice-versa, other than try a different model, board or NIC.

That's fine for 3rd gen with a full load, look for a bios update, unfortunately other than that don't have many suggestions, a future Unraid release with a newer kernel might also help.

Ryzen and Linux not the best choice, though it does work OK for some, there are NMIs logged, but no idea what is causing them, make sure RAM is not over the to max officially supported speed for your config, can't see that without the full diags.

It's still the parity check plugin pausing the check. Yes.

Set the filesystem to xfs and it should work, if not you can do it using the console: https://wiki.unraid.net/Check_Disk_Filesystems#Drives_formatted_with_XFS

Diags are after rebooting and not much help, if it keeps happening try this and post that syslog after a crash.

Delete/rename network.cfg and network-rules.cfg (if it exists) and reboot.

Yeah, resilvering is what zfs uses when rebuilding/repairing a disk, why I assumed he meant rebuilding. I love astronomy, I wish I had better conditions in my home for that, I did get a telescope some years ago, but basically only looked at the moon and a couple of planets, still worth it seeing Jupiter's moons and Saturn's rings.

One thing I forgot to ask before, leave the HBA disconnected from the backplane, boot Unraid and post new diags, this way we can see if the HBA is able to initialize correctly if not connected to the backplane.

Format is done after the device is part of the array, so parity can be updated. Default Unraid xfs format is: mkfs.xfs -m crc=1,finobt=1 -f /dev/mdX where X is the disk #, since I don't use xfs for a long time not current on the options, but probably crc=0 would get rid of the extra space, google "mkfs.xfs man page" for the options. Format will likely not work on a mounted filesystem, you'd need to manually unmount, probably easier for you to do this: -stop array -click on the disk you want to format and change it to a different filesystem -start array, that disk won't mount -type the correct mkfs command for the disk on the console (all data on that disk will be deleted) -stop array, change its fs back to xfs/auto -start array, if you used the correct format options it will now use less space.

Issue appears to start after some Macvlan call traces, those are usually related to dockers with a custom IP address, and in some some might end up locking up the server, more info here:

It's not using all the RAM, large part is cached, look here. As for the CPU usage, looks normal on the diags, if it wasn't at 100% then try to grab new ones when the CPU is at 100%.

It doesn't need to be, but it's better if it is.