Recently having strange performance spikes with the loopback image I have been using since forever, I bit the bullet and gave Btrfs a try.
First let’s address the elephant in the room: “Is Btrfs stable yet”? The wiki has your answer. I’ll give you mine: If it’s stable enough for kernel developers to use on their workstations for 4 years, it’s stable enough for me.
The Setup
I had a big Ext4 partition spanning most of the drive, and a loopback image in it for encryption purposes1. Most of my stuff is in the loopback image.
Anyway, the loopback image works fine, but when some application uses a lot of disk IO, disk access would freeze for a few seconds (then unfreeze for a few seconds, then freeze again). Nix and VirtualBox tend to trigger this a lot.
It would have been nice to figure out the exact component that causes the spikes, but I figured having a filesystem on top of LUKS on top of another filesystem didn’t help. Time to simplify the stack.
The Steps
These aren’t intended to be a walkthrough, just the general picture. Some links are included, though you can easily find details elsewhere.
- Update the kernel. You aren’t going to enjoy improvements to Btrfs if you use a few year old kernel. Use the latest stable kernel for your distribution. For Ubuntu it means installing the newest hardware enablement stack.
- Shrink the main partition. Because this cannot be done offline you need to boot into a live USB or something. In my case shrinking a 1TB partition (300GB used) to 500GB took a few hours.
- Put LVM in the unused space to make this easier in the future.
- Add LUKS
- Add Btrfs (more below)
The Better FS
Better how? Well I don’t care that much about the filesystem, I just wanted to see if getting rid of the loopback device also gets rid of the performance spikes, and it did.
However I went through the documentation to make sure I didn’t miss anything obvious, and here are some interesting options I decided to change from the default values:
autodefrag: The Gotchas page mentions potential problems with fragmentation, to which this option is a nice solution. It’s not enabled by default though2, so you’ll have to explicitly enable it.commit=3600andnoflushoncommit: By default Btrfs “commit” data to disk every 30 seconds. This additional safety measure makes sure you don’t lose more than that much of data when the worst happens. On my laptop it doesn’t really matter, so I decide to trust the other safety measures.compress: Transparent compression, why not!noatime: Same as always, there is no need to keep access time updated because I don’t use applications like Mutt.
After going through Google+ and Hacker News (which stops accepting comments after 2 weeks) I will now try using Diaspora as the commenting platform. I guess requiring a D* account is nothing worse than a G+ or HN account. So comment there maybe. Hacker News is good for 2 weeks too.