btrfs check: root errors 400, nbytes wrong

btrfs check: root errors 400, nbytes wrong

[Cebtenzzre]

I am getting these errors from btrfs-progs v6.3.3 on Linux 6.4.7.

Can I safely run `btrfs check --repair`?

root 258 inode 123827824 errors 400, nbytes wrong
root 15685 inode 123827824 errors 400, nbytes wrong
root 15752 inode 123827824 errors 400, nbytes wrong
root 15760 inode 123827824 errors 400, nbytes wrong
root 15768 inode 123827824 errors 400, nbytes wrong
root 15772 inode 123827824 errors 400, nbytes wrong
root 15786 inode 123827824 errors 400, nbytes wrong
root 15798 inode 123827824 errors 400, nbytes wrong
root 15814 inode 123827824 errors 400, nbytes wrong
root 15818 inode 123827824 errors 400, nbytes wrong
ERROR: errors found in fs roots

Thanks,
Cebtenzzre

Re: btrfs check: root errors 400, nbytes wrong

[Qu Wenruo]

On 2023/8/24 08:38, Cebtenzzre wrote:
> I am getting these errors from btrfs-progs v6.3.3 on Linux 6.4.7.
>
> Can I safely run `btrfs check --repair`?
>
> root 258 inode 123827824 errors 400, nbytes wrong

Just to be extra safe, you may want to run "btrfs check --mode=lowmem"
to get a more human readable output.

But it's mostly fine, a btrfs check --repair should be safe if and only
if those are the only errors.

Thanks,
Qu
> root 15685 inode 123827824 errors 400, nbytes wrong
> root 15752 inode 123827824 errors 400, nbytes wrong
> root 15760 inode 123827824 errors 400, nbytes wrong
> root 15768 inode 123827824 errors 400, nbytes wrong
> root 15772 inode 123827824 errors 400, nbytes wrong
> root 15786 inode 123827824 errors 400, nbytes wrong
> root 15798 inode 123827824 errors 400, nbytes wrong
> root 15814 inode 123827824 errors 400, nbytes wrong
> root 15818 inode 123827824 errors 400, nbytes wrong
> ERROR: errors found in fs roots
>
> Thanks,
> Cebtenzzre

Re: btrfs check: root errors 400, nbytes wrong

[Cebtenzzre]

On Thu, 2023-08-24 at 19:32 -0400, Cebtenzzre wrote:
> On Thu, 2023-08-24 at 13:40 +0800, Qu Wenruo wrote:
> > 
> > 
> > On 2023/8/24 08:38, Cebtenzzre wrote:
> > > I am getting these errors from btrfs-progs v6.3.3 on Linux 6.4.7.
> > > 
> > > Can I safely run `btrfs check --repair`?
> > > 
> > > root 258 inode 123827824 errors 400, nbytes wrong
> > 
> > Just to be extra safe, you may want to run "btrfs check --
> > mode=lowmem"
> > to get a more human readable output.
> 
> Here is the log with --mode=lowmem:
> 
> Opening filesystem to check...
> Checking filesystem on /dev/nvme0n1p2
> UUID: 76721faa-8c32-4e70-8a9e-859dece0aec1
> [1/7] checking root items
> [2/7] checking extents
> [3/7] checking free space cache
> [4/7] checking fs roots
> ERROR: root 258 INODE[123827824] nbytes 1777664 not equal to
> extent_size 1757184
> ERROR: root 259 EXTENT_DATA[1522634 4096] gap exists, expected:
> EXTENT_DATA[1522634 128]
> ERROR: root 259 EXTENT_DATA[1522636 4096] gap exists, expected:
> EXTENT_DATA[1522636 128]
> ERROR: root 407 EXTENT_DATA[398831 4096] gap exists, expected:
> EXTENT_DATA[398831 25]
> ERROR: root 407 EXTENT_DATA[398973 4096] gap exists, expected:
> EXTENT_DATA[398973 25]
> ERROR: root 407 EXTENT_DATA[398975 4096] gap exists, expected:
> EXTENT_DATA[398975 25]
> ERROR: root 407 EXTENT_DATA[398976 4096] gap exists, expected:
> EXTENT_DATA[398976 25]
> ERROR: root 407 EXTENT_DATA[418307 4096] gap exists, expected:
> EXTENT_DATA[418307 25]
> ERROR: root 407 EXTENT_DATA[418316 4096] gap exists, expected:
> EXTENT_DATA[418316 25]
> ERROR: root 407 EXTENT_DATA[418317 4096] gap exists, expected:
> EXTENT_DATA[418317 25]
> ERROR: root 407 EXTENT_DATA[420660 4096] gap exists, expected:
> EXTENT_DATA[420660 25]
> ERROR: root 407 EXTENT_DATA[420673 4096] gap exists, expected:
> EXTENT_DATA[420673 25]
> ERROR: root 407 EXTENT_DATA[439382 4096] gap exists, expected:
> EXTENT_DATA[439382 25]
> ERROR: root 407 EXTENT_DATA[439383 4096] gap exists, expected:
> EXTENT_DATA[439383 25]
> ERROR: root 407 EXTENT_DATA[451252 4096] gap exists, expected:
> EXTENT_DATA[451252 25]
> ERROR: root 407 EXTENT_DATA[451264 4096] gap exists, expected:
> EXTENT_DATA[451264 25]
> ERROR: root 407 EXTENT_DATA[451265 4096] gap exists, expected:
> EXTENT_DATA[451265 25]
> ERROR: root 407 EXTENT_DATA[452326 4096] gap exists, expected:
> EXTENT_DATA[452326 25]
> ERROR: root 407 EXTENT_DATA[452332 4096] gap exists, expected:
> EXTENT_DATA[452332 25]
> ERROR: root 407 EXTENT_DATA[452339 4096] gap exists, expected:
> EXTENT_DATA[452339 25]
> ERROR: root 407 EXTENT_DATA[4293157 4096] gap exists, expected:
> EXTENT_DATA[4293157 25]
> ERROR: root 407 EXTENT_DATA[4293570 4096] gap exists, expected:
> EXTENT_DATA[4293570 25]
> ERROR: root 407 EXTENT_DATA[4293571 4096] gap exists, expected:
> EXTENT_DATA[4293571 25]
> ERROR: root 407 EXTENT_DATA[4293572 4096] gap exists, expected:
> EXTENT_DATA[4293572 25]
> ERROR: root 407 EXTENT_DATA[4302136 4096] gap exists, expected:
> EXTENT_DATA[4302136 25]
> ERROR: root 407 EXTENT_DATA[4302148 4096] gap exists, expected:
> EXTENT_DATA[4302148 25]
> ERROR: root 407 EXTENT_DATA[4302149 4096] gap exists, expected:
> EXTENT_DATA[4302149 25]
> ERROR: root 407 EXTENT_DATA[4302150 4096] gap exists, expected:
> EXTENT_DATA[4302150 25]
> ERROR: root 407 EXTENT_DATA[5970391 4096] gap exists, expected:
> EXTENT_DATA[5970391 25]
> ERROR: root 15685 INODE[123827824] nbytes 1777664 not equal to
> extent_size 1757184
> ERROR: errors found in fs roots
> found 2324685996032 bytes used, error(s) found
> total csum bytes: 1812599528
> total tree bytes: 12918194176
> total fs tree bytes: 9882157056
> total extent tree bytes: 836272128
> btree space waste bytes: 2041051573
> file data blocks allocated: 25781547192320
>  referenced 2545608298496
> 
> Does it look okay?

Whoops, I forgot to CC the list.

> 
> > But it's mostly fine, a btrfs check --repair should be safe if and
> > only
> > if those are the only errors.
> > 
> > Thanks,
> > Qu
> > > root 15685 inode 123827824 errors 400, nbytes wrong
> > > root 15752 inode 123827824 errors 400, nbytes wrong
> > > root 15760 inode 123827824 errors 400, nbytes wrong
> > > root 15768 inode 123827824 errors 400, nbytes wrong
> > > root 15772 inode 123827824 errors 400, nbytes wrong
> > > root 15786 inode 123827824 errors 400, nbytes wrong
> > > root 15798 inode 123827824 errors 400, nbytes wrong
> > > root 15814 inode 123827824 errors 400, nbytes wrong
> > > root 15818 inode 123827824 errors 400, nbytes wrong
> > > ERROR: errors found in fs roots
> > > 
> > > Thanks,
> > > Cebtenzzre

Re: btrfs check: root errors 400, nbytes wrong

[Cebtenzzre]

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
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__);

Is this anything I should be concerned about?

Thanks,
Cebtenzzre
> 

Re: btrfs check: root errors 400, nbytes wrong

[Qu Wenruo]

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
>>