Convertir des Gio en To

Un gibioctet vaut 1 073 741 824 octets, environ 7 % de plus qu’un gigaoctet. Windows mesure en gibioctets tout en les étiquetant « Go », et c’est là tout le mystère de l’espace disque qui s’évapore.

Un téraoctet vaut mille milliards d’octets. Un disque vendu pour 1 To en contient exactement autant : l’espace qui semble manquer est un désaccord sur les unités, pas un défaut.

Le facteur vaut 0,001074, et à peu près personne ne le trimballe. Arrondi à 0,00107, il s'écarte de 0,35 % — invisible sur de petits nombres, et devenu une unité entière vers 1 000 GiB.

C'est ce chiffre-là qu'il faut connaître avant d'arrondir : pas l'erreur elle-même, mais l'endroit où elle cesse d'être négligeable. En dessous, le facteur court est le bon choix ; au-dessus, servez-vous du champ ci-dessus, qui n'arrondit qu'au moment d'afficher.

Un GiB vaut 1 024 fois l'unité du dessous ; un GB, 1 000. Sur cette page, c'est l'écart entre 0,0011 TB et 0,001 TB — 7,4 % — et il grandit à chaque palier : négligeable sur une photo, visible sur un disque dur.

Le mystère de l'espace disque manquant tient tout entier là-dedans, et sur cette page il vaut 7,4 %. Un disque vendu en GB contient exactement ce qui est annoncé ; Windows divise ensuite par 1 024 au lieu de 1 000, garde le nom décimal, et affiche 0,001 TB là où la boîte annonçait 0,0011 TB. macOS compte ces tailles en unités décimales depuis 10.6, d'où le même disque qui paraît de deux tailles sur deux machines — rien n'a disparu et personne n'arrondit : les mêmes octets portent deux noms.

Le nombre qui commence cette conversion est presque toujours sorti d’une machine. Un gestionnaire de volumes qui rapporte la taille d’un pool existant, un hyperviseur qui résume ses datastore, un tableau de bord qui trace la consommation — tous calculent en puissances de 1 024 et impriment des GiB, ou un Go qui veut dire la même chose. Le nombre qui termine va sur un bon de commande, et chaque fournisseur chiffre en téraoctets décimaux.

Cela fait de la conversion un passage de frontière plutôt qu’un exercice arithmétique, et c’est dans les passages de frontière que les unités se perdent. Un besoin voyage de l’ingénieur au formulaire d’achat comme un chiffre nu, est lu comme décimal parce que le formulaire est décimal, et la commande est passée pour sept pour cent de capacité en moins que ce qui était demandé. Rien dans la chaîne n’est faux, sauf que l’unité a cessé de voyager avec le nombre.

La plupart des conversions d’unités sont symétriques dans leurs conséquences : être un peu au-dessus ou un peu en deçà coûte à peu près la même chose. Celle-ci ne l’est pas. Un achat de capacité qui arrive en deçà du besoin ne se corrige ni par un réglage, ni par un tuning, ni par un ticket d’assistance. Il se corrige en rachetant du matériel, ce qui veut dire un nouvel agrément, un nouveau délai, et une nouvelle fenêtre de maintenance.

La règle est donc d’arrondir vers le haut à la capacité disponible suivante, puis d’appliquer par-dessus les marges prévues par le dimensionnement. 4 000 GiB font 4,295 To et appellent un disque plus gros qu’un 4 To. 8 000 GiB font 8,59 To. 20 000 GiB font 21,47 To. Dans chaque cas, l’arithmétique tombe un cran après une taille de catalogue, ce qui n’est pas un hasard — les tailles de catalogue sont des nombres décimaux ronds et les besoins sont des nombres binaires ronds.

Une petite table couvre l’essentiel des achats. 500 GiB font 0,537 To. 1 000 GiB font 1,074 To. 1 024 GiB — un tébioctet — font 1,0995 To. 2 000 GiB font 2,147. 5 000 GiB font 5,369. 10 000 GiB font 10,737. Le multiplicateur de GiB à To est 0,001074, ou, plus facile à retenir, ajoutez 7,4 % et décalez la virgule de trois rangs.

La ligne 1 024 est celle qui mérite d’être mémorisée, parce que c’est là que l’intuition se casse. Un tébioctet n’est pas un téraoctet, c’est 1,0995 téraoctet, de sorte qu’un besoin exprimé en « un téraoctet » par un ingénieur qui regarde un affichage binaire appelle un achat de 1,1 To, et il n’existe pas. Ce décalage unique est derrière un grand nombre de volumes provisionnés exactement à la taille qui se révèle un peu trop étroite.

L’ordre des opérations décide si le nombre à la fin signifie quelque chose. Commencez par la capacité utile dans l’unité où le besoin a été mesuré — le GiB —, parce que c’est le chiffre dont quelqu’un a réellement besoin. Convertissez-le en To. Appliquez ensuite la disposition redondante, qui est un multiplicateur sur l’achat et non sur le besoin : un miroir le double, une parité simple sur huit membres ajoute un huitième, la double parité un quart.

Faire l’inverse produit des nombres qui ne se vérifient pas. Appliquer la conversion d’unités après l’arithmétique de parité mélange une correction de 7,37 % dans une correction de 25 % et rend les deux invisibles, de sorte que, quand l’ensemble livré est plus petit que prévu, personne ne peut dire quelle étape était fausse. Deux lignes séparées avec deux justifications séparées survivent à une revue ; un seul chiffre mélangé n’y survit pas.

Les consoles de nuage sont la version la plus nette du problème, parce que les deux unités apparaissent à quelques clics d’écart. Il est banal qu’un volume bloc soit créé avec une taille en gibioctets, que le graphe d’usage soit tracé en gibioctets, et que la page de tarification affiche un tarif par gigaoctet-mois. Chaque écran est cohérent en interne, et l’ensemble ne l’est pas.

La conséquence pratique est sur la facture plutôt que sur la capacité : un volume créé à 1 000 GiB correspond à 1 074 Go de stockage facturable, et la facture dépasse donc de 7,4 % une estimation naïve faite à partir du chiffre de provisionnement. C’est un petit pourcentage d’un grand nombre récurrent, et c’est exactement la forme d’un écart de coût qui se remarque un trimestre trop tard.

Il est tentant de traiter les 7,4 % comme du mou — d’acheter au chiffre converti et d’appeler la différence une marge. Ce n’est pas une marge, c’est la même quantité écrite correctement, et la dépenser laisse le dimensionnement sans réserve. La croissance, les instantanés, les réserves du système de fichiers et la falaise de performance que la plupart des stockages atteignent avant d’être pleins sont des allocations distinctes, et chacune a besoin de son propre chiffre.

L’habitude utile consiste à rédiger le plan comme une chaîne qui se relit : besoin utile en GiB, ce même chiffre en To, le multiplicateur de disposition, la marge de croissance pour le cycle d’achat, la taille de catalogue retenue. Cinq lignes, chacune défendable seule, et la conversion posée à l’air libre où quiconque peut la contrôler plutôt que pliée dans une marge que personne ne peut.

La seule protection fiable est de garder l’unité avec le chiffre partout où il va, et d’inclure le nombre d’octets quand le chiffre franchit une limite d’organisation. Un besoin écrit en « 10 737 418 240 000 octets, soit 10 000 GiB ou 10,74 To » ne peut pas être mal lu par un service achats, par un fournisseur, ni par quiconque héritera du système dans deux ans.

Cela ressemble à de l’excès sur une seule ligne et cesse d’en avoir l’air la première fois qu’un devis revient sur la mauvaise base. Le stockage est le domaine de ce site où un désaccord d’unité a un prix, et où la personne qui découvre l’erreur n’est en général pas celle qui l’a commise.

Un ensemble redondant n’utilise de chaque membre que ce que son plus petit fournit, de sorte qu’un ensemble monté à partir de disques nominalement identiques peut perdre quelques gigaoctets à cause d’écarts entre fabricants. C’est un risque réel depuis aussi longtemps que les disques se vendent en nombres décimaux ronds, et c’est pourquoi les contrôleurs d’entreprise arrondissent souvent tous les membres à un commun avant de construire l’ensemble.

Cela compte pour cette conversion, parce que le chiffre d’achat ne peut pas être un total nu. Un besoin de 40 000 GiB, converti à 42,95 To et satisfait par onze disques de 4 To, n’est pas la même commande qu’un besoin satisfait par six disques de 8 To, et les deux ont des temps de reconstruction, des expositions à la panne et des totaux utiles après parité différents. Convertissez d’abord, puis choisissez la taille des membres, puis vérifiez que l’arithmétique couvre toujours le besoin une fois la disposition appliquée.