Convertir des Tio en Gio

Un tébioctet vaut 1 024 gibioctets. L’écart avec le téraoctet grandit à chaque échelon : 2,4 % au kilo, 4,9 % au méga, 7,4 % au giga, 10 % au téra.

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.

Dans ce sens, l'opération est une multiplication, et par un nombre entier : un tébioctet fait 1 024 gibioctets, exactement, et 1 024 est la définition, pas une mesure tombée juste.

C'est donc une des rares conversions qui valent le coup de tête, et le résultat se vérifie : divisez en sens inverse et vous devez retomber exactement sur le nombre de départ, sans reste à justifier.

Un TiB vaut 1 024 fois l'unité du dessous ; un TB, 1 000. Sur cette page, c'est l'écart entre 1024 GiB et 931,3226 GiB — 10 % — 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 10 %. Un disque vendu en TB contient exactement ce qui est annoncé ; Windows divise ensuite par 1 024 au lieu de 1 000, garde le nom décimal, et affiche 931,3226 GiB là où la boîte annonçait 1024 GiB. 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.

Quasiment toute interface qui demande du stockage prend un chiffre en gibioctets. Les volumes de blocs en nuage sont provisionnés en Gio entiers. Une revendication de volume persistant Kubernetes s’écrit storage: 100Gi. Les disques de machines virtuelles, les volumes logiques LVM et les cibles iSCSI se spécifient à cette échelle. Le volume derrière — un ensemble, un SAN, un volume ZFS — se décrit en tébioctets, parce que c’est l’unité dans laquelle un achat se fait.

La conversion est donc vraiment une division en un nombre. Un volume de 10 Tio fait 10 240 Gio, ce qui représente 102 volumes de 100 Gio, ou 20 de 512, ou 5 de 2 048. Calculer ce compte avant la création du premier volume est ce qui rend la vie du volume prévisible, et c’est l’étape qui est sautée quand les volumes sont provisionnés un par un en réponse à des demandes.

Un volume en provisionnement léger déclare sa taille complète à l’invité et ne consomme que les blocs qui ont été écrits. C’est pourquoi cent volumes de 100 Gio — 10 000 Gio de promesses — peuvent siéger sur un volume de 2 Tio tout en consommant 800 Gio, et c’est une véritable efficacité plutôt qu’un tour de passe-passe : la plupart des volumes sont surtout vides, et réserver de l’espace pour des données qui n’existeront jamais est du gaspillage.

L’exposition est que les promesses sont réelles et que le volume ne l’est pas. Quand l’usage agrégé approche de la taille du volume, les écritures commencent à échouer sur des volumes dont leur propre chiffre d’espace libre dit qu’il en reste, et les systèmes de fichiers invités n’ont aucun moyen de l’interpréter — un échec d’écriture sur ce que le noyau croit être un périphérique sain tend à produire une corruption de système de fichiers plutôt qu’une erreur nette. Les volumes légers requièrent donc une surveillance sur l’usage du volume plutôt que sur celui d’un volume particulier, et un seuil d’alerte avec une marge suffisante pour acheter des disques.

Un volume léger LVM conserve un volume de métadonnées qui cartographie chaque bloc alloué à son emplacement, et il est dimensionné à la création du volume. Il croît avec le nombre de blocs et avec le nombre d’instantanés qui les partagent, et non avec la quantité de données, donc un volume contenant quelques centaines de gibioctets modestes à travers cent instantanés peut épuiser ses métadonnées alors que la zone de données est presque vide.

La défaillance est pire qu’un manque d’espace. Un volume léger dont les métadonnées se remplissent cesse d’accepter les écritures et doit généralement être réparé hors ligne avec thin_check et thin_repair avant de revenir. lvs -o+metadata_percent rapporte le chiffre, et il mérite sa propre alerte à un seuil plus bas que la zone de données, parce que, contrairement à l’épuisement des données, il ne se règle pas en supprimant des fichiers.

Trois déductions sortent du volume avant que le chiffre en gibioctets ne soit divisé. L’espace d’instantanés, qui dépend du taux de réécriture plutôt que de la taille des données. Un plafond de remplissage, parce que la plupart des volumes se dégradent bien avant d’être pleins. Et assez d’espace libre pour mener à bien une reconstruction, une migration ou une restauration — l’opération qu’il est le plus probable de devoir faire au moment même où le volume est le plus plein.

Sur un volume de 10 Tio, réserver vingt pour cent pour le plafond et un tébioctet de plus pour les instantanés et la manœuvre laisse environ 7 168 Gio à allouer, ce qui représente 71 volumes de 100 Gio au lieu de 102. Cet écart est assez grand pour devoir être décidé à l’avance, parce que récupérer de l’espace sur des volumes déjà attribués signifie les rétrécir, et rétrécir est l’opération qui ne marche pas.

Le stockage en blocs en nuage est provisionné en gibioctets entiers et facturé au Gio-mois provisionné indépendamment de l’usage. Une demande de 100 Gio est facturée 100 qu’un seul ou quatre-vingt-dix-neuf gibioctets soient écrits, et une demande formulée en 100 Go contre une API dont l’unité est le Gio obtient 7,4 % de capacité en plus et 7,4 % de coût en plus que ce que le chiffre décimal suggérait. Quand un devis et une facture diffèrent d’environ un quinzième, c’est en général pour cette raison.

Le même arrondissement rend les petits volumes disproportionnellement chers en cumulé. Cinq cents volumes de 8 Gio font 4 000 Gio provisionnés, ou 3,9 Tio, et si l’utilisation moyenne est d’un quart, trois tébioctets de la facture sont de l’espace vide. Consolider sur moins de volumes plus grands avec un système de fichiers partagé est la réponse habituelle, et l’arithmétique qui la justifie est exactement cette conversion appliquée aux chiffres provisionnés plutôt qu’aux chiffres utilisés.

Étendre un volume puis étendre le système de fichiers qui s’y trouve est une opération en ligne sur ext4, XFS et la plupart des piles modernes, et elle prend quelques secondes. Aller dans l’autre sens est un problème d’une autre catégorie : le système de fichiers doit relocaliser tout ce qui se trouve à la fin du périphérique avant que le périphérique puisse être tronqué, XFS ne sait pas le faire du tout, et ext4 exige que le système de fichiers soit démonté. En pratique, la taille d’un volume est une décision à sens unique.

Cette asymétrie devrait conditionner l’allocation initiale. Commencer les volumes petits et les agrandir à la demande coûte quelques minutes de travail par agrandissement et préserve l’espace libre du volume pour celui qui en a le plus besoin ; les démarrer à la taille que quelqu’un a deviné qu’ils pourraient finir par atteindre verrouille le volume dans des allocations qui ne seront jamais récupérées. Sur un volume léger, l’argument est plus faible, parce que les blocs non utilisés ne sont pas consommés — mais les métadonnées et l’effet psychologique d’un volume déclarant 2 Tio libres s’appliquent toujours.

Choisir des tailles qui sont des puissances de deux, ou au moins des fractions nettes d’un tébioctet, rend la capacité restante facile à raisonner. 10 240 Gio se divise exactement en volumes de 128, 256, 512, 1 024 ou 2 048 Gio et ne laisse rien d’inconfortable à la fin. Une taille standard de 750 Gio laisse 490 Gio en suspens après treize volumes — pas assez pour un quatorzième et trop pour être ignoré.

La même logique s’applique à l’unité d’allocation sous-jacente. Les étendues LVM, les tailles de bloc d’un volume léger et les bandes RAID ont tous des granularités auxquelles une taille de volume correspond ou non, et une taille qui est un nombre entier de gibioctets est un nombre entier de chacune d’elles. C’est la forme la moins coûteuse de propreté : l’arithmétique est exacte dans les deux cas, et la version qui divise nettement est celle que quelqu’un pourra encore auditer dans deux ans.