On 2015-12-07 10:12, Jon Panozzo wrote:
> 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.
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.