How RAID Parity Actually Works

RAID parity is a mathematical technique that allows an array to survive drive failures without losing data. The core operation is XOR (exclusive OR): a bitwise function that compares bits from multiple data blocks and produces a parity block. If any one input is lost, it can be recalculated from the remaining inputs and the parity. RAID 5 uses single parity (one drive failure tolerance). RAID 6 uses dual parity (two drive failure tolerance). The math is straightforward, but the implementation details of stripe layout, parity distribution, and write handling determine how the array performs and how it fails.

What is parity in a RAID array?

In a striped parity array of three or more members, parity is a value the controller or software RAID driver calculates from the other data blocks sitting in the same stripe, then writes alongside them on a member of the array. It isn't a second copy of a data block, and it isn't a spare mirror of any one drive. Read on its own, a parity block holds nothing a filesystem can use. It turns back into data only when the array solves that stripe's parity equation against the surviving blocks, which is how an array keeps handing the host a block whose member drive is gone.

The cost is capacity. In a fixed-geometry array of equal-capacity members, single parity spends the capacity of one member across the array and lets the array keep serving reads with one member missing. Dual parity spends the capacity of two members and keeps serving with two missing.

What parity covers is a member device dropping out of the array, and an unreadable sector on a member that is still online. It does not cover a deleted file, a ransomware run, or filesystem damage, because parity is an availability mechanism rather than a backup. Only discrete, offline copies of the data cover those.

How does XOR parity math work in RAID 5?

XOR is associative and commutative, which means it scales to any number of inputs: A XOR B XOR C XOR D = P. That property is what makes the parity block recalculable from the surviving data blocks across an arbitrarily wide stripe.

In a four-drive RAID 5 array, each stripe has three data blocks (D1, D2, D3) and one parity block (P). The parity block stores D1 XOR D2 XOR D3. If drive 2 fails, the controller reconstructs D2 by computing D1 XOR D3 XOR P. This calculation happens for every stripe across the entire array during a rebuild or during degraded-mode reads.

A concrete example with bytes: if D1 = 10110010, D2 = 01101001, and D3 = 11001100, then P = 10110010 XOR 01101001 XOR 11001100 = 00010111. If D2 is lost, D1 XOR D3 XOR P = 10110010 XOR 11001100 XOR 00010111 = 01101001. The original D2 is recovered exactly.

When a second drive drops or a surviving member returns an unrecoverable read error in the same stripe as the failed drive, single XOR parity has no equation left to solve. For RAID 5 data recovery, we image every member individually before we attempt any rebuild.

What is the difference between distributed and dedicated parity?

In a four-drive RAID 5 array, the parity block rotates to a different drive for each stripe:

The parity block rotates to a different drive in each stripe. This distributes write I/O evenly: no single drive is a bottleneck. The specific rotation pattern (left-symmetric, left-asymmetric, right-symmetric, right-asymmetric) varies by controller manufacturer and affects the order in which data and parity are laid out. During recovery, knowing the exact layout algorithm is necessary to reassemble the array correctly.

How do the four standard RAID 5 parity layouts differ?

The Linux md (multiple device) driver defaults to left-symmetric. LSI/Broadcom MegaRAID and Dell PERC controllers write the array layout to the end of each member drive, in a variant of the SNIA Common RAID Disk Data Format (DDF). That record includes the stripe size, drive order and parity rotation.

HP SmartArray controllers use a "delayed parity" layout. The parity block doesn't move every stripe. It stays on the same drive for a run of consecutive stripes, then moves. A recovery tool has to work out the delay interval and the first-delay offset before it can reassemble a coherent image.

When an array comes in for RAID data recovery without surviving controller metadata, we have to work out the drive order, chunk size, parity direction and parity rotation pattern before we can reassemble the data. On HP hardware we also need the delay parameters. Data Extractor Express RAID Edition has an auto-detection mode for this that analyzes the file systems and user data on the members.

How does RAID 6 dual parity work?

This two-failure tolerance matters increasingly with large-capacity drives (8 TB, 16 TB, 20 TB+) because the probability of an unrecoverable read error (URE) during rebuild is high enough that a second failure during a RAID 5 rebuild is a realistic scenario, not a theoretical one.

Linux md won't run a RAID 6 with fewer than four devices. Broadcom's MegaRAID guide gives three drives as the minimum for a RAID 6 drive group. Usable capacity is (N-2) drives. Write performance is lower than RAID 5 because every data write requires updating both P and Q parity blocks.

Q Syndrome Reed-Solomon Math Inside Linux RAID 6

The P syndrome is plain XOR across all data blocks in a stripe. In Linux RAID 6, the Q syndrome is a Reed-Solomon code computed inside the Galois field GF(2⁸).

Linux RAID 6 uses the irreducible polynomial x⁸ + x⁴ + x³ + x² + 1 to keep the arithmetic confined to 8 bits. The generator g is the byte 0x02. Multiplying any byte by g is equivalent to a bitwise left shift. If the high bit was set before the shift, the result is XORed with 0x1D to fold it back into the field.

The Q value for a stripe is the XOR of each data block multiplied by a successive power of g: Q = (g⁰ · D₀) XOR (g¹ · D₁) XOR (g² · D₂) XOR ... XOR (g^N-1 · D_N-1). The exponent is the drive index, which is what makes P and Q mathematically independent and gives RAID 6 its two-failure tolerance. Because each data block is multiplied by a distinct coefficient, two simultaneous unknowns produce a two-equation, two-unknown system that can always be solved by Galois field matrix inversion.

Two-Failure Recovery Cases in RAID 6

RAID 6 handles four distinct failure topologies: (a) two data drives lost, (b) one data drive plus the P drive lost, (c) one data drive plus the Q drive lost, or (d) both the P and Q drives lost. Case (d) is trivial: the surviving data is intact and P and Q are recalculated from scratch. Case (c) is also straightforward: the surviving data plus P rebuild the missing data drive via XOR, then Q is recalculated.

Case (b) requires Galois field division, since P is gone and the missing data drive must be solved from the Q equation by multiplying through by the inverse of g raised to that drive's index. Case (a) is the hardest: both P and Q equations are needed, and the two missing data values are extracted by solving a 2x2 linear system over GF(2⁸).

Solving that system correctly depends on the exact drive order, Q-syndrome coefficient sequence, and chunk size, so RAID 6 data recovery starts with a full image of every surviving member before any Galois-field reconstruction math runs against the image files.

How does parity work in nested RAID 50 and RAID 60?

Subgroup (span)

One inner RAID 5 or RAID 6 set. It calculates and stores its own P (and, in RAID 60, Q) parity independently of the other subgroups.

Outer stripe

The RAID 0 layer sitting above the subgroups. It rotates successive chunks across the subgroups in round-robin order and stores no parity.

Chunk

The contiguous block the outer RAID 0 layer writes to one subgroup before advancing to the next.

A surviving subgroup holds only the chunks the outer RAID 0 layer assigned to it, so on its own it cannot reconstruct the complete striped filesystem. A subgroup that survived a failure is never independently mountable as the whole volume; it is one interleaved slice of the outer stripe.

Does a surviving subgroup hold every other chunk of each file?

Only when the array was built from exactly two subgroups.

Recovery of RAID 50 data recovery and RAID 60 data recovery therefore begins by imaging every member of every subgroup member-by-member through a write-blocked interface with ddrescue, a PC-3000 Portable III, or a PC-3000 Express, before any assembly runs. The array geometry, outer chunk size, subgroup boundaries, and per-drive rotation are then reconstructed virtually with Data Extractor Express RAID Edition against the image files, never against the live disks.

Rebuilding a degraded inner subgroup live is the trap. Whether a single unrecoverable read error during that rebuild collapses the subgroup depends on the controller. Lose one span, though, and the entire nested volume goes offline, because the outer RAID 0 stripe depends on every subgroup.

How do stripe size and chunk size affect a RAID array?

During RAID recovery, the chunk size must be known exactly. If a recovery tool assembles the array with the wrong chunk size, the data interleaving is incorrect and the resulting image will be garbled. When the RAID controller metadata is damaged or unavailable, Data Extractor Express RAID Edition has an auto-detection mode that analyzes the file systems and user data to work out the drive order and block size.

What is the RAID write penalty?

In write-back mode, a hardware RAID controller tells the host the write is done once the data is in the controller's cache. How that cache is protected depends on the vendor. Dell PERC uses a lithium-ion battery that powers a flush of cache DRAM to onboard NAND. Broadcom's retail MegaRAID cards use the supercapacitor-powered CacheVault module. HPE Smart Array uses flash-backed write cache (FBWC). If the battery is bad or missing on a MegaRAID set to Write Back with BBU, the firmware switches the virtual drive to Write Through.

The penalty figures above describe a partial-stripe write: the operating system updates a single block inside an existing stripe, so the controller must read the old data and old parity, calculate new parity, then write both back. Counted as I/O operations, that is two reads plus two writes for RAID 5 (penalty 4), and three reads plus three writes for RAID 6 (penalty 6, since the controller has to read the old data, old P, and old Q before writing the new data, new P, and new Q).

When the operating system writes enough contiguous data to fill an entire stripe, the controller skips the preliminary reads entirely, computes the parity from the new data already in cache, and writes the complete stripe in a single transaction. That's called a full-stripe write.

Linux md Stripe Cache

Linux software RAID exposes the buffer that holds in-flight stripes at /sys/block/mdX/md/stripe_cache_size. The default is 256 pages per disk.

What does a parity mismatch tell you?

A single-parity stripe is one equation. A consistency pass reads every chunk in the stripe, XORs the data chunks together & compares the result against the stored parity chunk; a disagreement says that the N values in that stripe no longer satisfy the equation that produced P. One equation can't localize an unknown among N members. Any of the data chunks could have gone bad, or the parity chunk itself could be the corrupt member, and each of those cases produces the same failed comparison.

Dual parity changes the algebra rather than the plumbing. In Linux RAID 6, the Q syndrome weights each data block by a distinct power of g inside GF(2⁸). So a stripe in Linux md dual-parity RAID 6 arrays carries two mathematically independent equations over the same members. With two independent equations, you can identify the one wrong member with algebra instead of guessing. The arithmetic permits that identification; it doesn't oblige a controller or a software stack to perform it during a routine parity pass.

A repair pass that finds a disagreement still has to resolve it, and it resolves it by assumption rather than by evidence. Parity is the derived value in the stripe, so the cheap resolution is to re-derive it: read the data chunks, recompute P from them, and write the new P over the stored one. That costs nothing when the data side is intact. When the data side was the corrupt side, the pass ratifies the corruption into parity & erases the only on-disk record that the stripe ever disagreed, which is what a MegaRAID Consistency Check does after a stale member has been forced back online.

Reconstructed Blocks Reach the Filesystem With No Error Flag

A degraded array answers reads for the missing member by computing them. The block is XORed out of the survivors and handed up the stack with the same success status as a sector that came off a platter, and nothing in that completion tells the layer above that the bytes were derived rather than read. If one survivor quietly returned wrong data for that stripe, the derived block is wrong too, and it arrives marked good.

Parity left stale by an interrupted update does the same thing. That's the RAID 5 write hole. The read comes back wrong, and it's marked successful.

Image-first handling isn't the answer to every array that reports an inconsistency. A routine enterprise failure with verified backups and a monitored controller rebuild is standard practice, with the URE exposure of a full-surface read across aging same-batch members weighed into that decision. Imaging first belongs to the narrower case where the data is irreplaceable, no verified backup exists, or the members are already degrading: every member is imaged through a write-blocked interface with ddrescue, a PC-3000 Portable III, or a PC-3000 Express, then drive order, chunk size, & parity rotation are reconstructed virtually in software with Data Extractor Express RAID Edition against the image files. An adjudication call that turns out wrong then costs an image file rather than the original stripe, which is the working assumption behind recovering a failed parity array in-house. Degraded-array triage comes before any of it, because the decision to image is made before the array is asked to do more work.

Why do unrecoverable read errors cause RAID rebuild failures?

What happens on a URE depends on the controller. Dell PERC and LSI/Broadcom MegaRAID "puncture" the affected stripe: they mark that specific LBA range as unrecoverable & continue rebuilding the rest of the array. The data in the punctured stripe is lost, but the server comes back online. Linux md records the unreadable LBA in its Bad Block Log and continues, the md analog of hardware puncture, so only the affected blocks are lost rather than the whole array. Legacy block-level and low-end consumer controllers, and HP/HPE Smart Array P-series and E-series, instead abort the rebuild and drop the volume offline (HP flags POST Error 1784 or 1786), which is the failed state that requires professional RAID data recovery.

A second parity block doesn't just protect against a second drive dying; it provides a mathematical fallback when a surviving drive can't deliver clean reads during reconstruction.

Worked Example: Worst-Case URE Limits in a Degraded RAID 5 Rebuild

A RAID 5 rebuild on large drives carries real risk because the worst-case unrecoverable read error budget across the reads a resync demands can exceed one. The 1-per-10¹⁴ bit rate consumer drives carry is a worst-case manufacturer specification floor of roughly one URE per 12.5 TB read, and real drives often perform far better than that baseline. Dividing the bytes read in a pass by 12.5 TB gives the worst-case URE count the spec permits, not a count the drive is guaranteed to reach.

A worst-case figure of roughly 3.5 across the rebuild means that on aging, same-batch surviving members, encountering at least one URE before the resync finishes is a real risk rather than an edge case. On a single-parity array that is already missing one member, there is no second parity equation left to solve, so any single URE in a stripe halts reconstruction of that stripe. That is the punctured-stripe or offline-volume outcome described above, reached statistically rather than by a second whole-drive failure.

This worst-case exposure is the concrete reason a degraded array holding irreplaceable, unbacked data should be imaged member-by-member with a write-blocked imager before any parity recalculation is attempted: ddrescue for direct-attached members, or Data Extractor Express RAID Edition running on the PC-3000 for controller-independent reconstruction from the resulting images. It is also the rebuttal to the "add more drives and it's safer or faster" claim; wider member counts and larger per-drive capacities push the worst-case URE exposure higher, not lower, which is why a stalled RAID rebuild on a big array is a predictable engineering risk, not bad luck.

What is the RAID 5 write hole?

A logical write to a single block forces the controller to perform a sequence: read old data, read old parity, compute new parity, write new data, write new parity. The array is consistent enough to serve reads in normal operation, because the controller reads from data drives directly. The corruption only surfaces later, when a degraded array has to rely on that stale parity for reconstruction and bakes the wrong bytes permanently into the rebuilt drive.

On hardware RAID, a write-back cache that survives power loss closes this hole. Broadcom MegaRAID switches a Write Back with BBU policy to Write Through when the battery is low, failed, missing, or running a re-learn cycle.

Linux md Mitigations: Bitmap, Journal, and Partial Parity Log

Linux software RAID has no battery, so the kernel implements three mitigations:

• Write-intent bitmap. A bitmap records which blocks of the array may be out of sync. After a crash, only those blocks are resynced instead of the entire array. The bitmap accelerates recovery but does not prevent the underlying torn-stripe condition; it just narrows the search space for the resync.
• Journal device (mdadm --write-journal). A fast external SSD logs the data and parity of every write. After a crash the kernel replays the journal before bringing the array online. This closes the hole but requires dedicating a fast, reliable device to the array.
• Partial Parity Log (PPL). PPL doesn't need a dedicated journal drive. Before new data and parity are dispatched, md computes the XOR of the stripe's unmodified chunks and stamps that partial parity into the metadata area on the parity drive of that stripe. After a crash, XORing the partial parity with the modified chunks produces parity consistent with the stripe, so the unmodified chunks stay recoverable. It doesn't protect the in-flight data being written.

How does ZFS RAID-Z handle parity at the filesystem layer?

Two structural differences fall out of that:

Variable-width stripes. Block-layer RAID 5 has fixed stripe geometry: if the stripe width is 4 drives and the chunk size is 64 KB, every stripe is 192 KB of data plus a 64 KB parity chunk regardless of the size of the logical write. ZFS allocates sectors per transaction sized to the actual record being written (governed by recordsize and the disk's ashift). A 4 KB write with RAID-Z1 uses one 4 KB data sector plus one 4 KB parity sector and leaves the rest of the stripe alone. Every write is a full-stripe write by definition, so the read-modify-write cycle that creates the partial-write penalty in block-layer RAID does not exist.

Copy-on-write closes the write hole. ZFS never overwrites live data. A write allocates new sectors elsewhere on the pool, commits data and parity atomically as a new transaction, then advances the Uberblock pointer to the new tree. If a power loss occurs after the write but before the Uberblock advance, the pool still references the previous consistent tree on the next mount. There is no stripe to be torn between data and parity because parity is always written as part of the same transaction as its data, and the visibility of the entire transaction is gated by a single atomic pointer flip.

A ZFS rebuild, called a resilver, copies only live data instead of the entire device. That makes it faster, unless the pool is very close to full, where it's slower. For recovery, RAID-Z pools require ZFS-aware tools that walk the pool's block pointer tree from the Uberblock; generic block-layer RAID parity calculators cannot reassemble RAID-Z because the stripe geometry is variable per record.

Frequently Asked Questions