Re: Simple quota unsafe? RIP: 0010:__btrfs_free_extent.isra.0+0xc41/0x1020 [btrfs] / do_free_extent_accounting:2999: errno=-2 No such entry

[Marc MERLIN <marc_btrfs@merlins.org>]

On Tue, Apr 21, 2026 at 07:26:27PM -0700, Boris Burkov wrote:
> I believe I have reproduced the balance bug, and in my reproducer, the
> fact that the subvolume predated squota was critical.
> 
> reproducer sketch:
> - create subvol
> - write stuff
> - snapshot subvol
> - enable squota (usage = 0)
> - delete subvol (leave snapshot)
> - run a data balance that hits an extent in the snapshot (owned by subvol)
> - balance double counts extents in squotas (valid interpretation) but
>   critically, creates a new tree block with the old dead owner but a
>   fresh generation.
> - run_delayed_refs happens now, say from a commit running (important race),
>   writing that dangerous tree block to disk (in the reloc root)
> - we do the pointer swapping and drop the reloc root. the nodes of the
>   reloc tree are of this bogus form and cause your abort
> - I believe the snapshot also has some bogus leaves and would abort
>   later, too.
 
That does sound like my situation, yes.

> So the thing that is definitely dangerous, as far as I can tell, is
> running balance on a filesystem where squotas was enabled after any
> subvolume owning a shared extent (snapshot or reflink) was deleted.

so that's also good news where if I enable squota on a new FS at
creation time, that's supposed to be safe.
It would also explain why no one saw this bug since squota is only very
marginally useful when enabled way later on a filesytem which has seen a
lot of use.

> Now that I am at least clear on the more sophisticated bugs we have, I
> think that I am ready to put in some fixes and some defense in depth. I
> was feeling sheepish about just wallpapering over it without explaining
> your actual bug. So I think you should wait for that, to be safe with
> your big FS, even if it happens to not *need* the fixes.
 
I appreciate that, while I don't know the btrfs code, as a sysdadmin I
do not want to paper over anything without understanding the root cause
and applying a wrong or incomplete fix, so thank you.

> FYI
> I believe that when btrfs mounts a filesystem with qgroup trees present
> it will enable quotas, so you don't need to manually enable them if it
> was created with squotas.
 
It now looks like it, because I didn't find good documentation at the
time I tried to turn them on, I didn't know it could be done clearly at
mkfs.btrfs creation time.

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