I had tried btrfs some years ago, and my disk went into thrashing mode. I gave up and went to EXT4. Now I tried it again, on my wife’s laptop 
It seemed to work okay for quite some time, but now she is getting out of disk space messages. It looked like quite a few snapper entries. I am just having a hard time finding much about this. I know I can delete them, but don’t want to have to keep doing that. There should be a way to limit snapshots to not run out of disk space. I can’t remember what the size of the partition was, but at least 50GB, maybe 100GB.
Have a look at the configuration files in /etc/snapper/configs - the settings in those files control how long the snapshots stay around and how the automatic cleanup works. The default file for the root configuration is well-commented.
Show the output of this, for a start … be sure to show the command and output and then the final prompt:
(use the Preformatted Text tool)
:> sudo btrfs filesystem usage -T /
Not sure if you are using Gnome or not, but apparently that misreports disk usage under BTRFS, so often those messages are nothing to worry about. Admins may know more about this & be able to confirm or do a search for more info. . The command in the previous post will should also help to show the real picture.
I found a couple of settings in /etc/snapper/configs/root that probably should be adjusted.
# fraction of the filesystems space the snapshots may use
SPACE_LIMIT="0.5"
# fraction of the filesystems space that should be free
FREE_LIMIT="0.2"
But not sure what they should be. Looks like the free limit should give about 61*.2 = 12 GB free?
> sudo btrfs filesystem usage -T /
[sudo] password for root:
Overall:
Device size: 61.00GiB
Device allocated: 61.00GiB
Device unallocated: 1.00MiB
Device missing: 0.00B
Device slack: 0.00B
Used: 59.43GiB
Free (estimated): 371.24MiB (min: 371.24MiB)
Free (statfs, df): 371.24MiB
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 133.84MiB (used: 0.00B)
Multiple profiles: no
Data Metadata System
Id Path single DUP DUP Unallocated Total Slack
-- --------- -------- -------- -------- ----------- -------- -----
1 /dev/sda5 54.98GiB 6.00GiB 16.00MiB 1.00MiB 61.00GiB -
-- --------- -------- -------- -------- ----------- -------- -----
Total 54.98GiB 3.00GiB 8.00MiB 1.00MiB 61.00GiB 0.00B
Used 54.62GiB 2.41GiB 16.00KiB
Whoa!!! I’m shocked ya’ll haven’t experienced any erratic behavior (or as you wrote: thrashing mode) with your wife’s laptop.
I’d highly recommend doing a “clean-up” (BTRFS, etc) to clear up some disk space. I would also suggest checking “where” all the disk space consumption is happening.
It could be some hidden “excessive caching” with applications[1]. And of course, configuration for BTRFS filesystem.
I have a thread out here from quite a while ago , when I experienced the same issue. I’ll search for it to see the various commands I executed to clean it up … it did work and was able to ‘recover’ the system.
.
[1] Interesting side note about “excessive hidden caching of apps”, in my search to find where large files exist in my home directory.
I use the Chrome browser - I discovered that it creates a subsystem named, “OptGuideOnDeviceModel” and stores OVER 4 gigabyte of disk space in your home directory!!! I disabled that feature, so instantly recovered the disk space.
Not sure if you have already installed filelight or are still able to install it but this is a great way to get fast insight on where space is used:
Filelight shows wrong calculations for BTRFS. You can google it. And there are even threads here.
Your screenshot is a good example…/home and / are 0 B?
/root is empty as I did run it as normal user and /home is empty as it is on another disk.
Yes, BTRFS is a pain on disk usage but AFAIK filelight generally work, it treats them like regular directories.
There are BTRFS-specific quirks like compression, deduplication, or shared extents, so sizes may not reflect actual disk usage but as long as you take the numbers not as absolute the relative sizes will be still semi-accurate.
Okay, I found my old thread. But my situation was a bit more “catastrophic”. The link to the orig thread is the last one in this Reply. (geez I was wordy).
Basically, my system at the time was locked up (read-only), running Tumbleweed (now with Leap).
This basically sums it up … what I did:
(basically, these command can be used to clean up a BTRFS system, even if you’re no locked up )
==== quote
I am HAPPY to report that I ran the steps, one by one, found in here
“repair broken btrfs” link
https://en.opensuse.org/SDB:BTRFS#How_to_repair_a_broken/unmountable_btrfs_filesystem
.
I also toggled to this webpage to compare the steps (SLES documentation):
“How to recover from BTRFS errors” link
https://www.suse.com/support/kb/doc/?id=000018769
==== end quote
My long-time-ago thread:
.
I did filelight, thought it was running on the /home directory, added an exclude, and still going past 61GB! I finally just let run and it came up with 900 some GB for .snapshots. That seemed wrong, but maybe it expanded the (what I would call the deltas)?
Two days ago, you showed the output of “btrfs”, which MORE ACCURATELY shows device size and space usage:
It was already mentioned to NOT RELY on Filelight.
( Folks should not recommend the use of Filelight to openSUSE users with BTRFS filesystems ).
So now, you’re showing that Filelight is reporting an almost one terabyte storage device, when it’s size is really 61 gigabyte ?!?!?!?!? Yes, it’s rwong 
I provided a link to documentation (previously), which I recommend reading the section, " Disk Space Full Because of Snapper" … and obviously, check the other sections 
https://en.opensuse.org/SDB:BTRFS#How_to_repair_a_broken/unmountable_btrfs_filesystem
Well, I was asked to find out where the space was. Didn’t figure accuracy was important as long as it showed the most space.
And I have no reason to think the system is broken. I did see the full portion, but it referred to a zram which I do not understand what it’s purpose is, and looked like a good way to mess things up if I don’t know what I’m doing.
sudo zramctl /dev/zram0 --algorithm zstd --size "$(($(grep -Po 'MemTotal:\s*\K\d+' /proc/meminfo)/2))KiB"
I mean, that’s too much without explanation of why. Yes, “to use as temporary, memory backed storage for our full btrfs filesystem”, but why? And if it’s a temporary backup and I do something wrong, will it destroy the main system?
And after creating the zram device, there didn’t seem any reference for using it. Of course, I don’t understand it.
But that section was for deleting certain snapshots. And in Yast, there’s something about snapper and also in partition that lists snapshots and give a delete option. But having to manually go in every so often before it fills and delete some is what I wanted to get away from. The FREE_LIMIT=“0.2”. Why doesn’t that work to give 20% free space?
There’s so many strange and odd btrfs commands I came across, but one was to see what things would automatically run, and the system showed one was for cleanup.
Without knowing what else to do so it automatically takes care of things, I went into Yast and snapshots, deleted a few of the earlier ones, and got 15GB of free space. This will buy me time until I can update her computer to 16.0. And will probably never try btrfs again.
I would recommend against not using btrfs, better to understand it. It is particularly helpful for rolling back updates if you have issues (more important on TW than Leap, but still useful on Leap, too).
It’s just important to ensure you’ve allocated enough space to the partition at installation time to account for snapshots.
Likewise if it is filling up, then likely the maintenance routines to cleanup are not running… they run monthly… There should only be 10 pre/post kept as well…
I suspect when you move to Leap 16.0 it will keep btrfs stuff clean.
I did a systemctl list-timers and it showed a snapper timeline and cleanup timer ran a few minutes ago. But I think there was more than 10 snapshots when I was manually deleting some.
How much space does one need for the snapshots?
It just seems like btrfs is like a whole new programming language you have to learn just to keep your file system functioning and not a lot of information that I can find on how to do it.
@dt30 It should only keep 10… This is a Leap 16.0 system installed mid March;
snapper list
# │ Type │ Pre # │ Date │ User │ Used Space │ Cleanup │ Description │ Userdata
────┼────────┼───────┼─────────────────────────────────┼──────┼────────────┼─────────┼───────────────────────┼──────────────
0 │ single │ │ │ root │ │ │ current │
1* │ single │ │ Tue 17 Mar 2026 10:34:09 AM CDT │ root │ 139.13 MiB │ │ first root filesystem │
22 │ pre │ │ Tue 17 Mar 2026 11:29:11 AM CDT │ root │ 705.20 MiB │ number │ zypp(zypper) │ important=yes
23 │ post │ 22 │ Tue 17 Mar 2026 11:32:18 AM CDT │ root │ 1.16 GiB │ number │ │ important=yes
40 │ pre │ │ Mon 06 Apr 2026 07:32:08 AM CDT │ root │ 23.38 MiB │ number │ zypp(zypper) │ important=yes
41 │ post │ 40 │ Mon 06 Apr 2026 07:33:51 AM CDT │ root │ 94.11 MiB │ number │ │ important=yes
42 │ pre │ │ Sat 11 Apr 2026 09:31:17 AM CDT │ root │ 8.88 MiB │ number │ zypp(zypper) │ important=yes
43 │ post │ 42 │ Sat 11 Apr 2026 09:32:06 AM CDT │ root │ 28.61 MiB │ number │ │ important=yes
50 │ pre │ │ Tue 21 Apr 2026 11:44:57 AM CDT │ root │ 26.40 MiB │ number │ zypp(zypper) │ important=yes
51 │ post │ 50 │ Tue 21 Apr 2026 11:47:17 AM CDT │ root │ 117.66 MiB │ number │ │ important=yes
52 │ pre │ │ Thu 23 Apr 2026 09:33:46 PM CDT │ root │ 9.53 MiB │ number │ zypp(zypper) │ important=no
53 │ post │ 52 │ Thu 23 Apr 2026 09:34:44 PM CDT │ root │ 50.05 MiB │ number │ │ important=no
54 │ pre │ │ Sat 02 May 2026 08:40:17 PM CDT │ root │ 9.34 MiB │ number │ zypp(zypper) │ important=yes
55 │ post │ 54 │ Sat 02 May 2026 08:42:11 PM CDT │ root │ 73.38 MiB │ number │ │ important=yes
56 │ pre │ │ Wed 06 May 2026 04:11:20 PM CDT │ root │ 3.53 MiB │ number │ zypp(zypper) │ important=no
57 │ post │ 56 │ Wed 06 May 2026 04:11:38 PM CDT │ root │ 4.01 MiB │ number │ │ important=no
58 │ pre │ │ Wed 06 May 2026 04:16:42 PM CDT │ root │ 2.00 MiB │ number │ zypp(zypper) │ important=no
59 │ post │ 58 │ Wed 06 May 2026 04:16:57 PM CDT │ root │ 22.77 MiB │ number │ │ important=no
60 │ pre │ │ Wed 06 May 2026 04:23:13 PM CDT │ root │ 336.00 KiB │ number │ zypp(zypper) │ important=no
61 │ post │ 60 │ Wed 06 May 2026 04:23:27 PM CDT │ root │ 4.36 MiB │ number │ │ important=no
btrfs fi usage /
Overall:
Device size: 699.85GiB
Device allocated: 25.07GiB
Device unallocated: 674.78GiB
Device missing: 0.00B
Device slack: 0.00B
Used: 21.29GiB
Free (estimated): 678.08GiB (min: 340.69GiB)
Free (statfs, df): 678.08GiB
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 47.66MiB (used: 0.00B)
Multiple profiles: no
Data,single: Size:23.01GiB, Used:19.71GiB (85.65%)
/dev/nvme0n1p5 23.01GiB
Metadata,DUP: Size:1.00GiB, Used:812.86MiB (79.38%)
/dev/nvme0n1p5 2.00GiB
System,DUP: Size:32.00MiB, Used:16.00KiB (0.05%)
/dev/nvme0n1p5 64.00MiB
Unallocated:
/dev/nvme0n1p5 674.78GiB