Dit artikel introduceert 'Uberblok', een interactief museum dat de architectuur van het ZFS-bestandssysteem ontsluit. Het project gebruikt specifieke regels uit de OpenZFS-broncode om uit te leggen hoe ZFS omgaat met data-integriteit en hardwarefouten.
Centraal staat het uberblock, het cruciale record dat fungeert als de wortel van de gehele storage pool. Het artikel beschrijft hoe ZFS een ring van uberblocks gebruikt om consistentie te waarborgen na crashes, waarbij het meest recente geldige blok wordt geselecteerd.
Het museum is gestructureerd in verschillende 'kamers' die de datastroom volgen, waaronder:
- Copy-on-Write en checksums: Mechanisme voor self-healing zonder dat een
fsck nodig is.
- RAID-Z: Geavanceerde stripes die het 'write hole'-probleem oplossen.
- ARC: Een intelligente cache die leert van eerdere missers.
- Snapshots en clones: Beheer van data-versies via deadlists.
Tot slot is het werk een eerbetoon aan de oorspronkelijke ontwikkelaars bij Sun Microsystems (zoals Jeff Bonwick en Bill Moore) en de huidige OpenZFS-gemeenschap, waarbij de fundamentele filosofie wordt benadrukt: vertrouw nooit blindelings op de onderliggende hardware.
Uberblok: Een interactief museum van ZFS
Elke animatie correspondeert met regels uit OpenZFS zfs-2.4.4, bevroren op commit 71a9f9578616, en elk fragment linkt naar deze regels. Niets in dit museum is uit het geheugen geschreven.
De Hall: Het Uberblock
Het object onder het glas: struct uberblock (Regels 122–128 van include/sys/uberblock_impl.h in zfs-2.4.4, geprint met regels 36–150 van het bestand)
ub_txg: de transactiegroep (transaction group) van de laatste synchronisatie.ub_rootbp: de blokpointer naar de wortel van de boom, de MOS (Main Object Set).
Wat is het uberblock?
Een pool bestaat uit miljoenen blokken verspreid over verschillende schijven. Na een crash moet het systeem zijn huidige, consistente staat kunnen vinden zonder al deze blokken te hoeven scannen. Daarom benoemt één klein record de wortel van alles: het uberblock. Het bevat een transactiegroepnummer (ubtxg) en één blokpointer (ubrootbp); elk ander blok in de pool is bereikbaar via die pointer.
Elke schijf bevat vier labels, twee aan het begin en twee aan het einde. Elk label beheert een ring van 128 KiB aan uberblocks. Een nieuw uberblock overschrijft nooit het vorige: het uberblock van txg $N$ gaat naar slot $N \pmod{\text{aantal slots}}$ (bij multihost=on wordt het laatste slot bewaard voor MMP en draait de ring op één slot minder). Bij het importeren leest ZFS elk slot van elk label en behoudt het geldige uberblock met de hoogste txg.
De ring wordt vaak beschreven als een verzameling van 128 uberblocks, maar hij bevat exact 128 KiB. Een slot neemt één sector in beslag, afgerond naar boven op 1 KiB en begrensd op 8 KiB. Dit betekent:
- 128 slots bij 512-byte sectoren.
- 64 slots bij
ashift 11.
- 32 slots bij de huidige 4K-sector schijven.
- 16 slots of minder bij grotere sectorgroottes.
Elk uberblock begint met hetzelfde magische getal, 0x00bab10c: "oo-ba-bloc".
---
Routekaart van het bezoek
De kamers volgen de datastroom: de wortel en de boom, hoe de boom verandert, waar blokken terechtkomen, wat de boom mogelijk maakt, de daarop gebouwde functies, en tot slot de machinekamer.
- 00 Hall: Het uberblock – Het enige record dat de hele pool benoemt, en de ring die dit bewaart.
- 01 History wing – Van de eerste regels code tot OpenZFS, met elke bron vermeld.
- 02 De boom en het uberblock – Blokpointers tot in de kleinste details, en de schrijfactie die een nieuwe boom tot de huidige maakt.
- 03 Copy-on-write, checksums en self-healing – Waarom een pool consistent blijft zonder
fsck, en hoe het een schijf detecteert die onjuiste data teruggeeft.
- 04 Transactiegroepen – Open, quiescing, syncing: hoe duizenden schrijfacties één commit worden.
- 05 De vdevs – Mirror, raidz, draid, log, cache, special: de boom van apparaten onder een pool.
- 06 RAID-Z – Stripes van variabele breedte, en waarom er geen "write hole" is.
- 07 Snapshots en clones – Geboortetijden en deadlists: welk snapshot is eigenaar van dit blok?
- 08 De ARC – Een cache die leert van wat hij is vergeten.
- 09 Metaslabs en space maps – Snel vrije ruimte vinden met een append-only log van allocaties.
- 10 ZIL en SLOG – Het pad van een synchrone schrijfactie.
- 11 Send / Receive – Een dataset als stroom, en het increment tussen twee snapshots.
- 12 Compressie, dedup, encryptie – Drie transformaties in de write-pipeline, en de werkelijke kosten van deduplicatie.
- 13 Machinekamer – Hoe dit museum is gebouwd en vanaf welke commit.
---
Toewijding: Waarom dit museum?
Het veilig houden van data is kritiek werk dat zelden zichtbaar is. Een bestandssysteem krijgt alles toevertrouwd wat mensen bewaren, en het moet correct blijven functioneren ondanks crashes, falende schijven en afgebroken schrijfacties. Een van de principes waarop ZFS is ontworpen, in de woorden van Bill Moore: vertrouw nooit, maar dan ook nooit, op de onderliggende hardware.
Dit museum is een eerbetoon aan dat stuk techniek en aan de mensen die het hebben gebouwd. Jeff Bonwick leidde de ontwikkeling van ZFS, met Bill Moore als co-leider; Matt Ahrens was een van de twee oorspronkelijke auteurs. Het werk begon in 2001 met twee ingenieurs bij Sun Microsystems en werd op 31 oktober 2005 geïntegreerd in Solaris. Bonwick vatte deze stap samen als: 584 bestanden, 92.000 regels wijzigingen, 56 patenten, 5 jaar. Op 17 november schreef hij: "I’m incredibly proud of the ZFS team, and deeply grateful: no one person can do something on this scale."
Het is evenzeer een eerbetoon aan de engineering bij Sun in die jaren, waar ingenieurs publiceerden hoe hun systemen werkten: de slab allocator, gepresenteerd door Jeff Bonwick bij USENIX in 1994; DTrace, door Bryan Cantrill, Michael Shapiro en Adam Leventhal in 2004; en de broncode van ZFS zelf, uitgebracht onder de CDDL als onderdeel van OpenSolaris.
En aan hen die het werk voortzetten: OpenZFS, aangekondigd in 2013 en opgericht door leden van de Linux, FreeBSD, Mac OS X en illumos gemeenschappen. De release die dit museum analyseert, noemt meer dan 700 mensen in het AUTHORS-bestand.
De onderliggende hardware: Een 3,5-inch harde schijf
(Beschrijving van de componenten bij een explosietekening)
- Bovenkap
- Schijfklem
- Platters (magnetische schijven)
- Kopstack: armen en koppen
- Voice coil en magneet
- Spindelmotor
- Basisgietvorm
---
Bronnen
- "A Conversation with Jeff Bonwick and Bill Moore", ACM Queue 5(6), november 2007.
- OpenZFS launch announcement, open-zfs.org.
- openzfs.org wiki, "History".
- Jeff Bonwick, "ZFS: The Last Word in Filesystems", blogpost van 31 oktober 2005.
- Jeff Bonwick, blog, posts van november 2005, "Thank You" van 17 november 2005.
- USENIX, abstract van "The Slab Allocator: An Object-Caching Kernel Memory Allocator", Summer 1994 Technical Conference.
- USENIX, abstract van "Dynamic Instrumentation of Production Systems", 2004 Annual Technical Conference.
Uberblok: Een interactief museum van ZFS
Elke animatie correspondeert met regels uit OpenZFS zfs-2.4.4, bevroren op commit 71a9f9578616, en elk fragment linkt naar deze regels. Niets in dit museum is uit het geheugen geschreven.
De Hall: Het Uberblock
Het object onder het glas: struct uberblock (Regels 122–128 van include/sys/uberblock_impl.h in zfs-2.4.4, geprint met regels 36–150 van het bestand)
ub_txg: de transactiegroep (transaction group) van de laatste synchronisatie.ub_rootbp: de blokpointer naar de wortel van de boom, de MOS (Main Object Set).
Wat is het uberblock?
Een pool bestaat uit miljoenen blokken verspreid over verschillende schijven. Na een crash moet het systeem zijn huidige, consistente staat kunnen vinden zonder al deze blokken te hoeven scannen. Daarom benoemt één klein record de wortel van alles: het uberblock. Het bevat een transactiegroepnummer (ubtxg) en één blokpointer (ubrootbp); elk ander blok in de pool is bereikbaar via die pointer.
Elke schijf bevat vier labels, twee aan het begin en twee aan het einde. Elk label beheert een ring van 128 KiB aan uberblocks. Een nieuw uberblock overschrijft nooit het vorige: het uberblock van txg $N$ gaat naar slot $N \pmod{\text{aantal slots}}$ (bij multihost=on wordt het laatste slot bewaard voor MMP en draait de ring op één slot minder). Bij het importeren leest ZFS elk slot van elk label en behoudt het geldige uberblock met de hoogste txg.
De ring wordt vaak beschreven als een verzameling van 128 uberblocks, maar hij bevat exact 128 KiB. Een slot neemt één sector in beslag, afgerond naar boven op 1 KiB en begrensd op 8 KiB. Dit betekent:
- 128 slots bij 512-byte sectoren.
- 64 slots bij
ashift 11.
- 32 slots bij de huidige 4K-sector schijven.
- 16 slots of minder bij grotere sectorgroottes.
Elk uberblock begint met hetzelfde magische getal, 0x00bab10c: "oo-ba-bloc".
---
Routekaart van het bezoek
De kamers volgen de datastroom: de wortel en de boom, hoe de boom verandert, waar blokken terechtkomen, wat de boom mogelijk maakt, de daarop gebouwde functies, en tot slot de machinekamer.
- 00 Hall: Het uberblock – Het enige record dat de hele pool benoemt, en de ring die dit bewaart.
- 01 History wing – Van de eerste regels code tot OpenZFS, met elke bron vermeld.
- 02 De boom en het uberblock – Blokpointers tot in de kleinste details, en de schrijfactie die een nieuwe boom tot de huidige maakt.
- 03 Copy-on-write, checksums en self-healing – Waarom een pool consistent blijft zonder
fsck, en hoe het een schijf detecteert die onjuiste data teruggeeft.
- 04 Transactiegroepen – Open, quiescing, syncing: hoe duizenden schrijfacties één commit worden.
- 05 De vdevs – Mirror, raidz, draid, log, cache, special: de boom van apparaten onder een pool.
- 06 RAID-Z – Stripes van variabele breedte, en waarom er geen "write hole" is.
- 07 Snapshots en clones – Geboortetijden en deadlists: welk snapshot is eigenaar van dit blok?
- 08 De ARC – Een cache die leert van wat hij is vergeten.
- 09 Metaslabs en space maps – Snel vrije ruimte vinden met een append-only log van allocaties.
- 10 ZIL en SLOG – Het pad van een synchrone schrijfactie.
- 11 Send / Receive – Een dataset als stroom, en het increment tussen twee snapshots.
- 12 Compressie, dedup, encryptie – Drie transformaties in de write-pipeline, en de werkelijke kosten van deduplicatie.
- 13 Machinekamer – Hoe dit museum is gebouwd en vanaf welke commit.
---
Toewijding: Waarom dit museum?
Het veilig houden van data is kritiek werk dat zelden zichtbaar is. Een bestandssysteem krijgt alles toevertrouwd wat mensen bewaren, en het moet correct blijven functioneren ondanks crashes, falende schijven en afgebroken schrijfacties. Een van de principes waarop ZFS is ontworpen, in de woorden van Bill Moore: vertrouw nooit, maar dan ook nooit, op de onderliggende hardware.
Dit museum is een eerbetoon aan dat stuk techniek en aan de mensen die het hebben gebouwd. Jeff Bonwick leidde de ontwikkeling van ZFS, met Bill Moore als co-leider; Matt Ahrens was een van de twee oorspronkelijke auteurs. Het werk begon in 2001 met twee ingenieurs bij Sun Microsystems en werd op 31 oktober 2005 geïntegreerd in Solaris. Bonwick vatte deze stap samen als: 584 bestanden, 92.000 regels wijzigingen, 56 patenten, 5 jaar. Op 17 november schreef hij: "I’m incredibly proud of the ZFS team, and deeply grateful: no one person can do something on this scale."
Het is evenzeer een eerbetoon aan de engineering bij Sun in die jaren, waar ingenieurs publiceerden hoe hun systemen werkten: de slab allocator, gepresenteerd door Jeff Bonwick bij USENIX in 1994; DTrace, door Bryan Cantrill, Michael Shapiro en Adam Leventhal in 2004; en de broncode van ZFS zelf, uitgebracht onder de CDDL als onderdeel van OpenSolaris.
En aan hen die het werk voortzetten: OpenZFS, aangekondigd in 2013 en opgericht door leden van de Linux, FreeBSD, Mac OS X en illumos gemeenschappen. De release die dit museum analyseert, noemt meer dan 700 mensen in het AUTHORS-bestand.
De onderliggende hardware: Een 3,5-inch harde schijf
(Beschrijving van de componenten bij een explosietekening)
- Bovenkap
- Schijfklem
- Platters (magnetische schijven)
- Kopstack: armen en koppen
- Voice coil en magneet
- Spindelmotor
- Basisgietvorm
---
Bronnen
- "A Conversation with Jeff Bonwick and Bill Moore", ACM Queue 5(6), november 2007.
- OpenZFS launch announcement, open-zfs.org.
- openzfs.org wiki, "History".
- Jeff Bonwick, "ZFS: The Last Word in Filesystems", blogpost van 31 oktober 2005.
- Jeff Bonwick, blog, posts van november 2005, "Thank You" van 17 november 2005.
- USENIX, abstract van "The Slab Allocator: An Object-Caching Kernel Memory Allocator", Summer 1994 Technical Conference.
- USENIX, abstract van "Dynamic Instrumentation of Production Systems", 2004 Annual Technical Conference.
Groetjes,