On Nov 16, 2013, at 1:54 PM, Duncan <1i5t5.duncan@xxxxxxx> wrote: > 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. Bad sectors should show up very clearly in dmesg, so maybe we need a full dmesg from the OP. Any case of a write failure is grounds for tossing that device as completely and immutably broken. > 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. I wouldn't expect a modern file system to track bad sectors. This is firmware domain these days. All available data indicates when drives start to develop many bad sectors, especially the case where write failures occur means all reserve sectors are unavailable, that the drive is self-destructing with material either damaging the head or peripheral areas of the drive (surface coating detachment). I think it's a waste of resources to support this brick, the drive should just be replaced. Chris Murphy -- 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
