Hugo Mills posted on Sat, 16 Nov 2013 12:23:42 +0000 as excerpted: > On Sat, Nov 16, 2013 at 04:06:10AM -0800, Anatol Pomozov wrote: >> Follow-up for the issue. I stuck with this "invalid csum for free space >> extent" error. Could anyone explain what does it mean? If this is not >> data and just a free space, why do we care about its checksum? And if >> we do really care then btrfs should have a way to fix this error. I can >> "fix" a file checksum error by removing the file, but how to "fix" free >> space extent checksum error? > > Probably drop the free space cache and rebuild it. If you check the thread history (well, at least based on my interpretation thereof, perhaps I'm wrong), he tried that. Apparently there's a problem in the free-space cache area that appears to go away when he drops cache, but the moment he lets it rebuild, the problem reappears. Almost as if there's a physical defect on the hardware itself, but the usual automatic hardware sector relocate functionality isn't triggering for some reason, so every time he tries to use that physical location, which happens to be in the middle of where btrfs tries to put its space- cache, the csum errors trigger. I guess btrfs doesn't (yet?) work with badblocks output as ext* (and reiserfs, which I'm personally more familiar with) does? I don't see anything listed in the btrfs or mkfs.btrfs manpages for it, at least. Is such support planned? One would expect it given that btrfs appears to be the assumed successor to ext* series' default Linux filesystem title. -- 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
