A Random Btrfs Experience

After all the buzz about btrfs and Ubuntu I figured I’d try experimenting with it a little. Aside: I think the hype over Ubuntu is a bit overblown – more power to them if they can pull it off but I suspect that it won’t be more than an option in the end.

I’m really looking forward to btrfs maturing enough for everyday use. I’ve been battling with md and lvm for ages and btrfs has a lot of promise. Some of the things I’m looking forward to are:

• The resizeability and reshapeability of linux md.
• The ability to create subvolumes as in lvm.
• The potential performance boost of COW.
• The snapshot ability and performance as compared to lvm.
• Full barrier support down to the metal. Right now I can’t do that as md doesn’t support barriers.

So, how did it go?

I figured I’d give it a test in a use case similar to how I would first experience it. Bear with me as it sounds messy, but I have a lot of existing data on ext3 on raid5 that I’d want to migrate.

To test out my migration strategy I created two 250MB and one 320MB image files (dd if=/dev/zero of=image bs=1M count=250/320). Then I mapped each to a loop, and created a raid5 across them. Then I put an ext3 on that (with 4096 byte blocks – very important), and put some data on it, filling up 90% of the drive. This is what I’m starting with, at 1/1000th scale.

My plan was to convert that to btrfs, then create a 1GB additional drive and add it to the btrfs in multiple device mode, and then start moving drives out of the old array and into the btrfs “array” until I’m free of md and just running btrfs.

So, step 1 was to run btrfs-convert on the ext3. That didn’t go so well. In my first attempt the convert aborted with a failed assert error. I ended up with a corrupted image that I couldn’t do anything with.

Then I tried again, and this time the conversion went fine and was almost instant. I then mounted that image and it looked great – all my files were there. Then I tried to diff one of them just to see how the conversion went, and that’s where things started going bad.

The diff seemed to be taking a while, so I looked at atop and saw that it wasn’t doing anything (no disk io, no nothing). So, I tried to kill it, and it wouldn’t die. Then I tried deleting the ext3 recovery image that btrfs-convert leaves behind, and that ended up as a zombie as well. In the end I had to manually shut down the system (stopping all processes, unmounting everything I could, etc), and hard rebooted with a few dirty filesystems. No data loss (no surprise – I did get just about everything turned off but the hung processes and gave the system plenty of time to sync), but not a good showing for btrfs.

I’ll be honest – I’m not on the latest kernel, and for something experimental like btrfs that makes a big difference. My use case is hardly a simple scenario – I tried just making a plain multiple-device filesystem with it and it worked fine. However, if this had been a real conversion I’d be out half of my data right now – twice.

I still look forward to the promise of btrfs. I’m impressed with how far it has come, and it holds great promise. However, I just can’t see this being production-ready quite yet. At least not without heavy backups (which I can’t afford right now – at least not doing it right).

However, rest assured I’ll be trying this again over the coming months. I really can’t wait to migrate as my current setup is going to be limiting soon.