Something went wrong: 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(+0x6dd94)[0x55a933af7d94] btrfs(+0x71b94)[0x55a933afbb94] btrfs(btrfs_search_slot+0x11f0)[0x55a933afd6c8] btrfs(btrfs_csum_file_block+0x432)[0x55a933b19d09] btrfs(+0x360b2)[0x55a933ac00b2] btrfs(+0x46a3e)[0x55a933ad0a3e] btrfs(main+0x98)[0x55a933a9fe88] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7f263ed550b3] btrfs(_start+0x2e)[0x55a933a9fa0e] Aborted I just noticed I have btrfs-progs 5.6 installed and 5.6.1 is available. I'll let that try overnight? On Thu, May 7, 2020 at 8:11 PM Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: > > > > On 2020/5/7 下午11:52, Tyler Richmond wrote: > > Thank you for helping. The end result of the scan was: > > > > > > [1/7] checking root items > > [2/7] checking extents > > [3/7] checking free space cache > > [4/7] checking fs roots > > Good news is, your fs is still mostly fine. > > > [5/7] checking only csums items (without verifying data) > > there are no extents for csum range 0-69632 > > csum exists for 0-69632 but there is no extent record > > ... > > ... > > there are no extents for csum range 946692096-946827264 > > csum exists for 946692096-946827264 but there is no extent record > > there are no extents for csum range 946831360-947912704 > > csum exists for 946831360-947912704 but there is no extent record > > ERROR: errors found in csum tree > > Only extent tree is corrupted. > > Normally btrfs check --init-csum-tree should be able to handle it. > > But still, please be sure you're using the latest btrfs-progs to fix it. > > Thanks, > Qu > > > [6/7] checking root refs > > [7/7] checking quota groups skipped (not enabled on this FS) > > found 44157956026368 bytes used, error(s) found > > total csum bytes: 42038602716 > > total tree bytes: 49688616960 > > total fs tree bytes: 1256427520 > > total extent tree bytes: 1709105152 > > btree space waste bytes: 3172727316 > > file data blocks allocated: 261625653436416 > > referenced 47477768499200 > > > > What do I need to do to fix all of this? > > > > On Thu, May 7, 2020 at 1:52 AM Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: > >> > >> > >> > >> On 2020/5/7 下午1:43, Tyler Richmond wrote: > >>> Well, the repair doesn't look terribly successful. > >>> > >>> parent transid verify failed on 218620880703488 wanted 6875841 found 6876224 > >>> parent transid verify failed on 218620880703488 wanted 6875841 found 6876224 > >>> parent transid verify failed on 218620880703488 wanted 6875841 found 6876224 > >>> Ignoring transid failure > >>> ERROR: child eb corrupted: parent bytenr=225049956061184 item=84 > >>> parent level=1 > >>> child level=4 > >> > >> This means there are more problems, not only the hash name mismatch. > >> > >> This means the fs is already corrupted, the name hash is just one > >> unrelated symptom. > >> > >> The only good news is, btrfs-progs abort the transaction, thus no > >> further damage to the fs. > >> > >> Please run a plain btrfs-check to show what's the problem first. > >> > >> Thanks, > >> Qu > >> > >>> parent transid verify failed on 218620880703488 wanted 6875841 found 6876224 > >>> Ignoring transid failure > >>> ERROR: child eb corrupted: parent bytenr=225049956061184 item=84 > >>> parent level=1 > >>> child level=4 > >>> parent transid verify failed on 218620880703488 wanted 6875841 found 6876224 > >>> Ignoring transid failure > >>> ERROR: child eb corrupted: parent bytenr=225049956061184 item=84 > >>> parent level=1 > >>> child level=4 > >>> parent transid verify failed on 218620880703488 wanted 6875841 found 6876224 > >>> Ignoring transid failure > >>> ERROR: child eb corrupted: parent bytenr=225049956061184 item=84 > >>> parent level=1 > >>> child level=4 > >>> parent transid verify failed on 218620880703488 wanted 6875841 found 6876224 > >>> Ignoring transid failure > >>> ERROR: child eb corrupted: parent bytenr=225049956061184 item=84 > >>> parent level=1 > >>> child level=4 > >>> parent transid verify failed on 218620880703488 wanted 6875841 found 6876224 > >>> Ignoring transid failure > >>> ERROR: child eb corrupted: parent bytenr=225049956061184 item=84 > >>> parent level=1 > >>> child level=4 > >>> parent transid verify failed on 218620880703488 wanted 6875841 found 6876224 > >>> Ignoring transid failure > >>> ERROR: child eb corrupted: parent bytenr=225049956061184 item=84 > >>> parent level=1 > >>> child level=4 > >>> parent transid verify failed on 218620880703488 wanted 6875841 found 6876224 > >>> Ignoring transid failure > >>> ERROR: child eb corrupted: parent bytenr=225049956061184 item=84 > >>> parent level=1 > >>> child level=4 > >>> parent transid verify failed on 218620880703488 wanted 6875841 found 6876224 > >>> Ignoring transid failure > >>> ERROR: child eb corrupted: parent bytenr=225049956061184 item=84 > >>> parent level=1 > >>> child level=4 > >>> parent transid verify failed on 218620880703488 wanted 6875841 found 6876224 > >>> Ignoring transid failure > >>> ERROR: child eb corrupted: parent bytenr=225049956061184 item=84 > >>> parent level=1 > >>> child level=4 > >>> parent transid verify failed on 218620880703488 wanted 6875841 found 6876224 > >>> Ignoring transid failure > >>> ERROR: child eb corrupted: parent bytenr=225049956061184 item=84 > >>> parent level=1 > >>> child level=4 > >>> ERROR: failed to zero log tree: -17 > >>> ERROR: attempt to start transaction over already running one > >>> WARNING: reserved space leaked, flag=0x4 bytes_reserved=4096 > >>> extent buffer leak: start 225049066086400 len 4096 > >>> extent buffer leak: start 225049066086400 len 4096 > >>> WARNING: dirty eb leak (aborted trans): start 225049066086400 len 4096 > >>> extent buffer leak: start 225049066094592 len 4096 > >>> extent buffer leak: start 225049066094592 len 4096 > >>> WARNING: dirty eb leak (aborted trans): start 225049066094592 len 4096 > >>> extent buffer leak: start 225049066102784 len 4096 > >>> extent buffer leak: start 225049066102784 len 4096 > >>> WARNING: dirty eb leak (aborted trans): start 225049066102784 len 4096 > >>> extent buffer leak: start 225049066131456 len 4096 > >>> extent buffer leak: start 225049066131456 len 4096 > >>> WARNING: dirty eb leak (aborted trans): start 225049066131456 len 4096 > >>> > >>> What is going on? > >>> > >>> On Wed, May 6, 2020 at 9:30 PM Tyler Richmond <t.d.richmond@xxxxxxxxx> wrote: > >>>> > >>>> Chris, I had used the correct mountpoint in the command. I just edited > >>>> it in the email to be /mountpoint for consistency. > >>>> > >>>> Qu, I'll try the repair. Fingers crossed! > >>>> > >>>> On Wed, May 6, 2020 at 9:13 PM Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: > >>>>> > >>>>> > >>>>> > >>>>> On 2020/5/7 上午5:54, Tyler Richmond wrote: > >>>>>> Hello, > >>>>>> > >>>>>> I looked up this error and it basically says ask a developer to > >>>>>> determine if it's a false error or not. I just started getting some > >>>>>> slow response times, and looked at the dmesg log to find a ton of > >>>>>> these errors. > >>>>>> > >>>>>> [192088.446299] BTRFS critical (device sdh): corrupt leaf: root=5 > >>>>>> block=203510940835840 slot=4 ino=1311670, invalid inode generation: > >>>>>> has 18446744073709551492 expect [0, 6875827] > >>>>>> [192088.449823] BTRFS error (device sdh): block=203510940835840 read > >>>>>> time tree block corruption detected > >>>>>> [192088.459238] BTRFS critical (device sdh): corrupt leaf: root=5 > >>>>>> block=203510940835840 slot=4 ino=1311670, invalid inode generation: > >>>>>> has 18446744073709551492 expect [0, 6875827] > >>>>>> [192088.462773] BTRFS error (device sdh): block=203510940835840 read > >>>>>> time tree block corruption detected > >>>>>> [192088.464711] BTRFS critical (device sdh): corrupt leaf: root=5 > >>>>>> block=203510940835840 slot=4 ino=1311670, invalid inode generation: > >>>>>> has 18446744073709551492 expect [0, 6875827] > >>>>>> [192088.468457] BTRFS error (device sdh): block=203510940835840 read > >>>>>> time tree block corruption detected > >>>>>> > >>>>>> btrfs device stats, however, doesn't show any errors. > >>>>>> > >>>>>> Is there anything I should do about this, or should I just continue > >>>>>> using my array as normal? > >>>>> > >>>>> This is caused by older kernel underflow inode generation. > >>>>> > >>>>> Latest btrfs-progs can fix it, using btrfs check --repair. > >>>>> > >>>>> Or you can go safer, by manually locating the inode using its inode > >>>>> number (1311670), and copy it to some new location using previous > >>>>> working kernel, then delete the old file, copy the new one back to fix it. > >>>>> > >>>>> Thanks, > >>>>> Qu > >>>>> > >>>>>> > >>>>>> Thank you! > >>>>>> > >>>>> > >> >
