Convertir des Kio en o

Un kibioctet vaut exactement 1 024 octets. Le nom a été introduit en 1998 pour que « kilooctet » puisse de nouveau valoir 1 000 — l’habitude n’a jamais tout à fait cédé.

Un octet vaut huit bits — c’est d’ailleurs ce que le mot dit, là où l’anglais *byte* ne dit rien de la taille. Elle n’a pas toujours été fixée : les premiers ordinateurs employaient six, sept ou neuf bits. Huit s’est imposé parce qu’un caractère y tient et que le nombre se coupe proprement en deux.

Dans ce sens, l'opération est une multiplication, et par un nombre entier : un kibioctet fait 1 024 octets, 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 KiB vaut 1 024 fois l'unité du dessous ; un kB, 1 000. Sur cette page, c'est l'écart entre 1024 B et 1000 B — 2,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 2,4 %. Un disque vendu en kB contient exactement ce qui est annoncé ; Windows divise ensuite par 1 024 au lieu de 1 000, garde le nom décimal, et affiche 1000 B là où la boîte annonçait 1024 B. 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.

L’arithmétique est le moindre des soucis : multipliez par 1 024 et le compte d’octets est exact. Ce qui rend la conversion digne d’une page, c’est que le chiffre source arrive sous une demi-douzaine d’étiquettes différentes. Les interfaces du noyau impriment ko et entendent des kibioctets. Les outils invoqués avec un drapeau k rapportent en kibioctets et n’en disent rien. La documentation écrite après 1998 dit Kio et le pense. Les trois désignent la même unité de 1 024 octets, et l’identification est ce qui précède la multiplication.

Il reste donc au lecteur une étape d’identification avant la multiplication. Le test fiable est l’outil plutôt que l’étiquette : tout ce qui rapporte l’utilisation de mémoire ou de blocs sur un système de type Unix compte en unités de 1 024 sauf si on lui a explicitement demandé des unités SI. Tout ce qui cite une taille de fichier à un humain — une page de téléchargement, une limite de téléversement, un chiffre de transfert réseau — est plus susceptible de signifier mille, et c’est l’asymétrie qui mérite d’être connue avant de convertir.

Le nombre de blocs stockés d’un fichier est exprimé en unités de 512 octets, et il l’a été depuis la définition de l’interface, indépendamment de ce que le système de fichiers en dessous alloue réellement. Un fichier occupant un bloc de 4 096 octets rapporte donc huit blocs. Le même fichier sous du -k rapporte 4, parce que cet outil compte en kibioctets. Aucun des deux chiffres n’est faux et aucun ne peut être comparé à l’autre sans savoir quel bloc chacun signifie.

La règle pratique est de tout convertir en octets avant de comparer quoi que ce soit. Huit blocs de 512 octets et quatre kibioctets font tous les deux 4 096 octets, et l’accord est invisible tant que les deux ne sont pas exprimés ainsi. Les scripts qui comparent un nombre de blocs stockés à un total en kibioctets sans normaliser sont à un facteur deux près, et l’erreur est assez stable pour ressembler à une vraie divergence plutôt qu’à un bogue, ce qui la rend difficile à trouver.

Deux questions différentes se cachent derrière le mot taille. La longueur d’un fichier est le nombre d’octets qu’il contient ; l’espace qu’il occupe est le nombre de blocs alloués multiplié par la taille du bloc. Pour un fichier de configuration de 100 octets, cela fait 100 octets et 4 096 octets, une différence de quarante fois, et chacun est la bonne réponse à une question différente, et la confusion entre les deux est l’erreur qui revient le plus souvent dans les estimations de stockage.

L’écart va dans les deux sens. Un fichier creux — un avec des régions non écrites qui n’ont jamais été allouées — rapporte une longueur bien plus grande que les blocs qu’il détient, et c’est pourquoi une image de disque virtuel peut s’afficher comme 40 Gio et en occuper 3. Convertir un total de blocs en kibioctets en octets dit ce que le stockage porte ; convertir une longueur dit ce que produira une copie du fichier. Les estimations de sauvegarde qui utilisent la mauvaise des deux sont fausses de l’ampleur de la fragmentation, et l’erreur peut être énorme.

Les limites de ressources du shell mélangent leurs unités, et le mélange n’est pas évident à partir de la sortie. La limite de taille de pile et la limite de mémoire virtuelle sont en kibioctets, donc une limite de pile lisant 8192 fait 8 388 608 octets. La limite de taille de fichier est en blocs de 512 octets par défaut. Lire un ensemble de limites comme s’ils partageaient une unité produit un plafond de mémoire qui est à un facteur deux près dans un sens ou dans l’autre, et c’est l’erreur la plus rapide à faire.

La raison de les convertir du tout est d’habitude que quelque chose d’autre est exprimé en octets. Un processus qui échoue avec une erreur de mémoire rapporte l’allocation qu’il a tentée en octets ; la comparer à une limite rapportée en kibioctets prend une multiplication et transforme une supposition en réponse. Là où la limite s’avère être nulle part près de l’allocation qui échoue, la cause est ailleurs, et le savoir rapidement vaut l’arithmétique, et c’est l’usage diagnostique réel de cette conversion.

En dessous d’une certaine granularité, le compte d’octets cesse d’être le chiffre utile. La mémoire est distribuée en pages, et sur la plupart des systèmes une page fait 4 096 octets. Les systèmes de fichiers allouent par blocs, et la valeur par défaut courante est le même chiffre. Les disques au nouveau format de secteur présentent des secteurs de 4 096 octets. Les couches s’empilent proprement parce qu’elles ont toutes choisi la même puissance de deux, et une taille qui en est un multiple traverse toutes sans gaspillage.

Cet alignement est pourquoi les tailles de tampon, les entrées de cache et les longueurs d’enregistrement se regroupent sur des multiples de 4 096. Une lecture de 4 000 octets touche la même page qu’une lecture de 4 096 et coûte la même chose ; un enregistrement de 4 100 octets s’étend sur deux blocs et coûte deux fois les écritures qu’il semble avoir besoin. Convertir un chiffre en kibioctets en octets est souvent la première étape pour vérifier si une taille se trouve sur cette frontière ou un peu au-delà, et c’est le test qui évite les pertes de performance inexpliquées.

À cette échelle, la différence entre un kilooctet et un kibioctet est de 24 octets, et pour la plupart des usages elle disparaît dans l’arrondi. Un poids de page cité comme 500 ko n’est pas significativement différent de 500 Kio, et discuter de la distinction sur un seul fichier est du temps mal employé, parce que la distinction n’a aucun effet pratique à ce niveau.

Elle devient matérielle quand elle est multipliée. Un million d’enregistrements de 4 Kio chacun fait 4 096 000 000 d’octets, et non 4 000 000 000, et un plan de capacité bâti sur le second chiffre est à 96 Mo de court avant que quoi que ce soit d’inattendu n’arrive. La même chose s’applique à la comptabilisation par requête, aux calculs de quota et à tout le reste où une petite unité est comptée un grand nombre de fois : l’écart ne grandit pas, mais le nombre par lequel il est multiplié grandit.

Tout les k ne valent pas 1 024, et supposer le contraire est sa propre erreur. Le débit réseau, les allowances de transfert, les capacités de stockage et tout ce qui est imprimé sur un emballage sont décimaux, donc un kilooctet dans ces contextes fait 1 000 octets et multiplier par 1 024 surestime le résultat de 2,4 pour cent. Le même lecteur qui a appris à se méfier d’un k dans une sortie de shell doit se rappeler de lui faire confiance sur une facture, et c’est l’asymétrie qui cause la moitié des erreurs de cette catégorie.

La règle qui couvre les deux sans trop d’effort : si le nombre décrit ce qu’une machine fait en interne, il est binaire ; s’il décrit ce qui est vendu, transféré ou annoncé, il est décimal. Cette heuristique n’est pas parfaite, mais les exceptions s’annoncent d’elles-mêmes — un outil qui entend 1 000 a d’habitude un drapeau qui le dit, et un qui entend 1 024 a d’habitude une documentation qui l’admet, et le test empirique sur un fichier de taille connue reste le plus rapide de tous.

Les comptes d’octets restent exacts dans tout type entier suffisamment large pour les contenir, et un chiffre en kibioctets multiplié par 1 024 reste exact aussi. Les ennuis commencent quand une valeur a déjà été arrondie pour l’affichage : un outil qui imprime 1,4 Kio a jeté le compte d’octets, et multiplier le chiffre arrondi en retour donne quelque chose entre 1 382 et 1 485. Récupérer l’original n’est pas possible, donc prenez le compte d’octets à la source plutôt qu’au résumé partout où les deux existent, et l’auditabilité qui en résulte vaut le détour.

La plupart des outils produiront des octets bruts sur demande, et c’est cette sortie qu’il faut donner à tout ce qui est automatisé. Le formatage lisible par un humain est un choix d’affichage fait au dernier moment, et le traiter comme des données est la façon dont un pipeline de supervision finit avec des tailles qui dérivent de quelques pour cent pour aucune raison que personne ne trouve plus tard, et la dérive se voit quand le chiffre en octets du même fichier ne concorde plus avec la taille résumée.