An Atomic NVMe Write Is Not a Complete Application Transaction

Separate four requirements hidden inside an atomic-write claim

An SSD proposal can use atomic to answer a narrower question than the buyer intended. If the requirement is that a payload and its index always describe the same application generation, an intact write to either object is only part of the answer.

Atomicity concerns the unit that must remain indivisible under specified conditions. Persistence concerns whether the new contents have reached nonvolatile storage at the completion being claimed. Ordering concerns which operations must precede others. A transaction concerns the grouped effect of the application's changes.

Those requirements can coexist, but evidence for one does not automatically establish the others. Start by identifying whether the offer describes a device command, a host-visible completion or a complete application update. The distinction determines what additional evidence the storage and application owners need.

This comparison uses the NVM Express NVM Command Set Specification, Revision 1.3, dated July 31, 2026. It explains the contract rather than prescribing device operations or a database design. The existence of that edition establishes no particular SSD's optional capabilities.

References: [N1]

Normal operation and interrupted writes have different limits

AWUN and its namespace counterpart NAWUN concern normal command atomicity relative to other reads and writes. AWUPF and NAWUPF concern power-failure or other error interruption. A normal-operation limit cannot substitute for the interruption limit.

For a qualifying interrupted write, section 2.1.4.3 permits the whole old contents or the whole new contents across its addressed blocks. The excluded outcome is a torn mixture within that protected operation.

Old contents can therefore satisfy the atomicity requirement while failing a buyer's separate requirement to retain a newly acknowledged application update. The word whole describes the update's indivisibility; it does not choose which generation must survive.

Likewise, serialization of qualifying overlapping writes does not identify the application's required sequence. An offer must explain the order the application needs, rather than treating indivisibility as evidence that the controller selected that order.

References: [N1]

Read the unit, namespace and boundaries together

Controller AWUN and AWUPF use zero-based logical-block counts. Namespace applicability is reported through NSABP; where NAWUN or NAWUPF is defined, its zero value inherits the controller limit. NABSN, NABSPF and NABO describe normal and interruption boundaries and their offset; a zero boundary size means none.

Normal-atomicity claims also depend on the applicable Write Atomicity Normal feature state.

These are different quantities. A maximum protected amount answers how much; a boundary answers where an operation can lie. Namespace boundary crossings can remove the namespace-level promise, while the controller baseline is specified to remain supported across boundaries.

A 4 KiB logical-block label alone consequently leaves the offered atomic-write scope unanswered. It supplies the byte unit for interpreting a reported block count, without supplying the count, applicable namespace behavior or command range. The linked sector-format guide covers that addressing distinction in more detail.

Ask for the exact device, firmware applicability, namespace format and relevant behavior behind a supplier's interpretation. Evidence about an application request also needs to be connected to the actual device command being claimed. The two sizes should not silently become interchangeable.

References: [N1]

An 8 KiB command fits this fictional 16 KiB limit

Consider a wholly fictional controller and namespace. Each logical block contains 4 KiB, or 4,096 data bytes. Controller AWUPF has raw value 3. There is no namespace override, no atomic boundary and Single Atomicity Mode is stipulated. The example assumes a valid addressed range and no subsequent competing write.

The decoded limit is 3 + 1 = 4 logical blocks. Its data-byte quantity is 4 x 4,096 = 16,384 bytes, or 16 KiB. Raw 3 means neither three blocks nor three bytes.

Now stipulate one device Write command containing 8 KiB: 8,192 / 4,096 = 2 logical blocks. Two is within the fictional four-block limit. Call the two old block contents A0 and A1, and the proposed replacements B0 and B1.

For the covered interruption case, the intact alternatives are A0 with A1, or B0 with B1. A0 with B1 would mix generations inside this protected operation. These alternatives illustrate the stated contract; they report no observed device result.

The calculation does not require the B pair to be the surviving pair. Nor does it establish what any application was told about completion, whether other required data exists or whether the application state is coherent. It answers one bounded size question under the stipulated assumptions.

The single-command assumption matters. An offer that identifies only an 8 KiB application request has not yet supplied evidence that this same two-block device command represents it.

References: [N1]

An oversized command can still contain protected portions

Single Atomicity Mode provides no whole-command atomicity guarantee beyond the applicable size or boundary. Multiple Atomicity Mode protects each boundary-defined LBA subrange separately, including under interruption; the namespace MAM indicator identifies the mode.

Thus two conclusions need to remain separate: the entire command lacks one indivisible outcome, and particular portions may nevertheless have atomic protection. Saying every oversized command has no protected portions would erase the mode distinction.

Conversely, protection for every portion does not combine those portions into one application-wide decision. Whole portions can represent different stages of an update. The supplier's explanation needs to identify both the mode and the unit to which each promise applies.

References: [N1]

Persistent completion does not create command ordering

Figure 71 defines Write Force Unit Access, or FUA, as requiring the command's specified data and associated metadata to reach nonvolatile medium before command completion. It explicitly implies no ordering with other commands. Section 2.1.4.3.2 separately qualifies persistence under specified volatile-cache and power-loss conditions.

Treat that definition as a statement about the completion boundary. A supplier claiming persistent application completion needs to connect the application's acknowledgement to the relevant storage behavior. The presence of an atomicity number supplies no such connection by itself.

Even if two independent writes each meet their promised persistence condition, that fact does not require the first to be undone when the second never happens. Keeping the first change more reliably can simply preserve an intermediate application state more reliably. Ordering, persistence and grouping each need an answer.

References: [N1]

Two intact 4 KiB writes can leave a mismatched application state

In a second conceptual example, an application has one 4 KiB payload and one separate 4 KiB index. The application requires matching generations: payload P-A belongs with index I-A, and payload P-B belongs with index I-B. Stipulate that each individual device write is atomic and that completed new contents are persistent.

Initially the pair is P-A with I-A. The payload update to P-B completes persistently. Before the application submits the separate index update to I-B, it stops. At that point the stored pair is P-B with I-A.

Neither object contains a torn individual write. The new payload is whole and persistent; the index remains its whole earlier value. No controller reordering is needed to explain the mismatch, because the second write has not even been submitted. Individual atomicity and persistence have both met the example's stipulations while the application's grouped requirement remains unmet.

Adding the two sizes gives 8 KiB, but adding byte quantities does not turn two separate write operations into the single command in the earlier example. Their combined size falling below a fictional limit supplies no grouping rule.

PostgreSQL 18's transaction tutorial describes that different requirement: several updates form one all-or-nothing operation, with intermediate effects hidden from other transactions. It also distinguishes permanent recording before the database acknowledges completion. This is a conceptual transaction model, not evidence for a particular database deployment's configuration or storage path.

For this application's generation rule, the responsible software team needs to explain what groups the payload and index changes and what its completion acknowledgement means. An SSD atomic-write limit alone cannot provide that explanation.

References: [P1]

Compare the proposal with the result the application needs

A useful proposal names the protected unit, the conditions under which it is indivisible, the completion that establishes persistence and the application's grouped update. A statement such as supports atomic writes leaves those relationships unresolved.

Ask the supplier to connect the selected device's documented behavior to the actual command ranges and namespace, then identify the separately responsible application component that supplies the required transaction semantics. A capability field and a database transaction claim are evidence about different parts of that chain.

The linked SSD power-loss-protection guide addresses received buffers and internal metadata. The sector-format guide addresses the unit of block addressing. The checkpoint guide addresses which application state belongs in a captured package. Those decisions remain useful alongside this one; none can be replaced by the word atomic.

Carry an approved equipment choice into its physical work package

If the storage assessment leads to a separately approved hardware refresh, Leviathan's Hardware Refresh & Physical Support service can discuss the surrounding equipment replacement, recabling and physical records. The service and its project inquiry are linked below.

Share a nonconfidential equipment summary, approved replacement identities, site, appointed parts supplier and intended physical change. Identify the storage and application owners responsible for configuration, data handling and return to service. Physical replacement records establish the agreed work performed; application transaction behavior requires its own evidence.

References: [L1]