---
title: "Intact Drive Writes Can Still Leave an Inconsistent RAID Parity Stripe"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/raid-parity-write-hole-versus-member-write-integrity"
last-updated: "2026-10-20"
---

# Intact Drive Writes Can Still Leave an Inconsistent RAID Parity Stripe

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

A parity stripe depends on a relationship between its data and parity, not just intact bytes on each drive. An interrupted update can preserve a whole new data value beside whole old parity. Those surviving values can reconstruct an unchanged missing member incorrectly. Assess the array's interruption-consistency mechanism separately from protected capacity, drive-local protection, command atomicity and application recovery.

## Identify the relationship the protection claim must preserve

A storage offer can account for parity capacity and specify protected drives while leaving one question unanswered: what keeps the stripe's data and parity mutually consistent if an update stops partway through?

For the simplified single-parity stripe below, parity is computed from the data using exclusive OR, or XOR. The complete set is a consistent codeword when that equation holds. Keeping each stored value intact does not establish that relationship across members.

Linux md's v6.6 PPL documentation identifies this interruption problem as the RAID5 write hole. Its named implementation grounds the comparison; it does not establish the behavior of every RAID5 product or a present-day deployment. The article explains the mechanism and evidence needed to assess an offer, without prescribing array operations.

References: [PW1](https://www.kernel.org/doc/html/v6.6/driver-api/md/raid5-ppl.html)

## Follow an interrupted update through three intact values

Fictional example PW-304 represents one stripe with three one-byte symbols: data A = 0x3C, data B = 0x0F and parity P = 0x33. The prefix 0x denotes hexadecimal. These symbols simplify the arithmetic; they are not SSD sector sizes, device commands or measured fault results.

XOR returns 1 where corresponding bits differ and 0 where they match. Initially, A XOR B = P: 0x3C XOR 0x0F = 0x33. In eight-bit binary, 00111100 XOR 00001111 = 00110011.

Now change only A to 0x30. B should remain 0x0F. The corresponding new parity must be 0x30 XOR 0x0F = 0x3F. The intended new stripe is therefore A = 0x30, B = 0x0F, P = 0x3F.

Stipulate an interruption after new A has persisted but before new parity has replaced old parity. The surviving stripe is A = 0x30, B = 0x0F, P = 0x33. Each byte is whole. A contains its complete new value, B its unchanged value and P its complete old value. Nevertheless, A XOR B is 0x3F, which differs from stored P = 0x33.

This outcome needs no torn byte and no changed B. It arises because persistence of one member update has not been coupled to the matching update on another member. Even a promise that each individual write survives as an intact old or new value leaves this combination possible unless the array supplies an additional consistency mechanism.

## An unchanged missing member can receive the wrong reconstruction

Continue the same example with one further stipulation: B is unavailable while this inconsistent stripe remains unresolved. In a consistent XOR stripe, B = A XOR P, because XORing A twice cancels it.

Using the surviving values instead gives 0x30 XOR 0x33 = 0x03. That differs from B's unchanged 0x0F. In binary, 00110000 XOR 00110011 = 00000011. The reconstruction error is caused by the relationship between the surviving A and P, even though neither surviving byte is torn.

The error can also be expressed as B XOR old A XOR new A. Here, old A XOR new A = 0x0C, so the wrong result is 0x0F XOR 0x0C = 0x03. This derivation shows why the inconsistency can affect a member outside the original data change.

The parity equation provides a way to derive a missing value under its consistency assumption. It does not independently identify the intended application contents when that assumption is false. Finding a mismatch alone also does not establish which version the application needed retained.

## PPL records the unchanged portion's contribution

In Linux md v6.6 RAID5, Partial Parity Log records the XOR of data chunks excluded from the current update before dispatching new data and parity. Its records occupy metadata space on the stripe's parity member.

In PW-304, that unchanged contribution is B = 0x0F. Combining it with surviving A = 0x30 yields matching parity 0x3F; 0x30 XOR 0x3F then gives the original B = 0x0F. These are arithmetic consequences of the example, rather than an operating procedure.

PPL does not retain every new payload. The documentation excludes protection of in-flight data and describes a limitation when a data member being written is lost: that stripe receives no PPL recovery. The claim therefore needs its missing-member conditions preserved.

References: [PW1](https://www.kernel.org/doc/html/v6.6/driver-api/md/raid5-ppl.html)

## A data journal changes the information retained and the completion point

The Linux md v6.6 RAID4/5/6 cache documentation describes a separate log device. Write-through records data and parity there before writing the array members; upper-layer completion follows storage on those members.

Write-back reports completion after data reaches the log device, with member placement later. Its implementation subsequently records calculated parity before placing data and parity on the array members. Pending data therefore depends on the journal, and the documentation identifies journal-device failure as a data-loss exposure in write-back mode.

Both modes address the documented write hole, but their completion points differ. PPL's partial parity and a journal's retained payload also represent different information. A supplier's journal claim needs its actual mode, applicability and dependencies identified.

References: [PW2](https://www.kernel.org/doc/html/v6.6/driver-api/md/raid5-cache.html)

## Compare offers against the interrupted update you need covered

Consider two fictional offers for the same stated storage capacity. Offer A provides capacity accounting, a drive-local power-loss-protection statement and per-command atomicity documentation. Offer B additionally identifies the array implementation, its interruption-consistency mechanism, its completion boundary and its limitations when a member or journal is unavailable. Neither offer represents a tested system here.

For the stripe-consistency question, B supplies evidence that A's listed documents leave unresolved. That omission does not establish that A lacks protection. Ask its supplier to connect the offered implementation to the interrupted multi-member update, rather than treating a capacity deduction or drive feature as that explanation.

The useful response distinguishes the retained information from the result claimed. Does the mechanism retain new payload, a contribution needed to restore parity, or both? What must already be persistent when completion is reported to the upper layer? Which missing-member cases are covered, and what additional device does the claim depend on? Retain the relevant software version or controller and firmware applicability with the answer.

Read that evidence alongside the linked guides. Protected-capacity accounting answers how much space coding consumes. SSD power-loss protection addresses its documented drive-held objects. NVMe atomicity addresses applicable command boundaries. Application transactions and checkpoints address grouped application state. None of those descriptions alone answers the cross-member equation exposed by PW-304.

Conversely, restoring a valid parity relationship does not establish that every new payload survived or that several application changes completed together. For example, A = 0x30 with B = 0x0F and P = 0x3F is mathematically consistent; it says nothing about a separate application index update. Keep that application requirement with the appointed software and storage owners.

## Carry an approved hardware choice into its physical work package

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

Bring a nonconfidential equipment summary, approved replacement identities, site, appointed parts supplier, requested physical changes and required handoff records. Assign array configuration, data handling and return-to-service decisions to the responsible storage and application teams. The proposed Leviathan engagement concerns the agreed physical work; storage architecture, tuning, data recovery and application operation require separately appointed scope.

## Primary sources

- [PW1 — Linux kernel v6.6 documentation: Partial Parity Log](https://www.kernel.org/doc/html/v6.6/driver-api/md/raid5-ppl.html). Checked 2026-10-20. RAID5 partial-parity mechanism and missing-member limits in this version of Linux md. It does not establish protection for another implementation or complete application state.
- [PW2 — Linux kernel v6.6 documentation: RAID 4/5/6 cache](https://www.kernel.org/doc/html/v6.6/driver-api/md/raid5-cache.html). Checked 2026-10-20. Write-through and write-back completion boundaries, log contents and ordering, and journal-device dependency for the documented implementation.

## Related Leviathan resources

- [NVMe atomicity, persistence and application transactions](/articles/nvme-atomic-write-versus-persistence-and-transactions)
- [SSD power-loss protection: drive-held writes and mapping metadata](/articles/gpu-ssd-power-loss-protection-cache-nand)
- [Raw, protected and client-usable storage capacity](/articles/gpu-storage-raw-versus-protected-usable-capacity)
- [Training checkpoints and storage snapshots: identify the application state](/articles/gpu-training-checkpoint-versus-storage-snapshot)
- [Hardware Refresh & Physical Support](/services/data-center-remediation)
- [Discuss physical work around an approved hardware refresh](/contact?service=data-center-remediation&from=%2Farticles%2Fraid-parity-write-hole-versus-member-write-integrity)

## Planning physical work around an approved storage refresh?

Share the selected equipment, approved replacements, site, appointed parts supplier and required physical changes to discuss scope and availability.

[Discuss the scope](/contact?service=data-center-remediation&from=/articles/raid-parity-write-hole-versus-member-write-integrity)