On Fri, May 3, 2019 at 6:22 PM Dave T <davestechs...@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
