MiB naar KiB omrekenen

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.

Een kibibyte is precies 1.024 bytes. De naam is in 1998 ingevoerd zodat «kilobyte» weer 1.000 kon betekenen, al is de gewoonte nooit helemaal aangeslagen.

Deze kant op is het een vermenigvuldiging, en wel met een heel getal: één mebibyte is 1.024 kibibytes, precies, en 1.024 is de definitie en geen meting die er dichtbij kwam.

Daarmee is het een van de weinige omrekeningen die je uit je hoofd kunt doen, en de uitkomst is controleerbaar: deel terug en je moet precies op je begingetal uitkomen, zonder rest die je moet wegpraten.

Eén MiB is 1.024 van de eenheid eronder; één MB is 1.000. Op deze pagina is dat het verschil tussen 1024 KiB en 976,5625 KiB — 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 verrassend aantal Unix-limieten wordt in kibibytes geteld zonder enige manier om dat in de waarde aan te geven. ulimit -s, ulimit -v en ulimit -m zijn allemaal kibibytes. De kolommen stack, data, memlock en as in /etc/security/limits.conf zijn kibibytes. rsync’s --bwlimit is standaard kibibytes per seconde bij een kaal getal.

Dat is waarom deze omzetting een schrijfhandeling is in plaats van een leeshandeling. Je weet dat je een stack van 8 MiB of een plafond van 20 MiB/s wilt; het veld wil 8192 of 20480; en de enige terugkoppeling op een fout is een segfault, een overdracht op een duizendste van het bedoelde tempo, of een limiet zo groot dat hij net zo goed afwezig kan zijn.

Elk mebibyte-cijfer vermenigvuldigd met 1.024 komt uit op een veelvoud van 1.024, en elk mebibyte-cijfer dat zelf een macht van twee is, komt uit op een macht van twee: 8.192, 16.384, 65.536, 262.144, 524.288, 1.048.576. Een configuratiebestand lezen en 8192 vinden, vertelt je dat iemand in mebibytes dacht; 8000 vinden, vertelt je dat iemand in megabytes dacht.

De discrepantie telt zelden op zichzelf en betrouwbaar in optelling. Een limiet op 8000 in plaats van 8192 is 192 KiB te kort, wat geen enkel proces merkt; een buffer van 500.000 in plaats van 524.288 over een vloot is een meetbaar doorvoerverschil.

Waar een tool een achtervoegsel accepteert, verwijdert het gebruik ervan het rekenwerk en documenteert het meteen de bedoeling. sort -S 512M, curl --limit-rate 200K, dd bs=4M, rsync --bwlimit=20M lezen een jaar later nog correct, wat sort -S 524288 niet doet.

De uitzondering is alles dat door iets anders dan de tool zelf geparst zal worden. Monitoring en configuratiebeheer vergelijken deze velden vaak als kale gehele getallen, en een mix van 524288 en 512M over een vloot verslaat de vergelijking.

GNU dd is het duidelijkste geval omdat het beide expliciet spelt: bs=1K is 1.024 bytes, bs=1KB is 1.000, en bs=1KiB wordt als synoniem voor de eerste geaccepteerd. Niets aan de syntax verraadt welke je typte, en een dd-run met de verkeerde kopieert de juiste data in net iets verkeerd formaat.

Elders is de vuistregel dat alles dat een tempo meet, waarschijnlijk decimaal is en alles dat geheugen meet, waarschijnlijk binair, want netwerktechniek standaardiseerde op machten van tien lang voordat de kibibyte een naam had.

De standaard stack van 8 MiB verschijnt als 8192 omdat dat de eenheid is waarin ulimit -s telt, en het is de moeite waard om om te rekenen in plaats van te kopiëren, want het cijfer is per thread. Een JVM of een server met honderden threads per verbinding reserveert die adresruimte honderden keren over.

Het verlagen ervan is een echte tuning-hendel en een echt gevaar. 512 KiB instellen — het veld neemt 512 — is genoeg voor de meeste applicatiecode en niet genoeg voor een diep recursieve parser. Het falen is een segmentation fault zonder melding over limieten, dus het mebibyte-cijfer is de moeite waard om ernaast te noteren.

PostgreSQL geeft zijn geheugeneenheden op als kB, MB en GB en definieert ze als binair, dus shared_buffers, work_mem en wal_buffers zijn allemaal kibibyte-veelvouden onder decimaal ogende labels. SHOW shared_buffers geeft de waarde terug in de eenheid die het het netst vindt.

MySQL neemt bytetellingen met optionele K-, M- en G-achtervoegsels die eveneens op 1.024 gebaseerd zijn. Het praktische gevolg voor beide is dat een waarde gekopieerd uit een tuninghandleiding die megabytes noemde, 2,4 procent kleiner is dan bedoeld per voorvoegselstap.

Vermenigvuldigen met 1.024 houdt elke waarde die als zinnige breuk begon: een helft is 512, een kwart is 256, drie kwart is 768. Waarden die uit een decimale berekening kwamen, overleven niet zo netjes — 0,1 MiB is 102,4 KiB — en het veld neemt een geheel getal, dus moet er een beslissing genomen worden.

Welke kant je afrondt, hangt af van wat het veld is. Een limiet of maximum hoort naar beneden af te ronden, want de bedoeling is "niet meer dan dit". Een buffer of reservering hoort naar boven, want een buffer één kibibyte tekort kan een extra toewijzingsronde kosten.