RAID Levels, Parity and the Write Hole Explained

RAID levels are taught as capacity and redundancy arithmetic, but the operational decisions hinge on two things the tables rarely mention: rebuild time with large drives, and the write hole in parity arrays. This article compares the levels that matter in production, then explains the write hole and the journal that closes it on Linux md arrays.

The Levels That Actually Ship

• RAID 0 - striping only. Highest throughput, zero protection: one disk failure loses the set. Fine for scratch data, never for anything you would restore.
• RAID 1 - mirroring. Survives one disk per mirror, halves usable capacity, and read performance scales with the number of mirrors. Write cost is doubled unless the controller caches.
• RAID 5 - striping with single distributed parity. n-1 usable, survives one failure. Rebuilds read every surviving disk; with today's multi-terabyte drives the rebuild window is measured in days, and an unrecoverable read during the rebuild costs the array.
• RAID 6 - striping with dual parity. n-2 usable, survives two failures and, critically, survives one failure plus one read error during rebuild. This is why large-capacity SAS/SATA arrays standardised on RAID 6.
• RAID 10 - mirror then stripe. Half the capacity, but fast rebuilds (copy one mirror, not recompute parity) and far lower exposure during a degraded window.

Rule of thumb: if the array is made of large spinning disks and the data matters, RAID 6 or RAID 10. If write latency matters and capacity is affordable, RAID 10.

What the Write Hole Is

In RAID 4/5/6 a stripe write touches several disks. If the system loses power before all data and parity blocks land, the stripe is left inconsistent: data and parity no longer agree. The array is marked degraded and md resynchronises - but until that resync completes, a crash during the rebuild can expose the inconsistent stripe and corrupt real data. That is the write hole, and it exists in any parity RAID implementation without a journal or a battery/flash-backed write cache.

Closing the Hole with the Linux md Journal

mdadm --create /dev/md0 --level=5 --raid-devices=4 \
  --write-journal /dev/nvme0n1p1 /dev/sd[b-e]1

cat /sys/block/md0/md/journal_mode
echo write-back > /sys/block/md0/md/journal_mode
echo write-through > /sys/block/md0/md/journal_mode

The cache disk sits alongside the RAID members and absorbs writes first. In write-through mode md calculates parity, writes data plus parity to the journal, then flushes to the members and only then reports completion - the journal disk does not need to be large, and cache-disk failure only reopens the write hole rather than losing data. In write-back mode writes complete as soon as they are in the journal, which also speeds up non-full-stripe writes; the trade-off is that reads may have to query the journal and the cache disk becomes a read-path dependency.

Operational Checklist

• Verify the array after creation, and schedule patrol reads so latent media errors surface before a rebuild does.
• Monitor the parity-initialisation/resync progress and never assume an array is protected until it completes.
• Keep a spare disk (or hot spare) per shelf, and record the exact layout - a lost array with unknown stripe order is a recovery project.
• For SAN arrays, the equivalent protection is a battery or capacitor-backed write cache plus periodic scrub; the vendor-side disk replacement workflow is described in HPE 3PAR ServiceMag disk replacement and array-level resiliency in Dell PowerStore best practices.

RAID is not backup: snapshots and replicas protect against the failures parity cannot, as covered in ONTAP snapshot policies.

原文链接：https://www.kernel.org/doc/html/latest/driver-api/md/raid5-cache.html