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

[Marc MERLIN <marc_btrfs@merlins.org>]

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?

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?)

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