JorgeB

Can't be that one as it's not installed on the server I had the problem.

Just to make sure, using just the onboard Intel/AMD SATA ports correct? Since a few board have an onboard LSI controller.

Then it's very difficult to diagnose remotely, you can try safe mode but likely it's a hardware problem, run memtest and if possible try swapping some components, like PSU, board, etc

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

Readonly is perfectly safe, just don't use --repair, if there are issues it would be best to backup and re-format, or at least backup before trying to repair.

Scrub is to check data integrity, filesystem check to fix filesystem corruption, but note that btrfs check --repair should only be run as a last resort and if you known what you're doing, more info here.

There are ATA errors on both cache devices: Jan 22 22:27:32 eon kernel: ata4.00: exception Emask 0x0 SAct 0x3e00000 SErr 0x0 action 0x6 frozen Jan 22 22:27:32 eon kernel: ata4.00: failed command: READ FPDMA QUEUED Jan 22 22:27:32 eon kernel: ata4.00: cmd 60/08:a8:38:aa:21/00:00:1d:00:00/40 tag 21 ncq dma 4096 in Jan 22 22:27:32 eon kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Jan 22 22:27:32 eon kernel: ata4.00: status: { DRDY } Jan 22 22:27:32 eon kernel: ata4.00: failed command: READ FPDMA QUEUED Jan 22 22:27:32 eon kernel: ata4.00: cmd 60/70:b0:d0:ae:21/00:00:1d:00:00/40 tag 22 ncq dma 57344 in Jan 22 22:27:32 eon kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Jan 22 22:27:32 eon kernel: ata4.00: status: { DRDY } Jan 22 22:29:49 eon kernel: ata3.00: exception Emask 0x0 SAct 0x6 SErr 0x0 action 0x6 frozen Jan 22 22:29:49 eon kernel: ata3.00: failed command: READ FPDMA QUEUED Jan 22 22:29:49 eon kernel: ata3.00: cmd 60/38:08:88:55:22/00:00:1d:00:00/40 tag 1 ncq dma 28672 in Jan 22 22:29:49 eon kernel: res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Jan 22 22:29:49 eon kernel: ata3.00: status: { DRDY } Jan 22 22:29:49 eon kernel: ata3.00: failed command: READ FPDMA QUEUED Jan 22 22:29:49 eon kernel: ata3.00: cmd 60/28:10:38:0e:da/00:00:00:00:00/40 tag 2 ncq dma 20480 in Jan 22 22:29:49 eon kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Jan 22 22:29:49 eon kernel: ata3.00: status: { DRDY } Jan 22 22:29:49 eon kernel: ata3: hard resetting link Jan 22 22:29:59 eon kernel: ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jan 22 22:29:59 eon kernel: ata3.00: configured for UDMA/133 Jan 22 22:29:59 eon kernel: sd 3:0:0:0: [sdd] tag#31 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x06 Jan 22 22:29:59 eon kernel: sd 3:0:0:0: [sdd] tag#31 CDB: opcode=0x28 28 00 1d 22 4d 68 00 00 28 00 Jan 22 22:29:59 eon kernel: print_req_error: I/O error, dev sdd, sector 488787304 This is a hardware problem, it could be a connection issue but strange happening on both devices at the same time, so it could also be a compatibility issue with your board and those model SSDs, try replacing/swapping all cables first, including power cables.

Config should work fine with v6.7.2 but you can get v6.8.0 from https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.8.0-x86_64.zip

Most of the similar reports I remember reading were using LSI HBA(s), myself included, so to rule that out anyone having this problem not using one?

This is happening to several users, created a bug report:

I've created a bug report about this:

Array is kind of a mess, disk8 is also disabled now. Did you let disk2 rebuild finish before?

Please post the diagnostics: Tools -> Diagnostics

This seems to be happening to various users, in fact it just happened to me after updating one of my servers to v6.8.1: I'll create a bug report about this. Done:

Most errors on the log are because spin down doesn't work for NVMe devices, disable it for cache1. If you have issues with read speed it won't have nothing to do with write cache, in addition to running an iperf test like mentioned you can also test read speeds from array or cache to see if they are the same. So why use 3? Especially 3 different models, try with just one.

Best to post in the wireguard support thread.

Depends mostly on the backplane on the 846E1-R900B chassis, what model is it?

Ryzen on Linux can lock up due to issues with c-states, make sure bios is up to date, then look for "Power Supply Idle Control" (or similar) and set it to "typical current idle" (or similar), or completely disable C-sates. More info here: https://forums.unraid.net/bug-reports/prereleases/670-rc1-system-hard-lock-r354/

Yes, and you could have done both at the same time.

Post new diags, but I'm leaving now so will only see them tomorrow, someone else might help in the meantime.

You only re-enabled disk1, you need to do the same for parity, but since disk1 rebuild is underway probably best to wait for it to finish. Diags are after reboot so we can't see why the disks got disabled but since they look healthy and it's unlikely for two disks to get bad at the same time it's like a connection or hba/power issue.

Are you using a Ryzen based server by any chance? You should always post the diagnostics: Tools -> Diagnostics

Disk1 never got disabled, it's still normal. If you have another one it's fine to replace, as long as it's not a RAID controller, disks will be detected the same.

No, preclear doesn't format disks, format was done by you after array start: Jan 22 11:45:03 Server emhttpd: req (4): startState=STARTED&file=&cmdFormat=Format&unmountable_mask=512&confirmFormat=OFF&csrf_token=****************