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.
View the data behind this chart
| Layer | Detail |
|---|---|
| Pool layout (vdevs) | IOPS scale with vdev count |
| RAIDZ level | Z1 / Z2 / Z3 parity per vdev |
| recordsize / volblocksize | 128 KiB default; small = padding |
| ashift (sector size) | ashift=12 (4 KiB), set at creation |
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.
View the data behind this chart
| 128 KiB | 32 KiB | 8 KiB (zvol) | |
|---|---|---|---|
| Padding overhead | Negligible | Some | Large |
| Good for | Files / media | Mixed | VM / DB zvols |
| Better on | RAIDZ2 | RAIDZ2 | Mirror vdevs |
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.