RAID-Z-calculator: wat je ZFS-pool werkelijk overhoudt
Inhoud bijgewerktMet 6 × 8 TB in RAID-Z2 komt de pariteitsformule uit op 32 TB, oftewel ongeveer 29,10 TiB. ZFS houdt daarvan nog ongeveer 1 TB achter als reserve, dus wat de pool uiteindelijk meldt is ruwweg 28,19 TiB. Dat laatste getal is waar deze calculator om draait: elke andere RAID-Z-rekenmachine stopt bij de pariteitsformule en laat je de reserve zelf ontdekken als je pool al draait.
Als Amazon-partner verdienen wij aan kwalificerende aankopen op Amazon.nl. Onze links dragen de partnertag cloudzat0a08-21. Dat kost je niets extra en verandert niets aan de prijs die je betaalt.
RAID-Z2 (dubbele pariteit)
Meerdere vdevs verdelen de schijven over aparte groepen. Het aantal schijven moet dan deelbaar zijn door het aantal vdevs.
De pariteitsberekening alleen komt uit op 29,10 TiB (32 TB). ZFS houdt daarvan nog 1 TB achter als reserve, zodat een volle pool beschrijfbaar blijft. Dat is het getal dat mensen kwijtraken als ze alleen de pariteitsformule gebruiken.
Kosten om te vullen: vanaf € 2.034 voor 6 × 8 TB (€ 42,37/TB over het geheel)
De reserve die ZFS achterhoudt
ZFS reserveert ongeveer 1/32 van een pool, de zogenoemde slop space. De reden is fundamenteel voor hoe ZFS werkt: het is een copy-on-write bestandssysteem, wat betekent dat zelfs het verwijderen van een bestand tijdelijk ruimte nodig heeft om de nieuwe metadata weg te schrijven. Loopt een pool helemaal vol, dan kun je zonder die reserve letterlijk niets meer doen, ook geen ruimte vrijmaken. Die 1/32 is dus geen verspilling maar een nooduitgang, en hij verschijnt nooit als beschikbare ruimte.
Praktisch betekent dit dat je een ZFS-pool sowieso niet boven ongeveer 80 procent moet vullen. Daarboven begint de prestatie merkbaar terug te lopen, omdat ZFS steeds meer moeite moet doen om aaneengesloten blokken te vinden. Reken die 20 procent dus mee als je bepaalt hoeveel ruimte je nodig hebt, bovenop de reserve die deze calculator al aftrekt.
Hoeveel schijven per vdev
Een vdev is de eenheid waarin ZFS pariteit organiseert. Een pool bestaat uit een of meer vdevs, en de pool valt uit zodra één vdev uitvalt. Dat is de belangrijkste regel die mensen missen: twee vdevs naast elkaar geven meer prestatie, maar ze verdubbelen ook het aantal plekken waar het fout kan gaan.
Voor de breedte van een vdev is de vuistregel eenvoudig. Blijf bij RAID-Z1 onder de zes schijven, en gebruik het alleen met schijven tot ongeveer 8 TB. Voor alles daarboven is RAID-Z2 de gangbare keuze, met zes tot twaalf schijven per vdev. RAID-Z3 is voorbehouden aan brede vdevs vanaf ongeveer twaalf schijven of aan data waar je echt niet buiten kunt.
Waarom RAID-Z1 met grote schijven riskant is
Het gaat niet om de kans dat een schijf uitvalt, maar om wat er daarna gebeurt. Bij een resilver leest ZFS elke overgebleven schijf in de vdev volledig uit om de nieuwe schijf te vullen. Bij schijven van 16 of 20 TB duurt dat makkelijk een dag, soms meerdere. In die periode staan al je overgebleven schijven onder maximale belasting, en dat is precies het moment waarop een tweede schijf die al zwak was het opgeeft. Bij RAID-Z1 is de pool dan weg. Eén schijf extra aan pariteit kost een fractie van wat het herstellen van die data kost.
ZFS tegenover SHR en klassieke RAID
Het grote voordeel van ZFS is niet de capaciteit maar de integriteit: het controleert elk blok dat het leest tegen een checksum, en met pariteit erbij repareert het stille gegevensbeschadiging vanzelf. Dat is iets wat klassieke RAID niet kan, want die weet niet welke van de twee kopieën de goede is. Daar betaal je voor met starheid: een vdev is niet zomaar te verbreden, gemengde schijfgroottes kosten ruimte, en de reserve is er altijd. Wie flexibiliteit belangrijker vindt dan integriteitscontrole, kijkt naar SHR met de RAID-calculator of naar Unraid, waar gemengde schijven juist niets kosten.
Hoeveel geheugen erbij
De vuistregel "8 GB plus 1 GB per TB" wordt nog steeds overal herhaald, maar hij stamt uit het FreeNAS-tijdperk en past niet meer bij hoe OpenZFS 2.x de cache beheert. De TrueNAS-geheugencalculator rekent zowel de oude regel als de praktische behoefte uit en zegt welke van de twee voor jouw pool geldt.
Over de prijzen in deze calculator
De bedragen in het koopblok komen rechtstreeks van Amazon.nl via de Creators API en worden een paar keer per dag automatisch bijgewerkt. Onder elke tabel staat wanneer dat voor het laatst gebeurde. De prijs op Amazon.nl op het moment van bestellen is de prijs die geldt.
Veelgestelde vragen
Hoeveel ruimte houd ik over met zes schijven van 8 TB in RAID-Z2?
Ruwweg 32 TB aan pariteitsniveau, oftewel ongeveer 29,10 TiB. Daarvan houdt ZFS nog ongeveer 1 TB achter als reserve, dus wat de pool uiteindelijk meldt ligt rond 28,19 TiB. RAID-Z2 offert twee schijven op aan pariteit: zes schijven min twee, maal de kleinste schijf.
Waarom toont mijn pool minder dan de pariteitsformule zegt?
Omdat ZFS ongeveer 1/32 van de pool achterhoudt als reserve, de zogenoemde slop space. Een bestandssysteem dat helemaal vol loopt kan niets meer verplaatsen, en juist ZFS heeft vrije ruimte nodig om te kunnen schrijven. Die reserve zie je nooit terug in df. Deze calculator toont hem apart, want het is het getal dat mensen kwijtraken als ze alleen de pariteitsformule gebruiken.
Wat is het verschil tussen RAID-Z1, Z2 en Z3?
Het aantal schijven dat aan pariteit opgaat, en dus het aantal schijven dat tegelijk mag uitvallen. Z1 offert er één op, Z2 twee en Z3 drie. Voor een pool met schijven tot ongeveer 8 TB is Z1 te verdedigen; vanaf 12 TB per schijf is Z2 de gangbare keuze, omdat de rebuild dan zo lang duurt dat een tweede uitval een reëel risico wordt.
Kan ik een RAID-Z-vdev later uitbreiden met een schijf?
Sinds OpenZFS 2.3 kan dat met RAID-Z expansion, maar met een kanttekening: de bestaande data blijft op de oude verhouding tussen data en pariteit staan en wordt niet automatisch herverdeeld. Je wint dus minder ruimte dan je zou verwachten totdat je die data herschrijft. Plan een vdev daarom nog steeds liever meteen op de gewenste breedte.
Heb ik ECC-geheugen nodig voor ZFS?
Nodig is het niet, verstandig wel. ZFS controleert alles wat het van schijf leest op juistheid, maar het kan niet zien of het geheugen zelf een bit heeft laten vallen voordat de data werd weggeschreven. ECC-geheugen vangt dat af. Voor een thuisserver met vervangbare data is niet-ECC te verdedigen; voor onvervangbare data is het de goedkoopste verzekering die er is.
Moeten alle schijven in een vdev even groot zijn?
Technisch niet, praktisch wel. Een RAID-Z-vdev rekent net als RAID 5 naar de kleinste schijf, dus alles boven die maat blijft ongebruikt. ZFS heeft geen tegenhanger van SHR, dus gelijke schijven binnen één vdev is hier geen advies maar de enige manier om niets weg te gooien.