JorgeB

This is parity2, also de SATA controller is in IDE mode, and that's not ideal, but your board likely doesn't support AHCI.

This means the HBA stopped responding, make sure it's well seated or try a different PCIe slot if available.

Usually yes, unless pre-allocate all files is enable.

Not really since we can't see what caused the errors, like trurl mentioned safest option is to rebuild using spare disks.

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

No, but if there are sparse files on source you need to use the --sparse flag or it will take much more space.

Take a look at the SEL in the BIOS, this is how it appears for one of my SM boards:

Not that one, it's a Marvell, search for ASM1164 or JMB585

Looks at the system event log in the BIOS, or IPMI event viewer, there should be more info there.

If it's not RAM the next suspects are a controller or a disk, since you're using controller with SATA port multipliers and those are not recommended anyway I would start by replacing that.

Correct.

Dec 11 09:47:54 Tower kernel: macvlan_broadcast+0x10e/0x13c [macvlan] Dec 11 09:47:54 Tower kernel: macvlan_process_broadcast+0xf8/0x143 [macvlan] Macvlan call traces are usually the result of having dockers with a custom IP address, upgrading to v6.10 and switching to ipvlan might fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info. https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/ See also here: https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

I have one of those expanders also with an LSI HBA and never had any issues, but there could be with some specific models, also could be firmware related, but IIRC to update it requires a supported HP controller.

It appears after you click on the #1 device of any pool, so yes, pool needs to exist already.

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

Enable the syslog server and post that after a crash, hopefully it catches something.

Cool, would it be possible to also fix this long standing bug? https://forums.unraid.net/bug-reports/stable-releases/clearrebuild-operations-are-reported-as-the-last-parity-check-and-with-the-wrong-avg-speed-if-drive-is-smaller-than-parity-r3/?do=getNewComment&d=2&id=3 First bug report created on this subforum

Check filesystem.

That suggests a hardware issue, start by running memtest.

Log starts over after every reboot, so no way of knowing now if the previous check was correcting or not.

Log only shows one check, maybe the other one was non correcting, run another non correcting check and post new diags if it still finds sync errors.

Yes, this is normal with any disk.

You just need to assign them and start the array to begin the parity sync.

It does, not sure why they don't for me, but can't be the only one.

Intel SAS2 based expanders should work fine, like the RES2SV240, chip is LSI, so less likely to run into compatibility issues.