JorgeB

Correct, it can detect some if there are errors during read, i.e. calculating the checksum for the stored block failed to match the written one due to RAM errors, I believe it's possible that either the block or checksum are corrupted before storing and those can also be detected since they won't match, but if the corruption happens before the data is written and the checksum is calculated for the corrupt block then those would go undetected, unless there were more errors during reads.

You can run a scrub on that pool to look for any corrupt files, if there are any they will be listed on the syslog, files corrupted on btrfs would be detected and you'd get an i/o error when trying to move/copy them, like the ones you got above, but some files might get corrupt after leaving btrfs at the time they got written to the xfs array disks, and no way to find those.

That syslog is spammed with loop2 errors, this is usually the docker image, possible running out of space, but we'd need the full diags to confirm.

When you mount one it mounts the other. Yep.

Yes, they are failing checksums, I also noticed data corruption was detected in you other pool, you likely have bad RAM or other hardware problem. You can use btrfs restore since it won't check for that, but files will still be corrupt, but depending on the severity they might still work.

You can check bellow for a list of recommended controllers:

That suggest those files might be corrupt, post current syslog.

These Asmedia controllers are two port SATA controllers: 03:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612] (rev 02) Subsystem: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:1060] Kernel driver in use: ahci Kernel modules: ahci 04:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612] (rev 02) Subsystem: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:1060] Kernel driver in use: ahci Kernel modules: ahci 05:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612] (rev 02) Subsystem: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:1060] Kernel driver in use: ahci Kernel modules: ahci If they have more than two ports they have SATA port multipliers (or are connected to an external enclosure with a port multiplier).

After everything is copied you can try to init the log tree: First unmount filesystem with: umount /x Then: btrfs rescue zero-log /dev/nvme0n1p1 Start the array normally and see if the pool mounts, if it does and all looks fine nothing more should be needed, but make sure you do regular backups of anything important.

I can't see which drive it is just by the log but it was parity in the previous diags, so likley still is. There are also more ATA errors: May 24 22:08:18 Plex kernel: ata9.00: failed to read SCR 1 (Emask=0x40) May 24 22:08:18 Plex kernel: ata9.01: failed to read SCR 1 (Emask=0x40) May 24 22:08:18 Plex kernel: ata9.02: failed to read SCR 1 (Emask=0x40) And these show you're using SATA port multipliers, those should really be avoided.

Then

The syslog is after a crash, wait for another crash then post it.

Try this option first, but note that the device was missing the partition: mount -o ro,notreelog,nologreplay /dev/nvme0n1p1 /x

Those would be normal with turbo write disable.

Enable this then post that log after a crash together with the diagnostics.

Changed Status to Closed Changed Priority to Other

You should post the diagnostics, if that's the only NIC and you can't boot with GUI mode you can get them on the console by typing "diagnostics"

Note that with gigabit you can't get more than around 115MB/s, diags saved during a transfer might show something, also good idea to run a single stream iperf test to check network bandwidth.

See here for some recovery options, first one to try in this case would be the nologreplay mount option.

Wipe the SSDs with blkdiscard -f /dev/sdX Then add to pool and re-format.

Your disks should be fast enough for gigabit to be the bottleneck when transferring with turbo write, I can transfer to one of my arrays at 200MB/s+ sustained with disks slower than those.

Plug and play. Basically yes, see if the server starts working normally. Disk3 on an Asmedia controller, replace cables on that disk.

There are constant ATA errors on disk6, replace cables and try again.

No need if you're splitting any directory as required, it will move to the next disk when it hits the share's minimum free space.

Yes, I forgot that, you can't use an existing config with a trial key.