Re: We have a space info key for a block group that doesn't exist

[Dominique Martinet <asmadeus@codewreck.org>]

Qu Wenruo wrote on Tue, Feb 03, 2026 at 06:17:14PM +1030:
> > We're running rountine btrfsck before copying the filesystem for cloning
> > in one of our tools, and I'm starting to get user reports of errors due
> > to this error (we run an ancient 5.10 kernel but there hadn't been any
> > such report, and now we just got two in a couple of weeks so something
> > must have been backported to the stable tree...)
> > 
> > Anyway, I agree with your answer that it's safe to ignore, but it's not
> > obvious for users to decide that, so I'd like to address this somehow.
> > 
> > If it's really harmless, could it be printed as info message but not
> > change the btrfsck return code? (e.g. if that's the only error, return
> > success)
> 
> I think it's possible to change it to a warning, not an error, but we are
> going to have proper automatic kernel in v6.20 kernel.
> 
> With that said, at least for us developers a proper error will help us more,
> and prevent further similar problems.
> 
> Trading between end users complains and future proof, I still prefer to keep
> it as an error for now.

Fair enough, I understand.

> > If you think it's worth keeping as an error, would you (or someone else)
> > happen to have any idea where I should start looking?
> 
> In v6.20 kernel, the first RW mount of the fs will automatically fix the
> problem.
> 
> The patch is here:
> 
> https://lore.kernel.org/linux-btrfs/f58857f1ac741bd1fb4fa2e7ec56ed87815bb1f5.1766198159.git.wqu@suse.com/

Oh!
I only searched for the btrfsck error message so this didn't come up,
sorry.
That's great, thank you.


> And it's already in our for-next branch, heading towards v6.20 kernel.
> 
> I will backport that fix to older LTS kernels (6.6 and 6.12 planned) so that
> even older kernel users will get their fs fixed properly.

Thanks.. Unfortunately that part of the code changed greatly in 5.11
(btrfs_start_pre_rw_mount didn't even exist back in 5.10), so I'll just
give up on that one -- I just don't think it's worth the effort for our
old kernel.

However your commit message explains why we didn't see it before (it's
limited to a range of "bad" btrfs-progs version), and we've already
upgraded to btrfs-progs-6.17 so hopefully will stop seeing it as soon as
people move away from the "bad" 6.14 version that likely caused the
problem (I'll check a bit more on this)

Thank you,
-- 
Dominique Martinet | Asmadeus