On 2015-12-07 10:12, Jon Panozzo wrote:
I think there is a tool in btrfs-progs to do it, but I've never used it, and you would still need to get scrub to spit out actual error addresses for you.This is what I was thinking as well. In my particular use-case, parity is only really used today to reconstruct an entire device due to a device failure. I think if btrfs scrub detected errors on a single device, I could do a "reverse reconstruct" where instead of syncing TO the parity disk, I sync FROM the parity disk TO the btrfs single device with the error, replacing physical blocks that are out of sync with parity (thus repairing the scrub-found errrors). The downside to this approach is I would have to perform the reverse-sync against the entire btrfs block device, which could be much more time-consuming than if I could single out the specific block addresses and just sync those. That said, I guess option A is better than no option at all. I would be curious if any of the devs or other members of this mailing list have tried to correlate btrfs internal block addresses to a true block-address on the device being used. Any interesting articles / links that show how to do this? Not expecting much, but if someone does know, I'd be very grateful.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
