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?)
Answer
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!
No comments:
Post a Comment