zfs: Opslag en bestandssystemen

Je koopt een NAS, je stopt er vier schijven in, en dan moet je kiezen. Niet welke schijven — dat is een prijsvraag. Welk bestandssysteem eroverheen gaat, en dat bepaalt de komende tien jaar wat je wel en niet kunt terugdraaien als er iets misgaat.

ZFS is dan de naam die bovenaan de lijstjes staat. Zettabyte File System, in 2001 bij Sun Microsystems begonnen door Jeff Bonwick en Matt Ahrens, publiek aangekondigd op 14 september 2004, in Solaris 10 sinds 2006. Die geschiedenis is niet belangrijk voor je keuze. Wat belangrijk is: wat het ding doet, en wat het je kost.

Het eerste wat je moet weten is dat ZFS geen bestandssysteem is in de zin die je gewend bent. Het is een bestandssysteem én een volume manager in één laag. Waar je bij ext4 of XFS eerst partities maakt, dan een RAID-opstelling bouwt met mdadm of een hardware-controller, en daar dan een bestandssysteem overheen legt, doet ZFS dat in één beweging. Je geeft het schijven, het maakt een pool, en klaar.

Dat klinkt als gemak, en het is ook gemak. Maar het is vooral een ontwerpkeuze met gevolgen. Omdat ZFS de schijven zelf beheert, weet het welke blokken waar staan en of ze kloppen. Het kan een schijf vervangen zonder dat jij iets hoeft te vertellen over partitietabellen. Het kan niet tegen je liegen over de staat van je data.

De prijs daarvan: je kunt ZFS niet even op een bestaande partitie zetten. Je geeft het hele schijven, en die schijven ben je kwijt aan ZFS. Geen dual boot met een ZFS-pool op dezelfde disk. Geen makkelijk uitschuiven van een schijf om hem ergens anders in te pluggen zonder de pool mee te nemen.

Dan de eigenschap waar mensen ZFS om prijzen: copy-on-write. Als je een bestand wijzigt, schrijft ZFS de nieuwe versie naar nieuwe blokken. Het overschrijft niets. Valt de stroom uit tijdens het schrijven, dan staat je oude versie er nog. Dat is geen luxe. Dat is het verschil tussen een middag werk en een week werk.

Elk blok krijgt een checksum. Bij elke leesactie controleert ZFS of het blok nog klopt. Klopt het niet, en heb je redundantie, dan haalt het de goede kopie op. Dit heet end-to-end data integrity, en het is het enige echte antwoord op stille corruptie — het fenomeen waarbij een schijf je vertelt dat alles goed gaat terwijl er bits zijn omgevallen.

Wat dat kost: rekenwerk. ZFS checksumt alles, altijd. Op een oude CPU met veel schijven ga je dat merken. Op moderne hardware niet.

Snapshots zijn de andere reden dat mensen blijven. Een snapshot maken is één commando en kost bijna niets. Geen kopie van je data, alleen een verwijzing naar de blokken zoals ze op dat moment waren. Je kunt er honderd hebben zonder dat je schijf vol loopt.

Tot je data gaat wijzigen. Dan blijven de oude blokken staan zolang een snapshot ze vasthoudt. Een snapshot van een database die elke seconde schrijft, groeit net zo hard als de database zelf. Snapshots zijn geen backup. Ze staan op dezelfde schijven, in dezelfde pool, en als die pool omvalt ben je ze allebei kwijt.

Replicatie is wel een backup, als je hem naar een andere machine stuurt. ZFS kan een snapshot incrementeel naar een andere pool sturen. Alleen de blokken die veranderd zijn, gaan over de lijn. Dat is efficiënt en het werkt, maar het vereist dat je die tweede machine hebt en onderhoudt.

Dan de RAID-kant. ZFS heeft RAID-Z1, Z2 en Z3. Dat is ruwweg te vergelijken met RAID 5, 6 en een variant met drie pariteitsblokken. Het verschil met traditionele RAID: ZFS schrijft nooit een partiële stripe. Bij een stroomstoring halverwege een schrijfactie heb je geen RAID die moet reconstrueren en onderweg je hele array sloopt.

RAID-Z1 met schijven groter dan 2 TB is vragen om problemen. De kans dat een tweede schijf bezwijkt tijdens de rebuild is te groot. Z2 is het minimum dat je serieus moet overwegen. Z3 als je niet wilt nadenken over de vraag of je genoeg redundantie hebt.

Wat dat kost: schijfruimte. Z1 verliest één schijf aan pariteit, Z2 twee, Z3 drie. Bij vier schijven in Z2 houd je de helft over. Bij zes schijven in Z2 verlies je een derde. Reken dat door voordat je schijven bestelt.

RAID-Z is ook niet uit te breiden door er simpelweg een schijf bij te prikken. Je kunt een pool vergroten door een tweede vdev toe te voegen — een tweede set schijven met eigen pariteit. Maar de bestaande vdev wordt niet groter. Wie zes schijven in Z2 heeft en later naar acht wil, moet die twee schijven als aparte mirror toevoegen, of alles opnieuw opbouwen.

Dat is een harde grens. Wie denkt ooit wel te gaan groeien, koopt nu meer schijven dan nodig. Wie dat niet doet, betaalt later met een migratie.

Geheugen is het volgende. ZFS gebruikt ARC, Adaptive Replacement Cache. Dat is geen buffer die zichzelf opruimt als iets anders geheugen nodig heeft. Het pakt wat het pakken kan. De vuistregel is 1 GB per TB opslag, plus wat extra. Onder de 8 GB moet je niet beginnen. Bij deduplicatie — wat je vrijwel nooit moet aanzetten — gaat het richting 5 GB per TB, en dat is de reden dat mensen hun pool om zeep helpen.

Deduplicatie klinkt als gratis ruimte. Het is het niet. Het vreet geheugen, het vertraagt schrijven, en het levert zelden op wat je hoopt, tenzij je honderden identieke virtuele machines hebt staan. Laat het uit.

Compressie daarentegen is bijna gratis op moderne CPUs. LZ4 kost je vrijwel geen snelheid en levert vaak 1,5 tot 2 keer zoveel effectieve ruimte op. Zet het aan. Er is geen goede reden om het niet te doen.

Dan de vraag die je eigenlijk stelt: welk ZFS krijg je, en van wie?

Er zijn twee kampen. Oracle ZFS, dat alleen op Solaris draait, en OpenZFS, de open-sourcetak die na de overname van Sun in 2010 is ontstaan. Oracle stopte OpenSolaris, de gemeenschap begon illumos, en daaruit groeide OpenZFS. Dat is wat je vandaag de dag tegenkomt op FreeBSD, Linux en TrueNAS.

Op Linux is OpenZFS beschikbaar als kernelmodule of via FUSE. FUSE is langzamer en je wilt het niet voor productie. De kernelmodule is wat je gebruikt, maar die zit niet in de standaardkernel. Je installeert hem apart, en na een kernelupdate moet je hem opnieuw bouwen. Op Debian en Ubuntu is dat tegenwoordig goed geregeld via DKMS. Op distributies die hun eigen kernel bouwen kan het misgaan.

FreeBSD heeft ZFS in de basisinstallatie. Geen module, geen DKMS, geen gedoe. Wie een opslagserver bouwt en geen andere reden heeft voor Linux, heeft in FreeBSD een sterk argument.

Waar het van afhangt is wat je al draait. Heb je een Linux-homelab met containers, dan is OpenZFS op Linux de logische keuze, met de kanttekening dat je kernel en je ZFS-module bij elkaar moeten passen. Draai je puur opslag, dan is FreeBSD minder werk. Wil je een kant-en-klare NAS, dan is TrueNAS een OpenZFS met een webinterface eroverheen, en dat scheelt je een hoop avonden.

De feature flags uit 2012 maken het mogelijk om functionaliteit toe te voegen zonder de on-disk versie te breken. Een pool van vijf jaar oud werkt nog, en nieuwe functies staan uit tot je ze aanzet. Dat is de reden dat ZFS-pools van een decennium geleden nog steeds te lezen zijn. Er zijn niet veel bestandssystemen waarvan je dat kunt zeggen.

Wat je uiteindelijk kiest hangt af van hoeveel schijven je hebt, hoeveel je bereid bent uit te geven aan redundantie, en of je iemand bent die op zondagavond een pool durft te reconstrueren. ZFS geeft je de middelen om dat te doen. Het geeft je niet de zekerheid dat je het goed doet.