Also available to us is ZFS compression. Let’s create a test pool for testing. We’ll turn a few options on and off so you see the syntax:

Verify that the dataset was created with all appropriate options:

Compression ratio is 1.00x, as you’d expect for an empty filesystem. Copy some stuff to it:

Then check the compressratio variable within the dataset properties:

So – compression has given us some benefit. It’d be worth weighing up compression/dedup/encryption of ZFS filesystems against the system resources which they consume. Nowadays I’d be pushing FOR turning all this stuff on – servers are cheap and can work hard. Put them to use.

Encryption

Filesystem encryption is another easy-to-implement feature of ZFS. ZFS root pools and other OS components (such as the /var filesystem) cannot be encrypted.

To start, I’ll create a new encrypted dataset. You will be prompted for a passphrase to use when encrypting/decrypting the filesystem. Needless to say – do not forget this passphrase! Create the dataset with the encryption=on option:

Verify that the operation has succeeded and that the encrypted dataset has been created:

Encrypted ZFS datasets, when created with encryption=on and no other options, use aes-128-ccm as the default encryption algorithm.

You will see that by default, ZFS uses passphrase,prompt as the value for the keysource property:

In this configuration, the ZFS filesystem will not be automatically mounted at boot – observe. After a reboot the output of zfs mount does not contain an entry for datapool/encryptfs:

So – any encrypted datasets, using passphrase,prompt as the value for the keysource property, require manual mount with zfs mount:

The passphrase can be placed in a file, so that it is automatically mounted on boot. Note – this is not secure nor is it recommended. It is best to use keys, and we will configure this shortly. For now, place the passphrase in a read-only file in root’s home directory:

Set the keysource property to include the passphrase file:///path/to/key value as below:

Now, unmount the filesystem and unload the cached key (otherwise the filesystem will be remounted using the cached key and nothing will change):

If the filesystem is mounted now, we are not prompted for a passphrase:

A reboot confirms this:

OK – this is all well and good, but storing the passphrase in a file is far from being best practice. A more secure method is to use pktool to create a key, then change the dataset to use this key (or indeed create the ZFS dataset in the first place using this key). Whilst this is better - it’s still only as secure as the security of the key file location. Any compromise of the key file leads to a potential compromise of the ZFS dataset. However, we’re not storing the passphrase clear-text in a file somewhere, which is positive in my book.

The conversion from using a passphrase based key to the pktool generated key is completed as follows. First, generate a key, and store in as secure a location as possible:

Load the existing wrapping key for the dataset, by either mounting the dataset, or using zfs key -l. In our case, we can see that the key is already loaded, and so can ignore the warning:

Change the wrapping key via zfs key -c:

To test that the change has been successfully implemented, unmount the filesystem and unload the wrapping key for the dataset:

Try mounting the dataset, and confirm that the operation is successful, and that no prompts/warnings are displayed:

As previously discussed, a ZFS filesystem with encryption=on set uses aes-128-ccm by default. We can change this when we create a new dataset, however. Observe:

Our new dataset has been created using aes-256-ccm encryption.