A sector is the smallest physical unit that can be written to or read from its underlying device.

• For several decades, most disks used 512 byte sectors.
• More recently, most disks use 4KiB sectors, and some, particularly SSDs, use 8KiB sectors, or even larger.
• ZFS has a property which allows you to manually set the sector size, called ashift.

Somewhat confusingly, ashift is actually the binary exponent which represents sector size.

• For example, setting ashift=9 means your sector size will be 2^9, or 512 bytes.

ZFS queries the operating system for details about each block device as it is added to a new vdev.

• In theory it will automatically set ashift properly based on that information.
• Unfortunately, there are many disks that lie through their teeth about what their sector size is, in order to remain compatible with Windows XP (which was incapable of understanding disks with any other sector size).

• This means that a ZFS admin is strongly advised to be aware of the actual sector size of his or her devices, and manually set ashift accordingly.
• If ashift is set too low, an astronomical read/write amplification penalty is incurred.
  • Writing a 512 byte “sector” to a 4KiB real sector means having to write the first “sector”, then read the 4KiB sector, modify it with the second 512 byte “sector”, write it back out to a *new* 4KiB sector, and so forth, for every single write.

In real world terms, this amplification penalty hits a Samsung EVO SSD, which should have ashift=13, but lies about its sector size and therefore defaults to ashift=9 if not overridden by a savvy admin—hard enough to make it appear slower than a conventional rust disk.

By contrast, there is virtually no penalty to setting ashift too high.

• There is no real performance penalty, and slack space increases are infinitesimal (or zero, with compression enabled).
• It is strongly recommended that even for disks that really do use 512 byte sectors should be set ashift=12 or even ashift=13 for future-proofing.