GB naar KiB omrekenen

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

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.

De factor is 976562,5, en die draagt vrijwel niemand met zich mee. Afgerond op 980000 zit hij er 0,35 % 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 KiB is 1.024 van de eenheid eronder; één kB is 1.000. Op deze pagina is dat het verschil tussen 0 GB en 0 GB — 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.

Een gigabyte is 1.000.000.000 bytes en een kibibyte is 1.024, dus is de verhouding exact 976.562,5. Het halve is geen afrondingsartefact en verdwijnt niet met meer precisie: een decimale gigabyte is geen heel aantal kibibytes, want 10 tot de negende heeft geen factor 1.024 erin. Elk oneven gigabyte-cijfer omgezet naar blokken landt op een half.

Dat doet ertoe waar het ontvangende gereedschap een geheel getal wil, wat de meeste zijn. Naar boven afronden geeft de gebruiker iets meer dan beloofd was, naar beneden iets minder, en truncatie — wat een naïeve gehele deling doet — doet stilzwijgend het tweede. Voor een quotum is het een verschil van 512 bytes en niemand merkt het; voor een assertie in een test is het het verschil tussen slagen en falen.

GNU df zonder argumenten drukt blokken van 1 KiB af. du -k doet hetzelfde. quota, repquota en setquota rekenen in eenheden van 1 KiB. vmstat rapporteert geheugen in blokken van 1.024 bytes. Deze interfaces werden ontworpen toen een schijf in megabytes gemeten werd en een blokaantal comfortabel in een kolom paste, en ze zijn niet veranderd omdat elk script dat ze parseert dan zou breken.

Het resultaat is dat een modern volume beschreven wordt met een negencijferig getal. Een filesystem van 2 TB is 1.953.125.000 blokken. Dat is onleesbaar per ontwerp en precies per ongeluk, en het is de reden dat deze omzetting veel vaker door scripts dan door mensen gedaan wordt — wat weer is waarom de constante eenmalig goed zetten, in een variabele met een naam, meer waard is dan hem te onthouden.

Een quotum wordt bijna altijd afgesproken in decimale gigabytes, want dat is de eenheid waarin de afspraak geschreven is: vijftig gigabyte per gebruiker, vijfhonderd per project. setquota wil blokken. De vermenigvuldiging is 976.562,5 per gigabyte, dus is vijftig gigabyte 48.828.125 blokken en vijfhonderd 488.281.250 — beide heel, want het halve verdubbelt bij elk even cijfer tot een geheel getal.

De zachte en harde limieten hebben daarna dezelfde behandeling nodig en krijgen die vaak verschillend. Een zachte limiet afgeleid van een rond gigabyte-cijfer en een harde limiet gezet door "tien procent" bij het blokaantal op te tellen zijn twee omzettingen met twee afrondingsbeslissingen, en het gat tussen hen stopt de tien procent te zijn die iemand bedoelde. Zet eenmaal om, bereken dan beide limieten uit het blokcijfer.

Quotumboekhouding werkt vrijwel universeel in eenheden van 1 KiB. Het filesystem eronder wijst standaard blokken van 4 KiB toe op ext4 en de meeste moderne volumes. Dat zijn twee verschillende hoeveelheden en een gebruiker verbruikt de tweede terwijl hij op de eerste wordt afgerekend, dus wordt quotumgebruik gerapporteerd als vier keer het blokaantal voor elk bestand dat één toewijzingseenheid inneemt.

Voor een thuismap met gewone documenten is het effect een paar procent. Voor een map met veel kleine bestanden is het de dominante term: duizend bestanden van 1 kB zijn een megabyte inhoud en ongeveer vier megabyte quotum. Beweert iemand onder zijn limiet te zitten terwijl het gereedschap het oneens is, controleer dit dan eerst, en het heeft niets met de decimaal-versus-binair-vraag te maken.

GNU coreutils leest de omgevingsvariabele BLOCK_SIZE, en DF_BLOCK_SIZE en DU_BLOCK_SIZE overschrijven die per gereedschap. POSIXLY_CORRECT instellen verandert het standaardblok van 1.024 bytes naar 512, waardoor elk cijfer dat de gereedschappen afdrukken halveert. Dit is allemaal gedocumenteerd, niets ervan is zichtbaar in de uitvoer, en het reist allemaal mee met een shellprofiel in plaats van met een commando.

Het praktische gevolg is dat een blokaantal geplakt in een ticket niet zelfbeschrijvend is. Twee beheerders die dezelfde df op dezelfde host draaien kunnen cijfers produceren die een factor twee verschillen, en de discussie erna gaat over het filesystem in plaats van over de omgeving. Een expliciete --block-size meegeven wanneer een getal ergens anders heen gaat dan je eigen scherm haalt die hele klasse problemen weg.

De blokcijfers de moeite waard om te herkennen zijn de ronde. 1 GB is 976.563 blokken afgerond, 10 GB is 9.765.625, 100 GB is 97.656.250, 1 TB is 976.562.500. De leidende cijfers zijn op elke schaal hetzelfde — 9765625 — wat maakt dat alleen de omvang het lezen waard is, en dat is een cijferaantal in plaats van een waarde.

Het maakt een gangbare fout ook makkelijk te herkennen. Een cijfer beginnend met 1048 of 1073 is een binair-naar-binaire omzetting gedaan met het verkeerde eenhedenpaar: 1.048.576 blokken is een gibibyte, geen gigabyte. Begint een blokaantal met een 9, dan zijn de systemen zoals bedoeld overgestoken; begint het met een 1, dan heeft iemand door het verkeerde ding gedeeld.

Een capaciteit in decimale gigabytes komt vrijwel altijd van buiten de machine: een schijfetiket, een dienstniveau, een contract, een bestelbon. Het is het cijfer dat iemand verkocht kreeg. Het blokaantal is het cijfer dat de machine afdwingt, en daartussen zitten de filesystem-overhead en de gereserveerde blokken waar geen van beide partijen het over had.

Zo zal een quotum van precies 976.562.500 blokken op een "1 TB"-volume niet haalbaar zijn, want het volume presenteert geen volle terabyte bruikbare ruimte zodra zijn eigen structuren zijn toegewezen. Per-gebruikersquota instellen die optellen tot de nominale capaciteit is de standaardmanier om een filesystem onbedoeld te oversubscriberen, en het is alleen een eenheidsomzettingsprobleem in de zin dat de eenheden het correct deden lijken.