GiB naar TiB omrekenen

Een gibibyte is 1.073.741.824 bytes, ongeveer 7 % meer dan een gigabyte. Windows meet in gibibytes maar noemt ze «GB», en daarin zit het hele raadsel van de verdwenen ruimte.

Een tebibyte is 1.024 gibibyte. De afstand tot de terabyte groeit bij elke trede: 2,4 % bij kilo, 4,9 % bij mega, 7,4 % bij giga en 10 % bij tera.

Deze kant op is het een deling, en wel door een heel getal: er gaan er 1.024 in één tebibyte, zonder rest. Het enige lastige is dat de uitkomsten in breuken vallen — een derde, een twaalfde — in plaats van de ronde getallen die de andere richting geeft.

Er gaat toch niets verloren, want de deling is exact. Wil je uitkomst als decimaal niet stil blijven staan — 0,0833… en familie —, dan is dat de breuk die doorschemert, geen fout die binnensluipt.

Eén GiB is 1.024 van de eenheid eronder; één GB is 1.000. Op deze pagina is dat het verschil tussen 0,001 TiB en 0,0009 TiB — 7,4 % — en het gat groeit bij elke stap omhoog: op een foto een verwaarloosbare afronding, op een harde schijf een zichtbaar stuk.

Hierin zit het raadsel van de verdwenen opslag volledig. Een schijf die als terabyte verkocht wordt bevat in decimale eenheden precies wat erop staat; Windows telt hem daarna in binaire eenheden maar houdt de decimale naam aan, en daar krimpt het getal zonder dat er iets weg is. macOS telt deze eenheden sinds 10.6 decimaal, en daarom kan dezelfde schijf op twee computers twee maten lijken.

Schijven worden in decimale terabytes verkocht en pools worden in binaire eenheden geteld, dus is het eerste dat met een aankoop gebeurt een korting van tien procent die helemaal geen korting is. Een schijf van 4 TB bevat precies 4.000.000.000.000 bytes zoals geadverteerd, wat 3.725,29 GiB of 3,638 TiB is. Acht ervan zijn 29.802 GiB, oftewel 29,10 TiB, en de factuur zegt 32 TB. Er is niets verloren gegaan tussen die twee cijfers; het zijn dezelfde bytes geteld in andere grondtallen.

De tweede omzetting is degene die echte capaciteit verwijdert, en die komt erna: pariteit of spiegeling, de reserve die het filesystem aanhoudt, en het vulplafond waar iedereen verstandig naar plant. Beide apart houden is wat een capaciteitsplan controleerbaar maakt. Noem het ruwe cijfer eerst in tebibytes, dan elke aftrek met een reden, in plaats van één getal te presenteren dat 40 procent onder de factuur ligt zonder rekenwerk te tonen.

Dit is de meest voorkomende bron van een gibibyte-cijfer dat niet klopt. zpool list rapporteert de ruwe grootte van de vdevs, pariteit inbegrepen, want dat is wat de poollaag beheert. zfs list rapporteert wat de datasetlaag kan opslaan, pariteit uitgesloten. Op een raidz2-pool van acht schijven toont de eerste ruwweg een derde meer dan de tweede, en beide kloppen.

De regel die daaruit volgt is capaciteitscijfers te halen uit de laag die bij de vraag past. Plannen hoeveel data past is een zfs list-vraag. Uitzoeken of een vervangende schijf groot genoeg is, of hoeveel een resilver moet lezen, is een zpool list-vraag. De verkeerde omzetten naar tebibytes en in een plan zetten levert een array op die een derde eerder vol raakt dan de spreadsheet beweerde.

De hoofdrekenkunde is eenvoudig. Een mirror geeft de helft. RAID 5 en raidz1 geven n − 1 schijven data. RAID 6 en raidz2 geven n − 2. Een gestriped mirror geeft altijd de helft, ongeacht breedte. Acht schijven van 3.725,29 GiB in raidz2 geven zes schijven data, 22.351 GiB, oftewel 21,83 TiB, en dezelfde acht als vier gespiegelde paren geven 14.901 GiB, oftewel 14,55 TiB, met veel beter herstelgedrag.

Padding neemt daarna nog een plak die de hoofdrekenkunde mist. ZFS wijst toe in eenheden afgeleid van de sectorgrootte, dus laten records die niet gelijk over de datadisks verdelen gaten achter, en het effect is het ergst bij kleine recordgroottes op brede vdevs. Voor een algemene bestandsserver met de standaard recordgrootte van 128 KiB is het verlies klein; voor een pool met een database op 8 KiB recordgrootte met ashift=12-schijven kan het oplopen tot een vijfde van de nominale capaciteit, wat de moeite waard is om te modelleren voor de pool gebouwd wordt.

Een copy-on-write-filesystem kan een bestand niet vrijmaken door een bit ter plekke te overschrijven; het moet nieuwe metadata schrijven, wat vrije ruimte vereist. Een pool die echt nul vrije ruimte bereikte, zou dus niets kunnen verwijderen, wat een toestand is zonder uitweg. ZFS vermijdt dat door een deel achter te houden — een tweeëndertigste van de pool standaard — dat gewone schrijfbewerkingen niet mogen aanraken.

Op een pool van 32 TiB is dat zo’n 1 TiB apart gezet, en het is niet zichtbaar als vrije ruimte in het cijfer dat gebruikers zien. Het is een vaste verhouding in plaats van een vast bedrag, dus groeit het mee met de pool, en het is een van de aftrekkingen die expliciet in een capaciteitsplan zou moeten staan.

Toewijzingsprestaties op een copy-on-write-pool verslechteren naarmate vrije ruimte fragmenteert, en dat gebeurt scherp in plaats van geleidelijk. Het advies is meestal om te plannen op tachtig procent voor een algemene pool en lager voor een met zware willekeurige schrijflast.

Dat maakt van 32 TiB bruikbare capaciteit ongeveer 25,6 TiB planningscapaciteit, en het verschil behandelen als een marge om tijdens een druk kwartaal aan te knagen is hoe een pool traag en moeilijk herstelbaar wordt. Het gibibyte-totaal omzetten naar tebibytes en het plafond in dezelfde stap toepassen geeft één getal om tegen te plannen; het ruwe cijfer in het plan houden nodigt iemand uit het te gebruiken.

Een pool groeit niet met een willekeurig bedrag. Capaciteit toevoegen betekent nog een vdev van dezelfde vorm toevoegen, of elke schijf in een bestaand vdev vervangen door een grotere en het laten uitbreiden zodra de laatste klaar is. Recente ZFS-releases kunnen een enkele schijf aan een raidz-vdev toevoegen, maar de bestaande data houdt zijn oude pariteitsverhouding tot hij herschreven wordt, dus beweegt het bruikbare cijfer minder dan de rekenkunde suggereert.

Het gevolg voor planning is dat de groei-increment groot en vooraf bekend is. Een raidz2-vdev van acht schijven van 4 TB voegt 21,83 TiB tegelijk toe, dus heeft een plan dat over achttien maanden zijn capaciteit overschrijdt een discrete aankoopbeslissing in plaats van een tarief. Het increment vroeg in tebibytes uitwerken maakt meestal meteen duidelijk of de volgende stap één vdev of twee is.

Een snapshot kost niets bij het nemen en groeit naarmate de levende data ervan afwijkt. Een dataset met 4 TiB en een maand dagelijkse snapshots met een zwaar herschrijfpatroon kan meerdere keren dat verbruiken, en niets van die groei is zichtbaar in de grootte van de huidige data. zfs list -o space splitst het uit in used, usedbysnapshots, usedbydataset en usedbyrefreservation, en die uitsplitsing is waar een onverklaard tekort meestal blijkt te leven.

Het gevolg voor planning is dat het bruikbare tebibyte-cijfer verlaagd moet worden met een toeslag voor snapshotbewaring, en de toeslag hangt af van het herschrijftempo eerder dan van de grootte van de data. Een mediatarchief dat eenmalig geschreven wordt heeft bijna niets nodig; een virtuele-machineopslag waar elke gast dagelijks zijn filesystem herschrijft heeft een grote veelvoud nodig. Is het tempo onbekend, dan is twee weken meten veel goedkoper dan het alternatief van erachter komen als de pool vol is.