On 2019/12/30 下午2:07, Patrick Erley wrote:
> On Sun, Dec 29, 2019 at 9:58 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> On 2019/12/30 下午1:50, Patrick Erley wrote:
>>> On Sun, Dec 29, 2019 at 9:47 PM Patrick Erley <pat-lkml@erley.org> wrote:
>>>>
>>>> On Sun, Dec 29, 2019 at 9:43 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 2019/12/30 下午1:36, Patrick Erley wrote:
>>>>>> (ugh, just realized gmail does top replies.  Sorry... will try to
>>>>>> figure out how to make gsuite behave like a sane mail client before my
>>>>>> next reply):
>>>>>>
>>>>>> here's btrfs check /dev/nvme0n1p2 (sda3, which is a mirror of it, has
>>>>>> exactly the same output)
>>>>>>
>>>>>> [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)
>>>>>> [6/7] checking root refs
>>>>>> [7/7] checking quota groups skipped (not enabled on this FS)
>>>>>> Opening filesystem to check...
>>>>>> Checking filesystem on /dev/nvme0n1p2
>>>>>> UUID: 815266d6-a8b9-4f63-a593-02fde178263f
>>>>>> found 89383137280 bytes used, no error found
>>>>>> total csum bytes: 85617340
>>>>>> total tree bytes: 1670774784
>>>>>> total fs tree bytes: 1451180032
>>>>>> total extent tree bytes: 107905024
>>>>>> btree space waste bytes: 413362851
>>>>>> file data blocks allocated: 90769887232
>>>>>>  referenced 88836960256
>>>>>
>>>>> It looks too good to be true, is the btrfs-progs v5.4? IIRC in v5.4 we
>>>>> should report inodes generation problems.
>>>>
>>>> Hurray Bottom Reply?
>>>>
>>>> /usr/src/initramfs/bin $ ./btrfs.static --version
>>>> btrfs-progs v5.4
>>
>> This is strange.
>>
>>
>> 6084adam|thinkpad|~$ btrfs check --mode=lowmem test.img
>> Opening filesystem to check...
>> Checking filesystem on test.img
>> UUID: c6c6ddd2-01c1-47fc-b699-cacfae9d4bfd
>> [1/7] checking root items
>> [2/7] checking extents
>> [3/7] checking free space cache
>> cache and super generation don't match, space cache will be invalidated
>> [4/7] checking fs roots
>> ERROR: invalid inode generation for ino 257, have 8858344568388091671
>> expect [0, 9)
>> ERROR: errors found in fs roots
>> found 131072 bytes used, error(s) found
>> total csum bytes: 0
>> total tree bytes: 131072
>> total fs tree bytes: 32768
>> total extent tree bytes: 16384
>> btree space waste bytes: 123409
>> file data blocks allocated: 0
>>  referenced 0
>> 6085adam|thinkpad|~$ btrfs --version
>> btrfs-progs v5.4
>>
>> As expected, v5.4 should detect such problem without problem.
>>
>> Would you please provide extra tree dump to help us to determine what
>> makes btrfs check unable to detect such problems?
>>
>> # btrfs ins dump-tree -b 303629811712 /dev/dm-1
> anvil ~ # btrfs ins dump-tree -b 303629811712 /dev/nvme0n1p2
> btrfs-progs v5.4
> Invalid mapping for 303629811712-303629815808, got 476092633088-477166374912
> Couldn't map the block 303629811712
> Couldn't map the block 303629811712
> bad tree block 303629811712, bytenr mismatch, want=303629811712, have=0
> ERROR: failed to read tree block 303629811712
> 
The bytenr is different from your initial report.

Anyway, you can try mount with v5.4, and use the bytenr from the dmesg.

Then please provide both dmeg (including the "corrupted leaf" line), and
the `btrfs ins dump-tree -b` output.

Thanks,
Qu