public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: 4e868df3 <4e868df3@gmail.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: corrupt leaf
Date: Sun, 1 Mar 2020 08:41:07 +0800	[thread overview]
Message-ID: <81a5e4cb-c6a6-23e0-9a29-76eaa07a6166@gmx.com> (raw)
In-Reply-To: <CADq=pgkuxOf7h=25Qice9q5Q-RiFXQiDzx0ZuEUCs4uN++3sxw@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 4486 bytes --]



On 2020/2/29 下午11:47, 4e868df3 wrote:
> It came up with some kind of `840 abort`. Then I reran btrfs check and
> tried again.
> 
> $ btrfs check --init-csum-tree /dev/mapper/luks0
> Creating a new CRC tree
> WARNING:
> 
>         Do not use --repair unless you are advised to do so by a developer
>         or an experienced user, and then only after having accepted that no
>         fsck can successfully repair all types of filesystem corruption. Eg.
>         some software or hardware bugs can fatally damage a volume.
>         The operation will start in 10 seconds.
>         Use Ctrl-C to stop it.
> 10 9 8 7 6 5 4 3 2 1
> Starting repair.
> Opening filesystem to check...
> Checking filesystem on /dev/mapper/luks0
> UUID: 8c1dea88-fa40-4e6e-a1a1-214ea6bcdb00
> Reinitialize checksum tree
> Unable to find block group for 0
> Unable to find block group for 0
> Unable to find block group for 0

This means the metadata space is used up.

Which btrfs-progs version are you using?
Some older btrfs-progs have a bug in space reservation.

Thanks,
Qu
> ctree.c:2272: split_leaf: BUG_ON `1` triggered, value 1
> btrfs(+0x71e09)[0x564eef35ee09]
> btrfs(btrfs_search_slot+0xfb1)[0x564eef360431]
> btrfs(btrfs_csum_file_block+0x442)[0x564eef37c412]
> btrfs(+0x35bde)[0x564eef322bde]
> btrfs(+0x47ce4)[0x564eef334ce4]
> btrfs(main+0x94)[0x564eef3020c4]
> /usr/lib/libc.so.6(__libc_start_main+0xf3)[0x7ff12a43e023]
> btrfs(_start+0x2e)[0x564eef30235e]
> [1]    840 abort      sudo btrfs check --init-csum-tree /dev/mapper/luks0
> 
> $ btrfs check /dev/mapper/luks0
> Opening filesystem to check...
> Checking filesystem on /dev/mapper/luks0
> UUID: 8c1dea88-fa40-4e6e-a1a1-214ea6bcdb00
> [1/7] checking root items
> [2/7] checking extents
> [3/7] checking free space cache
> [4/7] checking fs roots
> [5/7] checking only csums items (without verifying data)
> there are no extents for csum range 68757573632-68757704704
> Right section didn't have a record
> there are no extents for csum range 68754427904-68757704704
> csum exists for 68750639104-68757704704 but there is no extent record
> there are no extents for csum range 68760719360-68761223168
> Right section didn't have a record
> there are no extents for csum range 68757819392-68761223168
> csum exists for 68757819392-68761223168 but there is no extent record
> there are no extents for csum range 68761362432-68761378816
> Right section didn't have a record
> there are no extents for csum range 68761178112-68836831232
> csum exists for 68761178112-68836831232 but there is no extent record
> there are no extents for csum range 1168638763008-1168638803968
> csum exists for 1168638763008-1168645861376 but there is no extent
> record
> ERROR: errors found in csum tree
> [6/7] checking root refs
> [7/7] checking quota groups skipped (not enabled on this FS)
> found 3165125918720 bytes used, error(s) found
> total csum bytes: 3085473228
> total tree bytes: 4791877632
> total fs tree bytes: 1177714688
> total extent tree bytes: 94617600
> btree space waste bytes: 492319296
> file data blocks allocated: 3160334041088
>  referenced 3157401378816
> 
> $ btrfs check --init-csum-tree /dev/mapper/luks0
> Creating a new CRC tree
> WARNING:
> 
>         Do not use --repair unless you are advised to do so by a developer
>         or an experienced user, and then only after having accepted that no
>         fsck can successfully repair all types of filesystem corruption. Eg.
>         some software or hardware bugs can fatally damage a volume.
>         The operation will start in 10 seconds.
>         Use Ctrl-C to stop it.
> 10 9 8 7 6 5 4 3 2 1
> Starting repair.
> Opening filesystem to check...
> Checking filesystem on /dev/mapper/luks0
> UUID: 8c1dea88-fa40-4e6e-a1a1-214ea6bcdb00
> Reinitialize checksum tree
> Unable to find block group for 0
> Unable to find block group for 0
> Unable to find block group for 0
> ctree.c:2272: split_leaf: BUG_ON `1` triggered, value 1
> btrfs(+0x71e09)[0x559260a6de09]
> btrfs(btrfs_search_slot+0xfb1)[0x559260a6f431]
> btrfs(btrfs_csum_file_block+0x442)[0x559260a8b412]
> btrfs(+0x35bde)[0x559260a31bde]
> btrfs(+0x47ce4)[0x559260a43ce4]
> btrfs(main+0x94)[0x559260a110c4]
> /usr/lib/libc.so.6(__libc_start_main+0xf3)[0x7f212eb1f023]
> btrfs(_start+0x2e)[0x559260a1135e]
> [1]    848 abort      sudo btrfs check --init-csum-tree /dev/mapper/luks0
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-03-01  0:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27  5:59 corrupt leaf 4e868df3
2020-02-27  6:30 ` Chris Murphy
2020-02-27  7:23   ` 4e868df3
2020-02-27  8:03     ` Chris Murphy
2020-02-27  8:25 ` Qu Wenruo
2020-02-28  2:28   ` 4e868df3
2020-02-28  3:01     ` Qu Wenruo
2020-02-29 15:47       ` 4e868df3
2020-03-01  0:41         ` Qu Wenruo [this message]
2020-03-01  6:11           ` 4e868df3
2020-03-01 11:40             ` Qu Wenruo
2020-03-02  6:35         ` Chris Murphy

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=81a5e4cb-c6a6-23e0-9a29-76eaa07a6166@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=4e868df3@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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