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

[Dominique Martinet <asmadeus@codewreck.org>]

Hi Qu,

Qu Wenruo wrote on Wed, Nov 19, 2025 at 09:59:55AM +1030:
>>> We have a space info key for a block group that doesn't exist
>>
>> So even without clearing the cache as you've proposed below, it
>> couldn't have caused any post or future corruption, right?!
> 
> Yep. Allocation is always happening based on a block group, such
> orphan space info/bitmap keys won't cause the allocator to use it
> anyway.
> 
> So no corruption or whatever.

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)

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?


(Alternatively since we're not copying at the block level I guess there's
no real need for this check in the first place, as any real corruption
would cause IO error, and I could just forget about this... The check
was just ported e2fsck from back when the fs was ext4...)

Thanks,
-- 
Dominique Martinet | Asmadeus