JorgeB

Looks more like a disk problem, there's no SMART report for that disk in the diags, see if you can get one manually.

You can try this: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=781601

You can try this: -Tools -> New Config -> Retain current configuration: All -> Apply -Check all assignments and assign any missing disk(s) if needed, including the new disk you want to rebuild, replacement disk should be same size or larger than the old one -Check both "parity is already valid" and "maintenance mode" and start the array -Stop array -Unassign the disk you want to rebuild -Start array (in normal mode now), ideally the emulated disk will now mount and contents look correct, if it doesn't you should run a filesystem check on the emulated disk -If the emulated disk mounts and contents look correct stop the array -Re-assign the disk to rebuild and start array to begin.

That issue is usually caused by the flash drive, but not always clear why it happens, wiping the flash drive can sometimes fix it but not always, kind of an elusive problem, a different flash drive can also help, glad it's solved.

Try rebooting to reload the new partition info.

Might not be a config issue, copy your config to the new flash drive, array won't start because of the key but you can still see if it boots.

Only breakout cables (miniSAS to SATA or vice versa) have a direction, forward or reverse, miniSAS to miniSAS cables work in any direction.

That's not official, with 4 dual rank DIMMs max officially supported RAM speed for that CPU is 2666Mhz, and Ryzen and known issues with overclocked RAM, including data corruption.

Some SMART issues, but because of the way it dropped and the very large number of CRC errors (though these could be old) it could just be a connection issue, replace/swap cables and see how it goes.

How many ports do you need? There aren't many good 4 port options, there's the 5 port JMB385 controller, though most times you can get an used 8port LSI HBA for about the same.

I have the Microtik CRS309-1G-8S+IN, still need transceivers for the longer fiber cables.

For me SFP+ was the best option, since most servers are close together and can work with just a DAC cable, I do have 3 or 4 that are too far away for DAC, but got fiber cables together with the transceivers pretty cheap on ebay.

With single parity data drive order is not important, it is with dual parity (or just parity2).

You'll never get a PCIe 4.0 link with a PCIe 3.0 NIC.

The only option I see is doing the manual way, i.e., copy/move all the data somewhere else, any files that can't be copied due to an i/o error are corrupt, note that some of the corruption might not be on files but it can be the metadata, but it sill should show that info on the log.

Sorry, no idea why it's not showing the warnings, never seen that before, unlikely to show different info but check the dmesg by typing: dmesg on the console.

Please post diags again just to make sure.

It's working for me, are you sure you're seeing the full syslog? The snippet you posted is only showing "btrfs error" lines, it's is missing the "btrfs warning" lines, those are the ones that show the file, e.g.: Nov 24 05:35:17 Test2 kernel: BTRFS warning (device md1): checksum error at logical 1479372800 on dev /dev/md1, physical 2561503232, root 5, inode 257, offset 375222272, length 4096, links 1 (path: 1.iso) Nov 24 05:35:17 Test2 kernel: BTRFS error (device md1): bdev /dev/md1 errs: wr 0, rd 0, flush 0, corrupt 3, gen 0 Nov 24 05:35:17 Test2 kernel: BTRFS error (device md1): unable to fixup (regular) error at logical 1479372800 on dev /dev/md1

One possible cause is running the RAM out of spec, see here and stick to the max officially supported speeds for your config.

It should, maybe something changed on the log level in the new beta, need to test.

No, this is data corruption, usually caused by bad RAM. In the syslog.

No need to delete just create a new one on top, also best to rebuild the super block if not pretty sure it won't use the extra size.

That is correct, when running on an array device you always use the md device to maintain parity, since the md device is the partition no need to specify it, when running on a device outside the array you need to use the sdX device and always specify the partition.

Run UFS exploiter or any other file recovery utility and scan that disk.

Yes, that means that there's corrupt data and the balance will abort, you can run a scrub to find out the corrupt files(s), then delete them or restore from backup, also good idea to run memtest.