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
>>>
>>