GB naar MiB omrekenen

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

Een mebibyte is 1.024 kibibyte, oftewel 1.048.576 bytes. De hulpmiddelen van Linux en de geheugengetallen bedoelen vrijwel altijd dit, ook als er «MB» staat.

De factor is 953,674316, en die draagt vrijwel niemand met zich mee. Afgerond op 950 zit hij er 0,39 % naast — bij kleine getallen onzichtbaar, en rond 1.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 MiB is 1.024 van de eenheid eronder; één MB is 1.000. Op deze pagina is dat het verschil tussen 0,001 GB en 0,001 GB — 4,9 % — 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.

Een gigabyte is een miljard bytes. Een mebibyte is 1.048.576. Deel het een door het ander en je krijgt 953,67431640625, exact en zonder afronding — een getal dat niemand zou raden en dat iedereen moet opzoeken. Het instinct is om naar 1.000 te grijpen, wat de MB in een GB is, of naar 1.024, wat de MiB in een GiB is, en beide zijn hier fout omdat het paar de grens tussen de twee stelsels oversteekt.

De grootte van de fout hangt af van welk verkeerd getal je kiest. 1.000 gebruiken overschat met 4,9 procent; 1.024 gebruiken overschat met 7,4. Op een dashboard is dat een net iets verkeerde lijn. Op een drempelwaarde is het een alarm dat afgaat bij een percentage dat je niet koos.

Drempels zijn meestal bedoeld als breuken van iets: alarm bij 80 procent van de schijf, waarschuwing bij 90 procent van de geheugenlimiet. Die bedoeling overleeft alleen als de breuk genomen wordt van de toewijzing in de eigen eenheid van die toewijzing en dan eenmaal, aan het eind, wordt omgerekend. Tachtig procent van een gigabyte is 762,9 MiB en negentig procent is 858,3 MiB.

Wat mensen in plaats daarvan typen, is 800 en 900, ronde getallen die niet de bedoelde breuken zijn — 800 MiB is 84 procent van een gigabyte en 900 MiB is 94. Het alarm werkt nog steeds, het gaat alleen later af dan het draaiboek zegt, en de discrepantie is onzichtbaar omdat zowel de regel als de documentatie plausibele ronde getallen bevatten.

Prometheus neemt hier geen standpunt over: de conventie onder zijn exporters is om ruwe bytes op te slaan met een _bytes-achtervoegsel en de presentatielaag een eenheid te laten kiezen. Dat is het juiste ontwerp en het verplaatst de beslissing naar het dashboard, waar hij per veld wordt gemaakt.

Het praktische gevolg is dat twee panelen op hetzelfde dashboard dezelfde reeks 7 procent uit elkaar kunnen tonen en beide correct geconfigureerd zijn. Een query geeft bytes terug; het ene paneel formatteert ze decimaal, het andere binair; de assen zeggen GB en GiB, of erger, allebei zeggen GB.

Containerresources zijn de plek waar deze omzetting het vaakst gebeurt en het minst gecontroleerd wordt. Kubernetes accepteert beide stelsels en onderscheidt ze correct: Mi en Gi zijn de binaire hoeveelheden, M en G de decimale. Een limiet van 1G is 1.000.000.000 bytes; een limiet van 1Gi is 1.073.741.824. Beide zijn geldig, beide gelden zonder waarschuwing.

De valkuil is een keten waar de eenheden bij elke schakel veranderen. Capaciteit wordt in decimale GB gekocht, een node wordt in GiB beschreven, een limiet wordt in Mi geschreven, en een dashboard toont wat het ook was ingesteld. Reken alles één keer om naar bytes, op het punt waar de getallen vergeleken worden.

Er is een werkbare vuistregel en die moet als vuistregel behandeld worden. Getallen die iets beschrijven dat gekocht is — een abonnement, een quotum, een factuur — zijn vrijwel altijd decimaal, want dat is de eenheid waarin capaciteit verkocht wordt. Getallen die uit een draaiende machine komen — gebruikt geheugen, pagecache — zijn vrijwel altijd binair.

Waar de vuistregel opraakt, is er een test die dat niet doet. Zoek een hoeveelheid die je onafhankelijk in bytes kunt meten, stuur die door de console, en kijk welke deling het weergegeven cijfer reproduceert. Eén observatie beslecht de vraag voor die console permanent.

Hij ziet er nergens naar uit, en dat is het lastige. Een lijn 5 procent boven waar hij hoort te zijn heeft dezelfde vorm, dezelfde trend en hetzelfde veranderingstempo als de correcte; niets eraan roept argwaan op. De fout wordt pas zichtbaar zodra de grafiek vergeleken wordt met een extern cijfer.

De ene visuele aanwijzing om te kennen is een marge-lijn die nooit helemaal uitkomt. Plateaut een gebruiksreeks bij 93 of 107 procent van de capaciteit in plaats van bij 100, dan is die verhouding de eenhedenkloof en geen meetartefact. 1,074 en 0,931 zijn de twee getallen om te herkennen.

De blijvende oplossing is niet deze omzetting eenmalig goed doen, het is hem overbodig maken voor de volgende keer. Noem variabelen en metrieken naar wat ze bevatten — een drempel in bytes is een drempel in bytes, hoe hij ook wordt weergegeven — en zet de afleiding naast elke handmatig omgerekende letterlijke waarde.

Waar een systeem met een ander moet praten, spreek bytes af op de grens en reken alleen bij de randen om. Dat is dezelfde discipline gebruikt voor tijdzones en valuta, en om dezelfde reden: de ambiguïteit zit niet in het rekenwerk, dat triviaal is, maar in het aantal plekken waar iemand moet onthouden welke conventie gold.