Zoned Namespace (ZNS) SSDs

• ZNS SSDs are NVMe devices that divide storage into contiguous, sequential-write zones to reduce write amplification and improve flash endurance.
• They shift the flash management burden from internal FTL to host software, enabling lifetime- and affinity-aware placement and predictable garbage collection.
• Integration across block, filesystem, and application layers introduces complexity but allows optimizations in log-structured systems and caching architectures.

Searching arXiv for recent and foundational papers on ZNS SSDs to ground the article in published work. Zoned Namespace (ZNS) SSDs are NVMe flash devices that expose storage as zones rather than as a fully random-write linear block address space. In this model, storage is divided into contiguous, write-once zones, each managed as a sequential append-only space; writes must be sequential within a zone, reads remain unconstrained, and reclamation is expressed through host-visible zone reset rather than fully hidden device garbage collection (Ren et al., 10 Jul 2025, Tehrany et al., 2022). ZNS therefore shifts part of flash management from the device’s flash translation layer (FTL) to host software, with the stated aims of reducing the “block interface tax,” lowering write amplification, making garbage-collection overheads more predictable, and allowing lifetime- and affinity-aware placement, while also introducing substantial software obligations and integration complexity (Purandare et al., 1 Jan 2025, Tehrany et al., 2022).

1. Interface model and command semantics

A ZNS namespace is partitioned into zones, each of which is a contiguous logical block address range and the basic unit of sequential writing and reclamation. The interface distinguishes zone size from zone capacity, with the relation

$\text{zone capacity} \le \text{zone size},$

because zone capacity is aligned to the flash erase unit while zone size is kept a power of two for easy LBA-to-zone-offset conversion (Tehrany et al., 2022). On one evaluated device, the reported geometry was a 7.2 TiB namespace with zone size 2048 MiB, zone capacity 1077 MiB, and 3688 zones, while another study on a 1 TB ZN540 reported zone size 2,048 MiB, zone capacity 1,077 MiB, total zones 904, and max active zones 14 (Tehrany et al., 2022, Doekemeijer et al., 2023).

Each zone has a write pointer. Ordinary zone writes must occur exactly at the current write pointer and advance it after completion; consequently, when using ordinary writes, only one in-flight write per zone is safely permitted unless the host stack provides ordering and merging support (Doekemeijer et al., 2023). ZNS therefore adds zone append, in which the host specifies the zone but not the final in-zone offset; the controller places the write at the current write pointer and returns the resulting LBA, enabling multiple concurrent appends to the same zone (Tehrany et al., 2022, Doekemeijer et al., 2023).

The host must also manage zone lifecycle. Reported zone-state vocabularies include EMPTY, OPEN, FULL, CLOSED, OFFLINE, and READ-ONLY, while operational discussions also emphasize finished/full terminal states and the commands open, close, finish, and reset (Tehrany et al., 2022, Doekemeijer et al., 2023). Active zones are resource-bounded because open or closed zones consume device resources such as buffers and metadata structures; the tested namespaces in several studies exposed a limit of 14 active zones (Tehrany et al., 2022, Doekemeijer et al., 2023). The Linux-oriented analysis further stresses that ZNS requires direct I/O, because buffered writeback through the page cache can violate the required sequential write order (Tehrany et al., 2022).

2. Flash-management rationale and measured device behavior

The architectural motivation for ZNS is the mismatch between NAND flash physics and the conventional block interface. NAND flash cannot overwrite pages in place; updates generate new versions elsewhere, invalidate old pages, and eventually force garbage collection that migrates still-valid pages before erasing blocks. Conventional SSDs hide this with an FTL that performs logical-to-physical mapping, garbage collection, wear leveling, and related management, but the result is write amplification, overprovisioning pressure, endurance loss, latency spikes, and unpredictable performance (Ren et al., 10 Jul 2025). ZNS is presented as a host-assisted compromise: it does not expose raw flash as in classic open-channel SSDs, but it does require the host to respect sequentiality and makes reclamation timing explicit (Ren et al., 10 Jul 2025, Tehrany et al., 2022).

This shift has direct performance consequences. On a commercially available ZNS SSD, larger I/O sizes were required to saturate write bandwidth: writes needed block size $\ge 16$ KiB to reach peak write bandwidth, while sequential reads increased to about 2 GiB/s and sequential writes plateaued around 1 GiB/s on the tested device (Tehrany et al., 2022). A more systematic characterization of a ZN540 further reported that writes had up to 23% lower latency than appends, that intra-zone parallelism generally outperformed inter-zone scaling, and that large requests, especially $\ge 8$ KiB, were needed to reach the device bandwidth limit of about 1.2 GiB/s (Doekemeijer et al., 2023).

The same characterization shows that zone-management commands are not negligible. Reset latency increased with zone occupancy, reaching about 11.60 ms for a half-full zone and about 16.19 ms for a full zone, while finish latency decreased roughly linearly with occupancy, from 907.51 ms at $< 0.1\%$ occupancy to 3.07 ms near-full (Doekemeijer et al., 2023). This matters because finish is sometimes treated as a minor bookkeeping transition; the measurements show it can be one of the most expensive host-visible operations in the interface. At the same time, the same study reported that under heavy concurrent write pressure, ZNS provided about $3\times$ higher read throughput than a comparable conventional NVMe SSD, and with concurrent writes at peak rate and queue depth 1 the $95^{th}$-percentile read latency was 299.89 ms on the conventional device versus 98.04 ms on ZNS (Doekemeijer et al., 2023). This supports the recurring claim that ZNS reduces hidden device-side garbage-collection interference, even though it does not eliminate all interference or all host-visible management costs.

3. Host-stack integration and the question of placement ownership

The Linux-oriented integration literature identifies three main places where ZNS awareness can enter the stack: the block-device layer, the filesystem layer, and the application layer (Tehrany et al., 2022). Block-device-level translation is the least intrusive but recreates FTL-like logic in software. Filesystem-level integration is exemplified by F2FS, which aligns segments to zone size, handles zone capacity and active-zone limits, but still requires a separate randomly writable block device for metadata and write caching (Tehrany et al., 2022). Application-level integration is exemplified by ZenFS for RocksDB/MySQL, which maps files to extents within zones and groups data by expected lifetime, but also requires an auxiliary metadata path on a conventional filesystem (Tehrany et al., 2022).

A persistent theme in later work is that ZNS is technically valuable but that the burden of ZNS-specific logic has repeatedly been placed in software layers that are costly to evolve. One line of work argues that ZNS is promising precisely because it lets the host participate in flash-friendly placement, but that adoption remains shallow because the software stack has put the burden in the wrong place; its answer is a userspace shim layer that intercepts ordinary file calls, implements affinity- and lifetime-based placement, and translates an internal placement model onto ZNS zones without requiring application, kernel, or operating-system changes (Purandare et al., 1 Jan 2025). The same work reports that writing directly to zonefs with one file per zone achieves full device bandwidth, while F2FS on ZNS achieves only about 30–50% of that bandwidth with $2\text{–}3\times$ higher latency, attributing the gap to filesystem overheads such as caching, metadata churn, synchronization, and lock contention (Purandare et al., 1 Jan 2025).

The host-guided-interface lineage is explicitly unstable:

Interface	Introduced	Linux support
Multi-Stream	2016	deprecated
Open-Channel	2017	deprecated
Zoned Namespaces	2021	present
Flexible Data Placement	2022	not yet broadly surfaced via the stack

This progression is used to argue that without a stable adaptation layer, ZNS risks joining a “graveyard” of under-adopted interfaces despite its technical advantages (Purandare et al., 1 Jan 2025). The point is not that ZNS lacks merit, but that applications and kernels may not be the right long-term home for interface-specific placement logic (Purandare et al., 1 Jan 2025).

4. Data placement, reclamation, and cross-layer observability

The host-side value proposition of ZNS is fundamentally a data-placement proposition. Two recurrent placement goals are lifetime-aware placement and affinity-aware placement: data with similar expected lifetime should be colocated so that zones can be reclaimed with little or no relocation, while independent write streams should be separated to reduce interference in device buffers and flash resources (Purandare et al., 1 Jan 2025). A userspace ZNS backend built around this view represents each file as an extent list keyed by $(zone, offset)$, maps streams to zones, writes each stream sequentially into that stream’s current zone, and performs lazy GC by marking extents invalid on delete and resetting zones immediately when all extents in a zone are invalid (Purandare et al., 1 Jan 2025). The same work formalizes a compact memory accounting model: $\text{The buffer cache (Extent Size %%%%0%%%% Writeable Files) + \ ZoneMap (32 bits %%%%1%%%% Addressable Zones) + \ Stream Hints (64 bits %%%%2%%%% Hint Streams) + \ File Data (64 bits %%%%3%%%% Extents per File %%%%4%%%% Open Files)}$ and reports 32 MiB buffers with 2 write streams, totaling 64 MiB of write buffers, with peak engine memory of 73 MiB versus about 200 MiB for F2FS in the same experiments (Purandare et al., 1 Jan 2025).

However, making the contract explicit does not guarantee that the stack respects it. An end-to-end study using zns.tools argues that ZNS converts classic SSD “unwritten contracts” into more written, host-visible responsibilities, but that hints are not contracts and semantic intent can still be lost between application, filesystem, kernel, and device (Tehrany et al., 2023). The toolchain—zns.fiemap, zns.segmap, zns.imap, and zns.trace—correlates file extents, F2FS segment hotness, inode placement, and per-zone I/O/reset traces, and uses that to reveal two concrete “Grouping by death time” violations in RocksDB-on-F2FS over ZNS: F2FS GC can reclassify moved data blocks as cold regardless of original classification, and RocksDB SSTable footers smaller than one page can be written to the hot data segment because they fall below F2FS’s minimum threshold of 16 pages (Tehrany et al., 2023). The same study reports reset hotspots in inode zones and shows that aging the filesystem changes reset profiles materially, implying that fresh-device evaluations can mischaracterize steady-state ZNS behavior (Tehrany et al., 2023).

This suggests that, for ZNS, the control plane and the observability plane are inseparable. Host-managed placement is useful only to the extent that the intended grouping survives the application, filesystem, and runtime stack (Tehrany et al., 2023, Purandare et al., 1 Jan 2025).

5. Systems built for ZNS SSDs

ZNS is especially congenial to log-structured systems. A survey of device-level SSD optimization states that the sequential characteristics of LSM-trees naturally align with ZNS SSDs’ sequential-write constraints, and highlights designs such as revisiting LSM-tree KV stores for ZNS, lifetime-aware compaction, SplitZNS, and WALTZ using zone append to reduce compaction tail latency (Ren et al., 10 Jul 2025). The same survey also emphasizes that ZNS is useful for cloud data-storage caches, object-like patterns, and host-SSD co-design more broadly, while warning that poor zone management can worsen wear and that valid-data migration remains a live issue even in zoned designs (Ren et al., 10 Jul 2025).

Application-level results illustrate both the upside and the engineering diversity. A userspace shim-backed ZNS path reported almost $2\times$ the write throughput of F2FS for RocksDB inserts and updates and MongoDB/WiredTiger gains of more than $\ge 16$0 higher throughput on multi-threaded reads and up to $\ge 16$1 higher throughput on write-heavy workloads, with p50 read latency of $\ge 16$2 versus $\ge 16$3 and p50 update latency of $\ge 16$4 versus $\ge 16$5 (Purandare et al., 1 Jan 2025). On the same line, the MongoDB study also exposed an important limitation of pure zoned placement: mmap-based log writes require in-place, out-of-order updates, so those files were routed to the conventional random-write region while bulk LSM data remained on sequential zones (Purandare et al., 1 Jan 2025). A hybrid zoned-storage middleware for RocksDB, spanning a ZNS SSD and an HM-SMR HDD, used flush, compaction, and cache hints to control placement, migration, and caching; with a 200 GiB dataset of 1 KiB KV objects, it improved load throughput by 7.8% and workloads A–F by 21.0–56.4% over its best static baseline, and by 18.3% and 28.0–69.3% over AUTO, respectively (Li et al., 2022).

Other systems use ZNS for reliability or caching rather than only for single-device placement. ZapRAID builds parity RAID over multiple ZNS SSDs by combining group-based stripe layout with hybrid use of Zone Append and Zone Write; relative to ZoneWrite-Only, it reports 72.8% higher throughput for 4 KiB writes and 77.2% higher throughput for 8 KiB writes while maintaining high performance in normal reads, degraded reads, crash recovery, and full-drive recovery (Li et al., 2024). Z-CacheLib redesigns CacheLib around a zone-native storage engine plus cross-layer policies such as virtual over-provisioning, zLRU, and zDrop; it reports up to $\ge 16$6 throughput, 5% improvement in hit ratio, and almost no write amplification compared with CacheLib on compatible regular SSDs, and up to $\ge 16$7 throughput with 92% write-amplification reduction relative to an F2FS-based scheme (Yang et al., 2024). At the tiny-object end, Nemo argues that even when ZNS or FDP makes device-level write amplification low, application-level write amplification can still dominate; on a real ZN540, it reports write amplification 1.56 versus 15.2 for FairyWREN, with total memory overhead 8.3 bits/object and similar miss ratio (Yang et al., 10 Mar 2026).

A complementary database perspective comes from ZLeanStore, which argues that out-of-place writes are the enabling condition for writing well to SSDs in general and to ZNS in particular. It states that to guarantee SSD WAF of 1, ZNS enforces sequential writes within each zone and shifts GC responsibility to the host, and that an engine already built around translation, out-of-place writes, and its own GC can therefore support ZNS naturally (Lee et al., 10 Mar 2026). This suggests that ZNS tends to reward software that is already log-structured or willing to become so.

6. Limitations, competing interfaces, and open directions

The principal limitation of ZNS is not the absence of value but the cost of cooperation. A detailed comparison with Flexible Data Placement (FDP) states that, for ZNS, supported write patterns are sequential only, the placement primitive is zones, garbage collection is host-based, NAND media management by host is no, and the ability to run applications unchanged is no; FDP, by contrast, supports random and sequential writes, uses reclaim unit handles, keeps garbage collection SSD-based with feedback through logs, and allows application compatibility as yes (Allison et al., 21 Feb 2025). The same paper frames FDP as filling the “cost-benefit gap” between ZNS and conventional SSDs, particularly for systems that need host-guided segregation but cannot justify a rewrite around zone semantics (Allison et al., 21 Feb 2025).

Even within ZNS itself, the idealized story of “no device-side write amplification” is incomplete. A later study argues that current ZNS implementations still incur device-level write amplification, increased wear, and host-I/O interference because of two design decisions: fixed physical zones and full-zone operations (Bagashvili et al., 24 Oct 2025). It defines

$\ge 16$8

and shows that finishing partially written zones can trigger dummy writes into unwritten space. Its proposed SilentZNS maps logical zones to dynamically allocated storage elements rather than fixed physical zones and reports up to $\ge 16$9 less dummy data, 86% less DLWA at 10% zone occupancy, up to 76.9% less overall wear, and up to $\ge 8$0 faster workload execution (Bagashvili et al., 24 Oct 2025). This is a substantive correction to the common misconception that exposing zones automatically eliminates all hidden internal write costs.

Software and platform limitations remain equally important. The userspace-shim approach that avoids kernel changes is explicitly restricted: LD_PRELOAD cannot handle statically linked applications, is ineffective for ecosystems that bypass libc such as many Go or Java applications, and complex client-server process trees may lose interception across fork/exec boundaries (Purandare et al., 1 Jan 2025). Consumer-oriented emulation work further shows that zoned storage under tight SRAM, write-buffer, and hybrid SLC/TLC constraints behaves differently from enterprise ZNS assumptions; in one F2FS case study, zoned storage achieved 35.6 MiB/s on random 4 KiB updates to a 2 GiB file, while block-adaptive reached 84.9 MiB/s, with filesystem write amplification 3.81 for zoned versus near 1 for block-adaptive (Yu et al., 4 Sep 2025). This suggests that bringing zoned semantics into mobile or consumer platforms will require more than reusing datacenter-era ZNS software assumptions.

Open directions therefore concern both interfaces and software structure. The survey literature highlights fairness under sequential constraints, elastic zone sizing, size-flexible and parity-protected zones, in-storage zone compaction, RAID parity updates through ZRWA, compression under host-SSD collaboration, and the growing pressure of QLC/PLC endurance limits and AI/LLM-oriented workloads (Ren et al., 10 Jul 2025). Across these proposals, the recurring lesson is stable: ZNS is neither a drop-in replacement for the block interface nor a complete host-managed flash substrate in the open-channel sense. It is a cooperative interface whose benefits depend on where placement logic lives, how faithfully cross-layer intent is preserved, and how carefully the host and device divide responsibility for allocation, ordering, reclamation, and observability (Purandare et al., 1 Jan 2025, Ren et al., 10 Jul 2025).