JorgeB

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.

That's basically it, you can remove disk5 before or after the parity sync.

It appears to be a smartctl issue, newer Unraid is using v7.1 as opposed to v7.0 before, and for some reason v7.1 is not getting those drives temps, but it's not an Unraid problem, it would need to be fixed on smartctl, and likely it will in an upcoming release.

You could for example get and LSI 9305-24i, but it could be much cheaper to use an 8 port LSI with a SAS expander.

The dual controllers in each enclosure are for redundancy/multipath and since Unraod doesn't support SAS multipath you basically have two connection options: 1) single cable from HBA to first controller on the 1st enclosure then daisy chain to 2nd encloure 2) and best option for performance, one cable from each HBA port to each enclosure

IIRC those controllers have performance issues with Unraid, one of the recommended LSI HBAs would be preferred.