ref mismatch / root not found in extent tree / backpointer mismatch / owner ref check failed

ref mismatch / root not found in extent tree / backpointer mismatch / owner ref check failed

[Dave T]

The filesystem has become very, very slow. smartctl doesn't show any
problems with the HDD. My usual btrfs maintenance (balance, scrub,
defrag) did not show any problems -- but did not resolve the slowness.
So I ran a btrfs check -- the result is pasted below. What causes this
and is there any solution other than recreating the file system? Would
the errors shown below make a btrfs filesystem slow?

Opening filesystem to check...
Checking filesystem on /dev/mapper/bak_luks
UUID: 3ac770bc-e7c4-4792-2d2d-1d3ed19d126b
[1/7] checking root items
[2/7] checking extents
ref mismatch on [374849568768 16384] extent item 0, found 1
tree backref 374849568768 parent 6835 root 6835 not found in extent tree
backpointer mismatch on [374849568768 16384]
owner ref check failed [374849568768 16384]
ref mismatch on [374940549120 16384] extent item 0, found 1
tree backref 374940549120 parent 6835 root 6835 not found in extent tree
backpointer mismatch on [374940549120 16384]
owner ref check failed [374940549120 16384]
ref mismatch on [569319473152 16384] extent item 0, found 1
tree backref 569319473152 parent 6835 root 6835 not found in extent tree
backpointer mismatch on [569319473152 16384]
ref mismatch on [569329385472 16384] extent item 0, found 1
tree backref 569329385472 parent 6835 root 6835 not found in extent tree
backpointer mismatch on [569329385472 16384]
ref mismatch on [569516376064 16384] extent item 0, found 1
tree backref 569516376064 parent 6835 root 6835 not found in extent tree
backpointer mismatch on [569516376064 16384]
ref mismatch on [570749665280 16384] extent item 0, found 1
tree backref 570749665280 parent 6835 root 6835 not found in extent tree
backpointer mismatch on [570749665280 16384]
ERROR: errors found in extent allocation tree or chunk allocation
[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)
found 3655790232414 bytes used, error(s) found
total csum bytes: 3534402188
total tree bytes: 46277705728
total fs tree bytes: 34533392384
total extent tree bytes: 7925743616
btree space waste bytes: 8021706864
file data blocks allocated: 30545889550336
 referenced 31161532510208

Re: ref mismatch / root not found in extent tree / backpointer mismatch / owner ref check failed

[Chris Murphy]

On Fri, May 3, 2019 at 6:22 PM Dave T <davestechshop@gmail.com> wrote:
>
> The filesystem has become very, very slow. smartctl doesn't show any
> problems with the HDD. My usual btrfs maintenance (balance, scrub,
> defrag) did not show any problems -- but did not resolve the slowness.
> So I ran a btrfs check -- the result is pasted below. What causes this
> and is there any solution other than recreating the file system? Would
> the errors shown below make a btrfs filesystem slow?

Slow reads? Slow writes? What's the workload?

What kernel version? And what scheduler? e.g.

[root@flap ~]# cat /sys/block/nvme0n1/queue/scheduler
[none] mq-deadline
[root@flap ~]#



>
> Opening filesystem to check...
> Checking filesystem on /dev/mapper/bak_luks
> UUID: 3ac770bc-e7c4-4792-2d2d-1d3ed19d126b
> [1/7] checking root items
> [2/7] checking extents
> ref mismatch on [374849568768 16384] extent item 0, found 1
> tree backref 374849568768 parent 6835 root 6835 not found in extent tree
> backpointer mismatch on [374849568768 16384]
> owner ref check failed [374849568768 16384]
> ref mismatch on [374940549120 16384] extent item 0, found 1
> tree backref 374940549120 parent 6835 root 6835 not found in extent tree
> backpointer mismatch on [374940549120 16384]
> owner ref check failed [374940549120 16384]
> ref mismatch on [569319473152 16384] extent item 0, found 1
> tree backref 569319473152 parent 6835 root 6835 not found in extent tree
> backpointer mismatch on [569319473152 16384]
> ref mismatch on [569329385472 16384] extent item 0, found 1
> tree backref 569329385472 parent 6835 root 6835 not found in extent tree
> backpointer mismatch on [569329385472 16384]
> ref mismatch on [569516376064 16384] extent item 0, found 1
> tree backref 569516376064 parent 6835 root 6835 not found in extent tree
> backpointer mismatch on [569516376064 16384]
> ref mismatch on [570749665280 16384] extent item 0, found 1
> tree backref 570749665280 parent 6835 root 6835 not found in extent tree
> backpointer mismatch on [570749665280 16384]
> ERROR: errors found in extent allocation tree or chunk allocation
> [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)
> found 3655790232414 bytes used, error(s) found
> total csum bytes: 3534402188
> total tree bytes: 46277705728
> total fs tree bytes: 34533392384
> total extent tree bytes: 7925743616
> btree space waste bytes: 8021706864
> file data blocks allocated: 30545889550336
>  referenced 31161532510208


Hopefully a developer has an idea how serious it is and whether it's
safe to try to use --repair. In the meantime, I strongly advice
ensuring your backups are up to date while you wait for a reply.
Extent tree problems can be serious.

Also, what do you get for:

# btrfs dev stats <dev or mountpoint>

If unmounted use device node, if mounted use the mountpoint.



-- 
Chris Murphy