kB naar TiB omrekenen

Een kilobyte is 1.000 bytes als een normalisatie-instituut hem definieert en 1.024 als een besturingssysteem dat doet. Deze pagina rekent met 1.000; de eenheid van 1.024 heet kibibyte.

Een tebibyte is 1.024 gibibyte. De afstand tot de terabyte groeit bij elke trede: 2,4 % bij kilo, 4,9 % bij mega, 7,4 % bij giga en 10 % bij tera.

Deze kant op is het een deling, en wel door een heel getal: er gaan er 1.099.511.628 in één tebibyte, 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 TiB is 1.024 van de eenheid eronder; één TB is 1.000. Op deze pagina is dat het verschil tussen 1099511627,776 kB en 1000000000 kB — 10 % — 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 prognose heeft vier invoerwaarden en die zijn altijd hetzelfde: de grootte van één record, hoeveel er per tijdseenheid binnenkomen, hoelang ze bewaard worden, en waarmee de opslaglaag dat vermenigvuldigt. De eerste is in kilobytes want dat is de schaal van een logregel of een metriekmonster. De laatste is in tebibytes want dat is wat een pool rapporteert. Alles ertussen is vermenigvuldiging, en het enige lastige is niet halverwege van eenheidsstelsel wisselen.

Een uitgewerkt geval: een miljard records per dag van 1 kB elk is 1.000.000.000.000 bytes per dag, wat een terabyte is, wat de pool zal rapporteren als 0,909 TiB. Negentig dagen daarvan is 90 TB, wat de pool zal rapporteren als 81,85 TiB. Die twee cijfers beschrijven identieke data, dus is een plan dat 90 in het ene systeem berekent en 90 in het andere reserveert 8,15 eenheden opslag tekort — precies de hele last die dit paar veroorzaakt.

Voor je je zorgen maakt over 9 procent, pak eerst de factoren die honderden procenten waard zijn. Compressie is de eerste: gestructureerde logs en metrieken krimpen vaak tot een vijfde of een tiende van hun ruwe omvang, dus overschat een prognose die het negeert met een orde van grootte. Replicatie is de tweede en gaat andersom: drie kopieën is drie keer de opslag, en erasure coding is doorgaans 1,2 tot 1,5 keer.

Dan zijn er de indexen, makkelijk te vergeten omdat ze niet de data zijn. Een logopslag die velden indexeert voegt een structuur toe die een substantieel deel van de payload kan zijn, en een tijdreeksdatabase houdt zijn eigen bij. De eerlijke manier om al deze te bepalen is een representatieve steekproef een dag door het echte systeem te sturen en te meten wat het innam — één meting wint van elke hoeveelheid schatting.

Bewaring wordt meestal gewoontegetal ingesteld op het eerste getal dat iemand voorstelde, en het is de invoerwaarde met de grootste hefboom op kosten. De termijn halveren halveert exact de stabiele-toestandsgrootte; het verlies aan waarde is zelden proportioneel, want de overweldigende meerderheid van queries op operationele data reikt uren tot dagen terug in plaats van maanden. De opslagcijfers voor elke kandidaat naast elkaar zien verandert het gesprek.

Waar een langere termijn echt vereist is — een auditverplichting, een kwartaalvergelijking — is dat meestal voor een deelverzameling in plaats van voor alles. De stream splitsen zodat het kleine, waardevolle deel een jaar bewaard wordt en de bulk een veertien dagen, geeft het meeste van het voordeel voor een fractie van de omvang, en is een beslissing die genomen moet worden voor de data geschreven wordt in plaats van erna.

Een opslag met een vaste bewaartermijn groeit niet eeuwig: hij groeit tot de oudste data begint te vervallen, en houdt dan ongeveer constant op het dagelijkse tarief keer de termijn. Dat plateau is het getal om op te dimensioneren, en het komt na één bewaartermijn vanaf de start van het systeem. Dimensioneren op de groeicurve in plaats van het plateau koopt capaciteit die nooit gebruikt zal worden; dimensioneren onder het plateau betekent dat het vervalbeleid je capaciteitsbeheer overneemt.

Het plateau verschuift zodra het dagelijkse tarief verschuift, wat de moeite waard is om te monitoren. Nieuwe instrumentatie, meer verkeer of een debugniveau dat aan staat in productie verhogen het tarief, en het opslageffect verschijnt geleidelijk over een volle bewaartermijn in plaats van meteen. Een dashboard van bytes per dag ingenomen voorspelt het probleem; een van bytes opgeslagen rapporteert het twee weken te laat.

Hij verstopt zich op de grens tussen de berekening en de aankoop. De prognose gebeurt van nature in decimale eenheden, want tarieven en recordgroottes zijn decimaal en het rekenwerk is eenvoudig. De pool wordt gerapporteerd in binaire eenheden, want dat doen filesystemen. Zegt het plan 90 TB en de pool 82 TiB, dan is dat dezelfde hoeveelheid en oogt het als een tekort; zegt het plan 90 TiB en wordt 90 TB gereserveerd, dan is het een echt tekort van 9 procent en oogt het als een match.

Het tweede geval is het gevaarlijke omdat niets het signaleert. Opslag wordt in decimale terabytes gekocht, en een verzoek om "90 terabyte" ingevuld door een leverancier die decimale capaciteit verkoopt tegen een vereiste berekend in tebibytes komt bijna 9 TB tekort. De vereiste in bytes op de bestelbon zetten haalt de ambiguïteit weg voor de prijs van één extra getal.

Een prognose is een keten van vermenigvuldigingen, en afronden bij elke stap stapelt op in een onvoorspelbare richting. Tarief keer grootte keer termijn keer replicatie keer indexoverhead, elk afgerond op twee cijfers, kan tien procent van het exacte antwoord landen terwijl elke afzonderlijke stap redelijk oogt. Vermenigvuldig de exacte getallen en rond eenmalig af, aan het eind, waar de afronding zichtbaar en bewust is.

Dat is ook het punt om te beslissen hoeveel precisie het antwoord verdient. Een opslagprognose is hooguit twee significante cijfers waard, want de invoer bestaat uit schattingen en de compressieverhouding alleen al draagt meer onzekerheid dan al het andere samen. Wat het niet waard is, is valse precisie gegenereerd door een spreadsheet, want een cijfer op vijf cijfers nodigt een lezer uit het als gemeten te behandelen in plaats van als geprojecteerd.

Er is ongeveer 1,1 miljard kilobyte nodig voor een tebibyte, dus is een nuttig handvat dat één kilobyte per seconde, aangehouden, ongeveer 31,5 GB per jaar is — zo’n 29,4 GiB — en duizend kilobyte per seconde ongeveer 31,5 TB per jaar, oftewel 28,7 TiB. De meeste prognoses op deze schaal kunnen in een paar seconden tegen die twee getallen gecontroleerd worden, en een antwoord dat niet dicht bij een veelvoud ervan zit, heeft ergens een fout in de keten. Hetzelfde handvat werkt naar beneden: honderd bytes per seconde is ongeveer 3,15 GB per jaar, wat waar telemetrie per apparaat meestal zit voor het over de vloot vermenigvuldigd wordt.

De andere controle is de richting van de correctie. Van decimaal naar binair omzetten maakt het getal altijd kleiner, op deze reikwijdte met 9 procent, dus heeft een TiB-cijfer dat groter uitkwam dan het TB-cijfer ergens vermenigvuldigd waar het had moeten delen. Dat is de meest voorkomende rekenfout in deze categorie en de makkelijkste om te betrappen, want het exacte antwoord is niet nodig om hem te zien.