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

[Boris Burkov <boris@bur.io>]

On Wed, Apr 22, 2026 at 01:11:00PM -0700, Marc MERLIN wrote:
> On Wed, Apr 22, 2026 at 12:38:53PM -0700, Boris Burkov wrote:
> > 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.
>  
> Gotcha.
> 
> > 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
> 
> Gotcha too. When my copy is finally finished, I will run a check and
> report back.
> 
> > 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
> 
> I got that part.
> What I was saying is some out of band way that would be slow and long,
> but only run rarely, to fix things that drifted.
> 
> You mentioned btrfs check, maybe a check --repair option to regenerate
> squotas on an existing filesystem (also awesome if you add squotas later
> and want them to be correct). For extra points, it would be awesome if
> it were while the filesystem remains online, even if that run takes
> days (since it would be a one time run after converting to squota, or a
> very occasional "fix things up to be all clean and accounted for")

My proposal for repair was to clean up clearly broken states like
scrubbing off the owner_refs for missing subvols (basically
conditionally do what the btrfstune did when you notice leaked
extents)

> 
> Is that possible at all? (separately from being worth your time, which
> I'd understand). The biggest plus I see is allowing many people to
> switch to squotas on existing FS without having to wipe and start over
> just to benefit from squota.

I think the tricky part is deciding who should own data blocks. It is,
in my opinion, impossible to arrive at a given FS and properly account
each data block to its originating subvol, with the same result as "as
if you turned on squotas at the start". I think necessary information
would be gone by now in even relatively simple cases involving reflinks.

You could pick arbitrarily, or you could try to make educated guesses
based on the owner of the enclosing metadata tree blocks and their
generations or something, but I think fundamentally it would be a lossy
process.

Perhaps we could add an ioctl that was something like "assign extent E
(or maybe file F's extents) to subvol S" and then userspace could assign
how they want. Or maybe even something subvol oriented like "squota
account subvol S" which would mean "S takes ownership of all unowned
extents reachable by S". And you could iterate your subvols in the order
you wanted. I like those ideas more than the kernel making fundamentally
arbitrary picks.

Ultimately, I would still be sort of worried about the resultant weird
state where you could have a shared metadata block owned by S1 and
shared with S2 (so S2 is a snapshot of S1 and the data must be from S1)
but then the data is accounted to S2. Nothing would freak out about this
now, I don't think, but it's sort of sloppy.

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