Re: Scrub on btrfs single device only to detect errors, not correct them?

[Austin S Hemmelgarn]

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.

smime.p7s
Description: S/MIME Cryptographic Signature