B naar MiB omrekenen

Een byte is acht bits, en dat stond niet altijd vast: de eerste computers gebruikten er zes, zeven of negen. Acht won omdat er een teken in past en omdat het getal netjes in helften uiteenvalt.

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.

Deze kant op is het een deling, en wel door een heel getal: er gaan er 1.048.576 in één mebibyte, 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 MiB is 1.024 van de eenheid eronder; één MB is 1.000. Op deze pagina is dat het verschil tussen 1048576 B en 1000000 B — 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.

De bytetelling is het betrouwbare getal in deze uitwisseling. Hij komt uit een bestandssysteemaanroep of een content-length-header, kent geen eenheidsdiscussie, en is wat de software uiteindelijk vergelijkt. Het MiB-cijfer is een menselijk gemak erbovenop, en elk probleem in deze richting ontstaat door dat gemak als bron van waarheid te behandelen.

Doe de omzetting dus in de volgorde die de bytetelling gezaghebbend houdt: deel door 1.048.576, beslis waarop je afrondt, en vermenigvuldig terug om te bevestigen dat de limiet die je schreef het bestand dat je mat nog steeds toelaat.

Een bestand van 10.486.000 bytes is 10,0002 MiB. Geschreven in een uploadlimiet als "10m" is het nu groter dan de limiet en wordt het geweigerd. Naar beneden afronden is de standaardgewoonte, en voor een bovengrens is dat altijd de verkeerde — de grens moet minstens zo groot zijn als het grootste wat hij zou moeten toelaten.

Het spiegelbeeld is een reservering in plaats van een plafond. Ruimte gereserveerd voor een cache moet naar beneden afronden, want naar boven afronden belooft capaciteit die er niet is. Eén vraag beslist steeds de richting: wordt dit getal met een byte fout, wil ik dan liever iets te veel of iets te weinig?

Veel configuratie accepteert een achtervoegsel, en het achtervoegsel zegt zelden bij welk systeem het hoort. nginx leest k als 1.024 en m als 1.048.576, dus client_max_body_size 10m is 10.485.760 bytes. De JVM doet hetzelfde met -Xmx en -Xms.

Kubernetes is degene om van te leren, want het weigert te gokken. Mi, Gi en Ti zijn de binaire hoeveelheden en M, G en T de decimale, allebei geldig in een manifest, en een geheugenlimiet van 512M is 4,6 procent kleiner dan een van 512Mi. Niets waarschuwt je: het manifest wordt toegepast, de pod start, en de limiet zit niet waar bedoeld.

Een mebibyte is 2 tot de twintigste macht, en dat verklaart waarom het opduikt als de natuurlijke grootte voor dingen die een kernel toewijst. Pagina’s zijn 4 KiB, huge pages zijn vaak 2 MiB, en een buffer op een macht van twee gezet, sluit overal netjes op aan zonder rest.

Het praktische gevolg is dat binair gemaakte waarden zich voortplanten. Is je blokgrootte een macht van twee, en je deelgrootte een veelvoud daarvan, en je limiet een veelvoud van je deelgrootte, dan deelt alles precies en heeft geen stap een restje aan het eind.

Een groot object in delen uploaden is waar deze getallen ophouden cosmetisch te zijn. Een deelgrootte gekozen in binaire eenheden verdeelt een bestand in een geheel aantal volle delen plus een rest, en het aantal delen is beperkt, dus de deelgrootte moet groot genoeg zijn dat het object binnen dat plafond past.

De controle is rekenwerk en de moeite waard vóór de overdracht: deel de exacte objectgrootte in bytes door de deelgrootte in bytes, rond naar boven af, en bevestig dat het resultaat binnen de limiet van de provider valt.

10,5 MiB tonen is prima. 10,5 MiB opslaan en later de bytetelling reconstrueren niet, want de weergave heeft alles onder ongeveer duizend bytes weggegooid en er is geen manier om dat terug te krijgen. Manifesten en auditrecords horen de bytetelling te dragen en het vriendelijke cijfer pas bij weergave af te leiden.

Dezelfde regel geldt voor vergelijkingen. Twee objecten allebei getoond als 4,2 MiB kunnen vijftigduizend bytes verschillen, en een deduplicatie- of driftcontrole geschreven tegen de weergegeven waarde noemt ze identiek.

De duurste fout op deze pagina is niet de 4,9 procent tussen MB en MiB, het is de factor acht tussen bytes en bits. Opslag- en bestandsgroottes worden in bytes geteld; doorvoer wordt in bits per seconde opgegeven, wat verklaart waarom een verbinding van 100 Mb/s hoogstens 12,5 MB/s levert.

De conventie die ze onderscheidt is een hoofdletter B voor bytes en een kleine letter b voor bits, en die wordt vaak genoeg gevolgd om erop te vertrouwen en vaak genoeg geschonden om te controleren. Oogt een cijfer acht keer te groot of te klein, dan is dat het eerste om te toetsen.