From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org ([80.91.229.3]:32896 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752584Ab3KPUyb (ORCPT ); Sat, 16 Nov 2013 15:54:31 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vhmsv-0005wL-PR for linux-btrfs@vger.kernel.org; Sat, 16 Nov 2013 21:54:29 +0100 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Nov 2013 21:54:29 +0100 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Nov 2013 21:54:29 +0100 To: linux-btrfs@vger.kernel.org From: Duncan <1i5t5.duncan@cox.net> Subject: Re: How to fix/remove "csum failed ino" error Date: Sat, 16 Nov 2013 20:54:09 +0000 (UTC) Message-ID: References: <20131116122342.GT4315@carfax.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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