Ideas for btrfs roadmap

Btrfs is a great linux filesystem, with many great benefits over other filesystems like:

  • compression
  • snapshots
  • extreme flexibility
  • automatic defragmentation
  • raid features

Especially snapshotting with grub-btrfs and timeshift-autosnap are invaluable for rolling release distro.

However, there are some caveats that currently limit its adoption and prevent it from being the default filesystem:

  • it needs manual balancing in order not to run out of space
  • it is difficult to deal with when it runs out of space
  • system tools report free space wrong
  • btrfs-autosnap does not have error handling and can freeze updates
  • swap needs special considerations
  • advanced btrfs features like raid are out of reach for many regular users
  • setting up btrfs in calamares is both inflexible and not automated
  • nested subvolumes cannot be deleted recursively and there is no good gui to manage subvolumes beside snapshots

These obstacles cause the following dilemma: snapshot feature of btrfs would greatly benefit new users with limited problem solving capabilities, but btrfs itself requires skills that are not easy to achieve for nontechnical users.

So, I propose the following ideas:

  • write a systemd-service to automatically balance the filesystem when needed. The service should also inform the user of itself and block shutdown while running.
    • warn user when disk space is low or there is some other problem
  • write a gui to manage btrfs actions:
    • create subvolumes (optionally with mount point)
    • delete subvolumes (recursively with confirmation)
    • add and remove partitions or devices to btrfs volume
    • set raid level (with explanations)
    • set mount options (with explanations)
    • free up space in emergency by adding a ram device to btrfs volume, balancing it and then removing the ramdevive
    • defragment device
  • add option in calamares to install to btrfs subvolumes just by ticking a box
    • add some default subvolumes for the stuff in /var/log, /var/cache and for swap files
    • if swap is chosen, put the swap file in it's own subvolume and disable cow
    • disable cow for some directories where it can cause issues.
    • if btrfs is chosen, install grub-btrfs and timeshift-autosnap
  • add error handling to timeshift-autosnap

Does anyone else have any good ideas or opinions on the matter?


opensuse has this tools. like snapper.

1 Like

I appreciate forward thinking and see the positives in this but on the flip side it seems like a lot of hassle to introduce as a default file system. File system triage 24/7 in the forum for inexperienced users who will still manage to screw up even with a hand-holding installation approach by tinkering with settings after install? I'd like to use btrfs too but am more tempted by ZOL at the moment.

Either way, for simplicity ext4 should probably remain the default for the foreseeable.

1 Like

While snapper and snapper-gui are nice, they are only snapshot management tools (which could be integrated to the tool I'm proposing). The tool I wrote about would be to fill the gaps left by snapper and timeshift.

I'm not suggesting adopting btrfs as the default filesystem. My goal is simply making it more accessible and viable alternative for inexperienced users.

ZOL has unclear future, so I'm not putting too much ammo on that. Currently the zfs support in manjaro-architect shall suffice. When bcachefs becomes viable, I'll start working on that.

1 Like

My opinion:
btrfs is way to complex and fragile for a default filesystem and for a casual users. btrfs is an option for those who know what they are doing. And only for those. And this is not about missing tools.

While I am typing this I see @Chrysostomus reply saying that

I'm not suggesting adopting btrfs as the default filesystem.

But this is what I was understanding because your opening statement was:

However, there are some caveats that currently limit its adoption and prevent it from being the default filesystem

Anyways, ext4 or xfs are good for default filesystem because they are low maintenance filesystems.


ZFS is what I am using too. Since years. And it is brilliant.

@Chrysostomus is saying:

ZOL has unclear future

This is not correct. The future for ZFS is pretty clear. It will not be added to the kernel tree because of the license situation. It will stay out-of-tree like any other non-GPL modul (e.g. nvidia). But other than that it is under full development and maintenance with an excellent support.

This is indeed unclear communication from my part. So, to clarify: I suggest fixing the issues that prevent btrfs from being the default filesystem, but I'm not suggesting adopting btrfs the default filesystem.

you might want to check


Thank you! These seem useful


I wonder if a nautilus extension would be a good format for a gui. We could have a context menu for

  • revert file to a snapshot
  • create a subvolume
  • toggle cow
  • reflink copy

That still leaves out the raid management though.

A have a bad feeling about giving btrfs to the masses.
It offers too many ways for manual intervention, many possobilies for the user to break it.
It is a great filesystem for developer, sysafmins and power users.
For regular users I would propose to focus on simple backup solutions.

I learned to like Squashfs as a backup tool. It can create a full lz4 compressed image of the whole system in about 15 minutes. The problem is that you can't create diff only images or I just don't know how. And it would be great if there was a GUI which would make its use easy.

However, any backup tool that offers compressed backup and saves space through differential backups would be fine to recommend or implement as default.


Gnome edition is getting deja dub with next release, and timeshift has been long been a part of many editions.

I think btrfs has potential to be good for larger audiences. However, it is not yet ready for that. Before that, we would need better defaults, better interfaces and more maintenance automation for it. Also, some safeguards against the common gotchas. It's still not suitable for everyone, but I think more people could benefit from it if we made it a little friendlier.


For that there is btrfsmaintenance, although I have been using Btrfs for many years and have never needed to balance due to the space, but I take a few snapshots with Timeshift, maximum 5

On that, just have the installer do it, the only additional step is a dedicated subvolume and NOCOW flag, the user does not have to worry about this because the installer will.

If you point to the user desktop, even on this I find no worries, those who want to create raids must still know what an ordinary user is doing and does not.

Also on this I find no worries, the Manjaro team will decide the default subvolumes, as does openSUSE and recently Ubuntu with the ZFS pools. In the future, a graphical tool for the management of subvolumes would also be nice here. The openSUSE installer gives you the ability to create or delete subvolumes and to set them "nocow".
Schermata del 2020-05-23 16-03-14
To manage the snapshots I think Timeshift is excellent and could be improved further.

Manjaro with the default Btrfs filesystem would be fantastic, I would immediately abandon Ubuntu if this happened and the complexity of the filesystem I don't think is a problem for a desktop user.
openSUSE has been using Btrfs by default for many years without any major problems, so there is a desktop use case.
And the advantages of Btrfs on ext4 are many, compared to the ease of maintenance of ext4.
This is my customization of Btrfs on Ubuntu, I have modified the installer.

1 Like

I'm working on this, but it is going to take a while.


Also on Fedora there is the proposal to migrate to Btrfs by default. This could be of help.

Forum kindly sponsored by