Convertir des Go en Mio

Un gigaoctet vaut un milliard d’octets, au sens décimal qu’emploient les fabricants de disques, les forfaits mobiles et les tailles de vidéo.

Un mébioctet vaut 1 024 kibioctets, soit 1 048 576 octets. Les outils Linux et les chiffres de mémoire désignent presque toujours cela, même quand ils écrivent « Mo ».

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

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 MiB vaut 1 024 fois l'unité du dessous ; un MB, 1 000. Sur cette page, c'est l'écart entre 0,001 GB et 0,001 GB — 4,9 % — 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 4,9 %. Un disque vendu en MB 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 GB là où la boîte annonçait 0,001 GB. 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.

Un gigaoctet est un milliard d’octets. Un mebioctet en vaut 1 048 576. Diviser l’un par l’autre donne 953,67431640625, exactement et sans arrondi — un nombre que personne ne devinerait et que tout le monde doit aller chercher. Le réflexe est d’aller chercher 1 000, qui est le Mo dans un Go, ou 1 024, qui est le Mio dans un Gio, et les deux sont faux ici parce que la paire traverse entre les deux systèmes.

La taille de l’erreur dépend de quel mauvais nombre on prend. Utiliser 1 000 surestime de 4,9 pour cent  ; utiliser 1 024 surestime de 7,4. Sur un tableau de bord c’est une ligne un peu fausse. Sur un seuil c’est une alerte qui se déclenche à un pourcentage qu’on n’a pas choisi, et sur un plan de capacité c’est la différence entre provisionner assez et être à 7 pour cent de moins au moment où la prévision disait qu’on serait à l’aise.

Les seuils sont d’habitude pensés comme des fractions de quelque chose  : alerter à 80 pour cent du disque, réveiller à 90 pour cent de la limite de mémoire. Cette intention survit seulement si la fraction est prise de l’allocation dans l’unité propre de l’allocation et convertie une fois, à la fin. Quatre-vingts pour cent d’un gigaoctet font 762,9 Mio et quatre-vingt-dix font 858,3 Mio, et ni l’un ni l’autre n’est un nombre que quiconque tape par choix.

Ce que les gens tapent à la place est 800 et 900, qui sont ronds et ne sont pas les fractions qu’on voulait dire — 800 Mio font 84 pour cent d’un gigaoctet et 900 Mio en font 94. L’alerte fonctionne toujours, elle se déclenche plus tard que le runbook ne le dit, et la divergence est invisible parce que la règle et la documentation contiennent toutes deux des nombres ronds plausibles.

Prometheus ne prend pas position là-dessus  : la convention chez ses exportateurs est d’enregistrer des octets bruts avec un suffixe _bytes et de laisser la couche de présentation choisir l’unité. C’est la bonne conception et cela déplace la décision vers le tableau de bord, où elle est prise par champ, souvent par celui qui a construit le panneau, et rarement écrite là où la personne qui regarde le graphique la verra.

L’effet pratique est que deux panneaux sur le même tableau de bord peuvent montrer la même série à 7 pour cent d’écart et être tous deux correctement configurés. Une requête renvoie des octets  ; un panneau les formate au sens SI et l’autre au sens CEI  ; les axes indiquent GB et GiB, ou pire, tous deux indiquent GB. Quand un nombre sur un tableau de bord doit être comparé à un nombre venu d’ailleurs, vérifier le réglage d’unité du champ d’abord plutôt que l’étiquette de l’axe.

Les ressources de conteneur sont l’endroit où cette conversion est faite le plus souvent et vérifiée le moins. Kubernetes accepte les deux systèmes et les distingue proprement  : Mi et Gi sont les quantités binaires, M et G sont les décimales. Une limite de 1G est 1 000 000 000 d’octets  ; une limite de 1Gi est 1 073 741 824. Les deux sont valides, les deux s’appliquent sans avertissement, et elles diffèrent de 7,4 pour cent.

Le piège est une chaîne où les unités changent à chaque maillon. La capacité s’achète en Go décimaux, un nœud est décrit en Gio, une limite est écrite en Mi, et un tableau de bord affiche celui pour lequel il a été configuré. Chaque conversion dans cette chaîne est faisable  ; la défaillance est d’en faire trois de tête. Tout convertir en octets une fois, à l’endroit où les nombres sont comparés, et laisser les unités conviviales n’être que de l’affichage.

Il y a une heuristique utilisable et elle devrait être traitée comme une heuristique. Les nombres qui décrivent quelque chose d’acheté — un forfait, un quota, une facture, une allowance de transfert — sont presque toujours décimaux, parce que c’est l’unité dans laquelle la capacité se vend. Les nombres qui viennent de l’intérieur d’une machine en marche — mémoire utilisée, cache de pages, espace libre sur le système de fichiers sous Linux — sont presque toujours binaires, parce que c’est ce que le noyau compte.

Là où l’heuristique s’épuise, il y a un test qui ne s’épuise pas. Trouver une quantité qu’on peut mesurer en octets indépendamment, la faire passer par la console, et voir quelle division reproduit le chiffre affiché. Cela prend une observation et règle la question pour cette console définitivement, ce qui est un meilleur emploi de cinq minutes que n’importe quelle quantité de documentation qui pourrait ne rien dire.

Elle ne ressemble à rien, et c’est la difficulté. Une ligne 5 pour cent au-dessus de là où elle devrait être a la même forme, la même tendance et le même taux de variation que la correcte  ; rien chez elle n’invite au soupçon. L’erreur ne devient visible que là où le graphique est comparé à un chiffre externe — une facture, un quota, un second outil — et alors elle se présente comme un mystère plutôt que comme un problème d’unité.

Le seul indice visuel qui vaut la peine d’être connu est une ligne de marge qui ne s’aligne jamais tout à fait. Si une série d’usage est tracée contre une ligne de capacité prise ailleurs, et que l’usage se stabilise à 93 ou 107 pour cent de la capacité plutôt qu’à 100, ce rapport est l’écart d’unité plutôt qu’un artefact de mesure. 1,074 et 0,931 sont les deux nombres à reconnaître  ; 1,049 et 0,954 en sont les équivalents à un cran.

La correction durable n’est pas d’obtenir cette conversion exacte une fois, c’est de la rendre inutile la fois suivante. Nommer les variables et les métriques d’après ce qu’elles contiennent — un seuil en octets est un seuil en octets, quoi qu’il soit affiché — et mettre la dérivation à côté de tout littéral qui a été converti à la main, pour qu’un relecteur puisse vérifier 953,674 sans aller le chercher.

Là où un système doit parler à un autre, se mettre d’accord sur les octets à la frontière et ne convertir qu’aux bords. C’est la même discipline que pour les fuseaux horaires et les devises, et pour la même raison  : l’ambiguïté n’est pas dans l’arithmétique, qui est triviale, mais dans le nombre d’endroits où quelqu’un doit se rappeler quelle convention était en vigueur. Ramener cela à un seul endroit est toute la correction. Cela donne aussi à la personne suivante quelque chose à confronter  : une frontière documentée unique peut être vérifiée en une minute, alors qu’une convention appliquée de mémoire à six endroits différents ne peut pas être vérifiée du tout.