BTRFS: what is it and why is it great?
In the computer world and particularly in the Linux world there are many filesystems available: ext, XFS, NTFS, FAT32 to name a few. BTRFS is a relatively new filesystem that is quickly gaining attention in the Linux scene; let’s discover what it is and why it is great.
BTRFS and other filesystems
BTRFS (B-Tree FS; or Butter FS; or Better FS) is a Linux-native filesystem started in 2007 and merged into the mainline kernel in 2009. BTRFS aims to implement advanced features, fault tolerance and ease administration. Despite its name BTRFS is not a proper filesystem. As a matter of fact BTRFS is also capable of spanning across multiple devices and provide RAID functionality but it is also capable of manage partitions dynamically acting as a volume manager like LVM. As you can see it packs quite a few functions under the hood, much more than a file system should, that’s why it isn’t entirely correct to call it a filesystem, it is a sort of “evolution”. Another filesystem of this kind is ZFS.
BTRFS (interesting) features
Let’s give a quick look at some features offered by BTRFS:
- Ease of administration by incorporating RAID and LVM.
- Copy on Write file system.
- Max file size 16 EiB.
- Read-only or writeable snapshots.
- Incremental backups (through snapshots).
- Send/receive function to copy filesystems over network.
- Conversion from ext3/4 to BTRFS.
- Support for data balancing across multiple devices.
- Quota support.
- Ensures data integrity to avoid data corruption (using CRC32C).
As I stated before, BTRFS can span across multiple devices, this entity composed of 1+ devices is called pool or volume (although none of the two is really THAT used) which acts much like a LVM Volume Group. BTRFS pools can be further configured to act as RAID. On top of that you can create many “partitions” called subvolumes. Now subvolumes are technically like block devices (for example you can’t create hard links across them) but as a matter of fact they are not; BTRFS wiki describes them as similar to POSIX namespaces. Subvolumes are not like Logical Volumes of LVM: you can’t create a filesystem on top of a BTRFS subvolume since the filesystem is BTRFS itself. In the end a subvolume is shown by the operating system as a directory. Subvolumes can be mounted, snapshot-ed sent/received and support compression and quotas. And that’s really all there is to it. All the possible elements of BTRFS are shown below from BTRFS wiki:
toplevel +-- root (subvolume, to be mounted at /) +-- home (subvolume, to be mounted at /home) \-- snapshots (directory) +-- root (directory) +-- 2015-01-01 (subvolume, ro-snapshot of subvolume "root") +-- 2015-06-01 (subvolume, ro-snapshot of subvolume "root") \-- home (directory) \-- 2015-01-01 (subvolume, ro-snapshot of subvolume "home") \-- 2015-12-01 (subvolume, rw-snapshot of subvolume "home")
All that glisters is not gold
Now even though BTRFS is growing at an amazing rate, it is by many still not considered stable. Well that depends on what you mean by stable, for example BTRFS RAID5/6 implementation was very much unstable and unfinished until not so long ago. Another thing I find pretty unstable is the use of CRC32C to ensure data integrity (BTRFS developers have intention to implement other different checksumming algorithms); I still trust ZFS for my home-made nas more than BTRFS. Many operating systems have support for BTRFS as of the time of writing this article, and some are planning to integrate BTRFS in their operating system; nonetheless BTRFS is still regarded as an unstable piece of software by enterprises, but be on the watch: the BTRFS time will come and it might not be that far away in time from now.
RAID5-6 data corruption and Red Hat deprecating BTRFS
During August 2016 an important bug was discovered in BTRFS RAID5-6 implementation. The implementation was faulty and could potentially cause data loss and corruption, up to date there’s still no complete fix. Although many fixes were merged in Linux 4.12 the feature is still marked as unstable.
On the day Red Hat released RHEL 7.4 an unexpected entry was on the deprecation list: Btrfs. Red Hat deprecated the popular filesystem, probably because Btrfs wasn’t up to Red Hat expectations given the long time it has been under development.
Although Red Hat gave up on Btrfs in favor of Stratis, SUSE still uses Btrfs as its primary filesystem for SLES and up to date SUSE is one of the major contributors to the project.