On 2020-01-06 12:32 p.m., Stephen Conrad wrote:

> 
> 4) What steps should I take to clean up the file system errors/messages?  Start 
> fresh after full backup, (though I hate the idea of migrating off a redundant 
> array onto a single disk in the process)?  Scrub etc?  Evaluate each disk 
> independently and rebuild one from the other?


I'm not really an expert, so this is just my understanding of btrfs so far:

Assuming these two devices are in a btrfs raid 1, only one of the two
devices has errors, (which is what I would expect for a device that
disconnected while the filesystem was running.)

With Millions of failed writes, i don't think it's appropriate to count
on scrub to have fixed up all the potential data errors.  Scrub on BTRFS
will check the CRC independently on both drives, and copy over data
where CRC fails, but CRC isn't perfect.  To the best of my knowledge,
BTRFS does not actually compare the data between mirror copies.

So my suggestion, to fix this safely, is to do a btrfs replace, and
replace /dev/mapper/K1JG82AD with a new device.


btrfs replace -r /dev/mapper/K1JG82AD /dev/new_device_partition /btrfs

The -r switch will ensure data is only copied from the drive that is not
full of potentially bad data with CRC collisions.

If you determine that /dev/mapper/K1JG82AD is actually physically fine,
you can re-add to the array.. maybe even use it to replace the spare
drive we just put in.

One note about using btrfs replace,, I don't know if this might be fixed
with newer kernels,, but I find that the error count from the old device
will re-appear on the new device, but only after a reboot, (or maybe
unmount/mount.) you should check for that, and if the new device
inherits your old errors, you should zero it with btrfs dev stats -z