Somewhat confusingly, ashift is actually the binary exponent which represents sector size.
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.
WARNING: The ashift property is per-vdev, not per pool, as is commonly and mistakenly thought!
And it is immutable, once set.
If you accidentally flub ashift when adding a new vdev to a pool, you have irrevocably contaminated that pool with a drastically under-performing vdev, and generally have no recourse but to destroy the pool and start over.
Even vdev removal cannot save you from a flubbed ashift setting!