From: "^m'e" <marcoep@gmail.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs check: backref lost, mismatch with its hash -- can't repair
Date: Mon, 29 Jan 2018 15:08:46 +0000 [thread overview]
Message-ID: <CAAxOLF8f0RWtLQdsaMFYq=0q4yWZTo_d7zso9nBsVSp65Ekscg@mail.gmail.com> (raw)
In-Reply-To: <CAAxOLF9NTd4TcDc1FW23CE=5nR-Kp62=OJz31XmG_LqZBZJmsg@mail.gmail.com>
Lowmem check on my backup pool reports dozens of 'backref lost' on
extents... Excerpt:
----------------------------------------------------------
# ./btrfsck.static check --mode=lowmem /dev/sda1
checking extents
ERROR: data extent[33866182656 4096] backref lost
ERROR: data extent[37102219264 114688] backref lost
ERROR: data extent[37090353152 45056] backref lost
ERROR: data extent[37193342976 114688] backref lost
ERROR: data extent[50151686144 53248] backref lost
ERROR: data extent[49782943744 126976] backref lost
ERROR: data extent[49718861824 77824] backref lost
ERROR: data extent[33853538304 4096] backref lost
ERROR: data extent[41170333696 692224] backref lost
ERROR: data extent[37550239744 4096] backref lost
ERROR: data extent[33866182656 4096] backref lost
ERROR: data extent[37102219264 114688] backref lost
...
ERROR: data extent[37193342976 114688] backref lost
ERROR: data extent[50151686144 53248] backref lost
ERROR: data extent[49782943744 126976] backref lost
ERROR: data extent[49718861824 77824] backref lost
ERROR: data extent[33853538304 4096] backref lost
ERROR: data extent[41170333696 692224] backref lost
ERROR: data extent[37550239744 4096] backref lost
ERROR: data extent[44122832896 8192] backref lost
ERROR: data extent[45874237440 40960] backref lost
ERROR: errors found in extent allocation tree or chunk allocation
checking free space cache
block group 112772251648 has wrong amount of free space
failed to load free space cache for block group 112772251648
Wanted offset 127268339712, found 127268323328
Wanted offset 127268339712, found 127268323328
cache appears valid but isn't 127267766272
block group 133173346304 has wrong amount of free space
failed to load free space cache for block group 133173346304
Wanted offset 142837039104, found 142837022720
Wanted offset 142837039104, found 142837022720
cache appears valid but isn't 142837022720
ERROR: errors found in free space cache
Checking filesystem on /dev/sda1
UUID: 854e1bf5-7a98-4bcb-b971-0d9f2ac9452a
found 200684883968 bytes used, error(s) found
total csum bytes: 186712500
total tree bytes: 40191000576
total fs tree bytes: 39574110208
total extent tree bytes: 359038976
btree space waste bytes: 7605597010
file data blocks allocated: 946099404800
referenced 1091731312640
----------------------------------------------------------
Is that related to flawed snapshots of the ailing rootfs vol?
Is it safe to try to rollback from it?
Cheers,
M.
On Mon, Jan 29, 2018 at 2:49 PM, ^m'e <marcoep@gmail.com> wrote:
> On Mon, Jan 29, 2018 at 2:04 PM, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>> On 2018年01月29日 21:58, ^m'e wrote:
>>> Thanks for the advice, Qu!
>>>
>>> I used the system for a while, did some package upgrades -- writing in
>>> the suspect corrupted area. Then tried a btrfs-send to my backup vol,
>>> and it failed miserably with a nice kernel oops.
>>>
>>> So I went for a lowmem repair:
>>> ----------------------------------------------------------------------------------------
>>> # ./btrfsck.static check --repair --mode=lowmem /dev/sdb3 2>&1 | tee
>>> /mnt/custom/rescue/btrfs-recovery/btrfs-repair.BTR-POOL.1.log
>>> WARNING: low-memory mode repair support is only partial
>>> Fixed 0 roots.
>>> checking extents
>>> checking free space cache
>>> checking fs roots
>>> ERROR: failed to add inode 28891726 as orphan item root 257
>>> ERROR: root 257 INODE[28891726] is orphan item
>>
>> At least I need dig the kernel code further to determine if the orphan
>> inode handling in btrfs-progs is correct or not.
>>
>> So there won't be more dirty fix soon.
>>
>> Hopefully you could get some good backup and restore the system.
>>
>> At least the problem is limited to a very small range, and it's
>> something we could handle easily.
>>
>> Thanks for all your report,
>> Qu
>>
>>
>
> Right.
>
> Meanwhile, could you please suggest the best course of action? btrfs
> rescue or restore?
> I have snapshots of my two subvols (rootfs, home -- now fs-checking
> them just in case...)
>
> Cheers,
>
> Marco
--
^m'e
next prev parent reply other threads:[~2018-01-29 15:09 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-22 14:11 btrfs check: backref lost, mismatch with its hash -- can't repair ^m'e
2018-01-22 14:38 ` Qu Wenruo
2018-01-22 15:04 ` ^m'e
2018-01-24 8:49 ` Qu Wenruo
2018-01-24 9:18 ` Foo Bar
2018-01-24 10:14 ` Qu Wenruo
2018-01-24 11:57 ` ^m'e
2018-01-24 12:39 ` Qu Wenruo
2018-01-24 14:47 ` ^m'e
2018-01-24 19:00 ` ^m'e
2018-01-24 20:41 ` ^m'e
2018-01-25 0:59 ` Qu Wenruo
2018-01-25 11:54 ` ^m'e
2018-01-25 12:09 ` Qu Wenruo
2018-01-25 12:29 ` ^m'e
2018-01-25 12:37 ` Qu Wenruo
2018-01-25 16:40 ` ^m'e
2018-01-25 23:30 ` Qu Wenruo
2018-01-26 11:19 ` ^m'e
2018-01-26 12:16 ` Qu Wenruo
2018-01-26 15:15 ` ^m'e
2018-01-29 1:34 ` Qu Wenruo
2018-01-29 13:58 ` ^m'e
2018-01-29 14:04 ` Qu Wenruo
2018-01-29 14:49 ` ^m'e
2018-01-29 15:08 ` ^m'e [this message]
2018-01-29 15:10 ` Qu Wenruo
2018-01-29 15:09 ` Qu Wenruo
2018-01-29 18:16 ` ^m'e
2018-01-30 1:24 ` Qu Wenruo
2018-01-30 20:14 ` Foo Bar
2018-01-25 0:59 ` Qu Wenruo
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='CAAxOLF8f0RWtLQdsaMFYq=0q4yWZTo_d7zso9nBsVSp65Ekscg@mail.gmail.com' \
--to=marcoep@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.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).