MiB naar B 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 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.

Deze kant op is het een vermenigvuldiging, en wel met een heel getal: één mebibyte is 1.048.576 bytes, precies, en 1.048.576 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 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 meeste groottesomzettingen bestaan zodat een mens zich een hoeveelheid kan voorstellen. Deze bestaat meestal zodat een machine er een kan afdwingen. Een uploadlimiet, een heapgrootte, een buffertoewijzing, een chunkgrens in een multipart-overdracht — elk is een geheel getal waar iets tegen vergelijkt.

Het nuttige cijfer hier is dus 1.048.576 en zijn veelvouden, geen benadering. Tien MiB is 10.485.760 bytes; 64 MiB is 67.108.864; 512 MiB is 536.870.912. Elk daarvan is een getal dat deze week door iemand in een configuratiebestand getypt is, en elk ligt een cijfer verwijderd van een waarde die stiekem 4,86 procent anders is.

Een verrassende hoeveelheid software neemt een grootte met een letter erachter en behandelt die letter als op 1.024 gebaseerd. De nginx-achtervoegsels k en m zijn binair. De JVM-heapvlaggen -Xms512m en -Xmx2g zijn binair. PHP’s upload_max_filesize = 8M is binair. Geen van deze schrijft de i, en geen zegt het in de regel die je bewerkt.

GNU dd is het leerzame geval omdat het beide conventies accepteert en ze onderscheidt op lengte: bs=1M is 1.048.576 bytes en bs=1MB is 1.000.000. Dat is een verdedigbaar ontwerp en een betrouwbare valstrik, want de twee spellingen lijken op tikvarianten van elkaar.

Kubernetes-resourcehoeveelheden accepteren beide schalen expliciet, dus memory: 512Mi is 536.870.912 bytes en memory: 512M is 512.000.000. Beide zijn geldig, beide slagen voor schemavalidatie, en het verschil is één letter in een bestand dat wordt toegepast zonder dat iemand het nog eens leest.

Het gat wordt groter hogerop de schaal, waar het echte schade doet. Op de mega-stap is het 4,86 procent; op giga is het 7,37 procent, dus 4Gi en 4G verschillen ongeveer 295 megabyte. Een limiet gezet vanuit een monitoringaflezing in GiB en getypt als G is vanaf de eerste deploy ondergedimensioneerd.

In code verslaat de expressie de letterlijke waarde. 1024 * 1024 en 1 << 20 zeggen allebei wat de waarde is en laten een reviewer haar controleren zonder nullen te tellen, terwijl 1048576 naast 10485760 in een configuratietabel een diff is die niemand opmerkt.

De andere helft van de discipline is naamgeving. Een veld genaamd maxBytes kan geen mebibyte-cijfer per ongeluk krijgen; een veld genaamd maxSize wel. Waar een waarde een grens oversteekt — een formulier, een omgevingsvariabele, een API — hoort de eenheid in de naam.

Het getal dat bij deze omzetting aankomt, kwam meestal uit iets dat standaard in binaire eenheden meet. free rapporteert in kibibytes tenzij anders opgedragen. /proc/meminfo drukt kB af en bedoelt KiB. top en ps tonen resident set size in KiB. Containerruntimes rapporteren limieten en gebruik in bytes.

Dat is handig: die aflezing met 1.048.576 vermenigvuldigen brengt je terug naar het exacte bytecijfer dat de kernel had. Het botst pas wanneer een decimaal-megabytegetal van een specificatieblad of contract in hetzelfde veld terechtkomt.

Een net cijfer in MiB is een onnet in bytes, en er is geen opstelling van de twee schalen waarin beide er netjes uitzien. 700 MiB is 734.003.200 bytes. 250 MiB is 262.144.000. 1,5 MiB is 1.572.864. Geen daarvan oogt als een getal dat iemand koos, en allemaal zijn ze exact.

Het klassieke voorbeeld is de cd: een tachtig-minuten dataschijf bevat 360.000 sectoren van 2.048 bytes, wat 737.280.000 bytes is, ofwel 703,125 MiB. De schijf heet al dertig jaar een "700 MB"-schijf, en het cijfer is noch een decimale 700 MB noch een binaire 700 MiB.

Eén mebibyte is precies 256 geheugenpagina’s van 4.096 bytes, 2.048 schijfsectoren van 512 bytes, of 256 bestandssysteemblokken op een standaard ext4-volume. Elke grens onder een mebibyte-cijfer valt op een geheel getal, wat verklaart waarom buffergroottes en partitie-offsets in binaire eenheden gespecificeerd worden.

Een decimale megabyte deelt in geen daarvan. 1.000.000 bytes is 244,14 pagina’s en 1.953,125 sectoren, dus een buffer van die grootte overspant een paginagrens aan het ene eind en verspilt een deel van een blok aan het andere.

Een limiet in mebibytes verdient drie testfixtures in plaats van één, en hun groottes komen rechtstreeks uit deze omzetting. Voor een plafond van 10 MiB zijn de interessante bytes 10.485.759, 10.485.760 en 10.485.761: één eronder, precies erop, één erboven.

Die fixtures genereren is de moeite waard om op bytetelling te doen in plaats van op eenheid. Een bestand gemaakt met een groottearg in een vriendelijke eenheid erft de basis die het scheppende gereedschap gebruikte, dus een fixture bedoeld om één byte over een limiet te zijn, kan vier procent eronder uitkomen.