Three ZFS settings make or break a pool's capacity and performance: how you lay out vdevs, ashift (sector size) and recordsize. Get them wrong and you waste capacity or IOPS. See the effect live in the ZFS calculator.
vdev layout sets capacity and IOPS
A pool is striped across its vdevs, so layout is the biggest lever. A RAIDZ vdev delivers roughly the random IOPS of a single drive, so pool IOPS scale with the number of vdevs — many narrow vdevs (or mirrors) for IOPS, fewer wide vdevs for capacity. Redundancy is per vdev, and a lost vdev loses the pool, so wider vdevs of large drives should use RAIDZ2/3.
You can't shrink a vdev or (until recently) easily change its width, so plan layout up front. See RAIDZ1 vs Z2 vs Z3.
ashift — match the physical sector size
ashift sets ZFS's smallest allocation unit as a power of two: ashift=12 = 4 KiB sectors (modern drives), ashift=9 = 512 B (legacy). Set it to match the drive's physical sector size at pool creation — it can't be changed later. Too small an ashift on a 4 KiB drive wrecks performance; ashift=12 is the safe modern default.
ashift also interacts with capacity: RAIDZ rounds allocations to a multiple of (parity+1) sectors, so larger sectors mean coarser rounding and more potential padding on small blocks.
recordsize — the capacity/perf dial
recordsize (datasets) or volblocksize (zvols) is the maximum logical block size. The 128 KiB default is great for general files and minimises RAIDZ padding. But small fixed blocks — an 8 or 16 KiB volblocksize for VM/database zvols — combined with RAIDZ's (parity+1) rounding can waste a large fraction of capacity to padding, and read-amplify if mismatched to the workload.
Rule of thumb: large recordsize for big sequential files, smaller for databases/VMs (and prefer mirror vdevs there). The calculator lets you change ashift and recordsize to watch the padding overhead move.