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:

Another variant is to install cryptsetup and then issue:

cryptsetup benchmark

in order to determine which encryption algorithm and the hashing algorithm is the fastest on the platform. Sometimes, the results are mildly surprising due to the combination between the platform hardware and the implementation of the algorithms. For example, modern processors have hardware acceleration for AES such that any algorithms that are based on AES will be faster. More of the same applies to hashes like SHA that are very common and implementations are typically very fast because they are considered to be the next-level up since MD5 was susceptible to rainbow table attacks.

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

Whilst partitions and filesystems are identified by UUID, for example, to list UUIDs of existing partitions on the drives connected to the system, just issue blkid, hardware devices that act as hard-drives (this includes drives that are just logically acting as hard-drives via the BIOS) can be identified by the World Wide Name (WWN) number.

Just like UUIDs, the WWN is a hash generated by taking into consideration the actual hardware serial number of the device such that the WWN will be stable between operating systems and/or other environments, in case the drives would be removed and plugged into a different machine.

In the older days, stable identifiers were not used and even RAID arrays were created by specifing the component sd* drives which lead to a recovery disaster when the drives were placed in a different machine that would reorder them. For instance, the /etc/fstab file would have had to be updated because the partition mounts, including the root filesystem would not correspond to the correct drive and the machine would not boot up anymore.

In order to find the disk mapping, for example, to determine which sd* drive corresponds to which WWN number, simply issue:

ls -l /dev/disk/by-id/*

that should list the WWN number as a symlink to the sd* device name.

Upon failure of a drive, the failed drive can be first removed (even physically) and then physically replaced, after which a zpool replace command can be used to rebuild the tank.

For example:

zpool replace -f storage wwn-0x5000cca291f677bb wwn-0x50014ee20de4418e

will replace drive wwn-0x5000cca291f677bb by wwn-0x50014ee20de4418e.

The way the replacing will take place is that the ZFS array will start resilvering, which will take a long while and the new drive will then become part of the tank after the resilvering has completed.