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

[Marc MERLIN <marc_btrfs@merlins.org>]

On Thu, Apr 23, 2026 at 12:28:31PM -0700, Boris Burkov wrote:
> 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)

Ack.

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

In the case of blocks that are owned by multiple subvols, no need to be
fancy, it's fine to just assign them to the subvol with the lower number
and be done with it.
The main idea being to clean up unowned blocks and the state I just
reported (see end of this mail), which I can reproduce pretty much at
will (start btrfs receive, let it run, have bees run at the same time,
kill btrfs receive, delete subvoll, and up with unowned blocks forever).

> 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.
 
This doesn't need to be perfect, nor can you guess who to assign if
there are multiple others, just pick the lowest id one, and that's fine.

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

That is even btter if it's not too much work and you don't mind that.

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

So let me give my outside view and opinion :)
s in squotas stands both for simple and sloppy :)
When I took them, I accepted that in the name of performance. 
"good enough" that I can live with performance wise, 1000x beats
"perfect but I can't deal with the performance hit"

I already accepted that accounting won't be perfect and it's not true
reality with shared blocks, never mind snapshots of snapshots, but even
more so with bees. I'm ok with that.
I just want to know that this 10 million file subvol is around 7.2TB
without spending hours and hours running a du -sh on it.
And let's be honest, even with du -sh, shared blocks can be an issue, so
really it's not really worse.

But I do want to fix this is very very vexing to see forever unless I
wipe the filesystem and start over:

Qgroupid    Referenced    Exclusive   Path 
--------    ----------    ---------   ---- 
0/5            4.78GiB      4.78GiB   <toplevel>
0/256         16.00KiB     16.00KiB   backup
0/258         16.00KiB     16.00KiB   backup-btrfssend
0/260          1.06GiB      1.06GiB   .beeshome
0/261         63.74GiB     63.74GiB   backup/win_kodi_ro.20260328_21:48:59
0/262        229.51GiB    229.51GiB   backup/ubuntu_kodi_ro.20260328_10:19:47
0/263        297.04MiB    297.04MiB   <squota space holder>   <-- be gone
0/264        187.38GiB    187.38GiB   backup/0Notmachines_kodi_ro.20260325_20:08:49
0/266         10.37GiB     10.37GiB   backup/1Appliances_kodi_ro.20260325_23:22:32
0/268        294.27GiB    294.27GiB   backup/debian32_kodi_ro.20260325_23:43:06
0/269        287.84MiB    287.84MiB   <squota space holder>a <-- be gone too ;)

I think it's pretty obvious where to assign them, it's the other
subvolume that didn't get deleted, and if there are 4 that these blocks
are shared against, any of the 4 will do, I truly don't care :)

hope that makes sense.

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