Does ZFS work on Sabayon? Yes, very nicely 🙂 Here’s how:

Installing the driver

On kernels < 3.16 (as of November 2014), it’s a simple case of

 sudo equo install spl zfs zfs-kmod -a

On kernel 3.16 the package isn’t currently provided in the Sabayon repositories. Install it using portage:

 emerge --sync
 emerge spl zfs zfs-kmod

Once installed, load the module:

 modprobe zfs

Creating the Zpool and filesystems

In ZFS there are two layers of management: pools and filesystems. The pool is made up of ‘your physical storage and can be thought of like a hardware RAID set, or an LVM Volume Group. Within the pool are the individual filesystems which are the logical division of space, each with it’s own set of attributes, snapshots etc.

In this example, I’m going to create a zpool named myzpool from two physical disks mirrored together (which is a bit like RAID1 and means any one disk can fail without causing data loss). Note, it’s important to use persistent device names as ZFS will use these to reconstruct the pool on next boot, and you don’t want it to get confused with hardware changes and fail to bring your pool back online without manual intervention.

sudo zpool create myzpool /dev/disk/by-id/scsi-2001b4d2000000000 /dev/disk/by-id/scsi-2001b4d2008200700

Note: the items in /dev/disk/by-id are symlinks to the perhaps more familiar /dev/sdX device names, so if you’re not sure which to pick a simple ls -l should help.

Next up we’ll create a filesystem within that pool called myfilesystem. Unlike other volume managers, there’s no need to pre-define a size when creating a filesystem. ZFS will allow each filesystem to grow as long as there’s space in the pool so there’s no need to resize later on. Of course if you wish to set a maximum size (refquota), or even reserve some space for a specific filesystem (reservation), that’s possible too.

sudo zfs create myzpool/myfilesystem

Yup, it was that easy. Note that ZFS will automatically mount a filesystem for you when it’s created, so you don’t even have to do that.

Setting up automatic snapshots

One of the lovely things about ZFS is that snapshots are virtually free and only consume as much space as needed to store the changes made since the previous snapshot was taken. This means it’s cheap and easy to create lots of snapshots allowing granular, consistent, point-in-time recovery. The only hardship is that since creating them is so easy you’ll probably end up with a lot of them and managing them can become a burden. Cue the helpful tool to make things easier, zfs-auto-snapshot (zfs-auto-snapshot on Github).

zfs-auto-snapshot is designed to be run from cron and automatically creates snapshots on “frequent”, hourly, daily, weekly and monthly schedules, and rotates snapshots once they become old keeping the amount of space taken up constrained.

Installing it is a case of using portage to install it from the gentoo-zh overlay:

 emerge --sync
 layman -a gentoo-zh
 emerge sys-fs/zfs-auto-snapshot -av

And running it is as simple as adding something like the following to root’s crontab:

 */15 * * * * zfs-auto-snapshot --default-exclude -q -g --label=frequent --keep=4 //

See the help text for additional customisation.

Help, I accidentally changed/deleted a file!

This is the beauty of snapshots, you can view the files as they existed in any previous snapshot. The snapshots are automatically mounted read-only inside the .zfs/snapshot directory at the root of the filesystem. To view the available snapshots you can do one of two things:

 sudo zfs list -rt snapshot myzpool/myfilesystem
 # or
 ls /myzpool/myfilesystem/.zfs/snapshot

Recovering data is as simple as copying it from the snapshot back to the filesystem wherever you want it; amazingly simple.

Sharing data via NFS

ZFS and NFS are tightly integrated, so this is ridiculously easy as well. ZFS filesystems have attributes which are key/value pairs that can store arbitrary metadata about the filesystem. Some of the built-in attributes control sharing, so making a filesystem available via NFS is as simple as:

 sudo zfs set sharenfs=on myzpool/myfilesystem

Et voila, run showmount -e myserver on any client and you should magically see your filesystem available. Under the hood, ZFS has updated the NFS exports and reloaded the NFS server automatically.

If you wish to restrict access to specific hosts/ips that’s almost as easy as well:

 sudo zfs set share=prot=nfs,rw=@10.0.0.0/24,ro=@10.0.1.0/24 myzpool/myfilesystem

See man zfs for more options.

Sharing data via Samba

This one requires a little bit more work, but is still pretty easy. ZFS makes use of Samba’s usershare feature which allows for share definitions to be dropped into a particular directory at runtime which will automatically be loaded in. Turning on the share by modifying the zfs attributes drops the necessary file into this directory to have the filesystem shared, and removing the attribute deletes the file.

First up, add the following configuration options to /etc/samba/smb.conf to enable the usershare feature:

 usershare path = /var/lib/samba/usershares
 usershare max shares = 100

Then reload samba:

sudo systemctl reload samba

And finally share the filesystem:

 sudo zfs set sharesmb=on myzpool/myfilesystem

And hey-presto, the filesystem is available to your Windows clients as well.

Final thoughts

This post has only scratched the surface of what’s possible with ZFS. More information can be found in the official documentation. I’ve been running this setup at home for the last six months quite happily, and a few of the other fun things I’ve got working since (but are far beyond the scope of this post) include nfsv4 with kerberos and POSIX ACLs for improved security.

And don’t forget, mirroring and snapshots are not a suitable replacement for backups; help protect yourself from hardware failures, software bugs and human error by storing important data separately from your main system!