SSD Simulator
Advanced

Zoned Namespaces (ZNS): Giving the Host Control

A newer kind of SSD that trades convenience for dramatically lower write amplification.

A conventional SSD hides all its complexity behind the FTL — the host just writes anywhere and the drive sorts it out. Zoned Namespace (ZNS) SSDs take a different deal: they expose the flash as zones that must be written sequentially, and they hand garbage collection responsibility to the host. In return, write amplification can drop close to the ideal 1.0.

A zone is a large region of blocks with one rule: you may only append to it in order (a moving write pointer), and to reuse it you must reset the whole zone at once. The device does no garbage collection itself.
A zone: append-only, then reset the whole thing written (sequential) write pointer must stay erased → To rewrite: RESET the entire zone (erase all its blocks) and start over at the top. Because a zone resets as a unit, there's no mixed valid/invalid mess to clean up mid-zone.
No in-place updates, no random writes — just append and whole-zone reset. Simpler flash, smarter host.

Why ZNS lowers write amplification

On a conventional SSD, hot and cold data get mixed inside the same blocks, so garbage collection constantly copies cold data just to reclaim space near hot data. ZNS lets the host place data deliberately — and the biggest win is hot/cold separation:

  • Put frequently-updated (hot) data in its own zones. They fill entirely with soon-to-be-dead data, so when reset, almost nothing needs saving.
  • Put write-once (cold) data in separate zones. They stay valid and are rarely reset.
With hot and cold data physically separated, a hot zone becomes nearly all-invalid before reset → almost zero pages to migrate → write amplification approaches 1.0. A conventional device can't do this without host hints.
Analogy. Conventional GC is a recycling bin where paper, glass, and food scraps are mixed — every time you empty it you must sort out the still-good items. ZNS gives you separate bins up front, so emptying the 'trash' bin means just tipping it out — nothing to rescue.

The trade-off

ZNS isn't free lunch. The host (or file system / database) must be zone-aware: it has to write sequentially, track zones, and run its own garbage collection. That's more software complexity in exchange for lower amplification, more predictable latency, and longer flash life.

In the EyanaSSDSim paper & simulator. The Live Simulator has a full ZNS mode. Pick it, choose Blocks/zone, and toggle hot/cold separation. On a real trace, conventional WAF ≈ 2.4 while ZNS hot/cold drops to ≈ 1.1 — you can watch individual zones fill, get chosen for reset, and clear. This is the follow-up direction the paper discusses.