JorgeB

Next time please attach the diags directly to the forum. Yes, disk should be replaced, also check your CPU cooling, it's overheating and throttling down.

You can try repairing but even if successful it's more likely to go corrupt again so recommend formatting. It's up to you, if you don't need/use the btrfs extra features and don't plan on having a pool you might as well use xfs, since it's more reliable.

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

Please post the diagnostics: Tools -> Diagnostics

You should answer "a" for always, it's not that uncommon to get that.

Difficult to say, the diags are very recently after a reboot, it appears to have started with the docker image, any unclean shutdowns?

Cache filesystem is corrupt, best way forward is to backup and re-format, there are some recovery options here if needed.

Them it should perform as expected, i.e., as fast as your slowest disk with turbo write enable. You can use this to check the speed of your devices and if the writing speed (using the SATA ports and turbo write) is far from the slowest disk post the diagnostics grabbed during a transfer.

Update manually, just extract all bz* files overwriting existing ones and reboot, but you check the release notes for all major versions since and the v6.5 update notes.

Please reboot in safe mode, try again and post new diags if it still fails.

That's not correct 2nd parity uses a different calculation and isn't interchangeable with parity1, some info here. There is, you can recover any two failed drives.

It's better if you have a fan blowing some air directly over the HBA heatsink, but as long as there's good airflow in the case and the HBA isn't sandwiched between other cards you'll be fine. They both have the same max power draw of 13.5w, normal power draw in use (measured by me) is around 7w.

According to the diags you have 4 dual rank DIMMs, so max officially supported speed is 2666Mhz, it's currently running at 3600Mhz.

It's difficult to say especially when it's a one time thing, but if it keeps happening there's likely some hardware issue.

Both are logged as actual disk problems, but these errors can sometimes be intermittent, you should run an extended SMART test on both, or another parity check (non correcting)

In that case worth tying a new one on its place, assuming you're using good cables.

4kn will be fine as long as the LSI is in IT mode, and it is, but probably a good idea to update the firmware since it's on an ancient one.

What SMART errors? Note that Unraid SMART reports/tests doesn't work so great with SAS devices, they all look good to me, "Elements in grown defect list" is 0, but you can always run a long test on all, though a parity check accomplishes basically the same since it reads all sectors.

That disk failed the long SMART test so it should be replaced, there's also already a large number of "Elements in grown defect list" which is usually a good indicator of issues with SAS drives, similar to reallocated sectors.

You still need to free up some space on cache, this might help if any of those VMs are running Windows 8/10.

But is that a SAS or SATA controller? What controller and driver is in use? I never had any Dell servers so no idea what's there, I was talking about regular AHCI SATA ports, mostly the ones from an AHCI enable Intel controller, anything other than that may or may not have the similar issues.

Yes A sync error in this case could only be detected on parity2, and if detected it would be corrected (and logged in the history), if there's a read error on parity or any other device parity2 would be used to correct the error(s) and continue the rebuild so there's no corruption. The parity check after a rebuild is mostly to confirm that the rebuilt disk can be read back correctly, it's an optional step and IMHO there's not much reason to do it unless you don't trust your hardware, just wait for the next scheduled check, that's what I do, but parity2 being checked during the rebuild can't help for this anyway.

Unlikely to be a power issue then. Not really, try with a single DIMM/channel in use, if that doesn't help trying a different board would be my next move.

Checksum error on the docker image: May 1 11:29:50 Titan kernel: BTRFS warning (device loop2): csum failed root 5 ino 274 off 16384 csum 0x5fa31edb expected csum 0xcfa287d9 mirror 1 You should re-create it, but this might be the result of a hardware problem, like bad RAM, especially if it happens again in the near future.