GB naar TiB omrekenen

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

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.

De factor is 0,000909, en die draagt vrijwel niemand met zich mee. Afgerond op 0,00091 zit hij er 0,06 % naast — bij kleine getallen onzichtbaar, en rond 10.000 GB een hele eenheid.

Dat is het getal dat je vóór het afronden wilt weten: niet de fout zelf, maar vanaf waar hij ophoudt verwaarloosbaar te zijn. Daaronder is de korte factor de verstandige; daarboven gebruik je het veld hierboven, dat pas afrondt op het moment van afdrukken.

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.

Opslag wordt gespecificeerd in de eenheid van wie het document schreef. Schijfdatasheets, volumeaanvragen, database-sizingguides en quotumtabellen zijn bijna allemaal in decimale gigabytes, want zo werden de onderdelen verkocht. De pool waar die volumes in landen wordt door software gerapporteerd, en software telt in machten van 1.024, dus komt het totaal terug in tebibytes.

De twee tellen niet op de voor de hand liggende manier op. Een plan van veertig volumes van 250 GB is 10.000 GB, wat klinkt als tien van iets en 9,09 TiB is. Wie een pool van 10 TiB reserveerde, heeft een comfortabele marge die hij niet kende; wie 9 TiB reserveerde, is precies zoveel tekort als de omzetting verbergt, en zal dat merken zodra de pool vol raakt.

De divergentie tussen de decimale en binaire schaal stapelt op bij elke prefix: 2,4 procent bij kilo, 4,86 bij mega, 7,37 bij giga, 9,95 bij tera. Van GB naar TiB gaan gebruikt de tera-stapverhouding, dus is de correctie de grootste die iemand in de praktijk tegenkomt. Een tiende van een capaciteitsplan is geen afrondingsverschil; het is een schijf, een schap of een maand groei.

Het is ook de stap waarop de twee conventies te ver uit elkaar liggen om nog te wisselen. Onder een gigabyte komen mensen ermee weg dat ze de eenheden als verwisselbaar behandelen, omdat de fout zich verbergt in de veiligheidsmarge. Bij de tera-stap is de fout groter dan de meeste marges, en een plan dat duizend gigabyte als een tebibyte behandelt, is verkeerder dan dat het zorgvuldig is.

Vijf cijfers dekken het meeste van dit werk. 1.000 GB is 0,909 TiB. 2.000 GB is 1,819. 5.000 GB is 4,547. 10.000 GB is 9,095. 50.000 GB is 45,47. Andersom absorbeert een TiB 1.099,5 GB, dus zal een pool gerapporteerd als 20 TiB ongeveer 21.990 GB decimaal opgegeven volumes opnemen.

De vuistregel die overleeft ook als hij verkeerd wordt onthouden, is gigabytes met 0,0009095 vermenigvuldigen, of delen door 1.100 en een tiende van een procent fout accepteren. Delen door 1.024 is de fout om te vermijden: die verhouding gaat van gibibytes naar tebibytes, niet van gigabytes, en hem hier gebruiken rapporteert 0,977 TiB voor 1.000 GB — een overschatting van 7,4 procent, in de richting die een pool groter doet lijken dan hij is.

De mislukking is zelden een verkeerde omzetting. Het is een kolom die beide soorten getallen bevat. Een sizingblad haalt schijfcapaciteiten uit een leveranciersofferte in TB, huidig verbruik uit een monitoringexport in TiB, database-schattingen per stuk van een DBA in GB, en een back-upbewaarcijfer uit een beleidsdocument dat niets zegt. Elke waarde klopt op zichzelf en het totaal niet.

De praktische oplossing is bij binnenkomst om te zetten in plaats van aan het einde, en de kolom te benoemen naar zijn eenheid in plaats van naar zijn inhoud. Een kolom met de kop "bytes" kan geen tebibyte-cijfer stilzwijgend accepteren; een kolom met de kop "grootte" wel, en zal dat uiteindelijk doen. Dat is dezelfde discipline die valutakolommen ervan weerhoudt te mengen, toegepast op een verschil dat kleiner is en dus moeilijker te zien.

Op een dik toegewezen pool kondigt een eenheidsfout zich meteen aan: de toewijzingen passen niet en er wordt iets geweigerd. Thin provisioning haalt die controle door ontwerp weg, waardoor de som van volumegroottes de fysieke capaciteit mag overschrijden op de aanname dat niet alles tegelijk gebruikt wordt. De eenheidsfout overleeft die aanname intact en wacht.

Wat er later aankomt is een pool die eerder dan het model voorspelde zijn hoogwatermerk kruist, met ongeveer de omvang van de omzetting die is overgeslagen. Het symptoom is een prognose die steeds herzien moet worden, niet een fout, waarom het de moeite waard is het model eenmaal in bytes tegen de pool te reconciliëren in plaats van te vertrouwen dat twee sets plausibele getallen hetzelfde beschrijven.

De eenheidsomzetting is rekenkunde en geen verlies. De aftrekkingen die erop volgen zijn echt. Pariteit of replicatie neemt eerst zijn deel — een gespiegelde pool halveert, een dubbele-pariteitset van twaalf geeft tien leden bruikbare ruimte. Filesystemstructuren en reserves nemen nog een paar procent. Snapshots nemen wat er tussen hen verandert, wat een snelheid is in plaats van een vast cijfer en het vaakst uit een plan wordt weggelaten.

Die apart houden van de GB-naar-TiB-stap is wat een capaciteitsmodel controleerbaar maakt. Raakt de pool vroeg vol, dan is de eerste vraag welke van de vier aftrekkingen onderschat werd, en die vraag is alleen te beantwoorden als elke als eigen regel is vastgelegd. Eén samengevoegd overheadpercentage verbergt precies de fout die iemand zou willen vinden.

Groeicijfers komen in dezelfde gemengde eenheden als al het andere binnen — een paar honderd gigabyte per maand van een applicatieteam, een percentage van een trendlijn, een cijfer per kwartaal in tebibyte van een monitoringsysteem. Een groeipercentage toepassen op een cijfer in de ene eenheid en optellen bij een basislijn in een andere is de opgestapelde versie van dezelfde fout, en die drift verder met elke planningscyclus.

Zet de basislijn en de groei om naar bytes, draai het model daar, en zet het antwoord om naar welke eenheid de bestelbon ook gebruikt. Het is een saaie stap, kost één kolom, en het is het verschil tussen een plan dat binnen een procent uitkomt en een dat in het tweede jaar een hele schijf misschiet.