I'm starting to get impatient. I really want to start running a next-generation file system. I'd like to have easy to manage sub volumes, block level checksums, and RAID-like redundancy at a higher level.
Writable snapshots are what I'm most excited about, though. Snapshots of my home directory will help protect me from accidental file deletions and modifications between backups.
I'm currently saving disk space with my QEMU disk images by juggling cloned qcow images. It should be much easier to manage some writable Btrfs snapshots instead. Deduplication would likely save me quite a bit of space as the virtual machines age. ZFS already has deduplilcation, but it sounds like deduplication won't be all that far away for Btrfs.
What are the Best Practices for a Btrfs Root File System?
I have absolutely no idea, but I think I am on the right track. I did not want to use the root of the Btrfs file system as my
/ file system. I created a sub volume called
rootfs instead. I mounted that sub volume as
/ and I mounted the entire Btrfs volume under
Doing it this way felt pretty well organized. From this point, it would be pretty easy to create a
homefs and a
tmpfs. I didn't want to break out
/usr. That would make it too difficult to snapshot the operating system between upgrades.
Overview of How to Get it All Up and Running
There is a tool to convert and ext3 or ext4 file system to Btrfs. I didn't use them and I don't know if they would allow me to lay out the file system the way I was hoping. I ended up doing it the long way.
This isn't going to be a step-by-step guide. The quick overview of the steps was:
- Install Ubuntu 9.10, small ext2 or ext3 boot partition
- Compile and install kernel 2.6.32 and the latest btrfs-utils (you can skip this if you don't need snapshot removal)
- Add btrfs.ko, zlib_deflate.ko, and crc32c.ko to the initramfs
- Back up everything on the
- Create a Btrfs on the old
/block device, create a
- Restore the old
/file system contents to the
GRUB and fstab
You'll have to change your
root kernel parameter and add a
fstab just pointing to /dev/sda2. That seemed to be work fine and allowed me to boot from different snapshots. I also added a line to mount
Taking a snapshot and booting from a snapshot
I created a snapshot of
rootfs-1 and then I performed an
apt-get dist-upgrade and installed a few extra packages. It wasn't a huge change but it was enough to test booting from a snapshot.
Booting from a snapshot turned out to be easy. At the start of boot, I chose to edit the GRUB entry before booting. I just changed
subvol=rootfs-1. It would probably be pretty easy to automatically generate a GRUB menu with all the snapshots as options.
One Little GRUB Hiccup
update-grub ran fine the first time, while my root filesystem was still ext4.
update-grub got angry and wouldn't update properly with a Btrfs root. I don't have a good fix for this yet—I just kept fiddling with the GRUB entries during boot.
GRUB, Btrfs, and Kernels
Being able to snapshot root will be very handy. I'd be tempted to set up some automation to snapshot root every day and at every
Unfortunately, GRUB doesn't understand Btrfs or its snapshots. Kernels and initrd images have to be stored on a boot partition that won't support snapshots. That makes the kernel the weak link in the upgrade chain.
It would be nice if the boot loader could pull a kernel straight from the snapshot. That would let you keep your snapshots more self-contained. I don't feel this is very important, though. Snapshots of root alone will be a huge step forward.
Sorry for the Lack of Screen Shots
My X25 died this week and I didn't get around to backing up my Btrfs virtual machine. I didn't think I would need to back up that image because I was planning on deleting it after I wrote this article.
I am seriously considering giving Btrfs a try on my laptop when the replacement X25 gets here. I will post some screen shots if I do.