Re: btrfs check: root errors 400, nbytes wrong

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

On 2023/8/27 09:12, Cebtenzzre wrote:
> On Thu, 2023-08-24 at 13:40 +0800, Qu Wenruo wrote:
>> But it's mostly fine, a btrfs check --repair should be safe if and
>> only if those are the only errors.
>
> I ran btrfs check --repair, and it gave me a warning:
>
> Starting repair.
> Opening filesystem to check...
> Checking filesystem on /dev/nvme0n1p2
> UUID: 76721faa-8c32-4e70-8a9e-859dece0aec1
> [1/7] checking root items
> Fixed 0 roots.
> [2/7] checking extents
> No device size related problem found
> [3/7] checking free space cache
> cache and super generation don't match, space cache will be invalidated
> [4/7] checking fs roots
> reset nbytes for ino 123827824 root 258
> reset nbytes for ino 123827824 root 15685
> reset nbytes for ino 123827824 root 15760
> reset nbytes for ino 123827824 root 15786
> reset nbytes for ino 123827824 root 15814
> reset nbytes for ino 123827824 root 15822
> reset nbytes for ino 123827824 root 15826
> reset nbytes for ino 123827824 root 15830
> reset nbytes for ino 123827824 root 15834
> reset nbytes for ino 123827824 root 15838
> reset nbytes for ino 123827824 root 15842
> warning line 3916
> [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)
> found 2405445431302 bytes used, no error found

Despite the warning line, everything looks fine.

To be extra safe, you can run "btrfs check --readonly" to make sure the
repaired fs is completely fine.

> total csum bytes: 1891078208
> total tree bytes: 13012697088
> total fs tree bytes: 9898934272
> total extent tree bytes: 836861952
> btree space waste bytes: 2043135264
> file data blocks allocated: 25854472876032
>   referenced 2618226024448
>
> This is btrfs-progs v6.3.3. It looks like that would be line 3916 of
> check/main.c:
>
> if (!cache_tree_empty(&wc.shared))
> 	fprintf(stderr, "warning line %d\n", __LINE__);

I believe this is some corner cases we didn't take into consideration.

The original mode uses an internal cache to handle shared subvolume tree
blocks, I guess there is some thing related to the repair that confused
the old walk control cache.

But as long as the next "btrfs check --readonly" reports no error, you
should be fine to go.

Thanks,
Qu
>
> Is this anything I should be concerned about?
>
> Thanks,
> Cebtenzzre
>>