Re: Critical error from Tree-checker

[Qu Wenruo <wqu@suse.com>]

在 2024/9/12 19:27, Archange 写道:
> Le 12/09/2024 à 12:25, Qu Wenruo a écrit :
>> 在 2024/9/12 17:51, Archange 写道:
>>> Le 12/09/2024 à 02:34, Qu Wenruo a écrit :
>>>> 在 2024/9/12 07:35, Archange 写道:
>>>>>
>>>>> Le 12/09/2024 à 01:23, Qu Wenruo a écrit :
>>>> [...]
>>>>>
>>>>> While the previous one (see my second message in this thread) had no
>>>>> error, there is now one:
>>>>>
>>>>> # btrfs check /dev/mapper/rootext
>>>>> Opening filesystem to check...
>>>>> Checking filesystem on /dev/mapper/rootext
>>>>> UUID: e6614f01-6f56-4776-8b0a-c260089c35e7
>>>>> [1/7] checking root items
>>>>> [2/7] checking extents
>>>>> [3/7] checking free space cache
>>>>> wanted bytes 688128, found 720896 for off 676326604800
>>>>> cache appears valid but isn't 676326604800
>>>>
>>>> Minor problem, still I'd recommend to run
>>>>  `btrfs rescue clear-space-cache v1 <dev>` to clear the v1 cache first.
>>>
>>> I indeed did that as explained in the second part of my message.
>>>
>>>> Then you can mount with v2 space cache or keep going with the v1 cache
>>>> (not recommended, will be deprecated soon)
>>>
>>> Done too.
>>>
>>>> And if your fs only have subvolumes 5 (the top level one), 257 and 258,
>>>> then you're totally fine to continue.
>>>> I guess that's the case?
>>>
>>> Indeed!
>>
>> Just in case, you can run "btrfs check --mode=lowmem" to check if there
>> is no more inode cache left.
>>
>> If there is any left, lowmem mode can detect it with errors like:
>>
>> ERROR: root 5 INODE[18446744073709551604] nlink(1) not equal to
>> inode_refs(0)
>> ERROR: invalid imode mode bits: 00
>> ERROR: invalid inode generation 18446744073709551604 or transid 1 for
>> ino 18446744073709551605, expect [0, 72)
>> ERROR: root 5 INODE[18446744073709551605] is orphan item
>>
>> And I'm already adding the ability to the original mode check to detect
>> such problem.
> 
> No such thing appeared during the lowmem check. Only the
> 
> [3/7] checking free space tree
> there is no free space entry for 0-65536
> cache appears valid but isn't 0

Then it's totally fine.

For the 0-65536 problem, mind to provide the following dump?

# btrfs ins dump-tree -t fst <device>

I'm afraid since the fs is somewhat old, there may be some corner case 
btrfs-check is not handling properly.

Thanks,
Qu

> 
> is still there.
> 
> Archange
> 
>