JorgeB

Once the rebuild is done re-enable parity, if it fails to sync post new diags before rebooting.

Value needs to be larger than the largest file you expect to copy there, we usually suggest using twice the value of the largest file you expect to copy, to have some margin. Don't know is OSX supports server side copy with Samba, like Windows explorer does, if it doesn't data will transverse the network and will be much slower. Yes, and if a Windows VM you can use explorer to make a local copy/move like mentioned.

RAID controller BIOS, also keep in mind that RAID controllers are not recommended, this is just one of the reasons.

Disk7 appears to be failing, run an extend SMART test to confirm, there are also read errors on disk1 causing filesystem issues, disk1 looks healthy, issue could be spin down related, run xfs_repair o it and disable spin down for a few days to test.

Unlikely for that symptom.

That usually points to a hardware issue, one thing you can try it to boot the server in safe mode with all docker/VMs disable, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one.

Nothing jumps out, enable the syslog server and post that after a crash.

Post your diagnostics to see the hardware/config used.

Could be related to this: https://forums.unraid.net/bug-reports/prereleases/69x-610x-intel-i915-module-causing-system-hangs-with-no-report-in-syslog-r1674/?do=getNewComment&d=2&id=1674

If it's connected to the RAID controller you might need to initialize it or create a RAID0/JBOD volume with it.

Not sure about gen8, but gen7 came with write cache disable in the BIOS, this will also seriously hurt write performance, check yours.

You can't replace parity and add data disks at the same time:

First upgrade parity, once that's done you can add the new data disks, including old parity.

Also check this for better write speed, once the parity sync is done and there's no SMR parity:

With SMR as parity all writes to the array will be slower, with SMR as a data disk only writes to that disk will be slower, not ideal, but better.

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

Also note that array performance will be degraded while the parity sync doesn't finish, even if you pause it.

Parity disk is SMR, it's going to be slow writing, suggest replacing with a CMR model.

Shouldn't make much difference, but I would swap before.

There's a crash related to it: 2022-02-09T11:50:27+00:00 Mothership kernel: Call Trace: 2022-02-09T11:50:27+00:00 Mothership kernel: <IRQ> 2022-02-09T11:50:27+00:00 Mothership kernel: queued_spin_lock_slowpath+0x7/0xa 2022-02-09T11:50:27+00:00 Mothership kernel: nr_blockdev_pages+0x13/0x64 2022-02-09T11:50:27+00:00 Mothership kernel: si_meminfo+0x3a/0x57 2022-02-09T11:50:27+00:00 Mothership kernel: Sys_MemInfo+0x20/0x9b [corefreqk] 2022-02-09T11:50:27+00:00 Mothership kernel: ? paravirt_sched_clock+0x5/0x8 2022-02-09T11:50:27+00:00 Mothership kernel: ? timekeeping_get_ns+0x19/0x2f 2022-02-09T11:50:27+00:00 Mothership kernel: ? Sys_DumpTask+0xe9/0xf1 [corefreqk] 2022-02-09T11:50:27+00:00 Mothership kernel: Cycle_Skylake+0x53a/0x730 [corefreqk] 2022-02-09T11:50:27+00:00 Mothership kernel: __hrtimer_run_queues+0xb7/0x10b 2022-02-09T11:50:27+00:00 Mothership kernel: ? Cycle_Skylake_X+0x711/0x711 [corefreqk] 2022-02-09T11:50:27+00:00 Mothership kernel: hrtimer_interrupt+0x8d/0x15b 2022-02-09T11:50:27+00:00 Mothership kernel: __sysvec_apic_timer_interrupt+0x5d/0x68 2022-02-09T11:50:27+00:00 Mothership kernel: asm_call_irq_on_stack+0xf/0x20 2022-02-09T11:50:27+00:00 Mothership kernel: </IRQ> 2022-02-09T11:50:27+00:00 Mothership kernel: sysvec_apic_timer_interrupt+0x71/0x95 2022-02-09T11:50:27+00:00 Mothership kernel: asm_sysvec_apic_timer_interrupt+0x12/0x20 2022-02-09T11:50:27+00:00 Mothership kernel: RIP: 0010:nr_blockdev_pages+0x4c/0x64 Also it's a common issue.

Uninstall de corefeq plugin.

To expand a little more on this, diags you posted don't show the rebuilds, but: This means that the rebuilt disk10 will be corrupt, since when there were read errors on disk9 writes to disk10 would be skipped, so disk will be empty in those sectors. This would also result on a corrupt rebuild since disk10 was already corrupt. Same.

Could be a device problem, but the SASLP driver crashed, one of the reasons those controllers are not recommended, connect that SSD to an Intel SATA port, swap with another device if needed, and try again, post new diags if it fails again.

That's expected, do you still have the old disks? Might still be able to salvage some data that way.

Yep, check filesystem on both disabled disks, then if they mount look for a lost+found folder, if there's a lot of files there it's probably best to re-sync parity instead of rebuilding.