What ZFS pool, vdev and dataset properties should most people use?

Question

ZFS has many different configurable properties for pools, for vdevs and for datasets. Many of those can be changed at any point, but some can only be set at creation time (or only affect data written afterwards so should really be set at creation time).

As a noob I searched for many different questions and found several properties that were suggested to be set a lot.

Obviously each use case will have little differences on what properties make sense, but there seems to be a common set of properties that most zfs users should use. I'm thinking of those properties for which one should have an active reason not to use them. What are those and why?

Answer 1

(Disclaimer: as a ZFS beginner, this is only my understanding this far and is meant as a impetus for more complete and reliable information from others).

Pool properties

• ashift=12

  At a basic level this ensures that read/write operations of ZFS align with the block boundaries of the underlying storage. Theoretically for 512-byte blocks ashift=9 would be fine, but drives with those are rare these days and the penalty for having ashift set "too high" is rather low.

• autotrim=on

  Automatically inform the underlying block storage when some space is no longer needed. Especially useful on SSDs but seems to not hurt on classic HDDs either (though it likely won't help there).

Dataset properties

These can be specified with zfs create -o or via the -O switch of zpool create for the root filesystem (which will by default be inherited to others).

• xattr=sa

  The significantly increases the performance of xattr with no real drawback. (Only available on Linux for now).

• dnodesize=auto

  This property should be used when using xattr=sa. The primary reason not to use these is interacting with systems that don't support the required ZFS feature.

• relatime=on

  Tracking the access time of files can be very expensive even in read-only interaction. relatime signficiantly reduces the granularity/frequency of these updates at the cost of less precise information in the atime property (while maintaining some commonly require invariants). Note that this is the default for almost all filesystems on Linux for a long while for now. If one needs precise atime information, then don't turn this on. If one knows that atime is never needed then atime=off provides even better performance.

• normalization=formD

  This will ensure that file names are always normalized the same way. As a major side-effect this also means that the file system will treat file names as UTF-8 encoded and can no longer store file names with certain "broken" names that other file systems accept. If this isn't desired, then leave this out.

• compression=lz4

  The consensus seems to be that the cost of compression is so low on modern hardware that this has effectively only upside. Datasets that store predominantly already-heavily-compressed data might want to turn this off.

• no recordsize

  The default recordsize seems to be a good middle ground for many usecases, but some use cases like databases might benefit from specific values.

Sources

• Debian Root on ZFS
• Many individual forum posts