---
title: "Zoned NVMe Is a Different Write Contract: Zone Capacity Is Not Zone Size"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/zoned-nvme-ssd-write-contract-and-zone-capacity"
last-updated: "2026-10-20"
---

# Zoned NVMe Is a Different Write Contract: Zone Capacity Is Not Zone Size

Leviathan Systems — Technical content
Published 2026-10-20; updated 2026-10-20.

Matching NVMe and advertised TB does not establish the same write behavior. A zoned namespace divides its address space into zones with state-dependent write rules. Zone size counts the blocks in a zone's address span; zone capacity limits the user-data blocks writable from an empty zone. Establish which software layer honors that contract before treating a zoned SSD as an interchangeable offer.

## Identify the write contract behind the NVMe label

An SSD offer can match another offer's NVMe interface label, advertised TB and benchmark headline while leaving a more basic question unanswered: what writes will the host-visible namespace accept?

NVM Express defines Zoned Namespaces, or ZNS, as a specific I/O command set. Its zones make write placement part of the host/device agreement. This matters when an application expects to change an existing record at its current address. A device that accepts the data's original placement has not thereby promised to accept that later replacement at the same address.

The examples here begin with empty Sequential Write Required zones, have no associated optional Zone Random Write Area (ZRWA), and stipulate constant zone capacities. They explain a buying distinction without defining an operating procedure. Optional ZRWA support permits different write behavior within a defined area, so the precise feature set belongs in the supplier's explanation.

References: [ZN2](https://nvmexpress.org/wp-content/uploads/NVM-Express-Zoned-Namespace-Command-Set-Specification-Revision-1.5-Ratified-2026.07.31.pdf)

## Separate the address span from writable capacity

Zone size, ZSZE, counts the logical blocks in a zone's address span. The zone start logical block address, ZSLBA, locates that span. Zone capacity, ZCAP, is the maximum number of logical blocks available for user data when that zone is Empty. It may be less than or equal to zone size.

Consequently, a zone spanning 128 logical blocks can have capacity for only 120 data blocks. The next zone still begins after the 128-block span. The eight remaining addresses do not extend the first zone's writable capacity.

Keep the block unit attached to both quantities. The sector-format guide linked below explains bytes per logical block. Zoning adds another distinction after that addressing unit is known.

References: [ZN1](https://nvmexpress.org/wp-content/uploads/NVM-Express-Zoned-Namespace-Command-Set-Specification-Revision-1.3-2025.03.11-Ratified-1.pdf), [Z1](https://zonedstorage.io/docs/introduction/zns)

## Four empty zones span 512 blocks but accept 480 data blocks

Consider an original hypothetical namespace containing exactly four empty zones. Each zone spans 128 logical blocks, each has a constant capacity of 120 data blocks, and each logical block contains 4,096 data bytes. These are invented inputs, not specifications for a marketed SSD.

The zone starts are logical block addresses 0, 128, 256 and 384. The first zone spans addresses 0 through 127, while its writable portion runs from 0 through 119. The final zone spans 384 through 511, with a writable portion from 384 through 503. The intervening zones follow the same pattern.

The entire address span is 4 x 128 = 512 logical blocks. At 4,096 bytes per block, that is 512 x 4,096 = 2,097,152 B.

The summed initially writable capacity is 4 x 120 = 480 data blocks, or 480 x 4,096 = 1,966,080 B.

The difference is 32 blocks, or 131,072 B. It represents addresses outside the writable portions of these four hypothetical zones. It is not writable spare space, a NAND reserve or a filesystem-free estimate.

A comparison that multiplies zone count by zone size would describe this namespace's address span. Using that same result as its initially writable user-data capacity would overstate the stipulated quantity by 131,072 B. The mistake occurs before any filesystem allocation or data-protection calculation enters the comparison.

References: [ZN1](https://nvmexpress.org/wp-content/uploads/NVM-Express-Zoned-Namespace-Command-Set-Specification-Revision-1.3-2025.03.11-Ratified-1.pdf), [Z1](https://zonedstorage.io/docs/introduction/zns)

## A readable old address need not accept replacement data

Now consider a later hypothetical snapshot of the first zone. Data has been successfully written to addresses 0 through 39, the zone is Implicitly Opened, and its valid write pointer is 40. Its capacity remains 120 blocks. For this snapshot, 120 - 40 = 80 blocks remain in its writable portion.

Older data at address 12 can still be read. An ordinary address-specific replacement write starting at 12, however, does not match the next write position of 40. Readability of the old record and permission to overwrite its location are separate properties.

Under the stated ordinary-write model, the starting address must match the valid write pointer. A fully successful write advances that pointer by the number of blocks written. The rule therefore constrains placement, even while writable capacity remains.

State matters too. A Full zone rejects writes and has no valid write pointer. ZCAP describes the capacity available from an Empty zone, not a live free-space counter or a promise that any address inside the zone can currently be changed. The snapshot arithmetic relies on the stated successful writes and current state.

References: [ZN1](https://nvmexpress.org/wp-content/uploads/NVM-Express-Zoned-Namespace-Command-Set-Specification-Revision-1.3-2025.03.11-Ratified-1.pdf), [ZN2](https://nvmexpress.org/wp-content/uploads/NVM-Express-Zoned-Namespace-Command-Set-Specification-Revision-1.5-Ratified-2026.07.31.pdf)

## Zone Append changes who assigns the location

Zone Append is optional in the ZNS specification. When supported, it identifies a destination zone while the controller assigns the logical blocks used within that zone. Completion reports the lowest logical block address assigned to the data.

That changes placement responsibility. Software must associate the returned location with the data it submitted. The operation does not give the host unrestricted permission to replace an arbitrary older record in place.

For the buyer, an offer naming Zone Append still needs an explanation of how the selected software uses its placement results. A controller placement feature alone does not supply the application's update policy.

References: [ZN2](https://nvmexpress.org/wp-content/uploads/NVM-Express-Zoned-Namespace-Command-Set-Specification-Revision-1.5-Ratified-2026.07.31.pdf)

## Ask which software layer honors the contract

Zoned-device support needs a named software path. Western Digital's Linux zoned-storage documentation distinguishes paths where a filesystem handles sequential-write constraints from paths where an adapted application remains responsible for them. A statement that the operating system recognizes the device leaves that distinction open.

For example, a supporting filesystem can turn application updates into sequential device writes. The application can change a logical record while the filesystem places its new contents at a different device logical block address. Replacing an application record and overwriting its previous device address are different actions.

The Linux kernel's zonefs documentation provides a concrete example. It exposes zones as files, but its sequential-zone files require append writes. That file interface preserves the sequential-write obligation for the application. A familiar file abstraction therefore does not, by itself, establish familiar update behavior.

Consider two fictional SSD offers with the same advertised byte capacity and headline read throughput. Offer A specifies a conventional namespace for the buyer's existing application path. Offer B specifies a zoned namespace but names no software component responsible for its write constraints. The shared labels leave B's application suitability unanswered. This comparison does not establish A's complete compatibility either; it identifies the additional evidence B needs.

A useful supplier explanation traces the exact offered device and namespace through the supported software versions to the interface the application uses. It identifies who handles placement, updates and the lifecycle of written data, and accounts for the device's zone capacities, optional features and open or active zone limits. Another NVMe label cannot fill those gaps.

The appointed platform and storage owners make the hardware selection. Once the write contract is resolved, compare workload evidence using the linked performance guide and rated-write evidence using the endurance guide. ZNS alone promises no throughput or lifetime improvement for the proposed workload.

References: [K1](https://docs.kernel.org/filesystems/zonefs.html), [K2](https://zonedstorage.io/docs/linux/overview), [Z1](https://zonedstorage.io/docs/introduction/zns)

## Bring a separately approved equipment package to the physical inquiry

If the selection leads to a separately approved equipment replacement package, Leviathan's Hardware Refresh & Physical Support service can discuss the surrounding physical work. The service page and project inquiry are linked below.

Share a nonconfidential summary of the equipment, approved replacement identities, site, appointed parts supplier and intended physical change. Storage software, data handling and return-to-service decisions need their separately assigned owners. The inquiry concerns the agreed equipment change, recabling and physical records; it does not establish zoned-device compatibility.

References: [L1](https://www.leviathansystems.co/services/data-center-remediation)

## Primary sources

- [ZN1 — NVM Express Zoned Namespace Command Set Specification, Revision 1.3, March 11, 2025](https://nvmexpress.org/wp-content/uploads/NVM-Express-Zoned-Namespace-Command-Set-Specification-Revision-1.3-2025.03.11-Ratified-1.pdf). Checked 2026-10-20. Section 2.1.1.2.1, Figure 38 and Appendix A.5 distinguish write-pointer behavior, per-zone writable capacity and zone size. The four-zone calculation uses original hypothetical inputs.
- [ZN2 — NVM Express Zoned Namespace Command Set Specification, Revision 1.5, July 31, 2026](https://nvmexpress.org/wp-content/uploads/NVM-Express-Zoned-Namespace-Command-Set-Specification-Revision-1.5-Ratified-2026.07.31.pdf). Checked 2026-10-20. Sections 2.1.1.2.1, 3.4.1 and 5.7, Figure 4 and Figure 9 support the state-dependent write rules, optional Zone Append placement and optional ZRWA distinction.
- [Z1 — Western Digital Zoned Storage: SSDs with NVMe Zoned Namespace support](https://zonedstorage.io/docs/introduction/zns). Checked 2026-10-20. The zone-size, zone-capacity and resource-limit explanations help distinguish logical address span, writable user-data capacity and limits on open or active zones.
- [K1 — Linux kernel documentation: ZoneFS, introduction and sequential zone files](https://docs.kernel.org/filesystems/zonefs.html). Checked 2026-10-20. The zonefs file abstraction leaves sequential-zone append-write constraints visible to applications. This is a specific software-interface example, not a recommendation for the proposed storage stack.
- [K2 — Western Digital Zoned Storage: Linux Zoned Storage Support Overview](https://zonedstorage.io/docs/linux/overview). Checked 2026-10-20. The overview distinguishes software paths that handle zone constraints in a filesystem or mapping layer from paths that expose them to applications.
- [L1 — Leviathan Systems: Hardware Refresh & Physical Support](https://www.leviathansystems.co/services/data-center-remediation). Checked 2026-10-20. Project-defined equipment replacement, recabling and physical records require an approved work package, identified parts responsibilities and separately assigned system decisions.

## Related Leviathan resources

- [Logical and physical sector formats: 512e and 4Kn](/articles/storage-512e-4kn-logical-physical-sector-formats)
- [Compare storage IOPS, throughput and latency](/articles/gpu-storage-iops-throughput-latency-comparison)
- [Compare SSD endurance, DWPD and total writes](/articles/gpu-ssd-endurance-dwpd-tbw-workload)
- [Distinguish raw, protected and client-usable capacity](/articles/gpu-storage-raw-versus-protected-usable-capacity)
- [Hardware refresh and physical support](/services/data-center-remediation)
- [Discuss a separately approved physical equipment change](/contact?service=data-center-remediation&from=%2Farticles%2Fzoned-nvme-ssd-write-contract-and-zone-capacity)

## Scope the physical work around an approved equipment package

Share the equipment, approved replacements, site, appointed parts supplier and intended physical change so Leviathan can discuss physical scope and availability.

[Discuss the scope](/contact?service=data-center-remediation&from=/articles/zoned-nvme-ssd-write-contract-and-zone-capacity)