In case an ZFS mount has not been found at boot time, then the zpool utility can be made to scan and import any tanks that have been previously created. Issue:

zpool import

and a list of tanks will be provided that have been recognized. After that issue:

zpool import TANK

where TANK is the name of a tank that has been previously detected.

zfs set acltype=posixacl TANK
zfs set xattr=sa TANK

where TANK is the name of the ZFS pool.

On some machines, the SHA256 hash function can require a lot of CPU. This can be observed by running perf top and noticing that SHA256TransformBlocks produces a very high load. One solution is to change the checksum parameter to edonr that is a much faster hashing algorithm and works well with dedup.

zfs set checksum=edonr TANK

where TANK is the name of the ZFS pool.

Typically a ZFS pool cannot be set to compress or encrypt such that all those features are only available to datasets within the pool. However, it would be nice to be able to set the features on the pool and then for the datasets to inherit the settings automatically when they are created within the pool.

In order to enable features like encryption or compression when creating a ZFS pool, use the uppercase O parameter instead of the lowercase o parameter when specifying the feature.

For example, the following command creates a RAIDZ pool named storage out of three drives with encryption and compression enabled:

zpool create -f -o ashift=12 -o feature@encryption=enabled -O encryption=on -O keyformat=raw -O keylocation=file:///etc/zfs/private/storage.key -O compression=on -m /mnt/storage storage raidz /dev/sda /dev/sdb /dev/sdc

Later, when creating a dataset within the pool, for instance, named keel:

zfs create storage/keel

all the options are inherited from the storage ZFS pool as can be verified using zfs get in order to list the dataset parameters:

# zfs get compression storage/keel
NAME            PROPERTY     VALUE           SOURCE
storage/keel  compression  on              inherited from storage