JorgeB

Not much to go on with the call trace posted, 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.

That CPU, as most Xeon CPUs, doesn't appear in the board compatibility list, make sure you have the latest BIOS, still it might not work correctly, and it probably won't.

Once the rebuild finishes check filesystem on that disk. P.S. reiser is not recommended for a long time, you should convert all disks to xfs.

Please post the complete diagnostics.

Thinking about it, I believe there were some changes to UD and it might not allow mounting a former array device like that, if it doesn't leave them assigned and try to mount them manually read-only with the array stopped, like so: mkdir /x mount -v -o ro /dev/sdX1 /x Replace X with correct disk letter, if the disk mounts browse /x to check contents, if it doesn't post the output of the mount command. In the end to unmount use: umount /x

Do what I mentioned, with the array stopped unassign one or both disks that give you the invalid partition error and see if they mount with UD, best to activate read-only mount option in UD to keep parity in sync, if it still is.

Jan 25 16:22:03 Apollo kernel: ata5: softreset failed (1st FIS failed) Jan 25 16:22:03 Apollo kernel: ata5: hard resetting link Jan 25 16:22:03 Apollo kernel: ata9: softreset failed (1st FIS failed) Jan 25 16:22:03 Apollo kernel: ata9: hard resetting link Jan 25 16:22:03 Apollo kernel: ata1: softreset failed (1st FIS failed) Jan 25 16:22:03 Apollo kernel: ata1: hard resetting link Jan 25 16:22:03 Apollo kernel: ata10: softreset failed (1st FIS failed) Jan 25 16:22:03 Apollo kernel: ata10: hard resetting link Jan 25 16:22:03 Apollo kernel: ata2: softreset failed (1st FIS failed) Jan 25 16:22:03 Apollo kernel: ata2: hard resetting link Jan 25 16:22:09 Apollo kernel: ata10: hard resetting link Jan 25 16:22:09 Apollo kernel: ata1: SATA link down (SStatus 0 SControl 300) Jan 25 16:22:14 Apollo kernel: ata1: hard resetting link Jan 25 16:22:14 Apollo kernel: ata2: SATA link down (SStatus 0 SControl 300) Jan 25 16:22:19 Apollo kernel: ata2: hard resetting link Jan 25 16:22:19 Apollo kernel: ata9: SATA link down (SStatus 0 SControl 300) Jan 25 16:22:24 Apollo kernel: ata9: hard resetting link Jan 25 16:22:24 Apollo kernel: ata5: SATA link down (SStatus 0 SControl 300) Jan 25 16:22:29 Apollo kernel: ata5: hard resetting link Jan 25 16:22:30 Apollo kernel: ata5: SATA link down (SStatus 0 SControl 300) Jan 25 16:22:35 Apollo kernel: ata5: hard resetting link Jan 25 16:22:35 Apollo kernel: ata9: softreset failed (1st FIS failed) Jan 25 16:22:35 Apollo kernel: ata9: hard resetting link Multiple disk issues, could be a controller, power or connection problem.

Please post the diagnostics.

Unraid has the partitions starting on sector 2048 for SSDs vs 64 for disks, so there's a little less space and you can't direct replace a disk with an SSD of the same capacity, you can create a new array and manually copy the data though.

Correct, a full device write might fix it though, at least for some time, but if it does it's difficult to predict for how long.

And I might be wrong but doubt LT considers this issue a high priority, so you might need to live with it for some time.

Yep, that's a big difference, more than I'm used to seeing, but different hardware can provide very different results, looks like yours is considerably affected by the changes.

You can download v6.7.2 from here.

You could stop docker/VMs services, then just couple a 2min parity check and upgrade back up.

That still seems too slow to be this issue, I would recommend downgrading to v6.7 and do a quick test, you just need to run a check for a couple of minutes to check the starting speed and confirm.

Not really, but someone else might have.

It should, and with 24 devices and dual parity I could still do 140MB/s on my test server, that's about 12TB per 24H, what speed do you get at the start of the check?

That's expected, the change above it to avoid Unraid crashing, nothing to do with VMs working or not.

Don't think so as it works with RAW, and apparently it works for everybody except you, so no idea what the problem could be.

One thing I've remembered, you have two ports using IDE mode: 00:14.1 IDE interface [0101]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 IDE Controller [1002:439c] (rev 40) Subsystem: Gigabyte Technology Co., Ltd SB7x0/SB8x0/SB9x0 IDE Controller [1458:5002] Kernel driver in use: pata_atiixp Kernel modules: pata_atiixp IIRC this can cause sync errors with these AMD chip sets, change those (usually SATA5/6) to AHCI/SATA and try again 2 consecutive checks.

With rsync you just use the disks paths instead, e.g.: rsync -av /mnt/disk1/share/ dest_ip_adrress:/mnt/disk1/share/ That limit is for active copper cables, fiber cables can have much longer runs. https://en.wikipedia.org/wiki/Multi-mode_optical_fiber

You can't have the same filesystem mounted twice, doesn't matter if one of them is in the array or not, e.g., if you cloned the disk with dd you couldn't them mount the original and the clone at the same time using UD.

SMART test is failing so device needs to be replaced.

2022-01-24 01:27:24 Kernel.Warning 10.5.254.80 Jan 24 01:27:25 Astro-Server kernel: macvlan_broadcast+0x10e/0x13c [macvlan] 2022-01-24 01:27:24 Kernel.Warning 10.5.254.80 Jan 24 01:27:25 Astro-Server 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/

That's to fix the filesystem corruption, not data corruption if it exists, and if it's a RAM issue that's always a possibility, if you can recreate all data from scratch it's always better.