Wednesday, September 26, 2012

Btrfs: the good, the bad and the ugly

Tux
I have been testing btrfs on openSUSE 12.2 for nearly two weeks now, using it on my laptop daily and it seems to be nearly ready for use. There are however some things you have to take into account or everything can go wrong. I also encountered a bug, which I shall describe in this article.
First of all, the new openSUSE 12.2 installation runs very smoothly without any problems. It feels even a bit faster than before, but it is impossible to tell whether it is partly due to the btrfs filesystem or just due to the new build chain, new versions of software etc.

There are however some caveats for Linux in general one should really know about:

updatedb

If you are, like me, using snapshots on your brand new btrfs file system, do not forget to exclude those snapshots from updatedb, otherwise all your snapshots will be indexed separately, which can take a very long time. This problem is especially bad when you are e.g. using snapper op openSUSE to make snapshots automatically, since you will have 20 and more snapshots in no time. I filed a bug report on the openSUSE bug tracker, but there is no fix yet.

When your snapshots are in /.snapshots, you can fix it easily manually by adding /.snapshots to UPDATEDB_PRUNEPATHS in /etc/sysconfig/locate.

btrfsck

btrfsck is not like other fsck tools, so it will not exit immediately on a clean file system, but it will always check the file system! This is e.g. an issue on Ubuntu, where it slows down booting as seen in this bug report.
In fact, btrfs should be able to recover from a crash without a file system check in most cases and this tool should only be used when things are really broken. When that happens it is probably also a very good idea to read the Problem FAQ on the btrfs website.

A crash

After a crash of my computer I was not able to boot again due to a kernel oops in the btrfs module when trying to mount my root partition. I tried everything: btrfsck, mounting with read-only (ro) and recovery options, etc. but to no avail. The kernel kept panicking with
search_bitmap.irsa
remove_from_bitmap
btrfs_remove_free_space
at the beginning of the backtrace. I had backups but did not like the idea of reinstalling, so I went on Freenode IRC and luckily someone in the #btrfs channel there advised me
mount -o nospace_cache <device>
to destroy the free space caches, since they were probably corrupt. This worked!
The help I got on IRC was a positive experience of course, thanks to all the friendly guys there, but it is a sign of the shortcomings still present in btrfs that I have already encountered such a problem in the first two weeks I am using btrfs. It could be a rare case of course, I keep testing.

Conclusion

Btrfs has been in development for five years now and it is finally becoming mature. It seems to still contain annoying bugs, but recovery is possible and most bugs should be fixed by now. What is really required yet is a good integration in the Linux distributions. Some small changes can make the difference between btrfs being  regarded as experimental or btrfs finally becoming a mainstream file system.

Are you ready to try btrfs? Or have you already tried it? What are your experiences? Feel free to share them in the comments below!

No comments:

Post a Comment