btrfs fails to load qgroups from disk with error -2 (out of memory)

English Install/Boot/Login
1

I ran out of space in my OpenSUSE partition, which uses btrfs. I booted from a live Ubuntu USB to reallocate some of the space from my Windows partition to the Linux one. It succeeded in shrinking the Windows partition, but when it tried to move/resize the Linux partition, btrfs check failed with the following error:


root@ubuntu:~# btrfs check /dev/nvme0n1p5
Opening filesystem to check...
Checking filesystem on /dev/nvme0n1p5
UUID: 6afe1f98-2fc5-4dd7-a22f-0b9e2f514a71
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
cache and super generation don't match, space cache will be invalidated
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups
ERROR: out of memory
ERROR: Loading qgroups from disk: -2
ERROR: failed to check quota groups
found 65546706944 bytes used, error(s) found
total csum bytes: 59958768
total tree bytes: 1668497408
total fs tree bytes: 1538752512
total extent tree bytes: 53886976
btree space waste bytes: 264382931
file data blocks allocated: 321153744896
 referenced 97287462912
extent buffer leak: start 300026445824 len 16384
extent buffer leak: start 300063735808 len 16384

If I ask it to check quota groups specifically, I get:


root@ubuntu:~# btrfs check -Q /dev/nvme0n1p5
Opening filesystem to check...
Checking filesystem on /dev/nvme0n1p5
UUID: 6afe1f98-2fc5-4dd7-a22f-0b9e2f514a71
Print quota groups for /dev/nvme0n1p5
UUID: 6afe1f98-2fc5-4dd7-a22f-0b9e2f514a71
ERROR: out of memory
ERROR: Loading qgroups from disk: -2
extent buffer leak: start 300026445824 len 16384
extent buffer leak: start 300063735808 len 16384

I have already tried rebalancing (which required adding another device and then removing it because of the lack of free space), btrfs check --repair, and btrfs check --init-extent-tree, but nothing has changed.

After rebalancing I had just enough free space to delete some Docker images and free up space, but now I still only have about 5GB free to work with.

The only relevant thing I have been able to find online is Bug 183471 - BTRFS progs Unfixable btrfs qgroups with out of memory message, but there are no further comments on that bug report from 2016.

I am not 100% opposed to reinstalling OpenSUSE, but I would rather not have to if this is fixable. Any advice is appreciated.

I also posted this on Stack Exchange (Super User).](https://superuser.com/questions/1710200/btrfs-fails-to-load-qgroups-from-disk-with-error-2-out-of-memory)

2

Try with current btrfs-progs (e.g. booting Tumbleweed or compiling from sources). Try with “btrfs check --mode=lowmem” although it is known to lack some features comparable with --mode=original.

3

(Posting from my personal account. Earlier my password manager filled in my work account and I didn’t notice until it was too late.)

I booted from the latest Tumbleweed live ISO with btrfs-progs v5.16.1.

Thank you for that suggestion, I saw lowmem in the command help last night but somehow didn’t think to use it. Unfortunately, btrfs check (both with/without --mode=lowmem and with/without repair, I tried all four combinations) had the same error as before.

The weird thing is that the system boots and works just fine (as far as I can tell), the only problem is that gparted won’t let me move/resize the partition because btrfs check reports an error.

I don’t fully understand the error beyond “some metdata in my filesystem is corrupted” but if I’m reinstalling anyway and no longer care about the integrity of the partition, I’m curious to see if replacing btrfs check with a no-op would make gparted happy and let it continue, or if it will perform the actual resize operation using btrfs-progs as well.

If there’s no further troubleshooting to do, I might do that and report back for the benefit anyone finding this thread in the future. (Which will probably be me in 5-10 years when I somehow break this again!)

4

Are you using snapshots? First thing I’d try is make space deleting all old, not needed snapshots.
Edit:
Ah, and welcome to this forum, both of you, BTW.

5

I can’t believe it. It was that simple.

I deleted all the Docker subvolumes (wish it would do that when I delete the containers/volumes but that’s an open ticket), ran another balance, and it moved all 65 blocks.

I ran check again and it didn’t have the error this time. Rebooted into the live USB and tried move/resize again and now gparted is happily moving it as I type this.

I thought 5GB free would be enough to resolve any space-related issues, but maybe not? Or by deleting the Docker subvolumes I either a) removed a corrupted block that was causing it to allocate too much memory when checking the filesystem or b) reduced the number of something it had to allocate from over the threshold to under.

Either way,** for future readers: the solution that worked for me was to delete Docker subvolumes and rebalance.
**
Now gparted has finished and I booted back into OpenSUSE to make sure it didn’t break anything and it appears to be working just fine.

Thanks for the help guys :slight_smile:

6

Hi
Ahhh docker, that’s why I split out that and others to there own xfs partitions as I noticed the same thing on the previous Tumbleweed install.

1 Like
7

It lies.

ERROR: Loading qgroups from disk: -2

-2 == ENOENT. Code prints “out of memory” for any error returned during loading of qgroup information. Apparently there was some incorrect information in btrfs metadata. You should really have reported it to btrfs list so developers could request more diagnostic to improve btrfs check, but it is probably too late now.