JorgeB

Because it's not a clean shutdown: Mar 9 21:30:21 unMediaServer emhttpd: unclean shutdown detected Start by looking at this, sync errors (and btrfs checksum errors) are probably RAM related (either overclocked of bad RAM): https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173

First thing to do is to boot in safe mode to rule out any plugins, also if not needed delete the "extra" folder on the flash drive.

Pool has a missing device, despite both being assigned, to make sure there aren't surprises adding the device back and since current pool has multiple profiles it's best to backup and re-format the pool.

Disk was already disabled at boot so we can't see what happened, best to replace/swap cables to rule them out them rebuild.

I can't tell you what happened because whatever it was it happened before this boot but no btrfs filesystem are being detected which suggest cache devices were wiped.

See if this helps: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173

Yep.

If there are a lot of sync errors, and there will likely be, a parity sync is much faster than a correcting check, so I would recommend re-doing the new config.

Extract just the bz* files and replace the ones on the flash drive, then reboot.

That can only happen after a new config if you check "parity is already valid" before starting the array.

No, Unraid will detect the expanded disk size and won't mount the disks complaining that the partitions are invalid, if you can keep both controllers at the same time you could rebuild one disk at a time on the new controller (or 2 if you have dual parity).

IIRC there were errors with all controllers, on the original ad-don controller with a port multiplier, on the LSI, and this time with the onboard SATA ports, hence why I suspect there could be a power issue.

The sync errors are likely from the unclean shutdown, since it would be risky/impossible to do a correcting check, I would just cancel the parity check and replace the disk now, but keep the old disk in case it's needed.

Yes, and it won't hurt to replace them.

There are some reports of excess writes to the cache pool in some configurations, but nothing that would explain a new device getting reallocated sectors after 2 months.

Yes, nothing to do about that.

Yep.

Some folks? I only remember seeing one case and with a very specif configuration, but yeah if you want 6.8.2, you'll need to update manually.

All NVMe devices should support trim, and those support for sure, but you can jus run fstrim on them.

Yep, I have one.

Mostly because there aren't good 8+ ports SATA controllers.

There was a problem with the onboard SATA controller: Mar 9 01:41:23 MXCR-Unraid kernel: ahci 0000:03:00.1: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000e394c000 flags=0x0000] I've seen this multiple times on this forum with Ryzen boards, it might only happen with IOMMU enable.

That's one of the disks having ATA errors (hardware problem): Mar 8 00:35:30 Tower kernel: ata5.00: status: { DRDY SENSE ERR } Mar 8 00:35:30 Tower kernel: ata5.00: error: { ABRT } Mar 8 00:35:30 Tower kernel: ata5.00: configured for UDMA/133 (device error ignored) Mar 8 00:35:30 Tower kernel: ata5: EH complete Mar 8 00:35:30 Tower kernel: ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Mar 8 00:35:30 Tower kernel: ata5.00: irq_stat 0x40000001 Mar 8 00:35:30 Tower kernel: ata5.00: failed command: READ DMA EXT Mar 8 00:35:30 Tower kernel: ata5.00: cmd 25/00:08:00:f4:a0/00:00:ba:02:00/e0 tag 3 dma 4096 in Mar 8 00:35:30 Tower kernel: res 53/04:08:00:f4:a0/00:00:ba:02:00/e0 Emask 0x1 (device error) Mar 8 00:35:30 Tower kernel: ata5.00: status: { DRDY SENSE ERR } Mar 8 00:35:30 Tower kernel: ata5.00: error: { ABRT } Mar 8 00:35:30 Tower kernel: ata5.00: configured for UDMA/133 (device error ignored) Mar 8 00:35:30 Tower kernel: sd 5:0:0:0: [sdf] tag#3 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Mar 8 00:35:30 Tower kernel: sd 5:0:0:0: [sdf] tag#3 Sense Key : 0x5 [current] Mar 8 00:35:30 Tower kernel: sd 5:0:0:0: [sdf] tag#3 ASC=0x21 ASCQ=0x4 Mar 8 00:35:30 Tower kernel: sd 5:0:0:0: [sdf] tag#3 CDB: opcode=0x88 88 00 00 00 00 02 ba a0 f4 00 00 00 00 08 00 00 Mar 8 00:35:30 Tower kernel: print_req_error: I/O error, dev sdf, sector 11721044992 Mar 8 00:35:30 Tower kernel: Buffer I/O error on dev sdf, logical block 1465130624, async page read You still have some hardware issue causing problems with the devices using different controllers, I don't remember, did you try another power supply?

Yes, parity sync is always required for this, unless you clear the disk before removing.

For HBA, any LSI with a SAS2008/2308/3008/3408 chipset in IT mode, e.g., 9201-8i, 9211-8i, 9207-8i, 9300-8i, 9400-8i, etc and clones, like the Dell H200/H310 and IBM M1015, these latter ones need to be crossflashed. On the cheaper side for expanders you have the Intel SAS2 expanders, both the 24 (RES2SV240) and 32 port models (RES2CV360), another option is the HP 6Gb (SAS2/SATA2) expander.