Discard is not zeroing: what TRIM, UNMAP and fstrim actually promise

Published 11 October 2026 · Specification review, not a device benchmark

Discard says that logical ranges are no longer needed. It does not, by itself, establish zero-filled reads, recovered physical capacity or sanitization. Each of those claims needs different evidence.

Related operations, different contracts

Do not treat protocol names as aliases. The sg3_utils manual identifies UNMAP as a SCSI logical-block-provisioning command and relates it to ATA DATA SET MANAGEMENT with Trim. SCSI WRITE SAME can also request unmapping. The shared purpose does not make the command encodings or capabilities interchangeable. [1]

Choose the observation that matches the question, not just the tool name.
Operation	What it addresses	What not to infer
ATA TRIM / SCSI UNMAP	Protocol-specific block deallocation	Interchangeable commands or a physical erase certificate
Filesystem fstrim	Unused filesystem ranges eligible for discard	Newly recovered physical bytes
Ordinary blkdiscard	Selected device ranges, potentially the entire device	A safe probe or a zero-fill request
blkdiscard zeroout	Zero-filling instead of ordinary discard	Removal of every hidden old copy

The last two rows are deliberately separate: util-linux documents zeroout and secure discard as distinct options. Secure discard requires device support and covers garbage-collection copies. Direct block discard can destroy live data; filesystem-aware selection and direct device access are not interchangeable workflows. No destructive command is needed to understand these distinctions. [6]

NVMe: request acceptance is not the read contract

In NVMe 1.4a, Dataset Management is advisory: ranges may remain allocated. For actually deallocated blocks, DLFEAT identifies read values; supported and enabled DULBE can instead require a deallocated/unwritten-block error. With that error disabled, section 6.7.1.1 specifies zeros, FFh bytes, or either pattern according to DLFEAT. A deterministic value is not necessarily zero. These rules apply to that cited revision and state, not every successful discard request. [2, sections 6.7 and 6.7.1.1; Figure 247]

Diagnostic consequence: record the command, advertised namespace capability and active error policy together. A single returned buffer leaves too much context missing to establish which contract was exercised.

Why the fstrim number is not a reclamation meter

The util-linux manual describes verbose output as bytes submitted for potential discard. Repeating a run can report the same ranges again. Adjustments deeper in the block stack need not be reflected in that number. Adding successive reports therefore does not measure unique physical space returned to an SSD or storage pool. [3, verbose option]

For capacity planning, compare allocation counters at the layer whose capacity you manage and record the observation times. A filesystem's free-space total and a backend's allocated-space total answer different questions. This is an operational inference, not a claim that we measured a particular array.

Two easily misread Linux details

discard_zeroes_data is not a live zero-read capability test. Linux 6.12's stable ABI documentation says it always reports zero and should not be relied upon. The separate maximum-discard attributes describe request limits, not sanitization or readback guarantees. The software maximum can be reduced to limit individual requests on devices with long discard latency; that is a tuning option, not evidence that a particular workload will improve. [4]

Device-mapper thin provisioning adds another boundary. no_discard_passdown removes the thin mapping without forwarding discard to the underlying data device. ignore_discard disables discard support instead. Removing a mapping at one layer therefore does not prove that NAND below it received an erase operation. Record which layer accepted the request and which layer's allocation you inspected. [5, optional feature arguments]

Why logical readback cannot inspect hidden copies

Wei, Grupp, Spada and Swanson's FAST 2011 study used recognizable data patterns and raw flash extraction after erasure procedures. Its method crossed the translation-layer boundary instead of trusting only host-visible reads. Out-of-place writes and garbage collection can leave physical copies outside the currently mapped logical address. [7, sections 2.2 and 3]

That historical laboratory evidence supports a distinction between logical visibility and physical remnants. It does not give a failure rate for today's NVMe drives or prove that every current implementation behaves identically. For disposal assurance, use the separate sanitization evidence review; this article concerns routine deallocation semantics.

A compact investigation record

Hesela's synthesis is to separate four observations before declaring success:

Selection: which filesystem or caller declared the ranges unused?
Propagation: which storage layers accepted, translated or stopped the request?
Read semantics: what capability and error policy apply at the interface being read?
Allocation: which backend counter changed, over what interval and with what concurrent activity?

Sanitization is a separate assurance question. Do not relabel this record as an erasure certificate. Avoid experiments against a live device; even a command intended to inspect behavior may be destructive if it issues discard.

Method and limits

We reviewed the named specification sections, upstream documentation and the FAST paper's mechanisms and experimental method. No drive was discarded, zeroed or tested; there are no new throughput, capacity or erasure measurements here. Linux 6.12, util-linux 2.41.2 and NVMe 1.4a are explicit reference versions, not claims about the newest releases. Verify the deployed implementation before applying any operational conclusion.

The corpus now distinguishes discard, ATA TRIM, SCSI UNMAP, thin provisioning and deallocated read behavior. The legacy UNMAP identifier remains available for existing consumers.

Primary sources

Accessed 11 October 2026, Europe/Warsaw. This is a source-linked engineering explanation, not a reproduction of the FAST experiment.