Arch Linux

trinsdar

Member

Registered: 2022-05-11

Posts: 3

[SOLVED] btrfs check fails on root partition

Recently I decided I wanted to upgade my laptop's ssd to a bigger drive, so I used gparted to copy over the root partition (which is a btrfs drive containing @, @home, @cache, @log, and @root subvolumes. Also thought it had snapshot subvolumes, but apparently not), but gparted failed the btrfs check step. then because I was curious I ran that same btrfs check command on the original root partition and got the same error:

Opening filesystem to check...
Checking filesystem on /dev/nvme0n1p4
UUID: 009bbf01-7844-4a83-b6f7-125f20bce718
[1/8] checking log skipped (none written)
[2/8] checking root items
[3/8] checking extents
[4/8] checking free space tree
We have a space info key for a block group that doesn't exist
[5/8] checking fs roots
[6/8] checking only csums items (without verifying data)
[7/8] checking root refs
[8/8] checking quota groups skipped (not enabled on this FS)
found 93370728448 bytes used, error(s) found
total csum bytes: 89425572
total tree bytes: 1183399936
total fs tree bytes: 1004044288
total extent tree bytes: 71237632
btree space waste bytes: 198916382
file data blocks allocated: 673275850752
 referenced 122493935616

could it possibly be because that partition was originally at the end of the drive after the windows partition but I moved it in front?
also is this even worth trying to fix or should I just reinstall on the new drive?

Last edited by trinsdar (2025-12-08 22:22:05)

oe1tkt

Member

Registered: 2016-01-27

Posts: 1

Re: [SOLVED] btrfs check fails on root partition

I don't think so. To resolve the inconsistency, the recommended approach is to run a scrub, which can often fix such issues without data loss. The command to start a scrub is `sudo btrfs scrub start -Bd /mountpoint`, where /mountpoint should be replaced with the actual mount point of the affected filesystem. I like to use the program "Btrfs Assistant" to do so.
If a scrub does not resolve the problem, the btrfs check --repair command can be used, but it carries a higher risk of data loss and should be used with caution, especially on critical data.
In some cases, the issue may be related to the filesystem's allocation strategy, such as having a high number of partially filled block groups, which can lead to space allocation failures even when free space exists. For such scenarios, balancing operations like `btrfs balance start -dlimit=1 /` can help reclaim space by relocating data and freeing up block groups.

trinsdar

Member

Registered: 2022-05-11

Posts: 3

Re: [SOLVED] btrfs check fails on root partition

I don't think so. To resolve the inconsistency, the recommended approach is to run a scrub, which can often fix such issues without data loss. The command to start a scrub is `sudo btrfs scrub start -Bd /mountpoint`, where /mountpoint should be replaced with the actual mount point of the affected filesystem. I like to use the program "Btrfs Assistant" to do so.
If a scrub does not resolve the problem, the btrfs check --repair command can be used, but it carries a higher risk of data loss and should be used with caution, especially on critical data.
In some cases, the issue may be related to the filesystem's allocation strategy, such as having a high number of partially filled block groups, which can lead to space allocation failures even when free space exists. For such scenarios, balancing operations like `btrfs balance start -dlimit=1 /` can help reclaim space by relocating data and freeing up block groups.

So then there isn't any major issue with the data itself? If that's the case then i would prefer just to properly copy the data to the new drive, just not sure what the proper method would be. I did try the scrub command, it didn't seem to find anything and i still got the same error after. I haven't tried balancing yet just cause I would rather not add extra wear to the old drive if i'm just going to copy the data to the new drive anyways.

topcat01

Member

Registered: 2019-09-17

Posts: 263

Re: [SOLVED] btrfs check fails on root partition

Is

[4/8] checking free space tree
We have a space info key for a block group that doesn't exist

the only error. If so, this is a known, benign issue and can be ignored. See https://www.spinics.net/lists/linux-btr … 60026.html.

BTW, I wouldn't move the partition using an external tool like that (although it is technically fine to do so). Instead, I would create a new fs on the destination, and btrfs send the subvolumes to the new filesystem. This is particularly easy on btrfs. This will also make btrfs read the entire fs and detect any data errors, unlike a brute force/blind partition copy.

trinsdar

Member

Registered: 2022-05-11

Posts: 3

Re: [SOLVED] btrfs check fails on root partition

Ok good to know. Btrfs send worked really well, with no errors.

debo

Member

Registered: 2019-06-06

Posts: 27

Re: [SOLVED] btrfs check fails on root partition

I have seen this a few times before. You can clear the cache with:

btrfs rescue clear-space-cache <v1|v2> <device>

You can mount the filesystem read only, then use mount to see whether your filesystem uses v1 or v2. All of the file systems I have seen this on have used v2. Unmount the filesystem again before you use btrfs rescue.

debo

Member

Registered: 2019-06-06

Posts: 27

Re: [SOLVED] btrfs check fails on root partition

Also, note that the above will clear and remove the space cache. If you later want to use a space cache (v2 in this case), mount the filesystem with:

mount -o space_cache=v2 <device> <mountpoint>

ETA:

Note that this will create a space cache, and if you later mount the filesystem, you do not need to use the mount option again, it will just use the cache.

Last edited by debo (2025-12-09 00:53:38)