Editing RAID (section)

=== Atomicity<span class="anchor" id="WRITE-HOLE"></span> ===
<!-- [[RAID 5 write hole]] redirects here. -->
A system crash or other interruption of a write operation can result in states where the parity is inconsistent with the data due to non-atomicity of the write process, such that the parity cannot be used for recovery in the case of a disk failure. This is commonly termed the ''write hole'' which is a known data corruption issue in older and low-end RAIDs, caused by interrupted destaging of writes to disk.<ref name="RRG">{{cite web|title="Write Hole" in RAID5, RAID6, RAID1, and Other Arrays|url=http://www.raid-recovery-guide.com/raid5-write-hole.aspx|publisher=ZAR team|access-date=15 February 2012}}</ref> The write hole can be addressed in a few ways:

* [[Write-ahead logging]].
** Hardware RAID systems use an onboard nonvolatile cache for this purpose.<ref name=Danti>{{cite web |last=Danti |first=Gionatan|title=write hole: which RAID levels are affected? |url=https://serverfault.com/a/1002509 |website=Server Fault |language=en}}</ref>
** mdadm can use a dedicated journaling device (to avoid performance penalty, typically, [[SSD]]s and [[Non-volatile memory|NVMs]] are preferred) for this purpose.<ref>{{cite web|url=https://lwn.net/Articles/673953/|title=ANNOUNCE: mdadm 3.4 - A tool for managing md Soft RAID under Linux [LWN.net]|website=lwn.net }}</ref><ref>{{cite web|url=https://lwn.net/Articles/665299/|title=A journal for MD/RAID5 [LWN.net]|website=lwn.net }}</ref>
* Write [[intent log]]ging. [[mdadm]] uses a "write-intent-bitmap". If it finds any location marked as incompletely written at startup, it resyncs them. It closes the write hole but does not protect against loss of in-transit data, unlike a full WAL.<ref name=Danti/><ref>{{man|4|md|Linux}}</ref>
* Partial parity. [[mdadm]] can save a "partial parity" that, when combined with modified chunks, recovers the original parity. This closes the write hole, but again does not protect against loss of in-transit data.<ref>{{cite web |title=Partial Parity Log |url=https://www.kernel.org/doc/html/latest/driver-api/md/raid5-ppl.html |website=The Linux Kernel documentation}}</ref>
* Dynamic stripe size. [[RAID-Z]] ensures that each block is its own stripe, so every block is complete. Copy-on-write ([[Copy-on-write|COW]]) transactional semantics guard metadata associated with stripes.<ref name="RAID-Z">{{cite web |url= https://blogs.oracle.com/bonwick/en_US/entry/raid_z |title= RAID-Z |website= Jeff Bonwick's Blog |publisher= [[Oracle Corporation|Oracle]] Blogs |date= 2005-11-17 |access-date= 2015-02-01 |first= Jeff |last= Bonwick |url-status= dead |archive-url= https://web.archive.org/web/20141216015058/https://blogs.oracle.com/bonwick/en_US/entry/raid_z |archive-date= 2014-12-16 }}</ref> The downside is IO fragmentation.<ref name="b.PoO"/>
* Avoiding overwriting used stripes. [[bcachefs]], which uses a copying garbage collector, chooses this option. COW again protect references to striped data.<ref name="b.PoO">{{cite web |last1=Overstreet |first1=Kent |title=bcachefs: Principles of Operation |url=https://bcachefs.org/bcachefs-principles-of-operation.pdf |access-date=10 May 2023 |date=18 Dec 2021}}</ref> 

Write hole is a little understood and rarely mentioned failure mode for redundant storage systems that do not utilize transactional features. Database researcher [[Jim Gray (computer scientist)|Jim Gray]] wrote "Update in Place is a Poison Apple" during the early days of relational database commercialization.<ref>{{cite web |last1=Gray |first1=Jim |title=The Transaction Concept: Virtues and Limitations (Invited Paper) |url=http://www.informatik.uni-trier.de/~ley/db/conf/vldb/Gray81.html |publisher=VLDB [Very Large Data Bases] 1981 |archive-url=https://web.archive.org/web/20080611230227/http://www.informatik.uni-trier.de/~ley/db/conf/vldb/Gray81.html |archive-date=2008-06-11 |pages=144–154 |date=2008-06-11 |url-status=dead}}</ref>