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@gmx.com> 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@gmail.com> 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@gmx.com> 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!
>>>>>>
>>>>>
>>