In my journey to understanding the advantages of RAIDZ, i came across the concept of write hole.

As this page explains, a write hole is the inconsistency you get among the disks of the array, when the power is lost during a write. That page also explains that it affects both RAID-5/6 (if the power is lost after the data has been written, but before the parity has been calculated) and RAID-1 (data is written to one disk but not the others), and that it is an insidious problem that can only be detected during either a resync/scrub, or (disastrously) during the reconstruction of one of the disks...however, most of the other sources talk about it as it only affected parity-based RAID levels.

From what i understand, i think this could be a problem for RAID-1 too, as reads from the disks containing the hole would return garbage, so...is it a problem for every RAID level or not? Is it implementation-dependent? Does it affect software-RAID only, or also hardware controllers? (extra: how does mdadm fare in this regard?)


This is why a cache battery or some other method of cache consistency validation is required for raid. All raid cards should have battery backed cache, and all storage controllers should have mirrored cache. For software raid, I don't think there is a good answer. I think even raid Z can fail on a power loss.

  • 1
    The question is tagged software-raid. You cannot implement a battery in software. The problem can be fixed in software without needing any battery, but I don't know if it has been done. – kasperd Apr 16 '17 at 21:43
  • Thank you for answering, but as @kasperd noted i'm interested in the software-RAID solutions. Do mind though that RAID-Z was explicitly designed to eliminate the write hole problem. – Mario Vitale Apr 17 '17 at 8:01

The write hole can affect every RAID level but RAID-0; both striped (RAID-4/5/6) and mirrored (RAID-1) configurations may be vulnerable, simply due to the fact that atomic writes are impossible in 2 or more disks.

I say "may" because the problem is implementation-dependent. Leaving aside next-gen filesystem solutions such as RAID-Z, also classic software-RAID implementations have found ways to tackle this: mdadm has relatively recently introduced a journal feature that uses dedicated cache disks to avoid it, and even if you choose not to use this feature, it also forces a resync after every unclean shutdown, thus catching and resolving the write-hole as soon as it happens.

Thanks to the #zfs irc channel for the help!

  • how would mdadm "resolve" a write hole symptom, when not using a dedicated cache? – hbogert Mar 12 at 13:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.