---
title: "An Unused NVMe Logical Block Can Return Zeros, FF or an Error"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/nvme-deallocated-block-read-contract"
last-updated: "2026-10-20"
---

# An Unused NVMe Logical Block Can Return Zeros, FF or an Error

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

A zero-filled scratch-space claim needs the read behavior of the actual namespace, including its supported error capability and current policy. In the cited NVMe NVM Command Set revision, deallocated or unwritten blocks can produce zero bytes, FF bytes or an indicated error under different conditions. Match that interface to the consumer’s expectation; a returned pattern alone establishes neither allocation state nor an accepted sanitization outcome.

## Start with what the scratch consumer expects

A local-storage offer for an AI staging or scratch workload may describe unused space as zero-filled. That description matters if the consumer expects to read those positions before supplying new data. It leaves a concrete question: what will that interface actually return?

An application expecting readable zero-valued data cannot treat an error as the same result. It also cannot treat a buffer of FF bytes as zero-valued input. FF is hexadecimal notation for a byte whose eight bits are all one, numerically 255. Neither pattern is an empty response: a full logical block still contains its declared number of data bytes.

Identify the interface in the offer. This article concerns selected logical-block reads at an NVMe namespace, not a filesystem’s treatment of a sparse file. A namespace supplies the logical address space for this comparison. An application using files or another storage service also needs the behavior of that intervening layer.

The purchase question is whether the supported storage path meets the consumer’s actual expectations. The word unused, by itself, supplies no answer.

## Read capability, policy and pattern together

The source here is NVM Express’s NVM Command Set Specification, Revision 1.3, dated July 31, 2026. Its section 3.3.3.2.1 and associated namespace and error-recovery fields describe the read behavior used below. The official index identifies this command-set revision separately from the NVMe Base specification. A general NVMe version label does not identify every applicable document or feature.

DAE reports support for the namespace’s deallocated/unwritten-block error; DULBE determines whether that error is enabled. Where supported and enabled, the affected read returns that error instead of a successful ordinary data result. With the error disabled, DRB describes the readable pattern: 001b specifies zero bytes, while 010b specifies FF bytes.

DRB 000b does not report which pattern to expect. In this revision, the permitted result is zero or FF, and a particular deallocated block’s readable value remains deterministic until a write. An unreported pattern therefore supplies no universal zero guarantee. A write ends the block’s deallocated/unwritten state; a read does not.

Retain the actual namespace capability and current policy, rather than infer them from a default, a similar drive or a product-family name. These statements describe the cited revision. They are not instructions to query or change a device, and they do not establish that an offered controller implements that revision.

References: [NR1](https://nvmexpress.org/wp-content/uploads/NVM-Express-NVM-Command-Set-Specification-Revision-1.3-Ratified-2026.07.31.pdf), [NR2](https://nvmexpress.org/specification/nvm-command-set-specification/)

## NVR-01: hold three logical states constant

NVR-01 is an original fictional comparison of three independent offers, Z, F and E. Each offers a conceptual namespace containing the same three selected logical blocks, L0, L1 and L2. Each block has exactly 4,096 data bytes. Separate metadata and protection information are excluded. No device operation or measurement is performed.

L0 has been written with zero-valued data and is stipulated to remain allocated. L1 is actually deallocated. L2 has never been written. These are supplied states, not conclusions from a free-space total, deletion record or deallocation request.

A successful Dataset Management command-completion receipt also does not prove that the selected blocks were actually deallocated. Revision 1.3 describes that command as advisory: the controller may take no action on the supplied information. NVR-01 therefore stipulates L1's actual state separately from any request or completion record. This distinction changes which read rule applies; it is not a device-operation instruction.

Z stipulates the reported zero-read pattern with the relevant error disabled. F stipulates the FF pattern with that error disabled. E stipulates that the namespace supports the error and that it is enabled. The offers retain the same selected logical states while differing in their read contract.

For each offer, compare three separate single-block reads, one for each selected block, with no state change or other fault. Keeping the reads separate avoids inferring partial payloads from a failed multi-block request.

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

## The same states produce three different results

Z supplies a successful 4,096-byte zero-filled result for each of L0, L1 and L2. Three successful blocks total 3 × 4,096 = 12,288 data bytes. The bytes at L0 match those at L1 and L2 even though the supplied allocation histories differ.

F supplies the same 4,096 zero bytes for L0. Its results for L1 and L2 contain FF bytes: 2 × 4,096 = 8,192 bytes of that different pattern. It also returns 12,288 successful data bytes overall. Equal returned length does not make the contents equal to Z’s.

E supplies 4,096 successful zero bytes for L0 and an indicated deallocated/unwritten read error for each of L1 and L2. Those two failures do not supply a successful 8,192-byte payload. Describing it as two blocks of zeros would invent data that the stipulated result did not return.

## Zero-valued content does not identify allocation state

In Z, looking only at the returned buffers would leave L0, L1 and L2 indistinguishable. Each contains 4,096 zero bytes. Yet the example expressly supplies one allocated written block, one deallocated block and one never-written block. The content observation cannot recover those different histories by itself.

That is a useful limit on a zero scan. Even if the selected reads successfully return the expected pattern, the result describes what that interface returned. It is not an inventory of physical NAND pages, a count of erased blocks or a report of which logical positions remain allocated.

F and E show the other side of the comparison. Their different results need interpretation against their supplied conditions. F’s FF pattern and E’s indicated errors are consistent with this case’s respective contracts. Neither result alone demonstrates damaged NAND, corruption of retained data or a defective SSD.

An unexplained error in a real submission still needs investigation. The fictional result does not excuse an unknown failure. It shows why the exact status and applicable behavior matter before a buyer converts a report into an equipment diagnosis.

## Compare the read contract with the consumer’s requirement

Now give the buyer a specific requirement. A fictional scratch consumer must receive readable, zero-valued data at L1 and L2 in their stipulated current states. Its initialized L0 data is also zero. Under the case’s conditions, Z matches that selected expectation. F returns different data, while E returns errors for the two positions. Neither supplies the result this consumer requires.

This supports a limited compatibility comparison. It does not make Z the best device, establish a complete application result or recommend changing F’s or E’s policy. A different consumer that never reads uninitialized regions would ask a different question. Its usable capacity, performance and recovery requirements would still need their own evaluation.

For an actual offer, ask the storage/platform owner to connect the namespace and firmware identity to the supported capability, current error policy and successful-read pattern. Then request evidence of the intended consumer’s behavior at the actual interface. A bare feature name cannot replace the current state, and an unavailable field must not be read as numeric zero.

Keep the returned status beside the data. A consumer’s explicit handling of an error is application behavior; the storage result does not silently perform it. Treating an unsuccessful read as an implicit zero-filled buffer would require an additional, justified application rule. It cannot be inferred from the count of logical blocks in the request.

## Keep file behavior and media disposition at their own layers

At the Linux regular-file interface, the documented unwritten gap described by lseek(2) reads as zero-valued bytes. That is a positive filesystem behavior the file consumer can use; it does not reveal what an underlying namespace would return for a deallocated logical block. The filesystem interface can therefore answer a different question from NVR-01's direct namespace reads. This case provides no file-offset-to-LBA map. The related sparse-file guide explains readable holes and allocation in more detail.

The garbage-collection guide follows invalid data, relocation and physical block erasure. Its internal-space account answers another question. A logical read contract does not identify how the controller produced the returned bytes or how much physical working space is available. The over-provisioning and thin-pool guides similarly retain their own capacity boundaries.

Media release requires a separate decision. NIST’s July 16, 2026 FAQ for SP 800-88r2 distinguishes verification of a technique’s completed outcome from the organization’s validation of effectiveness and residual confidentiality risk. NVR-01 supplies neither kind of sanitization evidence.

Zeros at these selected addresses cannot establish physical overwrite, an effective cryptographic erase, coverage of all relevant media or copies, or authorization to reuse or release equipment. Use the existing encryption and cryptographic-erasure guide for that assessment. The data/security owner and appointed specialists retain the disposition decision; this read comparison prescribes no technique.

References: [NR3](https://csrc.nist.gov/files/pubs/sp/800/88/r2/final/docs/sp800-88r2-faq.pdf), [NR4](https://man7.org/linux/man-pages/man2/lseek.2.html)

## Carry selected equipment into a physical installation scope

Accept the narrow read-behavior claim only when the applicable namespace evidence and the consumer’s requirement support it. Keep unresolved behavior with the storage/platform owner. The worked byte totals supply no throughput, endurance, recovery or whole-system capacity result.

If the resulting equipment selection also requires a physical installation, Leviathan’s rack-and-stack service is the route to discuss agreed mounting, physical IT cabling, labels and installation records. Use the linked project inquiry with a nonconfidential equipment summary, rack and connection plans, site and target window.

That physical work package does not include storage-policy configuration, application validation or sanitization. Identify the appointed owners for those tasks so the installation discussion can use their confirmed inputs without turning the read example into a new service promise.

## Primary sources

- [NR1 — NVM Express NVM Command Set Specification, Revision 1.3, July 31, 2026](https://nvmexpress.org/wp-content/uploads/NVM-Express-NVM-Command-Set-Specification-Revision-1.3-Ratified-2026.07.31.pdf). Checked 2026-10-20. Section 3.3.3 advisory Dataset Management behavior, section 3.3.3.2.1 and DULBE, DAE and DRB definitions. Version-specific read semantics, not a device test. © 2008 to 2026 NVM Express, Inc. ALL RIGHTS RESERVED.
- [NR2 — NVM Express: NVM Command Set specification index](https://nvmexpress.org/specification/nvm-command-set-specification/). Checked 2026-10-20. Identifies the cited command-set revision separately from the base and other specifications; not evidence of an installed controller version.
- [NR3 — NIST SP 800-88r2 FAQ, July 16, 2026: question 7](https://csrc.nist.gov/files/pubs/sp/800/88/r2/final/docs/sp800-88r2-faq.pdf). Checked 2026-10-20. Verification and validation distinction only. No media-specific technique, product endorsement or compliance claim is adopted.
- [NR4 — Linux man-pages 6.19: lseek(2), June 13, 2026](https://man7.org/linux/man-pages/man2/lseek.2.html). Checked 2026-10-20. Documented zero-valued reads of the unwritten file gap and limits of reported holes. Filesystem-interface semantics only; no command, file operation or underlying device mapping is supplied.

## Related Leviathan resources

- [SSD reclamation and workload-conditioned write performance](/articles/ssd-garbage-collection-versus-fresh-drive-performance)
- [SSD reserved capacity and filesystem free space](/articles/ssd-overprovisioning-controller-spare-capacity)
- [Sparse-file readable bytes and allocated blocks](/articles/sparse-file-holes-logical-size-allocated-blocks)
- [Thin-volume addresses and shared-pool backing](/articles/thin-storage-logical-volume-size-versus-pool-backing)
- [Encryption features and sanitization outcomes](/articles/gpu-storage-encryption-versus-cryptographic-erasure)
- [GPU Rack Assembly & Rack-and-Stack Services](/services/rack-and-stack)
- [Discuss a physical equipment installation](/contact?service=rack-and-stack&from=%2Farticles%2Fnvme-deallocated-block-read-contract)

## Discuss the physical installation of selected equipment

Share the equipment, released rack and connection plans, site and target window to discuss agreed mounting, IT cabling, labels and handoff records.

[Discuss the scope](/contact?service=rack-and-stack&from=/articles/nvme-deallocated-block-read-contract)