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
Attachment:
signature.asc
Description: OpenPGP digital signature
