Convertir des Gio en ko

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 kilooctet vaut 1 000 octets quand c’est un organisme de normalisation qui le définit, et 1 024 quand c’est un système d’exploitation. Cette page compte en 1 000 ; l’unité valant 1 024 s’appelle kibioctet.

Le facteur vaut 1073741,824, et à peu près personne ne le trimballe. Arrondi à 1070000, 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 1073741,824 kB et 1000000 kB — 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 1000000 kB là où la boîte annonçait 1073741,824 kB. 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.

/proc/meminfo sur chaque hôte Linux imprime ses valeurs avec le suffixe « kB », et chacune d’elles est un kibioctet. L’étiquette précède les noms CEI de nombreuses années, et la changer maintenant briserait chaque analyseur, agent et script qui a lu le fichier depuis. Donc la source la plus consultée de chiffres de mémoire sur la plateforme rapporte dans une unité et en nomme une autre, définitivement.

Cela compte parce que presque rien ne lit /proc/meminfo directement de nos jours. Les exportateurs, les agents et les moteurs de conteneur le lisent, le mettent à l’échelle, et le passent à un tableau de bord, et chaque couche décide pour elle-même si le nombre qu’elle a reçu était décimal ou binaire. Un chiffre de mémoire sur un graphique a d’habitude traversé une unité mal étiquetée avant que quiconque ne le regarde, et l’erreur, là où il y en a une, a été introduite en amont du panneau.

Les affichages de supervision se fixent sur les gibioctets pour la mémoire et le disque parce que c’est l’échelle à laquelle les nombres sont lisibles. Les choses auxquelles ces nombres sont comparés sont souvent bien plus petites et écrites par une personne  : un budget mémoire par requête de 200 ko, une taille d’objet moyenne de 40 ko, un coût d’entrée de cache, un chiffre venu du document de capacité d’une autre équipe. Les chiffres écrits par des humains sont décimaux presque sans exception.

Ainsi la comparaison traverse à la fois un écart de préfixe d’un million et un écart de système d’unité de 7,37 pour cent, et elle les traverse d’habitude dans la tête de quelqu’un pendant un incident. C’est le pire moment disponible pour la faire, ce qui plaide en faveur de convertir une fois, d’écrire le résultat avec son unité, et de le mettre dans le runbook plutôt que de le redériver sous pression.

La liste d’unités de Grafana contient des octets dans une saveur SI et des octets dans une saveur CEI, choisies par panneau. Choisir la première et 8 589 934 592 octets s’affichent en 8,59 Go  ; choisir la seconde et ils s’affichent en 8 Gio. Les deux sont la même mesure et les deux sont étiquetés honnêtement, mais l’étiquette est petite, la différence est de 7,37 pour cent, et personne qui compare deux tableaux de bord ne vérifie la configuration du panneau d’abord.

L’endroit où cela mord est un tableau de bord assemblé à partir de panneaux construits par des personnes différentes à des moments différents. L’un affiche la mémoire d’un hôte en Gio et le suivant affiche la limite d’un conteneur en Go, et les deux se tiennent côte à côte paraissant directement comparables. Si deux chiffres qui devraient correspondre sont régulièrement à environ sept pour cent d’écart, l’unité du panneau est la première chose à inspecter et cela prend un clic.

Les exportateurs Prometheus, et la plupart des agents modernes, rapportent des comptes d’octets bruts. node_memory_MemAvailable_bytes est un nombre d’octets sans échelle attachée, et le nom le dit. C’est la bonne conception  : la métrique porte la mesure et l’affichage porte la présentation, de sorte que l’ambiguïté ne peut être introduite que là où un humain a choisi un format.

Cela signifie aussi que la résolution de tout désaccord est disponible. Quand deux vues du même système diffèrent, interroger la métrique sous-jacente et comparer les comptes d’octets, qui ne peuvent pas être dans la mauvaise unité. Presque toute discussion sur le fait que l’usage mémoire est 7,4 pour cent plus haut que rapporté se termine là, en une trentaine de secondes, sans que personne n’ait à avoir raison à l’avance.

Une alerte écrite comme « mémoire au-dessus de 85 pour cent » divise un compte d’octets par un autre, et les unités s’annulent. Elle ne peut pas être cassée par une convention d’affichage, elle survit au redimensionnement de l’hôte, et elle n’a pas besoin de conversion du tout. C’est pourquoi la grande majorité des alertes utiles s’expriment en proportion, et pourquoi une page sur la conversion d’unités devrait le dire plutôt que de prétendre le contraire.

Les seuils absolus ont encore leur place  : une limite qui doit correspondre à la mémoire configurée d’un conteneur, un chiffre de disque où l’espace libre compte plutôt que la proportion, un quota convenu par contrat. Ceux-là devraient être écrits en octets dans la définition de l’alerte et formatés pour l’affichage seulement. Un seuil tapé en 8 Go contre une limite configurée en 8 Gio est sous-posé de 6,87 pour cent et se déclenchera tôt, à chaque fois, pour toute la durée de la règle.

free rapporte en kibioctets par défaut et propose -m, -g et -h pour les unités binaires plus grandes. ps et top affichent la taille d’ensemble résident en kibioctets. vmstat utilise des blocs de 1 024 octets. slabtop compte en kibioctets. À eux tous ils couvrent la plupart de ce qu’un ingénieur regarde en diagnostiquant un problème de mémoire, et aucun n’écrit un i.

La constance est au moins utile  : sur un hôte Linux, un petit chiffre de mémoire sans unité explicite est presque certainement des kibioctets plutôt que des kilooctets, et multiplier par 1 024 mène aux octets. Le piège n’est pas à l’intérieur de la plateforme mais à ses bords, là où un chiffre d’une console cloud, d’un document fournisseur ou d’une spécification arrive en véritables kilooctets décimaux et ressemble exactement aux autres.

Un nombre qui quitte la pile de supervision perd le contexte qui le rendait interprétable. Dans un ticket, un rapport ou un compte-rendu post-incident, « le processus utilisait 1,4 Go » sera lu par différentes personnes comme 1,4 Gio et comme 1,4 Go, et les deux diffèrent de 100 mégaoctets à cette échelle — assez pour importer dans une discussion sur le fait qu’une limite ait été dépassée.

Écrire le compte d’octets à côté est la protection la moins chère possible, et à cette échelle c’est une seule clause supplémentaire  : « 1,4 Gio, ce qui fait 1 503 239 ko ». Cela supprime la conversion, la convention et la discussion en une ligne, et c’est la même discipline qui fait que toute mesure dans un registre d’incident vaut la peine d’être relue un an plus tard.

La limite mémoire d’un conteneur et son usage courant vivent tous deux dans le système de fichiers cgroup en tant qu’entiers d’octets bruts — memory.max et memory.current sur cgroup v2. Rien là n’est mis à l’échelle, étiqueté ou arrondi. Chaque chiffre qu’un tableau de bord affiche pour un conteneur a été lu depuis l’un de ces fichiers et formaté par quelque chose plus haut dans la pile, ce qui est la couche où un choix d’unité a été fait.

Cela donne une manière décisive de régler tout désaccord sur la mémoire d’un conteneur. Lire les fichiers, comparer les entiers, et la question de savoir si une limite est de 4 Go ou de 4 Gio cesse d’être une question d’interprétation  : 4 294 967 296 est l’un et 4 000 000 000 est l’autre, et le fichier dit lequel. C’est le même principe que lire le compte d’octets exact dans une boîte de dialogue de propriétés de fichier, appliqué une couche plus bas et à un nombre qui décide si un processus est terminé.