Btrfs killed ZFS (on my desktops)

not-btrfsFollowing the latest post about Btrfs, until yesterday both ZFS and Btrfs were running for testing and evaluation purposes, in my primary desktop machine.

The outcome was pretty straight forward, i wiped all the ZFS stuff from the disks.  Now, my desktop is just running Btrfs (also root/boot).

Why?

Very simple reason, Btrfs is very well integrated with the OS, right from the system install, to the automatic apt-snapshots (that already saved my ass a couple of times), to the graphical tools graceful integration. On the other side, ZFS…. let’s just say that to use ZFS you actually have to add a repository and then install ZFS in the system, and just then you are ready to start and use it.

Actually both of the file systems are from Oracle, but Btrfs is GPL licensed and ZFS is CDDL license so don’t expect a kernel/OS integration anytime soon….

For my personal needs, Btrfs has all the whistles and bells, mainly sub-volumes, snapshots and compression. And it’s pretty damn fast and stable (zero problems to this day). The only thing i miss is native encryption, but probably it will roll out in an upcoming version. Sure ZFS can be more mature and feature rich, but it’s lack of integration it’s just a pita (at least for linux desktop)…

For more in depth information about Btrfs i totally recommend this presentation:

 

Linux snapshots – apt-btrfs-snapshot

Since a couple (half dozen) of years I have been using the beautiful KDE Desktop in the very well made and supported Kubuntu distribution. As technology progresses and the switch on desktop computers from fast spinning disks to solid state disks is being made, I sleep better at night with a SSD… and if even SSDs can eventually fail (as Linus Torvalds knows…), you should always backup or cloud your important data, so I was much more worried by a system messed up with some update/upgrade or my own incompetence than trough hard drive failure.

So it was time to try snapshots in Linux. As always in Unix land there’s more than one way to cook an egg. You can go with LVM + classical File System, ZFS or Btrfs (and surely many other options). I did a new Kubuntu installation with the installer defaults using Btrfs as the file system (wanted to test drive Btrfs anyway) and from here is very simple to implement snapshots.

First thing, make sure that you have the default Btrfs setup

# btrfs subvolume list /
ID 257 gen 97520 top level 5 path @
ID 258 gen 97520 top level 5 path @home

Install apt-btrfs-snapshot

# apt-get install apt-btrfs-snapshot

And check that snapshots are supported

# apt-btrfs-snapshot supported
Supported

Here actually I get an error the first time i ran it

# apt-btrfs-snapshot supported
Traceback (most recent call last):
File "/usr/bin/apt-btrfs-snapshot", line 92, in
apt_btrfs = AptBtrfsSnapshot()
File "/usr/lib/python3/dist-packages/apt_btrfs_snapshot.py", line 113, in __init__
self.fstab = Fstab(fstab)
File "/usr/lib/python3/dist-packages/apt_btrfs_snapshot.py", line 76, in __init__
entry = FstabEntry.from_line(line)
File "/usr/lib/python3/dist-packages/apt_btrfs_snapshot.py", line 49, in from_line
return FstabEntry(*args[0:6])
TypeError: __init__() missing 3 required positional arguments: 'mountpoint', 'fstype', and 'options'

this was caused by unsupported fuse syntax entries in /etc/fstab, just had to change
sshfs#user@host:/path/ /mountpoint fuse options 0 0
to
user@host:/path/ /mountpoint fuse.sshfs options 0 0

and it will work. From now on the system is pretty much autonomous, every time you apt-get upgrade a snapshot will be made for you. Take notice that each snapshot is relative to root only, this means that /home is excluded, we are taking snapshot of the system not user files and configs…

# apt-btrfs-snapshot list
Available snapshots:
@apt-snapshot-2014-12-17_10:27:24
@apt-snapshot-2014-12-18_10:33:50
@apt-snapshot-2014-12-18_19:57:02
@apt-snapshot-2014-12-19_17:17:13

or you can force a new snapshot

# apt-btrfs-snapshot snapshot

to rollback, just issue

# apt-btrfs-snapshot set-default @apt-snapshot-2014-12-18_19:57:02

and reboot, yeah… fuckin awesome!

Note, i noticed some problems in apt-btrfs-snapshot to delete and list some of own snashots. Probably because of updates in btrfs or apt-btrfs-snapshot itself (pretty common after a distribution upgrade). The delete command doesn’t works as expected and btrfs gives also error. The situation is like this:

You see the snapshot in the list:

#btrfs subvolume list /
ID 257 gen 361392 top level 5 path @
ID 258 gen 361392 top level 5 path @home
ID 505 gen 361392 top level 5 path @apt-snapshot-2015-11-12_13:01:23

But when you go to delete it, btrfs spits an awful ERROR: error accessing…

btrfs subvolume delete @apt-snapshot-2015-11-12_13:01:23
Transaction commit: none (default)
ERROR: error accessing '@apt-snapshot-2015-11-12_13:01:23'

But the solution it quite simple, just mount all the btrfs device and delete it by path:

#mount /dev/sda1 /mnt/
# ls /mnt/
drwxr-xr-x 1 root root 78 Nov 12 13:01 ./
drwxr-xr-x 1 root root 244 Ago 4 12:30 ../
drwxr-xr-x 1 root root 244 Ago 4 12:30 @/
drwxr-xr-x 1 root root 244 Ago 4 12:30 @apt-snapshot-2015-11-12_13:01:23/
drwxr-xr-x 1 root root 40 Fev 7 2015 @home/
# btrfs subvol delete /mnt/@apt-snapshot-2015-11-12_13\:01\:23/
Transaction commit: none (default)
Delete subvolume '/mnt/@apt-snapshot-2015-11-12_13:01:23'
# cd /
# umount /mnt

even so, sometimes when you try to manual delete like above you get an

ERROR: cannot delete ‘/mnt/@apt-snapshot-2015-11-12_13:01:23’: Directory not empty

in this situation just dig a bit deeper

#cd /mnt/@apt-snapshot-2015-11-12_13:01:23
# rm -rf *
rm: cannot remove 'var/lib/machines': Operation not permitted
# subvol delete /mnt/@apt-snapshot-2015-11-12_13:01:23/var/lib/machines/
# subvol delete /mnt/@apt-snapshot-2015-11-12_13:01:23/
# cd /
# umount /mnt

You can thank me later