Someone brought up the issue of running out of space on btrfs and not being able to delete stuff. There are posts about this from years ago, but I wanted to see if it's still a problem.

The answer is... kind of, if you try hard enough and do absolutely unhinged things. I had to create a snapshot of a tiny (4GB) but full (data + metadata) filesystem with hundreds of thousands of files (with data, with xattrs, and empty to fill everything up) and then delete files without deleting the snapshot, retrying when I got an error and sync()ing the filesystem every time. At one point I managed to make the FS go read-only, and then remounting again and trying more torture in parallel shells eventually got it wedged into a state where it couldn't mount R/W at all (cannot do orphan cleanup due to -ENOSPC).

Even then, the FS was still mountable R/O (so all the data was recoverable). And even then, I found a way out: although you can't add a device to a FS that isn't mounted R/W, you can expand the base device with btrfs filesystem resize --offline, and you can use dm to glue two devices together temporarily for this purpose. I was able to mount R/W then, delete stuff the "proper" way (snapshots first), shrink again, and completely fix the situation.

So yeah, I don't think this is really a problem any more, more specific bugs notwithstanding. You have to try really really hard to cause the issue and even then there's still a way out.

@lina archlinuxcn community encountered this about a year ago. One of the leaders lilydjwg blogged this event and followups on both her blog at blog.lilydjwg.me and the archcn(maybe) wiki. The symptom was full disk with too large commit that didn't fit in global reserve.
@commdserv I wonder what triggers commits that large... there must be some kind of pathological setup for that.
@lina https://blog.lilydjwg.me/2023/7/6/a-btrfs-incident.216658.html
Bees dedup ate up all metadata space, and no space for new block group. Deleting snapshot also used up global reserve, so the commit stuck... and forced ro
btrfs 翻车记 - 依云's Blog

btrfs 翻车记- 如标题所言,我用了多年的 btrfs,终于还是遇到翻车啦。由于文件系统翻车了,相关日志内容缺失,所以本文我仅凭记忆描述事件,就不提供准确的日志输出了。 事件经过 出事的是 archlinuxcn 的编译机。那天中午时分我就收到了 Grafana 给我发送的莫名其妙的报警邮件,称某个监控项无数据了。我去面板上瞅了半天,明明有数据的啊。不解,但是忙别的事情去了,也没有细究。...

@commdserv Ah ok, so there was a third party dedup tool and lots of snapshots involved. That makes sense.

What I was mostly trying to get at is that "oh no my FS filled up and exploded" isn't really a thing any more for normal use cases. But if you have frequent automated snapshot creation/deletion, lots of snapshots, and tooling that does unconventional things with btrfs on top, then yeah, I could see it hitting corner cases...

@lina @commdserv It's not like the need to balance out partly-filled blocks when one does a lot of snapshot creation & deletion is unknown.

I'd consider it a bug there wasn't a frequent (at least daily) check by Bees.

@lispi314 In this case bees the dedup tool was doing an initial dedup with lots of snapshots and tight space left... Maybe just got used too hard😇
auto bg reclaim can help, but at that time it was off by default. Don't know if it's default on now.

@commdserv I honestly forgot bg_reclaim_threshold even exists.

Though even then unless it ensures the option is present on the mount, then it should check anyway (as would've been necessary until fairly recently, 5.19 isn't that old).

@commdserv @lispi314 This is documented in the bees docs as a difficult situation yeah (best enable the dedup tool before snapshots).

I'm not sure exactly what autoreclaim does, but in my test I did fill up the whole disk with data (256MB metadata alloc), caused a full condition of both, then freed some data, and metadata grew to 512MB, so it seems space can be automatically reallocated from data to metadata now

@lina @commdserv Autoreclaim, the new feature, takes note of how much of your storage is allocated vs how much is actually used, and if that goes below a certain threshold it balances & reclaims blocks so you don't get a huge amount of barely used metadata & data blocks.

It's a result of the work on SMR drive support (as those further compound the problem).