Sorry I don't have an answer but I like the title.

Your btrfs snapshots are possibly counted separately by all the regular tools. They simply go into every directory they can find and add up the size of the files they see. They do not care if they are looking at an identical snapshot of the folder next to them, they simply add it all up.

Use sudo btrfs filesystem show (and maybe add a path behind it, I am not sure). That will give you the true usage.

From the btrfs page on the archwiki

General linux userspace tools such as df(1) will inaccurately report free space on a Btrfs partition. It is recommended to use btrfs filesystem usage to query Btrfs partitions.

I confess I'm a big fan of the post title

This is a common thing one needs to do. Not all linux gui tools are perfect, and some calculate number differently (1000 vs 1024 soon mounts up to big differences). Also, if you're running as a user, you're not going to be seeing all the files.

Here's how I do it as a sysadmin:

As root, run:

du /* -shc |sort -h

"disk usage for all files in root, displaying a summary instead of listing all sub-files, and human-readable numbers, with a total. Then sort the results so that the largest are at the bottom"

Takes a while (many minutes, up to hours or days if you've slow disks, many files or remote filesystems) to run on most systems and there's no output until it finishes because it's piping to sort. You can speed it up by omitting the "|sort -h" bit, and you'll get summaries when each top level dir is checked, but you won't have a nice sorted output.

You'll probably get some permission errors when it goes through /proc or /dev

You can be more targetted by picking some of the common places, like /var - here's mine from a debian system, takes a couple of seconds. I'll often start with /var as it's a common place for systems to start filling up along with /home.

root@scrofula:~# du /var/* -shc |sort -h
0       /var/lock
0       /var/run
4.0K    /var/local
4.0K    /var/mail
4.0K    /var/opt
168K    /var/tmp
4.1M    /var/spool
5.5M    /var/backups
781M    /var/log
787M    /var/cache
8.3G    /var/www
36G     /var/lib
46G     total

Here we can see /var/lib has a lot of stuff in it, so we can look into that with du /var/lib/* -shc|sort -h - it turns out mine has some big databases in /var/lib/mysql and a bunch of docker stuff in /var/lib/docker, not surprising.

Sometimes you just won't be able to tally what you're seeing with what you're using. Often that might be due to a locked file having been deleted or truncated, but the lock's still preventing the OS from seeing the recovered space. That generally sorts itself out with various timeouts, but you can try and find it with lsof, or if the machine isn't doing much, a quick reboot.

It could be that hardlinked files are being double-counted. What software manages that snapshot folder?

Well, maybe you just have a non-measurable set as filesystem 😅

If you're using compression, try compsize.

Look at this:

https://gitlab.com/TheEvilSkeleton/flatpak-dedup-checker

I think that has some BTRFS stuff in it to display actual size with deduplication

BTRFS support in Filelight/kio is pretty important.

compsize will give you an honest overview of what's going on with btrfs.

when summing up totals, docker containers and snaps are likely counted twice in some programs: they have volume files that are counted once and then those are mounted as file systems and their contents can be counted again in the mount point.

Just a heads up: I've noticed that Steam tends to require a bunch of spare space beyond the size the game takes up.

Use df and du