Kernel Comment: Btrfs too fast?

by Thorsten Leemhuis

Oracle and SUSE already support Btrfs, even though the filesystem hasn't yet been proven in a proper field test and is officially still classified as experimental. The two distributors have also pressed ahead with the Btrfsck test and repair tool, foregoing any prior testing by the Linux community.

Dear developers and executives at Oracle and SUSE,

I admire you for the courage to provide official support for the experimental Btrfs filesystem with the latest Oracle Linux and SUSE Linux Enterprise updates. Being used more extensively will surely help stabilise the designated "next generation filesystem" for Linux.

However, if I were you I wouldn't be able to sleep easily in the coming weeks.

I'm sure you've thought about it carefully. And I know you have capable employees who contribute to Btrfs and test it extensively; even the creator and main developer of Btrfs, Chris Mason, is on Oracle's payroll. But you do also know: no matter how much software is tested, some flaws won't even show up in the most thorough lab testing, as demonstrated by crashing satellites and exploding rockets.

To protect paying customers from as many bugs as possible, you at SUSE have established the openSUSE project, which follows the example set by Red Hat with Fedora. These projects' freely available distributions have a number of users that run Fedora and openSUSE in the most varied environments. The operational diversity and the multitude of available hardware and software components expose bugs that even the most thorough test lab could never find in a reasonable amount of time. These bugs are reported by users, – and, taking a closer look at the bug reports, one is sometimes quite amazed at the serious blunders that occasionally still lurk in software which is generally considered well-seasoned and stable.

With every such problem fixed, the developers improve their distribution yet a tiny bit more. Red Hat Enterprise Linux (RHEL) and SUSE Linux Enterprise (SLE), the enterprise distributions that are based on Fedora and openSUSE, benefit extensively from these bug fixes. Add a support contract, and companies do agree to put money on the table for RHEL and SLE – or for Oracle Linux, which is based on RHEL.

But it seems that you at Oracle and SUSE were so keen on Btrfs that you largely made do without the community distributions' field testing that usually serves you so well.

OK, Btrfs filesystems have been available in Fedora and openSUSE for some time, despite various attempts in Fedora, however, Btrfs has so far not become the default filesystem. Neither have Ubuntu nor other mainstream distributions so far dared to take this step. Therefore, Btrfs has, at best, been tested by users that consider which filesystem they want to use and aren't scared off by the "experimental" status which Btrfs still has, even in the current release candidate of Linux 3.3. That was probably only a small percentage of users. And those who have dared use it do still find bugs, which can be seen in the archives of the mailing list the Btrfs developers use to communicate with each other. For example, the developers fixed a bug that occasionally corrupted filesystems after a crash or power outage with Linux 3.2 only at the end of last year.

Speaking of corrupted filesystems: Btrfs has at least been field tested here and there – which can't be said for the improved test and repair tool for Btrfs drives that everyone has been anticipating for so many months. The "improved" Btrfsck you now provide hasn't even become available on its own yet. Your code appears to be based on code that can be found in a Git branch of the Btrfs tools' source code – a branch that carries the alarming name "dangerdonteveruse".

If we were talking about a normal desktop application, I might still be able to live with insufficient field testing. But a filesystem to which I entrust my valuable data currently still seems too delicate a matter even if a good backup policy is in place – especially because, in my research for the Kernel Log series, I've repeatedly observed that each new kernel version still fixes problems that are hiding in filesystems such as Ext3 and Ext4, which have long been considered stable. Software always contains bugs that must be found and fixed – especially true for new and unproven code.

And that's not all of it, as Btrfs isn't even fully developed yet, because the developers are still working to integrate RAID-5 support, more efficient compression algorithms and various other improvements. While such features can be added at a later stage, working some more on a few further optimisations might have been a good idea – for example, it's well known that Btrfs is not very suitable for storing the disk images of virtual machines. In many cases, it also proves less effective than Ext4 or XFS for database storage. This is due to the use of Copy-on-Write (CoW), a mechanism that makes many of the benifits to Btrfs possible in the first place. The developers have been discussing tricks to avoid some of the inherent disadvantages of COW or at least minimise their effects – perhaps you should have waited for those.

I'm really looking forward to see how well any production-ready Btrfs turn out in the field with the updates and enhancements for your enterprise distributions. I wouldn't be surprised if the reputation of the "next generation filesystem" for Linux suffered substantially if major problems are found. Should there be many bugs, the filesystem may even need to enter another development round before it can eventually conquer the Linux world as "Btrfs2".

Thorsten Leemhuis