Convertir des ko en Go

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.

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.

Passer des kilooctets aux gigaoctets déplace la virgule de 6 rangs vers la gauche, et rien d'autre ne change. Aucun facteur à retenir, aucun arrondi à trancher : les chiffres restent dans le même ordre, seule leur position bouge.

1 234 kB font 0,001234 GB — les mêmes chiffres, décalés. C'est la seule conversion que vous pouvez vérifier d'un coup d'œil : si les chiffres du résultat ne sont pas ceux du départ, ce n'est pas cette conversion qui les a changés.

Le décimal fait de ce rapport une puissance de dix nette : un kilooctet fait 10³ octets, un gigaoctet fait 10⁹, et il y a exactement un million de kilooctets dans un gigaoctet. C’est ce que les préfixes SI veulent dire, et c’est la convention employée par les fabricants de stockage, par chaque norme réseau, et par les services qui vous annoncent une capacité. La conversion est six rangs de virgule sans aucun facteur à retenir.

L’erreur que cette paire produit est un facteur mille, et non un facteur 1,05. Quelqu’un qui a en tête la relation du mégaoctet — mille au gigaoctet — tend la main vers le même mille ici et arrive trois ordres de grandeur à côté. Une garde utile consiste à dire la réponse à voix haute avec son échelle attachée : 500 000 kB font un demi-gigaoctet, et si un total en centaines de milliers de kilooctets sort en centaines de gigaoctets, une étape a été sautée.

La forme du calcul est toujours la même : une taille moyenne d’élément en kilooctets, multipliée par un compte, divisée par un million. Cinquante millions de lignes de log par jour à 2 ko chacune font 100 000 000 ko, ce qui est 100 Go par jour et 36,5 To par an. Deux cent mille vignettes à 40 ko font 8 000 000 ko, ou 8 Go. Dix millions de lignes de base de données à 1,5 ko font 15 Go avant tout index.

Le maillon faible de cette chaîne n’est presque jamais la division. C’est la moyenne, parce que les tailles de fichiers et d’enregistrements sont à longue traîne : une poignée de très gros éléments tire la moyenne bien au-dessus de la médiane, et une moyenne mesurée sur cent échantillons peut être fausse d’un facteur deux. Mesurez la moyenne sur un échantillon réel des vraies données, indiquez le compte d’où elle vient, et citez le résultat à un ou deux chiffres significatifs plutôt qu’au gigaoctet le plus proche.

Un système de fichiers ne distribue pas des octets ; il distribue des blocs, et la valeur par défaut commune sur ext4 comme sur NTFS est 4 096 octets. Un fichier de 1 ko occupe un bloc entier, un fichier de 5 ko en occupe deux, et un fichier de 4,1 ko en occupe deux aussi. Donc un million de fichiers faisant en moyenne 1 ko contiennent un gigaoctet de données et occupent environ 4 Gio de disque — quatre fois l’estimation, produit entièrement par un arrondi qui n’a rien à voir avec les unités.

L’effet s’estompe quand les éléments grandissent et disparaît au-dessus de quelques dizaines de kilooctets, où la queue gaspillée du dernier bloc est une petite fraction du fichier. Il ne s’applique jamais aux enregistrements à l’intérieur d’un seul gros fichier : un million de lignes de 2 ko dans un seul fichier de base de données ou un seul fichier de log sont tassés bout à bout, et l’arrondi par bloc se produit une fois pour tout le fichier plutôt qu’un million de fois. Savoir si les petits éléments sont des fichiers ou des lignes est donc la première question à poser sur toute estimation à cette échelle.

Quasiment tout ce qui arrive en pièces de la taille du kilooctet est du texte, et le texte se comprime fortement. Les lignes de log, les documents JSON, les exports CSV et les dumps SQL tombent typiquement à entre un cinquième et un dixième de leur taille avec un algorithme généraliste, parce qu’ils répètent des noms de champs, des horodatages et de la structure à chaque ligne. Une estimation non compressée de 100 Go par jour devient fréquemment une facture de stockage de 10 à 20 Go par jour une fois les données au repos.

L’exception est le contenu déjà compressé. Les vignettes JPEG, les extraits MP3 et les segments vidéo ne portent pas de redondance utile à enlever, et les passer dans un archiveur gagne un pour cent ou deux au mieux. Une estimation devrait donc être construite en deux parties : le texte à sa taille compressée, le média à sa taille stockée, et les deux totalisés plutôt qu’un ratio unique appliqué à tout.

Cette page divise par 1 000 000. L’équivalent binaire divise par 1 048 576, parce qu’un gibioctet fait 1 024² kibioctets plutôt que 1 000² kilooctets, et les deux diviseurs sont à 4,9 % d’écart. C’est plus que les 2,4 % entre un kilooctet et un kibioctet, et moins que les 7,4 % entre un gigaoctet et un gibioctet — l’écart grandit à chaque pas de 1 024, et cette paire en fait deux.

Sur une estimation portant une incertitude d’un facteur deux sur la taille moyenne, 4,9 % n’est pas ce qui doit préoccuper. Cela compte quand les chiffres sont exacts plutôt qu’estimés : réconcilier une facturation avec un rapport de système de fichiers, ou vérifier qu’une migration a bien tout déplacé. Là, la règle est de convertir une fois, à partir d’un compte d’octets exact, et d’indiquer quel diviseur a été utilisé.

Les outils Unix auxquels la plupart des gens touchent à cette échelle sont les moins susceptibles de vouloir dire des kilooctets décimaux. du et df rapportent en blocs de 1 024 octets par défaut et les étiquettent K ou ko, une convention qui précède le kibioctet de plusieurs décennies. Un répertoire rapporté à 4 096 K fait 4 194 304 octets, et un système de fichiers rapporté à 976 562 500 K fait exactement un téraoctet.

Les deux acceptent un drapeau qui bascule en puissances de dix, et la différence mérite d’être connue avant qu’un chiffre ne quitte votre terminal pour un tableur. Sur un téraoctet, les deux lectures diffèrent de 24 Go, ce qui suffit à rendre un plan de capacité confortable alors qu’il ne l’est pas. Notez la convention d’un chiffre au moment où vous le copiez, parce que rien dans le chiffre lui-même ne vous le dira après.

Une estimation assemblée à partir d’une moyenne, d’un compte et d’une hypothèse de compression mérite d’être citée comme une fourchette plutôt que comme un chiffre. « Entre 8 et 20 Go par jour, à partir d’un échantillon de dix mille lignes faisant en moyenne 2,1 ko, compressé à environ 6 :1 » est une phrase que quelqu’un d’autre peut vérifier et discuter. « 13,4 Go par jour » ne l’est pas, et elle sera traitée comme une mesure.

Cela vaut aussi la peine d’écrire ce que l’estimation exclut, parce que les omissions à cette échelle sont en général plus grandes que l’arithmétique. Les index d’une base de données ajoutent fréquemment encore une moitié à la taille des lignes ; un pipeline de log garde les mêmes données dans un tampon, un magasin chaud et une archive à la fois ; et la rétention est un multiplicateur, de sorte qu’un chiffre quotidien ne dit rien tant que le nombre de jours de conservation ne lui est pas attaché.