Convertir des Kio en To

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 téraoctet vaut mille milliards d’octets. Un disque vendu pour 1 To en contient exactement autant : l’espace qui semble manquer est un désaccord sur les unités, pas un défaut.

Dans ce sens, l'opération est une division, et par un nombre entier : 976 562 500 de ces unités entrent dans un téraoctet sans reste. Le seul inconvénient, c'est que les résultats tombent en fractions — un tiers, un douzième — au lieu des chiffres ronds que donne le sens inverse.

Rien ne se perd pour autant : la division est exacte. Si votre résultat refuse de tenir en place en décimal — 0,0833… et compagnie —, c'est la fraction qui transparaît, pas une erreur qui s'installe.

Un KiB vaut 1 024 fois l'unité du dessous ; un kB, 1 000. Sur cette page, c'est l'écart entre 0 TB et 0 TB — 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 0 TB là où la boîte annonçait 0 TB. 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.

Les outils de quota et d'occupation disque affichent en blocs parce que c'est ce que compte le système de fichiers, et à l'échelle du stockage cela donne une chaîne de chiffres sans préfixe pour la rattacher à quelque chose. Un total de 3 200 000 000 blocs d'un kibioctet chacun représente 3 276 800 000 000 d'octets, soit 3,28 To. Lire le même chiffre comme si les blocs étaient des milliers d'octets donne 3,2 To et perd 77 Go en silence.

La conversion tient en deux étapes, dans l'ordre ou l'autre : multiplier par 1 024 pour les octets, diviser par un billion pour les téraoctets, ou multiplier le compte de blocs par 1,024 et décaler la virgule de neuf rangs. La seconde forme est plus facile à la main et rend la taille de la correction visible — la réponse dépasse toujours de 2,4 pour cent la lecture naïve, jamais en dessous.

Un téraoctet fait 976 562 500 kibioctets et un tébioctet en fait 1 073 741 824. L'un est un nombre à neuf chiffres qui commence par un neuf, l'autre un nombre à dix chiffres qui commence par un un, et un total de blocs qui tombe près de l'un ou de l'autre décrit à peu près un téraoctet de quelque chose — mais le choix entre les deux décide si la réponse sera 1,00 ou 1,10 dans l'unité d'un disque en rayon.

La façon de trancher est de regarder ce qui a produit le chiffre. Si le total vient d'une addition de ce qui est stocké, c'est une mesure et il tombe où il tombe. S'il vient d'une capacité — taille d'un volume, plafond de quota, total d'un périphérique — il a presque toujours été dérivé d'un chiffre décimal puis divisé par 1 024 au passage, et il se reconvertit en un rond suspect.

L'hypothèse dangereuse est qu'un bloc soit un kibioctet. C'est en général le cas quand l'outil a été appelé avec un drapeau k, mais un compte de blocs stocké sur disque est exprimé en unités de 512 octets par convention, et certains outils de rapport utilisent la taille de bloc configurée sur le système de fichiers, qui est le plus souvent de 4 096 octets. Se tromper est un facteur deux ou huit, et un facteur huit dans un plan de capacité n'est pas une erreur subtile.

La vérification peu coûteuse consiste à convertir une quantité connue. Prenez un fichier dont la taille en octets est connue, faites-le passer par l'outil, regardez le compte de blocs qui revient : le rapport donne la taille de bloc en une étape. Faire cela une fois par outil, et écrire la réponse à côté du script qui analyse la sortie, élimine toute la classe d'erreur pour de bon.

Un parcours de répertoire additionne ce qu'il voit. Les fichiers sous un point de montage qu'il n'a pas descendu manquent, les fichiers supprimés mais encore maintenus ouverts par un processus en cours manquent aussi, et l'espace que le système de fichiers s'est réservé pour lui-même n'est attribué à rien. Un rapport au niveau du volume inclut tout cela. Les deux chiffres répondent à des questions différentes et un écart de quelques pour cent entre eux est normal.

Les liens physiques ajoutent une deuxième source de divergence. Dans un seul parcours, un fichier lié compte une fois, ce qui est le bon comportement, mais additionner plusieurs totaux par répertoire le compte une fois par total. Les schémas de capture instantanée qui s'appuient sur des liens physiques pour partager les fichiers inchangés entre sauvegardes reposent précisément là-dessus, donc une somme naïve à travers les répertoires de capture peut rapporter plusieurs fois l'espace réellement occupé.

Convertir d'abord, puis ajouter les coûts séparément et dans l'ordre : le téraoctet décimal, le facteur de redondance pour l'architecture prévue, la surcharge du système de fichiers, la croissance attendue sur la durée du matériel, et la politique de marge. Un total de 4 000 000 000 de blocs fait 4,096 To ; une parité simple sur quatre disques impose de diviser par trois quarts, donc 5,46 To de capacité brute, puis viennent l'allocation de croissance et la politique de marge.

Garder les cinq chiffres séparés est ce qui rend le plan révisable un an plus tard. Un coefficient global a l'air propre et cache l'hypothèse qui s'est trompée quand la baie s'est remplie trop tôt. La conversion d'unités est la seule des cinq qui soit exacte, et elle ne devrait pas se retrouver mélangée aux quatre qui sont des estimations.

L'écart entre un kibioctet et un kilooctet est le plus petit de cette famille d'unités, et c'est celui qu'on néglige le plus — ce qui se défend sur un fichier et ne se défend pas sur un volume. À quatre téraoctets, ces 2,4 pour cent représentent 96 Go, soit davantage que la surcharge de système de fichiers qu'un plan prévoyait probablement, et c'est systématiquement dans le sens qui rend l'estimation trop petite.

Cela se cumule aussi avec l'erreur qu'on lui associe le plus souvent. Un lecteur qui traite un kibioctet comme mille octets puis compare le résultat à un disque dont la capacité a été supposée binaire a fait deux erreurs de tailles différentes dans le même sens, et le manque total approche les dix pour cent. Traiter les unités soigneusement une fois supprime les deux.

Un total de blocs mesure ce que le système de fichiers a alloué, ce qui sur un volume ordinaire est une bonne approximation de ce que la donnée demande. Sur un volume qui compresse de manière transparente, ou qui déduplique les blocs identiques entre fichiers, la relation se casse : la même donnée occupe ici moins de blocs qu'elle ne le fera sur le disque que vous allez acheter, et le total de blocs ne prédit plus le besoin.

Le sens de l'erreur dépend du système qui a été mesuré. Dimensionner une destination ordinaire à partir d'une source compressée sous-commande, parfois d'un facteur important sur de la donnée qui se comprime bien. Dimensionner une destination qui compresse à partir d'une source ordinaire sur-commande, ce qui est l'erreur la moins coûteuse. Dans les deux cas, le chiffre à convertir est celui mesuré sur un volume aux mêmes caractéristiques que celui qu'on planifie, et quand ce n'est pas possible le rapport doit être déclaré comme hypothèse plutôt que fondu dans le total.

Avant qu'un total de blocs ne devienne un bon de commande, recoupez-le avec le volume sur lequel la donnée se trouve aujourd'hui. Le chiffre d'occupation d'un rapport au niveau du volume, converti de la même façon, devrait se trouver dans le même voisinage que le total du parcours ; si ce n'est pas le cas, l'un des deux mesure quelque chose que vous ne vouliez pas mesurer, et cela vaut la peine de savoir lequel avant que le chiffre ne soit engagé.

L'autre vérification regarde la réalité physique. Reconvertissez la réponse en nombre de disques qu'elle implique aux capacités actuelles et voyez si c'est plausible. Un calcul qui conclut qu'un petit serveur de fichiers contient quarante téraoctets a en général compté deux fois un arbre de captures, et s'en apercevoir à l'étape arithmétique est nettement moins coûteux que s'en apercevoir après l'arrivée des disques.