After having followed the btrfs features and implementation progress for a while and following the btrfs integration done in natty I wanted to see how far the filesystem has progressed so far.
Note that while I consider btrfs usable, it’s still experimental and has it’s issues, so don’t cry if you don’t have backups of your data! (I do). It’s also a good idea to subscribe to the linux-btrfs malining list and join #email@example.com
One of the main points that attracted me to btrfs was the transparent compression, since that’s something what most other linux filesystems are missing.
Btrfs has supported gzip as compression for a while and 2.6.38 added lzo support to it (the mount option is
compress=lzo), so I went and tried both.
The results were pretty much as I had read on the net: Phoronix, LWN.
Lzo uses almost no cpu time here and does give some space improvements, so unless you need the CPU time, I would probably use it by default wherever possible.
In the end I settled with gzip/zlib compression on both my EeePC 1000H and my Thinkpad T510. It does make the EeePC a bit slower a bit but I’m happy to have more disk space, on my Thinkpad it’s barely noticible.
One currently annoying thing is that you can’t really recompress data on an uncompressed FS once you mount it with compress. It should be possible with the defrag command, but that’s currently a bit tricky to use. This affects the installation process, as ubiquity doesn’t let you specify custom mount options, thankfully someone had a workaround for that already which is basically letting ubiquity run the partitioning, and once the partition is created, run:
sudo mount -o remount,compress /dev/sda1 /target
and voilá, all data will be compressed during the installation, after that just adjust the mount option in fstab and you’re set.
My Kubuntu 11.04 64-bit installation used only 1.6GB disk space after installation. 🙂
Really cool feature, esp. since I never really got around learning how to use LVM, ubiquity doesn’t support LVM, and in natty some work was done to integrate snapshotting into apt so we’ll have the possiblity to roll-back upgrades sometime in the future! Main point there is that ubiquity creates a @ (root) and @home subvolume by default if you choose btrfs for root in the advanced partitioning dialog in natty.
Using that, creating a snapshot of root is pretty trivial:
sudo mount /dev/sda1 /mnt
sudo btrfs subvolume snapshot /mnt/@ /mnt/@_snap
mounting /dev/sda1 without a
subvol= option will mount the actual FS, so you can see the root subolume that’s usually invisible. Now you create a snapshot of root – @_snap – which behaves like any other subvolume except that it shares data with @.
Now while that is easy, actually using the new subvolume as root and throwing the changes to @ away took me a few trashed VMs to figure out, so here goes:
sudo mount /dev/sda1 /mnt
edit /mnt/@_snap/etc/fstab so it mounts @_snap as /,
reboot and change the kernel entry at the grub prompt so it uses the kernel and initramfs from @_snap, and set it to use @_snap as root. Once you’ve booted run
which will make sure grub.cfg now has the kernel entries from @_snap, now run
sudo grub-install /dev/sda
If you forget to do that, grub’s $prefix will stll show to (hd0,msdos1)/@/boot/grub, which we don’t want (see blow).
Now you can get rid of your old rootfs if you want to free some disk space:
sudo btrfs subvolume delete /mnt/@
now, if you didn’t run grub-install, $prefix would point still point to the deleted subvolume resulting in a “file not found” error and a grub rescue> prompt, so don’t forget that. (It’s what happened to me at least)
So, while making a snapshot is easy, you should know what you do if you plan to actually use it. The integration with update-manager and grub is planned to be improved in oneiric so this will get easier.
Some (currently) not so cool things (that you should know):
the btrfsck utility that’s currently shipped is pretty much useless, as it can’t actually fix any errors it finds, only report them. Also, it runs really slow on boot (8s on my thinkpad, 30 on my EeePC), so you usually want to delete the /sbin/fsck.btrfs symlink. A working btrfsck has been promised for a long time, though in February someone said the release is imminent, let’s hope for the best.
while btrfs supports TRIM, you don’t really want to use it currently, there’s a bug that resulted in every fsync() call taking over a second on my system. Now consider that dpkg calls fsync() several times per package and you can imagine the performance.
grub2 in natty doesn’t have lzo support, so you don’t want to use that for root currently without a seperate boot partition.
while btrfs already has some defragmentation support, the command only runs on files, not directories, so you need some shell magic to defragment the whole FS.
not the fault of btrfs but it bit me on my eeePC when Installed without a boot partition.