Re: [PATCH] btrfs: tree-checker: dump the page status if hit something wrong

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2024/2/7 08:18, Tavian Barnes wrote:
> On Tue, Feb 6, 2024 at 3:40 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>> On 2024/2/7 06:42, Tavian Barnes wrote:
>>> On Tue, 6 Feb 2024 16:24:32 +1030, Qu Wenruo wrote:
>>>> Maybe it's missing some fixes not yet in upstream?
>>>> My current guess is related to my commit 09e6cef19c9f ("btrfs: refactor
>>>> alloc_extent_buffer() to allocate-then-attach method"), but since I can
>>>> not reproduce it, it's only a guess...
>>>
>>> That's possible!  I tried to follow the existing code in
>>> alloc_extent_buffer() but didn't see any obvious races.  I will try again
>>> with the for-next tree and report back.
>>
>> The most obvious way to proof is, if you can reproduce it really
>> reliably, then just go back to that commit and verify (it can still
>> cause the problem).
>> Then go one commit before for, and verify it doesn't cause the problem
>> anymore.
>
> I just tried the tip of btrfs/for-next (6a1dc34172e0, "btrfs: move
> transaction abort to the error site btrfs_rebuild_free_space_tree()"),
> plus the dump_page() patch, and it still reproduces:
>
>      BTRFS critical (device dm-2): inode mode mismatch with dir: inode
> mode=0142721 btrfs type=6 dir type=1
>      page:000000004209c922 refcount:4 mapcount:0
> mapping:000000007cadbbf5 index:0x8379d17c pfn:0x13ca315
>      memcg:ffff8f2cba7d0000
>      aops:btree_aops [btrfs] ino:1
>      flags: 0x12ffff180000820c(referenced|uptodate|workingset|private|node=2|zone=2|lastcpupid=0xffff)
>      page_type: 0xffffffff()
>      raw: 12ffff180000820c 0000000000000000 dead000000000122 ffff8f1d446218a0
>      raw: 000000008379d17c ffff8f2faa26ea50 00000004ffffffff ffff8f2cba7d0000
>      page dumped because: eb page dump
>      BTRFS critical (device dm-2): corrupted leaf, root=518
> block=9034951802880 owner mismatch, have 15999665770497355816 expect
> [256, 18446744073709551360]
>
> Is it still worth trying that specific commit?  I'm guessing not.

Yes, still worthy.

The btrfs/for-next contains that commit (which is already upstreamed).
That patch itself has some bugs fixed early (before hitting upstream),
but since it's touching the whole memory management of tree blocks, it
is still the best possible culprit.

>
>> Although without a way to reproduce locally, it's really hard to say or
>> debug from my end.
>
> I can try to make a VM image reproducer if that would help.

That would help a lot.
Although the main part I guess is just the content/size of the target
fs, and transferring tens of gigabytes over internet would never be a
good experience AFAIK.

Thanks,
Qu

>
>> Thanks,
>> Qu
>