On 2015-12-07 09:47, Jon Panozzo wrote:
In theory, this is possible, but it's _really_ tricky to do right. BTRFS uses it's own internal block addressing that is mostly independent from what's done at the block device level, which makes things non-trivial to map to actual addresses. On top of that, it's non-trivial to get a address for a block that failed the scrub operation. It's probably easier to just run a check on the lower-level device if scrub reports errors. If that fails, then it's probably fixable by the lower level directly, if it passes, then the issue is probably a bug in BTRFS.And I'll throw this question out to everyone: Let's say I have a means of providing parity for a btrfs device, but in a way that's external to btrfs (imagine a btrfs single device as part of a hardware or software RAID). If BTRFS detected an error during a scrub, and parity wasn't updated as a result (say the result of bitrot on the btrfs device), couldn't parity be used to repair the broken bit(s)? If so, the big question is how to use scrub to determine the sector/bit (forgive me if I'm using wrong terminology) at the block level that needs to be fixed. I think my theory is sound in principle, but not sure if it's possible to correlate a scrub-found uncorrectable error to a physical location on the block device.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
