LABEL=datavol	/home	btrfs	defaults,subvol=home	0	0
LABEL=datavol	/media/btrfs-datavol	btrfs	defaults,noauto,subvolid=0	0	0

As /media is a temporary file system, meaning it is being recreated with every reboot, we need to create a mountpoint for the BtrFS volume before mounting. After that we create two read-only snapshots with a small delay in between. As there is currently no naming guide for how to call snapshots, I adopted the ZFS naming schema with the @-sign as separator between the subvolume name and timestamp.

$ sudo mkdir -m 0755 /media/btrfs-datavol
$ sudo mount /media/btrfs-datavol
$ cd /media/btrfs-datavol
$ sudo btrfs subvolume snapshot -r home home\@`date "+%Y%M%d-%H%m%S-%Z"`
Create a readonly snapshot of 'home' in './home@20124721-080109-CET
...
$ sudo btrfs subvolume snapshot -r home home\@`date "+%Y%M%d-%H%m%S-%Z"`
Create a readonly snapshot of 'home' in './home@20124721-080131-CET'
$ ls -l
totaal 0
drwxr-xr-x 1 root root 52 nov 21  2010 home
drwxr-xr-x 1 root root 52 nov 21  2010 home@20124721-080109-CET
drwxr-xr-x 1 root root 52 nov 21  2010 home@20124721-080131-CET

We now have two read-only snapshots and lets test to see if they are real read-only subvolumes. The creation a new file shouldn’t be possible.

$sudo touch home@20124721-080109-CET/test.txt
touch: cannot touch `home@20124721-080109-CET/test.txt': Read-only file system

Creating snapshots is fun and handy for migrations or as on disk backup solution, but they do consume space as the delta’s between snapshots is being kept on disk. Meaning that changes between the snapshots are being keept on disk even when you remove them. Freeing diskspace will not only be removing them from the current snapshot, but also removing previous snapshots that include the removed data.

$ sudo btrfs subvolume delete home@20124721-080109-CET
Delete subvolume '/media/btrfs-datavol/home@20124721-080109-CET'
$ ls -l 
totaal 0
drwxr-xr-x 1 root root 52 nov 21  2010 home
drwxr-xr-x 1 root root 52 nov 21  2010 home@20124721-080131-CET

As last step we unmount the BtrFS volume again. This is where ZFS and BtrFS differ too much for my taste. To create and access snapshots on ZFS the zpool doesn’t needs to be mounted, but then again with the first few release of ZFS the zpool needed to mounted as well. So there is still hope as BtrFS is still under development.

$ sudo umount /media/btrfs-datavol

Seeing what is possible with BtrFS, Sun’s TimeSlider becomes an option. Also the option of Live Upgrades with rollbacks as is possible with Solaris 11, but for that BtrFS with read-write snapshots needs to be tested in the near future.

The first tests with BtrFS where in a virtual machine already a longtime ago, but the userland tools where still in development. Now the command btrfs follows the path set by Sun Microsystems and basically combines the commands zfs and zpool for ZFS. But nothing compares to a test in the real world and so I broke a mirror and created a BtrFS volume with the name datavol:

$ sudo mkfs.btrfs -L 'datavol' /dev/sdb2

Now we can mount the volume and create a subvolume on it which we are going to be using as our new home volume for users homedirectories.

$ sudo mount /dev/sdb2 /mnt
$ sudo btrfs subvolume create /mnt/home
$ sudo umount /dev/sdb2

When updating /etc/fstab we can tell mount to use the volumename instead of a physical path to a device or some obscure UUID number. Also you can tell which subvolume you want to mount.

LABEL=datavol	/home	btrfs	defaults,subvol=home	0	0

After unmounting and disabling the original volume for /home we can mount everything and copy all the data with rsync for example to see how BtrFS is working in the real world.

$ sudo mount -a

As hinted before scrubbing is important as you can verify that all your data and metadata on disk is still correct. You can do a read-write test by default or only read test to see if all data can be accessed. There is even an option to read parts of the volume that are still unused. In the example below the subvolume for /home is being scrubbed and with success.

$ sudo btrfs scrub status /home
scrub status for afed6685-315d-4c4d-bac2-865388b28fd2
	scrub started at Sat Jan 17 15:11:58 2012, running for 106 seconds
	total bytes scrubbed: 5.77GB with 0 errors
...
$ sudo btrfs scrub status /mnt
scrub status for afed6685-315d-4c4d-bac2-865388b28fd2
	scrub started at Sat Jan 17 15:11:58 2012 and finished after 11125 seconds
	total bytes scrubbed: 792.82GB with 0 errors

The first glances of BtrFS in the real world are a lot better with kernel 3.1 then somewhere with kernel 2.6.30 and I’m slowly starting to say it becomes ready to be included in RHEL 7 of Debian 8 for example as default storage solution. The same as ZFS became in Solaris 11. But it is not all glory as still a lot of work needs to be done.

The first is encryption as the LUKS era ends with BtrFS as it is not smart to put it between your disks and BtrFS. You lose the advantage of balancing data between disks when you do mirroring for example. But then again LVM has the same issue where you then also first need to setup software raid with MD with LUKS on top of it and LVM on top of that. For home directories EncFS maybe an option, but it still leaves a lot of area’s uncovered that would be covered by LUKS out of the box.

The second issue is the integration of BtrFS in distributions and the handling of snapshots. As for now you first need to mount the volume before you can make a snapshot of a subvolume. The same for access a snapshot and for that I think ZFS still has an advantage with the .zfs directory accessible for everyone who has access to the filesystem. But time will tell and for now the first tests look great.

In dezelfde periode is Oracle begonnen aan Btrfs voor Linux welke in de kernel is op genomen sinds Linux 2.6.29. Nu begint ZFS redelijk volwassen te worden en het heeft wat jaren geduurt, maar hoe staat Btrfs ervoor. Een virtuele testmachine met een paar lege disken en de laatste versie van Debian Testing zou dus voldoende moeten zijn. Helaas is dit nog geen succesvolle combinatie en geeft aan dat Btrfs misschien nog niet helemaal volwassen is.

Als we naar de techniek en implementatie kijken dan zijn er nog meer verschillen tussen ZFS en Btrfs. Waar ZFS beschikt over RAID 0, 1, 10 maar ook over verschillende RAIDZ generaties en combinaties hiervan waarmee RAID 5 en 6 worden geimplementeerd. Dit terwijl Btrfs voorlopig alleen beschikt over RAID0, RAID1 en RAID10 zonder enige uitbreidingen hierop. Ook blijft Btrfs vertrouwen op bv andere RAID- en LVM-oplossingen, maar ook op de hardware die altijd correct is. Een mooi punt van oa ZFS is dat het de hardware meeneemt in de beslissingen waar het snelst te lezen is bv.

Op bijna alle punten lijkt ZFS volwassen te zijn en behoeft Btrfs nog vele jaren ontwikkeling terwijl ZFS al in 2006 productierijp was. En hoewel ZFS strict in Solaris verweven is en een niet GPL-licentie heeft is het zeer zeker de moeite waard om te gebruiken. Het is misschien ook de vraag of met de komt van Solaris 11 en de uitkomst van de Sun-Oracle merger het nog wel interessant is naar Btrfs te kijken. Zeker als je kijkt naar hoe volwassen OpenSolaris nu is tov wat Linux niet biedt. Alleen een licentie is vaak niet voldoende of het moet de moeite waard zijn om te wachten, maar live upgrade met ZFS is tegenwoordig echt de moeite waard en een verademing.

Bij verdere controle komt er toch een oude instinker naar boven. Er blijkt een filesysteem geen vrije inodes meer te hebben en er kan dus ook geen expire van data meer worden gedaan door de applicatie. De enige twee opties zijn dus het vrij maken van enkele inodes of extra inodes beschikbaar stellen. Helaas is de eerste optie niet echt een optie als de data belangrijk is of index afhankelijk. De tweede optie van het logische volume en daarna het filesystem vergroten.

Bij het lezen van de manpage voor ext2/3/4 blijft dat je niet kan opgeven of je inodes kan reserveren voor de root-gebruiker zoals bij het aantal beschikbaar vrije blokken. Dit doet me ook verwonderen hoe dit in ZFS is opgelost, maar het wordt wel duidelijk dat filesystemen gebaseerd op inodes hun beste tijd hebben gehad.

First the upgrade from a previous version of OpenSolaris is very simple. The commands below should be enough to upgrade to version 2009.06 and would only depend on your download speed.

$ pfexec pkg refresh --full
$ pfexec pkg install SUNWipkg
$ pfexec pkg image-update --be-name opensolaris-200906

After the reboot you can see which environments there are and which one is active now or will be active after the next reboot.

$ beadm list
BE Active Mountpoint Space Policy Created
-- ------ ---------- ----- ------ -------
opensolaris - - 72.79M static 2009-05-30 02:00
opensolaris-200906 NR / 7.35G static 2009-05-30 11:22
$ uname -a
SunOS homer 5.11 snv_111b i86pc i386 i86pc Solaris

The machine is now up and running with the latest stable release. So the next couple of weeks I’m going to experiment with a lot of new things like SourceJuicer and Crossbow to get a feeling for them.

Hier komt ook een probleem voor veel gebruikers aangezien de grote van filesystemen groeit en filesystemen van een paar honderd gigabyte tot een terabyte of soms zelfs meer zijn niet meer ongewoon. Je bent dan gewoon veel tijd kwijt aan het wachten totdat een controle is voltooid. Gelukkig is ext3 nu wel lang genoeg op de markt om aan te nemen dat het wel snor zit en hardwarefouten kan ext3 toch niet detecteren en oplossen, iets wat ZFS wel kan trouwens.

Het volgende commande zet dan ook een tijdslimiet van 12 maanden op het filesysteem en de controle zal dan ook maar eens per 12 maanden worden uitgevoerd. Dit ongeacht het aantal keren dat het filesysteem is gebruikt.

$ sudo tune2fs -c 0 -i 12m /dev/mapper/nemo01-home

Het bovenstaande natuurlijk alleen uitvoeren als je weet wat je doet en over goede back-ups beschikt.