My assessment of “btrfs”
In my previous post, I indicated that I would give my own view on “btrfs”. So that’s what this post is about.
Short version — I will continue to use “ext4” in future installs.
Note that this a personal view, not a recommendation. My own choice depends on how I use computers and my practices for backup, recovery, etc. Your practices are likely different. Much of this post will be about my considerations in deciding against “btrfs” for my own use.
What is “btrfs”?
“Btrfs” is a file system for linux. It is based on a b-tree data structure (often used in databases). You can think of the file system directory as an index into that database. I’ll give only a quick summary. You can find a more detailed summary in Wikipedia, or in the sources that linked there.
In addition to the b-tree structure, “btrfs” uses “copy on write” (abbreviated as COW). When you change some data in a file, the modified sector is written to a new disk location, with the original sector being left with its content unchanged.
A snapshot is something like an alternative index. After the file system has been created and populated (files added), a snapshot is created. So this is like a second copy of the file system directory. However, as files are update, the new data is copied to new sectors (the COW function), and the main directory is updated. The snapshot still refers to the original data. So a snapshot allow the possibility to reverting to an earlier version. The idea is that this could be useful for recovery from a catastrophe.
The operating system typically runs a background process (or cron job) which periodically creates new snapshots and deletes very old snapshots. Deleting a snapshot does free up disk sectors that are referenced by only that snapshot.
The file system is structured into subvolumes. The subvolumes are mainly for snapshot management. A snapshot does not cross subvolume boundaries. As configured by opensuse defaults, only the main subvolume (or root subvolume) receives periodic snapshots. Creating subvolumes prevents part of the file system from having snapshots.
There is an option to boot from a read-only snapshot. When I try that, I am given a list of snapshots, and can select one to boot. Next I get an error message (probably a bug), followed by a boot menu. Taking the default entry from that boot menu completes the boot into the read-only snapshot. If I like the result, I can do a rollback to that snapshot.
The boot to a read-only snapshot does work. I have not tried the rollback, as I did not need that. This could be a nice recovery option, depending on how you use your computer.
There are some disadvantages to “btrfs”. One disadvantage, is that those snapshots take space. Initially, the snapshot takes little space. But as files are updated, so that the snapshot version is different from the original version, the amount of space used begins to grow.
On my Tumbleweed system with “btrfs”, I have 40G assigned to the root file system. It is currently using a little more than 20G. My estimate is that I would be using less than 10G if I had used “ext4”. I have “latex” and the KDE Plasma 5 desktop installed, and not much else.
The output of the “df” command and/or the “mount” command is messy, because there is a line for each mounted subvolume. And then there’s the difficulty of needing to mount subvolumes when going into rescue mode (see my previous post).
My own assessment
The ability to recover from catastrophe is nice. It could, for example, be used to recover from a bad update, by rolling back to before that update. However, the catastrophe that worries me, is a hard disk failure. And rollback to an earlier snapshot won’t help in that case.
I actually did have my disk fail last December. So I replaced the disk, reinstalled opensuse Leap 42.1, and then restored my “/home” file system from a recent backup. I don’t do backups of the root file system, because it seems just as easy to reinstall as to restore from a backup. And I’m inclined to prefer that way of dealing with other possible catastrophes. So, for my usage, I don’t actually see much benefit with “btrfs”.
If I were running a server, instead of a home desktop system, I might have a different view. But then the “btrfs” file system needs about twice as much disk space as I would otherwise use. I’m inclined to think that I would prefer to have two alternative root partitions, preferably on different disks, so that I could recover from a catastrophe on one, but simply booting to the other. An advantage of this, is that I could mount the alternative root in rescue mode and apply updates to it, without disturbing the running system. Then I could boot the alternative root to test the new updates. And a rollback would amount to reverting to the previous root file system. I would, of course, need to periodically synchronize the alternative root to the working one. But I think that would give me more flexibility.
I’ll add that there was an extensive discussion of this on the opensuse mailing list for March 2016. I did not participate in that discussion, but several people discussed somewhat similar viewpoints. You can check at the mailinglist archives.