TiB naar GB omrekenen

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.

Een gigabyte is een miljard bytes, in de decimale betekenis die schijffabrikanten, databundels en videogroottes hanteren.

Eén TiB is 1.024 van de eenheid eronder; één TB is 1.000. Op deze pagina is dat het verschil tussen 1099,5116 GB en 1000 GB — 10 % — 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.

Arrays rapporteren tebibytes. Een ZFS-pool, een NAS-samenvattingspagina, een Linux-filesystem gevraagd om mensvriendelijke groottes — allemaal tellen ze in machten van 1.024, en het cijfer dat opgeschreven en in een planningsdocument meegenomen wordt, is een TiB-cijfer. Prijslijsten, quotumpagina’s en provisioneringsdialogen zijn overweldigend in decimale GB, want dat is de eenheid waarin capaciteit verkocht wordt en al zo lang voor iemand het per maand verkocht.

Ertussen zit een vermenigvuldiging met 1.099,511627776. Een pool van 12 TiB is 13.194 GB, niet 12.000, en het verschil van 1.194 GB is bijna 10 procent van de offerte. Niets aan de ronde omzetting oogt fout op een pagina — 12 TiB en 12.000 GB lezen voor bijna iedereen als dezelfde hoeveelheid — wat waarom deze fout de beoordeling overleeft en pas als eerste op een factuur verschijnt.

De omzetting is maar de helft van het probleem, want het veld dat je invult kan zelf gibibytes bedoelen. Blockopslagvolumes worden vaak in GiB geprovisioneerd terwijl objectopslag vaak per decimale GB gefactureerd wordt, en de twee kunnen in dezelfde console onder vergelijkbare labels staan. De documentatie van de dienst lezen is de juiste eerste stap en beantwoordt de vraag niet altijd.

Wat altijd antwoordt, is een meting. Provisioneer of sla een hoeveelheid op waarvan je de bytentelling kent, lees wat de dienst rapporteert, en deel: de verhouding zal exact 1.000.000.000 of exact 1.073.741.824 zijn, en er is niets ertussen om te zijn. Eén observatie per dienst beslecht het permanent en is de moeite waard vast te leggen waar de volgende persoon het vindt.

Een bruikbare capaciteit in TiB is meerdere aftrekkingen verwijderd van de schijven die gekocht moeten worden. Zet de bruikbare vereiste om naar bytes; tel de redundantie erbij op, wat voor enkelvoudige pariteit over een set schijven de capaciteit van een van hen kost en voor spiegeling de helft van alles; tel de marge erbij op die het filesystem nodig heeft om goed te blijven presteren, wat voor een copy-on-write-filesystem geen kleine toeslag is; zet dan om naar de decimale terabytes waarin de schijven geëtiketteerd zijn.

Die stappen in gemengde eenheden doen is hoe een pool een schijf tekort komt. Elke aftrekking moet gelden voor een cijfer in een bekend systeem, en de verleiding is hier 9 procent af te trekken en daar een schijf tot het antwoord plausibel oogt. In bytes is elke stap controleerbaar en gebeurt de laatste omzetting precies eenmaal, op het punt waar het getal een bestelbon wordt.

Opslag geprijsd per gigabyte per maand vermenigvuldigt welke hoeveelheid het ook krijgt, dus is een fout in de hoeveelheid een fout in elke factuur zolang de data bestaat. Een migratie van 12 TiB opgeven als 12.000 GB in plaats van 13.194 onderschat met 1.194 GB per maand, permanent, en het tekort is niet zichtbaar in een enkel getal op de factuur — het is alleen zichtbaar als een totaal dat niet overeenkomt met de schatting.

Hetzelfde geldt voor al het andere per volume gefactureerd: overdracht, snapshots, replica’s in een tweede regio. Elk is een vermenigvuldiger op een basishoeveelheid, en elk erft welke eenheidsfout de basis ook draagt. De basis eenmaal goed krijgen is meer waard dan elke regel achteraf controleren, wat het algemene argument is voor in bytes offreren en elk systeem het cijfer in zijn eigen eenheden laten presenteren.

Een poolsamenvatting toont meestal meerdere getallen die op capaciteit lijken en dat niet zijn: ruwe capaciteit over de schijven, bruikbare capaciteit na redundantie, toegewezen ruimte, en vrije ruimte, soms met compressie- en deduplicatiebesparingen in een ervan gevouwen. Het verkeerde paar vergelijken produceert een discrepantie die aan eenheden wordt toegeschreven terwijl het een definitieprobleem is.

De volgorde om ze in te lezen is ruw, dan bruikbaar, dan toegewezen. Ruw zou dicht moeten liggen bij de som van de schijfetiketten omgezet van decimale TB naar TiB — zo’n 91 procent van het getal op de dozen. Bruikbaar zou ruw min de redundantie moeten zijn. Toegewezen zou minder dan bruikbaar moeten zijn met wat vrij is. Klopt een van die drie relaties niet, dan zit de verklaring in de configuratie eerder dan in de rekenkunde.

Opslaglagen die comprimeren of dedupliceren rapporteren een logische grootte en een fysieke, en de verhouding ertussen is een eigenschap van de data eerder dan van het systeem. Een pool met sterk comprimeerbare data kan meer logische bytes opslaan dan zijn fysieke capaciteit, wat elke prognose op logische cijfers onbetrouwbaar maakt in beide richtingen — gunstig terwijl de data comprimeerbaar blijft, en abrupt ongunstig zodra een grote hoeveelheid al gecomprimeerde media aankomt.

Voor een offerte betekent dit vermelden welk cijfer geprijsd wordt. Een migratie geoffreerd op logische grootte en gefactureerd op fysieke, of andersom, produceert een verschil veel groter dan de 9,95 procent waar deze pagina over gaat. De eenheidsomzetting is exact en eenmalig te beslechten; de compressieverhouding is een schatting die op een representatieve steekproef gemeten en als aanname vermeld moet worden. Vermelden maakt de offerte ook herzienbaar: blijkt de echte verhouding anders, dan hoeft maar een getal in het document te veranderen.

De gewoonte die deze hele klasse geschillen wegneemt, is de bytentelling in elk document te dragen dat door meer dan een organisatie gelezen zal worden. Een offerte die 13.194 GB zegt en er 13.194.139.533.312 bytes naast geeft, is door iedereen controleerbaar, kan naar elke conventie omgezet worden, en kan zonder een gesprek over wiens gigabyte bedoeld wordt met elke prijslijst vergeleken worden.

Het kost één kolom en verandert waar een meningsverschil over gaat. Met bytes op de pagina is een mismatch een vraag over wat geteld wordt — snapshots, replica’s, overhead — wat een discussie is die beide partijen productief kunnen voeren. Zonder bytes gaat het eerste uur op aan vaststellen of iemand het überhaupt over dezelfde hoeveelheid heeft, en dat uur herhaalt zich bij elke fase van het project. De bytentelling is een getal, hoeft nooit vertaald te worden, en is het enige cijfer in het document waarvan beide partijen zeker kunnen zijn dat ze het op dezelfde manier lezen.