From: Marc MERLIN <marc@merlins.org>
To: Lu Fengqi <lufq.fnst@cn.fujitsu.com>, Chris Mason <clm@fb.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>,
David Sterba <dsterba@suse.cz>
Subject: We really need a better/working btrfs check --repair
Date: Sat, 8 Jul 2017 22:05:38 -0700 [thread overview]
Message-ID: <20170709050538.GF6704@merlins.org> (raw)
In-Reply-To: <20170709043417.GE6704@merlins.org>
+Chris
On Sat, Jul 08, 2017 at 09:34:17PM -0700, Marc MERLIN wrote:
> gargamel:/var/local/scr/host# btrfs check --repair /dev/mapper/crypt_bcache2
> enabling repair mode
> Checking filesystem on /dev/mapper/crypt_bcache2
> UUID: c4e6f9ca-e9a2-43d7-befa-763fc2cd5a57
> checking extents
> ref mismatch on [14655689654272 16384] extent item 0, found 1
> Backref 14655689654272 parent 15455 root 15455 not found in extent tree
> backpointer mismatch on [14655689654272 16384]
> owner ref check failed [14655689654272 16384]
> repair deleting extent record: key 14655689654272 169 1
> adding new tree backref on start 14655689654272 len 16384 parent 0 root 15455
> Repaired extent references for 14655689654272
> root 15455 has a root item with a more recent gen (33682) compared to the found root node (0)
> ERROR: failed to repair root items: Invalid argument
On this note, getting hit 3 times on 3 different filesystems, that are not
badly damaged, but in none of those caess can btrfs check --repair put them
in a working state, is really bringing home the problem with lack of proper
fsck.
I understand that some errors are hard to fix without unknown data loss, but
btrfs check --repair should just do what it takes to put the filesystem back
into a consistent state, never mind what data is lost.
Restoring 10 to 20TB of data is getting old and is not really an acceptable
answer as the only way out.
I should not have to recreate a filesystem as the only way to bring it back
to a working state.
Before Duncan tells me my filesystem is too big, and I should keep to very
small filesystems so that it's less work for each time btrfs gets corrupted
again, and fails again to bring back the filesystem to a usable state after
discarding some data, that's just not an acceptable answer long term, and by
long term honestly I mean now.
I just have data that doesn't segment well and the more small filesystems I
make the more time I'm going to waste managing them all and dealing with
which one gets full first :(
So, whether 4.11 has a corruption problem, or not, please put some resources
behind btrfs check --repair, be it the lowmem mode, or not.
Thank you
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
next prev parent reply other threads:[~2017-07-09 5:05 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-20 14:39 4.11.3: BTRFS critical (device dm-1): unable to add free space :-17 => btrfs check --repair runs clean Marc MERLIN
2017-06-20 15:23 ` Hugo Mills
2017-06-20 15:26 ` Marc MERLIN
2017-06-20 15:36 ` Hugo Mills
2017-06-20 15:44 ` Marc MERLIN
2017-06-20 23:12 ` Marc MERLIN
2017-06-20 23:58 ` Marc MERLIN
2017-06-21 3:31 ` Chris Murphy
2017-06-21 3:43 ` Marc MERLIN
2017-06-21 15:13 ` How to fix errors that check --mode lomem finds, but --mode normal doesn't? Marc MERLIN
2017-06-21 23:22 ` Chris Murphy
2017-06-22 0:48 ` Marc MERLIN
2017-06-22 2:22 ` Qu Wenruo
2017-06-22 2:53 ` Marc MERLIN
2017-06-22 4:08 ` Qu Wenruo
2017-06-23 4:06 ` Marc MERLIN
2017-06-23 8:54 ` Lu Fengqi
2017-06-23 16:17 ` Marc MERLIN
2017-06-24 2:34 ` Marc MERLIN
2017-06-26 10:46 ` Lu Fengqi
2017-06-27 23:11 ` Marc MERLIN
2017-06-28 7:10 ` Lu Fengqi
2017-06-28 14:43 ` Marc MERLIN
2017-05-01 17:06 ` 4.11 relocate crash, null pointer Marc MERLIN
2017-05-01 18:08 ` 4.11 relocate crash, null pointer + rolling back a filesystem by X hours? Marc MERLIN
2017-05-02 1:50 ` Chris Murphy
2017-05-02 3:23 ` Marc MERLIN
2017-05-02 4:56 ` Chris Murphy
2017-05-02 5:11 ` Marc MERLIN
2017-05-02 18:47 ` btrfs check --repair: failed to repair damaged filesystem, aborting Marc MERLIN
2017-05-03 6:00 ` Marc MERLIN
2017-05-03 6:17 ` Marc MERLIN
2017-05-03 6:32 ` Roman Mamedov
2017-05-03 20:40 ` Marc MERLIN
2017-07-07 5:37 ` ctree.c:197: update_ref_for_cow: BUG_ON `ret` triggered, value -5 Marc MERLIN
2017-07-07 5:39 ` Marc MERLIN
2017-07-07 9:33 ` Lu Fengqi
2017-07-07 16:38 ` Marc MERLIN
2017-07-09 4:34 ` 4.11.6 / more corruption / root 15455 has a root item with a more recent gen (33682) compared to the found root node (0) Marc MERLIN
2017-07-09 5:05 ` Marc MERLIN [this message]
2017-07-09 6:34 ` Marc MERLIN
2017-07-09 7:57 ` Martin Steigerwald
2017-07-09 9:16 ` Paul Jones
2017-07-09 11:17 ` Duncan
2017-07-09 13:00 ` Martin Steigerwald
2017-07-29 19:29 ` Imran Geriskovan
2017-07-29 23:38 ` Duncan
2017-07-30 14:54 ` Imran Geriskovan
2017-07-31 4:53 ` Duncan
2017-07-31 20:32 ` Imran Geriskovan
2017-08-01 1:36 ` Duncan
2017-08-01 15:18 ` Imran Geriskovan
2017-07-31 21:07 ` Ivan Sizov
2017-07-31 21:17 ` Marc MERLIN
2017-07-31 21:39 ` Ivan Sizov
2017-08-01 16:41 ` Ivan Sizov
2017-07-31 22:00 ` Justin Maggard
2017-08-01 6:38 ` Marc MERLIN
2017-05-02 19:59 ` 4.11 relocate crash, null pointer + rolling back a filesystem by X hours? Kai Krakow
2017-05-02 5:01 ` Duncan
2017-05-02 19:53 ` Kai Krakow
2017-05-23 16:58 ` Marc MERLIN
2017-05-24 10:16 ` Duncan
2017-05-05 1:19 ` Qu Wenruo
2017-05-05 2:10 ` Qu Wenruo
2017-05-05 2:40 ` Marc MERLIN
2017-05-05 5:03 ` Qu Wenruo
2017-05-05 15:43 ` Marc MERLIN
2017-05-17 18:23 ` Kai Krakow
2017-05-05 1:13 ` Qu Wenruo
2017-06-29 13:36 ` How to fix errors that check --mode lomem finds, but --mode normal doesn't? Lu Fengqi
2017-06-29 15:30 ` Marc MERLIN
2017-06-30 14:59 ` Lu Fengqi
2017-06-22 4:08 ` Qu Wenruo
2017-06-21 12:04 ` 4.11.3: BTRFS critical (device dm-1): unable to add free space :-17 => btrfs check --repair runs clean Duncan
2017-06-21 3:26 ` Chris Murphy
2017-06-21 4:06 ` Marc MERLIN
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170709050538.GF6704@merlins.org \
--to=marc@merlins.org \
--cc=clm@fb.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=lufq.fnst@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).