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@xxxxxxx> 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:
signature.asc
Description: OpenPGP digital signature
