Convertire GB in TiB

Un gigabyte è un miliardo di byte, nel senso decimale che usano i produttori di dischi, le tariffe dati e le dimensioni dei video.

Un tebibyte è 1.024 gibibyte. La distanza dal terabyte cresce a ogni gradino: 2,4 % sul kilo, 4,9 % sul mega, 7,4 % sul giga e 10 % sul tera.

Il fattore è 0,000909, e praticamente nessuno se lo porta dietro. Arrotondato a 0,00091 sbaglia di 0,06 % — invisibile sui numeri piccoli, e già un'unità intera intorno a 10.000 GB.

È questo il numero che serve sapere prima di arrotondare: non l'errore in sé, ma da dove smette di essere trascurabile. Sotto quella soglia il fattore corto è la scelta sensata; sopra, usa il campo qui in alto, che arrotonda solo al momento di scrivere.

Un TiB è 1.024 dell'unità sotto; un TB è 1.000. Su questa pagina è la differenza tra 1099,5116 GB e 1000 GB — il 10 % — e la distanza cresce a ogni gradino: per questo è un arrotondamento trascurabile su una foto e un pezzo visibile di un disco fisso.

Il mistero dello spazio che manca sta tutto qui. Un disco venduto come un terabyte contiene esattamente quello che dichiara in unità decimali, ed è Windows a ricontarlo in unità binarie tenendo però il nome decimale: il numero si accorcia senza che si sia perso niente. macOS conta questi valori in unità decimali fin dalla 10.6, ed è per questo che lo stesso disco può sembrare di due dimensioni diverse su due computer.

Lo storage viene specificato nell’unità di chi ha scritto il documento. Schede tecniche dei dischi, richieste di volumi e tabelle di quota sono quasi tutte in gigabyte decimali, perché è così che i componenti sono stati venduti. Il pool in cui finiscono quei volumi è riportato dal software, che conta in potenze di 1.024, quindi il totale torna in tebibyte.

I due non tornano nel modo ovvio: un piano per quaranta volumi da 250 GB sono 10.000 GB, cioè 9,09 TiB. Chi ha riservato un pool da 10 TiB ha un margine confortevole senza saperlo; chi ne ha riservati 9 è corto esattamente della quantità che la conversione nasconde.

La divergenza fra le scale decimale e binaria si accumula a ogni prefisso: 2,4% a kilo, 4,86 a mega, 7,37 a giga, 9,95 a tera. Passare da GB a TiB usa il rapporto del passaggio tera, quindi la correzione è la più grande incontrata nella pratica. Un decimo di un piano di capacità non è una differenza di arrotondamento; è un disco, uno scaffale o un mese di crescita.

È anche il punto in cui le due convenzioni smettono di sembrare intercambiabili. Un piano che tratta mille gigabyte come un tebibyte è sbagliato per più di quanto sia prudente.

Cinque cifre coprono la maggior parte del lavoro. 1.000 GB sono 0,909 TiB. 2.000 GB sono 1,819. 5.000 GB sono 4,547. 10.000 GB sono 9,095. 50.000 GB sono 45,47. Nell’altra direzione, un tebibyte assorbe 1.099,5 GB, quindi un pool riportato come 20 TiB accetterà circa 21.990 GB di volumi quotati in decimale.

La scorciatoia che regge anche ricordata male è moltiplicare i gigabyte per 0,0009095. Dividere per 1.024 è l’errore da evitare: quel rapporto porta da gibibyte a tebibyte, non da gigabyte, e usarlo qui sovrastima di circa il 7,4%.

Il fallimento raramente è una conversione sbagliata. È una colonna che contiene entrambi i tipi di numero. Un foglio di dimensionamento prende capacità di dischi da una fattura fornitore in TB, consumo attuale da un export di monitoraggio in TiB, stime per database in GB da un DBA, e una retention di backup da una policy che non specifica.

La correzione pratica è convertire all’ingresso piuttosto che alla fine, e nominare la colonna secondo la sua unità piuttosto che il suo contenuto.

Su un pool thick-provisioned un errore di unità si annuncia subito: le allocazioni non entrano e qualcosa si rifiuta di essere creato. Il thin provisioning rimuove quel controllo per design, lasciando che la somma dei volumi superi la capacità fisica sull’ipotesi che non tutto verrà usato insieme.

Ciò che arriva più tardi è un pool che supera la soglia critica prima di quanto previsto dal modello, di circa quanto valeva la conversione saltata.

La conversione di unità è aritmetica, non una perdita. Le sottrazioni che seguono sono reali. Parità o replica prendono la loro quota; le strutture di filesystem e le riserve prendono qualche punto percentuale in più; gli snapshot prendono qualunque cosa cambi tra uno e l’altro.

Tenere questi elementi separati dal passaggio GB-a-TiB è ciò che rende un modello di capacità verificabile. Quando il pool si riempie in anticipo, la prima domanda è quale delle sottrazioni era stata sottostimata.