Convertire GiB in TiB

Un gibibyte è 1.073.741.824 byte, circa il 7 % in più di un gigabyte. Windows misura in gibibyte ma li etichetta «GB», e in questo consiste tutto il mistero dello spazio che sparisce.

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.

In questa direzione il conto è una divisione, e per un numero intero: 1024 di queste stanno in un tebibyte senza avanzo. L'unica scomodità è che i risultati escono in frazioni — un terzo, un dodicesimo — invece delle cifre tonde che dà la direzione opposta.

Non si perde comunque nulla, perché la divisione è esatta. Se il risultato non sta fermo in decimali — 0,0833… e parenti —, quella è la frazione che traspare, non un errore che si insinua.

Un GiB è 1.024 dell'unità sotto; un GB è 1.000. Su questa pagina è la differenza tra 0,001 TiB e 0,0009 TiB — il 7,4 % — 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.

I dischi si vendono in terabyte decimali e i pool si contano in unità binarie, quindi la prima cosa che succede a un acquisto è una riduzione del dieci per cento che non è affatto una perdita. Un disco da 4 TB contiene esattamente 4.000.000.000.000 byte, cioè 3.725,29 GiB o 3,638 TiB.

La seconda conversione è quella che toglie capacità reale, e arriva dopo: parità o mirroring, la riserva mantenuta dal filesystem, e il tetto di riempimento che chiunque di buon senso rispetta.

È la fonte più comune di una cifra in gibibyte che non torna. zpool list riporta la dimensione grezza dei vdev, parità inclusa. zfs list riporta ciò che il livello dataset può effettivamente archiviare, parità esclusa. Su un pool raidz2 a otto dischi il primo mostrerà circa un terzo in più del secondo, ed entrambi sono corretti.

Prendete le cifre di capacità dal livello che corrisponde alla domanda: pianificare quanti dati entreranno è una domanda per zfs list; verificare se un disco sostitutivo è abbastanza grande è una domanda per zpool list.

Un mirror dà metà. RAID 5 e raidz1 danno n − 1 dischi di dati. RAID 6 e raidz2 danno n − 2. Otto dischi da 3.725,29 GiB in raidz2 danno sei dischi di dati, 22.351 GiB, cioè 21,83 TiB.

Il padding toglie un’ulteriore fetta che l’aritmetica di base non vede. ZFS alloca in unità derivate dalla dimensione del settore, quindi record che non si dividono in modo uniforme tra i dischi dati lasciano vuoti, con l’effetto peggiore su record piccoli e vdev larghi.

Un filesystem copy-on-write non può liberare un file sovrascrivendo un bit sul posto; deve scrivere nuovi metadati, che richiedono spazio libero. ZFS evita che un pool arrivi a spazio zero trattenendo una quota — un trentaduesimo del pool per default — che le scritture ordinarie non possono toccare.

Su un pool da 32 TiB sono circa 1 TiB messi da parte, e non è visibile come spazio libero nella cifra che vedono gli utenti.

Le prestazioni di allocazione su un pool copy-on-write degradano quando lo spazio libero si frammenta, e degradano bruscamente. La linea guida comune è pianificare sull’ottanta per cento per un pool generico e più basso per uno con carico di scrittura casuale pesante.

Questo trasforma 32 TiB utilizzabili in circa 25,6 TiB di capacità di pianificazione, e trattare la differenza come margine da consumare in un trimestre intenso è come un pool finisce lento e difficile da recuperare.

Uno snapshot non costa nulla quando viene preso e cresce man mano che i dati live divergono da esso. Un dataset da 4 TiB con un mese di snapshot giornalieri e un pattern di riscrittura pesante può consumare svariate volte quella cifra, e nulla di questa crescita è visibile nella dimensione dei dati correnti.

La conseguenza pratica è che la cifra utilizzabile va ridotta di un margine per la retention degli snapshot, e il margine dipende dal tasso di riscrittura più che dalla dimensione dei dati.