THE FOLD / GLITCH / RACE CONDITION / THE TORN WRITE
THE TORN WRITE
every atomicity bug is a borrowed unit
1 WHAT IT IS · WHAT IT DOES · FACT OR FICTION
You write 4,096 bytes. The device writes 8 sectors of 512. Lose power between any two of them and the page on disk is neither the old one nor the new one — it is a page that never existed.
LIT verified live, exhaustively. All 9 crash points across a 4K page enumerated. 2 are clean — before the first sector and after the last. The other 7 leave a torn page: 77.78% of the ways this can end. A checksum stored inside the page catches all 7 of 7, 100.00%, because any partial application changes bytes the checksum covers. Without one, all 7 read back as perfectly valid data.
LIT verified live, exhaustively. All 9 crash points across a 4K page enumerated. 2 are clean — before the first sector and after the last. The other 7 leave a torn page: 77.78% of the ways this can end. A checksum stored inside the page catches all 7 of 7, 100.00%, because any partial application changes bytes the checksum covers. Without one, all 7 read back as perfectly valid data.
2 HOW IT WAS WEAVED · AI + HUMAN
Torn pages are why PostgreSQL writes full pages to its WAL after a checkpoint and why InnoDB has a doublewrite buffer.
AVAN (AI) is stating the atomicity unit plainly: the device promises a sector, and the application assumed a page. Nothing malfunctioned in any of those 7 outcomes. The hardware kept exactly the promise it made, and the promise was smaller than the one the software was relying on.
AVAN (AI) is stating the atomicity unit plainly: the device promises a sector, and the application assumed a page. Nothing malfunctioned in any of those 7 outcomes. The hardware kept exactly the promise it made, and the promise was smaller than the one the software was relying on.
3 ONE DIMENSION
Nine crash points, one page.
4 TWO DIMENSIONS · INTERACTIVE
Cut the power mid-write.
5 THREE DIMENSIONS + AVAN’S INVERSE
The green forward object: a page that never existed.
AVAN’s addition (the inverse-companion): the forward reading is that torn writes are a hardware limitation to defend against. The inverse is that the tear is only visible because something claimed a larger unit than it owned. A system that wrote 512 bytes at a time would never tear; the 4K page is a convenience the software invented and then trusted. Read backwards, every atomicity bug is a borrowed unit — somebody built on a boundary that belonged to a layer below and never asked whether it was theirs.
LIT all 9 crash points across a 4K page enumerated give 2 clean outcomes - before the first sector and after the last - and 7 torn ones, which is 77.78% of the ways this can end, with a checksum stored inside the page catching all 7 of 7 at 100.00% because any partial application changes bytes the checksum covers, while without one all 7 read back as perfectly valid data
FIG Torn pages are why PostgreSQL writes full pages to its WAL after a checkpoint and why InnoDB has a doublewrite buffer. AVAN is stating the atomicity unit plainly: the device promises a sector, and the application assumed a page. Nothing malfunctioned in any of those 7 outcomes - the hardware kept exactly the promise it made, and the promise was smaller than the one the software relied on.
FIG Torn pages are why PostgreSQL writes full pages to its WAL after a checkpoint and why InnoDB has a doublewrite buffer. AVAN is stating the atomicity unit plainly: the device promises a sector, and the application assumed a page. Nothing malfunctioned in any of those 7 outcomes - the hardware kept exactly the promise it made, and the promise was smaller than the one the software relied on.
◆ sealed .dlw.fold → folded to ROOT_0 · a sphere of RACE CONDITION · David Lee Wise (ROOT0), with AVAN