JorgeB

Then you need to copy the data manually somewhere else, like a USB disk, then copy back to the new device.

If there's no "all data on this device will be deleted" in red letters to the right of the cache you can start normally and it should pick up old cache, if it doesn't please post diags.

Those are different, they were actual read errors.

Btrfs errors are likely the result of the previous crashes, I don't know how critical that particular error is, but it might be a good idea to re-format the pool just in case. Your main issue is likely related to the macvlan call traces, these are usually the result of having dockers with a custom IP address, and may end up crashing Unraid, see below for more info.

Yes, that what I meant, in this board the 3 top slots are from the CPU. In my experience lower end CPUs can still use the 20 CPU lanes, despite not being officially supported, in the past I used a G2030 and was still able to use the 3 top slots and confirmed they were linking at x8+x8+x4.

It doesn't show the beginning of the problem with the disks because there's a lot of other crashing, apparently related to IOMMU, if you don't need it try disabling it and/or look for a BIOS update.

No, you can only rebuild a disable drive to a single device, same size or larger than the original, and can't be larger than parity. 3TB rebuild should take around 5 or 6 hours, depending on the disks and other the hardware.

V6.8 allows 30 array devices and 24 cache devices, v6.9 allows multiple pools of up to 30 devices each, pools can only use one of the available btrfs profiles, but yes you can have separate pools with all of them moving data to the array when the mover runs.

The async page read errors are normal during a disk clear, it's an Unraid issue, the first controller related error not so normal, but by itself nothing to worry about for now, keep monitoring.

Usually it's not a 3rd slot, it allows to bifurcate a x8 CPU slot as two x4 slots, so for example I have an HBA in one slot and 2 NVMe devices in another, and most CPUs support it, no need for a Xeon.

If it's still logging constant ATA errors then it's likely a problem with the SSD, try another if available.

Thanks, didn't even notice it was an X9SCM, I've had the same issue where a 2 ports Asmedia controller wouldn't work in the CPU slots, only the PCH slots, will need to check the BIOS.

Yes, use those first, though onboard SATA on some Ryzen boards also has issues, and you can re-enable the drive.

Still constant ATA errors, but now easier to see which device is the problem, replace cables on the cache SSD, it can also be an SSD problem, but stat with the cables.

Please post the diagnostics: Tools -> Diagnostics

Disk looks fine, but this is usually no good: Feb 4 16:16:20 SpaceTaxi kernel: ata12.15: Port Multiplier 1.2, 0x197b:0x5755 r0, 5 ports, feat 0x5/0xf Never use SATA port multipliers with Unraid, see here for a list of recommended controllers:

Extended SMART test is usually a good way to test.

Depends on the boards, also some boards shares slots with other devices, only one can be enable.

That suggests the drive dropped offline, check/replace cables and post new diags.

Yes, doesn't look very healthy, you can run the extended SMART test by clicking on cache, then SMART section.

Please don't double post, locking this one.

Don't doubt that, but there's nothing in the log about it, not even the mover starting, so can't see the problem, you can try rebooting and grab new diags.

Is that assigned as cache? If yes what filesystem and can you connect both devices at the same time?

No, there were constant ATA errors on disk1: Jan 1 04:42:48 Tower kernel: ata5.00: status: { DRDY } Jan 1 04:42:48 Tower kernel: ata5.00: failed command: READ FPDMA QUEUED Jan 1 04:42:48 Tower kernel: ata5.00: cmd 60/00:10:d8:86:b8/04:00:70:00:00/40 tag 2 ncq dma 524288 in Jan 1 04:42:48 Tower kernel: res 40/00:00:d8:82:b8/00:00:70:00:00/40 Emask 0x10 (ATA bus error) Jan 1 04:42:48 Tower kernel: ata5.00: status: { DRDY } Jan 1 04:42:48 Tower kernel: ata5.00: failed command: READ FPDMA QUEUED Jan 1 04:42:48 Tower kernel: ata5.00: cmd 60/f8:18:d8:8a:b8/03:00:70:00:00/40 tag 3 ncq dma 520192 in Jan 1 04:42:48 Tower kernel: res 40/00:00:d8:82:b8/00:00:70:00:00/40 Emask 0x10 (ATA bus error) Jan 1 04:42:48 Tower kernel: ata5.00: status: { DRDY } Jan 1 04:42:48 Tower kernel: ata5.00: failed command: READ FPDMA QUEUED Jan 1 04:42:48 Tower kernel: ata5.00: cmd 60/00:20:d0:8e:b8/04:00:70:00:00/40 tag 4 ncq dma 524288 in Jan 1 04:42:48 Tower kernel: res 40/00:00:d8:82:b8/00:00:70:00:00/40 Emask 0x10 (ATA bu Most likely a power/connection problem.

It's not a general issue, I have several 860 EVO without issues, likely depends on the controller, but for you possibly better to try a different brand.