JorgeB

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.

Yes!!! That explains the missing partition.

Please post diags after a balance attempt. P.S. "No balance" is normal after the balance ends/stops.

I've several, but not on x1 slots, it might work if the slot is open ended.

Unlikely the BIOS would help, it should boot fine without it in legacy or UEFI mode, most likely this, or a compatibility issue with that board.

Only option now is using a file recovery util, like UFS explorer.

Also don't forget that you'll then need to always run reiserfsck on the partition, not the disk, always /dev/sdX1 never /dev/sdX

See if a different flash drive boots.

It doesn't, unless something goes wrong.

This is a hardware issue, if it's a Proliant server see here:

You can use this: sgdisk -o -a 8 -n 1:32K:0 /dev/sdX

There's a problem with the cache filesystem, you should backup and re-format, then restore the data and also best recreate the docker image.

If it didn't download them after 2 minutes it won't, get them on the console by typing "diagnostics"