TiB naar GiB omrekenen

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.

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 vermenigvuldiging, en wel met een heel getal: één tebibyte is 1.024 gibibytes, 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 TiB is 1.024 van de eenheid eronder; één TB is 1.000. Op deze pagina is dat het verschil tussen 1024 GiB en 931,3226 GiB — 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.

Vrijwel elke interface die opslag aanvraagt neemt een gibibyte-cijfer aan. Cloud-blokvolumes worden toegewezen in hele GiB. Een Kubernetes persistent volume claim schrijft storage: 100Gi. De pool erachter — een array, een SAN — wordt beschreven in tebibyte.

De omzetting is dus eigenlijk een deling in een aantal. Een pool van 10 TiB is 10.240 GiB, dat is 102 volumes van 100 GiB, of 20 van 512. Dat aantal vooraf uitwerken maakt de levensduur van de pool voorspelbaar.

Een thin-provisioned volume meldt zijn volle grootte aan de gast en verbruikt alleen de blokken die geschreven zijn. Dat is waarom honderd volumes van 100 GiB — 10.000 GiB aan beloftes — op een pool van 2 TiB kunnen staan terwijl ze 800 GiB verbruiken.

Het risico is dat de beloftes echt zijn en de pool niet. Naderen het totale gebruik de poolgrootte, dan beginnen schrijfacties te falen op volumes wiens eigen vrije-ruimte-cijfer zegt dat er genoeg is.

Een LVM thin pool houdt een metadatavolume bij dat elk toegewezen chunk aan zijn locatie koppelt, en die wordt bij het aanmaken van de pool bemeten. Ze groeit met het aantal chunks en snapshots, niet met de hoeveelheid data.

De storing is erger dan ruimte tekortkomen. Een thin pool wiens metadata vol raakt stopt met schrijven accepteren en moet meestal offline gerepareerd worden. lvs -o+metadata_percent meldt het cijfer en verdient een eigen alarm.

Drie aftrekkingen komen van de pool af voordat het gibibytecijfer verdeeld wordt. Snapshotruimte, die afhangt van het herschrijftempo. Een vulplafond, want de meeste pools degraderen ruim voor vol.

Op een pool van 10 TiB laat twintig procent reserveren voor het plafond en nog een tebibyte voor snapshots ongeveer 7.168 GiB over om toe te wijzen, dat is 71 volumes van 100 GiB in plaats van 102.

Cloud-blokopslag wordt in hele gibibyte toegewezen en per toegewezen gibibyte-maand gefactureerd ongeacht gebruik. Een aanvraag voor 100 GB tegen een API waarvan de eenheid GiB is krijgt 7,4 procent meer capaciteit.

Dezelfde afronding maakt kleine volumes onevenredig duur in totaal. Vijfhonderd volumes van 8 GiB is 4.000 GiB toegewezen, ofwel 3,9 TiB, en bij een kwart gebruik is drie tebibyte van de factuur lege ruimte.

Een volume uitbreiden en dan het bestandssysteem erop uitbreiden is een online bewerking op ext4, XFS en de meeste moderne stacks. Andersom is een ander soort probleem: het bestandssysteem moet alles wegverplaatsen van het einde van het apparaat.

Die asymmetrie hoort de eerste toewijzing te sturen. Volumes klein beginnen en op verzoek laten groeien kost een paar minuten werk per groei en houdt de vrije ruimte van de pool beschikbaar voor wie het het meest nodig heeft.

Groottes kiezen die machten van twee zijn, of op zijn minst nette breuken van een tebibyte, maakt de resterende capaciteit makkelijk te overzien. 10.240 GiB deelt exact in volumes van 128, 256, 512, 1.024 of 2.048 GiB.

Hetzelfde geldt voor de onderliggende toewijzingseenheid. LVM-extents, thin-pool-chunkgroottes en RAID-stripes hebben allemaal een korrelgrootte die een volumegrootte wel of niet matcht, en een grootte die een heel aantal gibibyte is, is een heel aantal van elke.