SUSE also famously uses btrfs on the root file system.
Don't ever let it fill up!
Don't ever let it fill up!
SUSE takes snapshots before packages are installed. The package manager cannot tell if the disk will fill up as a result because on Btrfs the `df` command lies.
If its Btrfs root fills up and the OS writes to it, it 100% will self-destruct, and the `btrfs-repair` tool (`fsck` replacement) cannot fix drives and usually makes the corruption worse and renders the drive unreadable.
This is why in the earlier thread about swapfiles...
https://news.ycombinator.com/item?id=49618087
... I advised 2 commenters not to recommend keeping the OS and data in a single big volume. I got downvoted for it. I was rude. Well, I was, but I stand by my comments even though I'm sorry for my tone when I made them.
A pragmatic fix would trigger read-only failure mode at 90% usage of the mount as a whole, with all subvolumes.
And you know what, that's a great idea.
I have a loopback mount on an fallocate file with a btrfs filesystem inside of it at work. I'm using send/receive to make sure there is hope of recovery.
I wrote this several years ago.
https://www.linuxjournal.com/content/btrfs-centos-living-loo...