Konstantinos Skarlatos posted on Thu, 19 Jun 2014 11:56:59 +0300 as excerpted: > Thats good to hear. But we should have a way to recover from these kinds > of problems, first of all having btrfs report the exact location, disk > and file name that is affected, and then make scrub fix or at least > report about it, and finaly make fsck work for this. > > My filesystem that consistently kernel panics when a specific logical > address is read, passes scrub without anything bad reported. What's the > use of scrub if it cant deal with this? Scrub detects (and potentially fixes) exactly one sort of problem (tho that one can definitely cause others), and that's not it. On btrfs, what scrub does is exactly this: (a) Scrub calculates the checksums for all data and metadata blocks and matches that against the recorded checksum, reporting any no-match cases. (b) Where the checksums don't match up, if there's another copy of the data that /does/ checksum- validate, scrub will "scrub" the bad copy, replacing it with a duplicate of the good one. As it happens, on a (non-ssd) single-device filesystem, btrfs defaults to single data, dup metadata. In that case there's a second, hopefully valid, copy of the metadata blocks that can be used to correct a bad copy. But there's only a single copy of data blocks so while scrub can detect data-block errors, it won't be able to fix them. On a multi-device filesystem, btrfs defaults to raid1 metadata (with only two copies regardless of the number of devices present, N-way-mirroring is roadmapped but not yet implemented), single data, so again, hopefully the second copy of a bad metadata block is valid and can be used to scrub the bad one, but just as with the single-device case, it can detect but not fix data checksum errors. Tho of course in the multi-device case it's possible to set data to raid1 as well, and that's what I've done here so it too can be error-corrected from a hopefully good second copy. (Raid10 is similarly protected. Raid5/6 should work a bit differently, with parity, but last I knew raid56 scrub and recovery wasn't fully implemented yet, leaving raid1 and raid10, along with dup mode for single-device metadata only, as the error- correcting choices.) But if the problem is a btrfs logic error, such that the (meta)data that was actually checksummed and written out was bad before it was ever checksummed in the first place, then scrub won't do a thing for it, because the checksum validates just fine, it's just that it's a perfectly valid checksum on perfectly invalid (meta)data. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
