NVMe Protection Information: Block Checks and Their Limits

Locate the block behind the integrity claim

A storage offer describing end-to-end data integrity needs to identify the bytes and path it covers. A drive capability can be relevant without establishing that an application's data travels through the proposed protection mechanism.

This article uses the NVM Express NVM Command Set Specification, Revision 1.3, ratified July 31, 2026. In its model, optional metadata accompanies each logical block; Protection Information, or PI, occupies part or all of that metadata. Metadata support alone therefore does not establish PI use.

Begin with three quantities: data bytes per logical block, metadata bytes per logical block and PI bytes within that metadata. A sector-size label supplies only part of that description. The related sector-format article explains logical addressing; the decision here concerns the integrity information associated with those addressed blocks.

References: [PI1]

A 16-bit guard is only one part of eight PI bytes

For the specification's 16b Guard format with no storage tag, the PI layout is 2 guard bytes, 2 application-tag bytes and 4 reference-tag bytes: 2 + 2 + 4 = 8. The 16-bit label names the guard, not the whole PI structure. Revision 1.3 also defines other formats, so this layout must stay attached to its stated assumptions.

The guard carries a CRC-16 for checking the block's data. The application tag is opaque to the controller: a tag comparison can assess an expected value without interpreting its application meaning. The reference tag supports an association between data and an address. These roles are complementary.

For example, agreement with an application tag chosen by software does not tell the controller whether a training label is correct. To interpret an offer, ask what supplied that expected tag and what the comparison establishes. A field called application tag does not itself provide application-level validation.

References: [PI1]

Worked example: 1 MiB of data plus 16 KiB of metadata

This original fictional accounting example describes no device specification or measured transfer. Stipulate exactly 2,048 logical blocks, each with 512 data bytes and 8 metadata bytes. All 8 metadata bytes contain the no-storage-tag PI described above, and PI is retained at the boundary being counted.

The data quantity is 2,048 x 512 = 1,048,576 bytes, or 1 MiB. Metadata adds 2,048 x 8 = 16,384 bytes, or 16 KiB. Together they total 1,064,960 bytes, or 1,040 KiB. Here 1 KiB is 1,024 bytes and 1 MiB is 1,048,576 bytes.

The 16 KiB neither enlarges the original 1 MiB of user data nor stores a second copy of it. It carries the stipulated integrity fields. Reading 520 bytes per combined block as 520 data bytes would misclassify that metadata.

The specification permits metadata alongside each block in an extended-LBA buffer or in a separate metadata buffer. With all PI retained in this example, those presentations change how the bytes are arranged, not their count: either 2,048 data-plus-metadata units or a 1 MiB data buffer accompanied by 16 KiB of metadata. This is no estimate of physical NAND consumption, client-usable capacity or performance cost.

References: [PI1]

An intact block can arrive for the wrong expected address

Consider a separate symbolic example with two blocks at logical block addresses 400 and 401. Each has different data and a valid guard for its own data. Assume the named 8-byte PI layout, Type 1 protection, applicable guard and reference checks, and tag values that do not disable checking.

A checker expects block 400 but receives block 401's data together with block 401's unchanged PI. Its guard still agrees with the data it accompanies: nothing in that pair has changed. A guard-only comparison therefore leaves the address mistake unresolved.

The reference comparison supplies a different expectation. Under these assumptions, the received reference identifies 401 while the checker expects 400, exposing that mismatch. This example computes no CRC and describes no actual device test. It shows why preserving content and preserving its address association are distinct requirements; it does not promise detection of every error.

Protection type matters. Type 1 ties its reference expectation to the addressed LBA; Type 2 uses a command-supplied reference sequence without the same LBA constraint. Type 3 does not supply that same reference-address check. A buyer cannot extend the Type 1 example to every offer mentioning PI.

References: [PI1]

Separate capability, namespace selection and performed checks

An offer saying PI supported establishes less than one explaining the selected namespace and its use. The specification distinguishes metadata and protection capabilities from the selected format and protection-type settings. Command processing also determines the checks performed; special tag values can suppress checking.

Ask the supplier to connect its claim to the exact device and firmware, the relevant namespace's data and metadata sizes, its PI format and type, and the checks applicable to the proposed I/O path. This is an evidence request, not a request to change the storage format.

For the worked example, a supplier naming 512 data bytes and 8 metadata bytes has resolved the byte accounting. If it supplies only a capability statement, the active type and checking behavior remain open. Conversely, a documented Type 1 namespace still leaves the host and intervening path to be explained. Compare offers on the documented configuration, selected checks and supported path. A segment without evidence remains unverified; it cannot extend the claimed coverage.

References: [PI1]

Name where protection is generated and checked

The Linux Data Integrity document, dated December 24, 2007, explains the architectural difference between protection confined to adjacent storage components and integrity metadata carried farther through an I/O path. Its discussion of attached metadata and separate buffers is useful conceptual history. It is not evidence of current Linux NVMe driver support or compatibility for a proposed system.

An end-to-end claim needs named endpoints: where integrity information first represents the intended bytes, where it is checked on the outward and return paths, and how the intervening hardware and software preserve or process it. Ask for support evidence for that complete path, including any component that generates, replaces or removes PI.

Revision 1.3 includes controller-generated PI on writes and controller checking followed by PI removal on reads. Such behavior must be located within the claim, rather than silently equated with application-generated and application-verified protection.

Suppose incorrect bytes already exist before the first guard is generated. A later guard agreement can show consistency with those supplied bytes while leaving the earlier mistake undiscovered. Similarly, a check completed before a later unprotected segment cannot establish what happens in that later segment. The useful boundary follows the actual generation and checking locations, not the supplier's use of the phrase end to end.

References: [PI1][PI2]

Valid protection can accompany the wrong dataset

Imagine an application intending to write dataset release B but selecting release A. Stipulate that A is written to the intended addresses, its PI is generated correctly and every applicable comparison succeeds. No corruption or misdirection is required: the storage path has preserved the bytes it was given, while the application has selected the wrong release.

The same distinction applies to an incorrect numerical value encoded before protection begins. A PI checker has no independent knowledge of the intended value. Dataset identity, version selection and semantic validation need expectations supplied at the application level.

Keep the other storage promises attached to their own questions. Device ECC addresses errors within its protected device domain. Replicas or parity concern redundancy and reconstruction. Encryption concerns confidentiality; authenticity depends on the authentication mechanism actually provided. A per-block CRC and tag comparison alone cannot establish those outcomes.

A whole-object checksum comparison concerns a named object's bytes and expected value, with its own algorithm and calculation scope. PI's block-level evidence cannot silently become that comparison. The related S3 integrity article explains this distinction for object delivery.

Durability concerns what persists through the relevant failure and completion conditions. Coherent training recovery also needs the right checkpoint components and generation. Neither follows merely because the surviving individual blocks have valid PI. The atomic-write and training-checkpoint guides address those separate decisions.

References: [K1][C1][S1][S2][A1][P1]

Connect an approved storage choice to physical work

If the assessment leads to an approved hardware change, Leviathan's Hardware Refresh & Physical Support service can discuss the surrounding physical replacement, recabling and handoff scope.

Use the linked project inquiry with a nonconfidential equipment summary, approved replacement identities, site, requested physical change and approval owner. Identify the appointed parts supplier and the storage and application teams responsible for configuration, data handling and return to service.

References: [L1]