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.

Picking a hashing algorithm for zfs would rely on the constraints of the implementation but also on the speed. Fortunately, on Linux, the file /proc/spl/kstat/zfs/chksum_bench can be checked for a list of hashing algorithms supported by ZFS and their benchmarked speed. For example, here is some output from a generic machine (more is better):

implementation               1k      4k     16k     64k    256k      1m      4m     16m
edonr-generic               565     666     679     676     675     658     653     635
skein-generic               237     255     264     263     263     260     253     258
sha256-generic               83      88      90      91      90      81      90      91
sha256-x64                  109     119      93     121     121     120     121     121
sha256-ssse3                136     150     156     159     159     160     161     162
sha256-shani                375     492     487     515     544     536     536     537
sha512-generic              102     118     129     138     131     138     141     139
sha512-x64                  154     164     171     171     179     187     188     189
blake3-generic              144     146     144     140     140     137     137     137
blake3-sse2                 187     647     698     719     712     696     669     683
blake3-sse41                201     718     770     787     785     749     741     738

which is easy to plot using gnuplot:

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