JorgeB

Yep, that's why I mentioned Glad you found the issue.

Does appear to be a disk issue, you can run an extended test to confirm, since this type of read errors can be intermittent, if it fails the test or you get more read errors replace.

Below the balance and scrub sections of every btrfs filesystem, just click on the device on main and scroll down.

No, it's for power only.

Problem with the onboard controller, quite common with some Ryzen boards, usually under load, look for a BIOS update and if that doesn't help use an add-on controller, or a different board.

Trimming the images/vdisks should have the same result.

Root must have a password set since v6.9.x

As mentioned adding slots is not a problem. Why not? Just need to check the "I want to do this" or similar box next to the array start button.

That is a big deal, only number of acceptable sync errors is 0. Except for one the sync errors started right at the 8TB mark, this suggests the initial sync or not correct or you did a parity swap, this sometimes results in a pesky bug that doesn't correctly zero out the reaming of the drive past the initial parity size.

When you remove a device, it's not a problem when you add one. Don't see how. Because the UUID comes from the filesystem and it was the same.

but v6.9.2 is not affected by the bug and won't let you anyway, so it's fine.

Only logical explanation is that a some point in the past they were both assigned to the same pool, but would need the syslog to confirm, if the server didn't reboot since it happened.

If you can't see start moving the data outside the pool, to the array for example, vdisks are a usual suspect, they can expand if not trimmed.

Like suspected both devices are in the same pool, easiest way to fix is by doing the below, since I don't know which Unraid version you're using make sure you don't change the number of cache slots when removing the pool device, there's a bug in some releases. -stop the array -unassign both pool devices -start array -stop array -assign both devices to the same pool, to the one where you want the existing data, there can't be a "all data will be delete" warning in front of any member -start array -stop array -unassign the device you want to remove from that pool -start array -wait for the btrfs balance to finish, when it does stop the array -you can now assign the removed device to the other pool -start array, there will be an option to format that pool and once that's done you can use it.

du (and other tools) isn't reliable with btrfs, this will be the actual used space.

That's not what I need, post the output of btrfs fi usage -T /mnt/name_of_pool for both pools, if that's enough fine, if not sorry but not going going to ask file by file as I need them.

Up to you of course.

The complete zip.

SFF-8087 to SFF-8087

Probably both devices are still in the same pool, please post diagnostics to confirm.

Cool, didn't know about this.

Possibly, but with USB and older disks in the array it might not, you can run the the disk speed docker to check disk performance.

No, it's a duplicate of disk2, so after wiping it there might still be issues with parity because there's only one btrfs array disk, likely also the reason parity is only showing 4TB, post new diags after fixing sdl and rebooting.

Good news is that the crashing is gone, how is the speed? Pool issues are the result of a duplicate filesystem on the unassigned disk (sdl), I guess that's old parity? Wiping/reformatting/disconnecting it should fix that, after rebooting.