Re: Deleted snapshots stay in squota, mayube because of bees?

[Boris Burkov <boris@bur.io>]

On Wed, Apr 22, 2026 at 12:30:56PM -0700, Marc MERLIN wrote:
> On Wed, Apr 22, 2026 at 12:23:44PM -0700, Boris Burkov wrote:
> > > Is that still working as intended and I don't quite grasp how?
> > 
> > We can't delete a qgroup that still has usage, and subvols own their
> > extents forever. So assuming no bugs, this means that some other
> > subvolume is referencing the extents originally owned by these
> > subvolumes. I agree that this sounds relatively unlikely for a failed
> > receive target you immediately deleted.
>  
> Right, especially a read only snapshot (btrfs receive), which I 1000%
> know I did not re-snapshot again or re-share/re-use in any way.
> The only culprit I can find is bees whose job is indeed to link blocks
> across subvolumes.
> So maybe the way bees works, it make squota think the new subvolume
> is the main owner and when that that is deleted, it doesn't know (as
> per documentation) to re-assign those blocks to the older subvolume
> those blocks were shared with after bees linked them.
> 
> > I believe that btrfs check has the ability to reconcile the on-disk
> > squota owner_refs with the on-disk qgroup values and find any real
> > discrepancies. So if you run that (without repair please :) ), and it
> > doesn't complain, I think you do have some legit sharing happening, and
> > you can try to track that down more directly.
> 
> Assuming bees/beesd is to blame (the only reasonable culprit I can find,
> but then again it's doing its job), are you saying btrfs check can do
> a one time pass and re-assign block quotas to the remainin volume so
> they are not "lost" for squota?

No, I'm saying that there are two explanations for your observations:
1. You have legitimate shared extents owned by the deleted snapshot.
   Presumably caused by bees as you guess.
2. A squotas bug where we have usage recorded for your qgroup but no
   matching extent in the extent tree.

btrfs check will walk the extent tree and add up the extent usage based
on the squota owner refs and compare that to the value stored on the
qgroup. The squotas invariant is that those are equal. If it complains,
that means there is an extent attributed to a subvolume that isn't in
the qgroup number or there is some usage in the qgroup number that
doesn't have an appropriately tagged extent. The system is inconsistent.

That is all check will look for. If it complains about squotas on those
subvols, then you have hit the buggy case 2. If it doesn't, I would
strongly suspect case 1. At that point we would have to use different
tools to track down the shared extent, as squotas does not help with
that, really.

> 
> Also, I understand the whole point of squota is not to take the huge
> amount of resources regular quota does, but is there a way (now, or
> planned) to do an expensive and occasional "re-assign/re-align" blocks 
> to where they belong when squota lost track due to how it works? Is that
> the btrfs check you're referring to? (but then again btrfs check is read
> only, is it not?)

As currently designed, squotas is quite dogmatic about never re-owning
an extent from the original creator. That is the core design conceit and
simplification that allows it to be fast. There are likely narrow cases
where we could do efficient or on-demand re-owning but nothing like that
is currently planned. This would primarily serve the case where an
extent gets shared but the original owner is removed. In general, that
case is most accurately handled by traditional qgroups, but that can
cause performance problems on some workloads.

> 
> Thanks,
> Marc
> -- 
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
>  
> Home page: http://marc.merlins.org/                       | PGP 7F55D5F27AAF9D08