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

[Boris Burkov <boris@bur.io>]

On Wed, Apr 15, 2026 at 10:59:44AM -0700, Marc MERLIN wrote:
> On Wed, Apr 15, 2026 at 10:05:10AM -0700, Boris Burkov wrote:
> > 1258303029248 is the logical address we were freeing so its backrefs in
> > the extent tree will be interesting. As will whatever subvol tree it is
> > in, as will the qgroup tree entry for that subvolid. If you can share a
> > full dump then I can find all that myself.
>  
> Note that I fixed the laptop, thankfully didn't have to rebuild this
> filesystem.  
> 
> Sorry, not very good with the debug tools. Was that the right command?
> merlin:/mnt/btrfs_pool3# btrfs inspect-internal dump-tree -t 1258303029248 /dev/mapper/pool3
> btrfs-progs v6.14
> total bytes 4074040004608
> bytes used 2415294197760
> uuid 49741c78-3949-4d7d-b77a-160ce071dee0
> merlin:/mnt/btrfs_pool3#
> 
> 

For a giant fs where we don't want to dump all the metadata or it would
be difficult to share the resulting gigabytes of text, I would still get
quite a bit of benefit from:

btrfs inspect-internal dump-tree -t 2 /dev/tst/lol
and
btrfs inspect-internal dump-tree -t 8 /dev/tst/lol

which will dump the extent trees and quota trees respectively. The other
useful thing is to find the extent in question in the extent tree and
see which subvols refer to it via the backrefs and dump those trees. But
that is relatively less important. If the extent tree dumps way too
much, then doing a grep -C 50 for 15506102321152 would likely be enough
to show us the relevant backrefs.

> > ditto for the logical address that broke on the rpi, but if that is a
> > gigantic fs, maybe doing the dump will be pretty unwieldy..
> 
> That's the bigger one indeed, still waiting read only until I'm told I
> can wipe it, or should wait for debug data request. It's been too long
> already and I had spare drives, so I started a full restore on a new
> set of drives and will swap them in for the current one I can't mount
> read/write but can keep it around for debugging / potential future 
> check --repair patch

If there is no rush to wipe it, then let's keep it around until I rule
out whether a repair patch makes sense? Sorry if I misunderstood the
state. If there *is* a rush to wipe it, then let's confirm we got what
we needed out of tree dumping first, if possible.

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