All of lore.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 19:40:47 +0800	[thread overview]
Message-ID: <df40a18a-4a28-f3b7-dfff-8ccade905d32@gmx.com> (raw)
In-Reply-To: <CADq=pgkV21ZSCeJEC8jGSB4P6+_OXzpG8v54Px8XbDDh72Edjw@mail.gmail.com>


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



On 2020/3/1 下午2:11, 4e868df3 wrote:
> It's possible a pacman upgrade triggered this BTRFS event. I don't
> know what was previously installed. Here is what is installed now.
> 
> $ btrfs version
> btrfs-progs v5.4

Then it's a bug in btrfs-progs. I need to find sometime to reproduce the
problem and fix it.

`btrfs fi df` output may help in this case.


For now, I only have possible workaround, that is to delete the
offending files which contains the csum.

You can try the following command to locate the offending files:

# btrfs ins logical 68761178112 -s 45056 <mnt>

And delete related files and hopes kernel find its way to delete the
offending csums.

Thanks,
Qu
> 
> On Sat, Feb 29, 2020 at 5:41 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> 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 11:40 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
2020-03-01  6:11           ` 4e868df3
2020-03-01 11:40             ` Qu Wenruo [this message]
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=df40a18a-4a28-f3b7-dfff-8ccade905d32@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.