Convertir des To en Kio

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.

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é.

Dans ce sens, l'opération est une multiplication, et par un nombre entier : un téraoctet fait 976 562 500 kibioctets, exactement, et 976 562 500 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 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.

Rien ne stocke un fichier octet par octet. Le stockage est distribué en blocs, et sur presque tous les systèmes de fichiers modernes un bloc fait 4 Kio, parce que c’est la taille de page mémoire sur les architectures sur lesquelles il tourne et qu’un bloc qui correspond à une page n’a pas besoin d’être divisé. Donc la lecture utile d’un téraoctet n’est pas 1 000 000 000 000 d’octets mais 244 140 625 blocs, et toute question sur ce qui tient revient à ce compte.

La division est exacte, ce qui est inhabituel pour cette catégorie et vaut la peine d’être remarqué  : un billion est divisible par 1 024 parce qu’il contient une puissance de deux assez grande, donc un téraoctet est exactement 976 562 500 Kio et exactement 244 140 625 blocs, sans reste. La plupart des conversions entre les deux systèmes se terminent en une longue décimale  ; celle-ci se termine en un nombre entier avec lequel on peut faire de l’arithmétique.

Un fichier occupe des blocs entiers, donc le dernier bloc de chaque fichier est partiellement vide. En moyenne sur une collection réaliste, le gaspillage est d’environ un demi-bloc, soit environ 2 Kio par fichier. C’est invisible sur une bibliothèque de photos et énorme sur une boîte aux lettres  : un million de fichiers perdent environ 2 Go et cent millions perdent environ 200 Go, ce qui est un cinquième du téraoctet avant que quoi que ce soit ait mal tourné.

C’est le ratio qui rend la chose dangereuse plutôt que la figure absolue. Les fichiers bien au-dessus de la taille de bloc perdent une fraction de pour cent  ; les fichiers à 4 Kio ou en dessous perdent la moitié de leur espace ou plus, donc un répertoire de fichiers de 1 Kio stocke 1 To de contenu dans 4 To de blocs. Toute estimation de ce qu’occupera une collection doit connaître la distribution de tailles autant que le total.

Sur la famille ext, le nombre d’inodes est décidé quand le système de fichiers est créé et ne peut pas être changé ensuite. Le ratio par défaut alloue un inode par un nombre fixe d’octets, ce qui est généreux pour l’usage ordinaire et fortement à côté pour un volume qui tiendra des centaines de millions de petits fichiers. Quand ils s’épuisent, les écritures échouent avec une erreur « no space » alors que la figure d’espace libre a l’air saine, ce qui est l’une des défaillances les plus déroutantes qu’un système de fichiers produise.

C’est évitable au moment du format et coûteux après, parce que changer le compte d’inodes veut dire reconstruire le système de fichiers. Si un volume va tenir un très grand nombre de petits objets, le compte doit être choisi délibérément à partir d’une estimation du nombre de fichiers plutôt que laissé à la valeur par défaut — et l’estimation est la même arithmétique de bloc que ci-dessus, appliquée au nombre de fichiers prévu plutôt qu’à leur taille totale.

Sous le système de fichiers, le périphérique a sa propre unité. Les disques sont passés de secteurs de 512 octets à des secteurs physiques de 4 Kio, et beaucoup présentent des secteurs logiques de 512 octets sur des secteurs physiques de 4 Kio pour la compatibilité. Quand une partition commence à un décalage qui n’est pas un multiple du secteur physique, chaque bloc du système de fichiers chevauche deux d’entre eux, et chaque écriture devient un cycle lecture-modification-écriture des deux.

L’effet est une perte de performance plutôt qu’une perte de capacité, et elle peut être substantielle sur les écritures. Les outils de partitionnement modernes s’alignent à 1 Mio par défaut et le problème a largement disparu, mais il survit dans des tables de partition créées il y a longtemps et recopiées, et il vaut la peine d’être vérifié sur tout volume dont la performance est en dessous de ce que son matériel devrait permettre.

La planification de capacité pour un grand magasin d’objets est en réalité deux budgets qui doivent être satisfaits en même temps. Le budget en octets demande si le contenu tient  ; le budget en objets demande si les comptes de blocs et de métadonnées tiennent. Un téraoctet peut tenir un fichier ou, à la limite des blocs, 244 millions d’entre eux, et tout entre ces extrêmes a un coût de métadonnées, un temps de sauvegarde et un temps de récupération différents.

C’est le second budget qui est oublié, parce qu’il n’apparaît dans aucun chiffre unique sur un tableau de bord. Un volume à 40 % de sa capacité en octets peut être effectivement plein — à court d’inodes, ou passant tout son temps dans les métadonnées — et la figure d’espace libre que tout le monde regarde le déclarera confortable jusqu’au moment où une écriture échoue.

Cette paire est l’un des endroits où les deux systèmes sont vraiment forcés de partager une phrase. La capacité vient d’un constructeur et est décimale parce que c’est ainsi que les disques sont vendus  ; la taille de bloc vient d’un noyau et est binaire parce que c’est ainsi que la mémoire est paginée. Aucun des deux côtés ne bougera, donc tout calcul sur ce qui tient traverse entre eux exactement une fois et doit le faire délibérément.

L’habitude qui garde les choses droites est de convertir en octets à la frontière et d’y rester. Capacité en octets, taille de bloc en octets, tailles de fichier en octets, puis diviser — chaque chiffre intermédiaire est dans la même unité et aucune étape n’a à se rappeler dans quel système elle était. Convertir en une unité familière est une décision d’affichage prise après l’arithmétique, jamais pendant.

Les chiffres de cette page ne sont utiles qu’à l’avance, parce que la plupart des décisions qu’ils éclairent ne peuvent pas être revisitées sans reconstruire le volume. La taille de bloc, le compte d’inodes et l’alignement sont tous fixés à la création. Une estimation qui prend dix minutes — nombre de fichiers prévu, distribution de tailles prévue, demande de blocs et d’inodes qui en résulte — est la différence entre un volume qui marche pendant des années et un qu’il faut migrer quand il se remplit d’une manière inattendue.

Une version grossière suffit pour décider. Si le nombre de fichiers prévu est dans les millions bas et que les tailles moyennes sont bien au-dessus de 4 Kio, les valeurs par défaut vont bien et il n’y a rien à penser. Si le compte monte dans les centaines de millions, ou que le fichier moyen est plus petit qu’un bloc, les valeurs par défaut ne suffiront pas et l’arithmétique ci-dessus est ce qui dit de combien. Écrire l’estimation à côté de la commande de format vaut la minute supplémentaire, parce que la prochaine personne à regarder le volume voudra savoir si ses paramètres ont été choisis ou hérités.