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

> 
> Dumb question, did I need to do that while booting a post 5.1 kernel?
> I ran these while not having the filesystem mounted, but against
> kernel 5.1.  I can easily repeat against 5.4.

Kernel version doesn't affect at all. All the detection and repair
should be able to be done by btrfs-progs.

But it would be better to use v5.4 to quick verify the fix is working.

Thanks,
Qu