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 03:55:39PM -0700, Marc MERLIN wrote:
> On Wed, Apr 15, 2026 at 03:36:29PM -0700, Boris Burkov wrote:
> > On Wed, Apr 15, 2026 at 01:22:42PM -0700, Marc MERLIN wrote:
> > > On Wed, Apr 15, 2026 at 11:44:27AM -0700, Boris Burkov wrote:
> > > > 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
> > > 
> > > 1.2G    /tmp/tree2.txt
> > > 65M     /tmp/tree2.txt.xz
> > > do you want it?
> > 
> > Yes, please!
>  
> https://marc.merlins.org/tmp/tree2.txt.xz
> please tell me when I can delete.
> 
> > > > btrfs inspect-internal dump-tree -t 8 /dev/tst/lol
> > > 
> > > btrfs-progs v6.14
> > > total bytes 4074040004608
> > > bytes used 2417457491968
> > > uuid 49741c78-3949-4d7d-b77a-160ce071dee0
> > > merlin:/mnt/btrfs_pool3# 
> > 
> > So no output? That is surprising. Did you already disable quotas on this
> > filesystem?
>  
> Ah, sorry, yes. First rule of sysadmining: after an unexplained crash:
> revert the last thing(s) you did.  2 crashes in 3 days on systems that
> were stable for years right after I turned on simple quotas and block-group-tree
> could not be a coincidence.

I am 99% sure this is a squotas bug now. I am able to reproduce friends
of your issue like:

  create subvol
  enable squota (usage is 0)
  delete subvol qgroup (allowed, usage is 0)
  add an extent to subvol (BOOM)

and also

  enable squota
  create subvol (usage = 0 until delayed refs run)
  destroy subvol qgroup (usage 0)
  sync (actually create usage, happens to swallow enoent)
  delete subvol
  sync (BOOM)

I haven't reproduced one yet that hits on subvol cleanup / extent
deletion without manually deleting a qgroup, but it is probably possible
as well. Did you happen to do any manual subvol qgroup deletion at any
point?

I think some variant of only logging that enoent will greatly harden
things and when we are deleting it really should not matter.

I also think "btrfstune --remove-simple-quota" may fix your fs. It will
have to do work in O(extents), and might fail in its fake mount, though.

In terms of a check option, I think I can try to detect that we
have a owner_ref item for a missing subvol and then nuke it. Working on
that next.

Thanks,
Boris

> Thankfully the laptop FS was not put into an unusable state and I was
> able to get it back online quickly. As soon as I did, turned quotas off.
> 
> Since then I have upgraded the laptop to 6.19.11 and turned squotas back
> on on that single filesystem.
> 
> Sorry if I removed evidence that could have helped. It's still on
> moremagic, the rPi, since I could never remount read/write and turn off
> quotas. Obviously I can do dump trees on it (please provide exact
> commands you'd like so I don't mess them up)
> I think there is also a way to backup the entire filesystem structure,
> mangle the filenames, and omit the data to alllow a copy that is much
> smaller and restore in a VM with spare blocks to emulate the FS without
> needing 22TB
> 
> Let me know if either helps
> 
> 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