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