KiB naar GiB omrekenen

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.

Een gibibyte is 1.073.741.824 bytes, ongeveer 7 % meer dan een gigabyte. Windows meet in gibibytes maar noemt ze «GB», en daarin zit het hele raadsel van de verdwenen ruimte.

Deze kant op is het een deling, en wel door een heel getal: er gaan er 1.048.576 in één gibibyte, 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 KiB is 1.024 van de eenheid eronder; één kB is 1.000. Op deze pagina is dat het verschil tussen 0 GiB en 0 GiB — 2,4 % — 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.

Elke waarde in /proc/meminfo is een telling van eenheden van 1.024 bytes gedrukt onder een label dat kB zegt, en hetzelfde geldt voor /proc/swaps, de per-node meminfo-bestanden onder /sys, en de geheugensysctls. Het label dateert van voor de kibibyte een naam had, en het nu veranderen zou elk script breken dat het bestand ooit parste.

Het gevolg voor wie met de hand omrekent, is een fout van 2,4 procent bij de eerste stap en 7,4 procent tegen de tijd dat het gibibytes bereikt, in de richting die de machine kleiner laat lijken dan hij is. MemTotal op 16.316.480 nemen en delen door een miljoen geeft 16,3 "GB"; delen door 1.048.576 geeft 15,56 GiB, en dat tweede cijfer is wat elk ander gereedschap op de machine rapporteert.

Op een harde schijf is het decimale cijfer van de fabrikant en het binaire cijfer van het besturingssysteem, en geen van beide is meer correct — het zijn twee manieren om dezelfde bytes te tellen. Geheugen is niet zo. Een geheugenarray wordt geselecteerd door adreslijnen, n ervan die 2ⁿ locaties decoderen, dus capaciteiten vallen op machten van twee omdat iets anders een deel van de adresruimte niets zou laten decoderen.

Dat maakt 8 GiB de echte grootte van een module van 8 GB: 8.589.934.592 bytes, met het decimale label als benadering in plaats van de werkelijkheid. Dat is de reden dat een geheugencijfer en een opslagcijfer van dezelfde nominale grootte niet dezelfde hoeveelheid bytes zijn.

De kloof is echt en te herleiden in plaats van mysterieus. Firmware reserveert gebieden onder 1 MiB en rond de ACPI-tabellen; geïntegreerde grafische chips nemen een vast deel dat op een laptop tot een gibibyte kan oplopen; het kernel-image, de paginatabellen en de geheugenkaart van de machine zelf gaan er vanaf voordat MemTotal berekend wordt.

Een laptop met 16 GiB die 15,56 GiB meldt, is dus ongeveer 450 MiB kwijt, ofwel 460.736 KiB, en het loont om het verschil om te rekenen in plaats van het totaal wanneer de vraag is "waar is het gebleven". Een server met foutcorrigerend geheugen verliest nog een achtste aan controlebits, al is dat aandeel onzichtbaar voor de kernel.

De verhouding is 1.048.576, dicht genoeg bij een miljoen dat zes cijfers laten vallen een schatting binnen vijf procent geeft. Een MemTotal van 32.633.240 KiB leest als "ongeveer 32,6", en het echte cijfer is 31,12 GiB — steeds ongeveer 4,6 procent te laag, dus de correctie is vast in plaats van elke keer opnieuw uit te rekenen.

Voor een cijfer dat echt moet kloppen, tel de komma’s in plaats daarvan. Kibibytes naar mebibytes is drie komma’s terug en een kleine correctie; mebibytes naar gibibytes hetzelfde nogmaals. Twee stappen van tien bits doen is makkelijker te controleren dan één stap van twintig bits.

Gewone geheugenpagina’s zijn 4 KiB op x86-64 en huge pages zijn 2 MiB, door de kernel gerapporteerd als Hugepagesize: 2048 kB. Een pool gedeclareerd als 2.048 huge pages is 4.194.304 KiB, precies 4 GiB — het rekenwerk blijft schoon omdat elke betrokken hoeveelheid een macht van twee is.

Het houdt op schoon te zijn zodra iemand de pool op een percentage instelt. "Ongeveer een derde" van een machine van 62 GiB reserveren geeft 10.600 pagina’s, ofwel 21.708.800 KiB, ofwel 20,7 GiB, en het onhandige gibibyte-cijfer is het teken dat het getal uit een percentage kwam in plaats van uit een workload.

/proc/swaps rapporteert zijn Size-kolom in blokken van 1.024 bytes, dus een swapbestand van 8.388.604 blokken is 8 GiB min vier blokken — de ontbrekende vier kibibytes zijn de header die het swapgebied vooraan schrijft. swapon --show drukt de leesbare vorm af en verbergt het detail.

De afstelknoppen blijven ook in kibibytes. vm.min_free_kbytes zet de reserve die de allocator niet aanspreekt, vaak rond 67.584 op een desktop, wat 66 MiB of 0,06 GiB is — klein genoeg dat het gibibyte-cijfer nutteloos is en het kibibyte-cijfer de juiste eenheid om in te denken.

Dezelfde computer rapporteert zijn geheugen in binaire eenheden decimaal gelabeld en zijn opslag in decimale eenheden binair herlabeld, en de twee gewoontes ontmoeten elkaar zonder waarschuwing. Een machine beschreven als 16 GB RAM en 512 GB SSD bevat 17,18 miljard bytes geheugen en 512 miljard bytes schijf.

De praktische regel is wie het label koos. Waar een fabrikant het getal koos — schijven, telefoonopslag, netwerksnelheden — is het decimaal en oogt het binaire cijfer tekort. Waar de hardware het koos — geheugenmodules, paginagroottes, cachelijnen, adresruimtes — is het binair en is het decimale cijfer de afronding.