Convertir des To en Mio

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 mébioctet vaut 1 024 kibioctets, soit 1 048 576 octets. Les outils Linux et les chiffres de mémoire désignent presque toujours cela, même quand ils écrivent « Mo ».

Le facteur vaut 953674,316406, et à peu près personne ne le trimballe. Arrondi à 950000, il s'écarte de 0,39 % — invisible sur de petits nombres, et devenu une unité entière vers 1 000 TB.

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 MiB vaut 1 024 fois l'unité du dessous ; un MB, 1 000. Sur cette page, c'est l'écart entre 0 TB et 0 TB — 4,9 % — 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 4,9 %. Un disque vendu en MB 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 tailles de morceau sont choisies par le logiciel et sont donc des puissances de deux  : extents de 4 Mio dans un gestionnaire de volume, blocs de 128 Mio dans un système de fichiers distribué, tailles de partie en multiples de 8 ou 16 Mio pour les gros envois. Les capacités sont fixées par le matériel et le commerce et sont donc décimales. Chaque fois que l’une est divisée par l’autre, la réponse a une fraction dedans, et la fraction doit aller quelque part.

La conversion est une seule division  : téraoctets fois 1 000 000 000 000, divisés par 1 048 576, donne 953 674,31640625 Mio par téraoctet. À partir de là, diviser par la taille de morceau donne le compte. L’exactitude compte moins que la direction — la figure en mébioctets est toujours environ 4,9 % en dessous de ce qu’une division naïve par un million suggérerait, et un compte de morceaux dérivé de la manière naïve est en conséquence trop haut.

Les gros envois d’objets sont découpés en parties, et les services qui les supportent plafonnent le nombre de parties — couramment à 10 000. Ce plafond transforme la taille de morceau en contrainte plutôt qu’en préférence  : un objet d’un téraoctet a besoin de parties d’au moins 100 000 000 d’octets, soit 95,37 Mio, sinon l’envoi ne peut pas aboutir. Un objet de cinq téraoctets a besoin de parties d’au moins 476,84 Mio par la même arithmétique.

La réponse habituelle est d’arrondir la taille de partie à la puissance de deux supérieure et d’accepter la marge supplémentaire. Une taille de partie de 128 Mio gère un téraoctet en 7 451 parties et couvre confortablement tout jusqu’à environ 1,34 To avant que le plafond ne soit atteint à nouveau. Choisir 100 Mo à la place fonctionnerait numériquement et ne s’alignerait avec rien en dessous, ce qui explique pourquoi la figure binaire est celle qui est retenue.

Un téraoctet est 7 450,58 blocs de 128 Mio  : 7 450 blocs entiers et un reste de 74,32 Mio. Les systèmes qui allouent des blocs entiers en réserveront 7 451, laissant le dernier un peu plus de deux cinquièmes vide — un coût d’arrondi d’environ 54 Mio contre un téraoctet, ce qui fait 0,005 % et ne mérite pas une réflexion sur un seul grand fichier.

La même arithmétique à l’autre bout de la distribution de tailles de fichier est là où cela mord. Une taille de bloc de 128 Mio stockant un million de fichiers de 2 Mio chacun alloue un bloc entier par fichier, consommant 122 Tio de capacité pour 1,9 Tio de contenu. La taille de bloc se choisit pour la charge de travail plutôt que pour la capacité, et convertir la capacité est l’étape qui montre ce qu’un choix donné coûtera réellement.

Les gestionnaires de volume allouent par extents, typiquement de 4 Mio, donc un téraoctet de volume logique est 238 418,58 extents et sera arrondi à un nombre entier de ceux-ci. Les dispositions en stripes ajoutent un second alignement  : une largeur de stripe qui est un multiple de la taille d’extent garde chaque stripe sur une limite, et une qui ne l’est pas produit des lectures qui chevauchent deux périphériques là où un seul aurait suffi.

Rien de cela n’est visible dans un chiffre de capacité et tout cela découle d’en convertir un. Travailler la taille décimale en mébioctets puis dans l’unité d’allocation est ce qui montre si la géométrie choisie se divise proprement ou laisse une unité partielle à chaque niveau. Quand elle ne se divise pas proprement, la correction habituelle est de dimensionner le volume en unités binaires et de laisser la figure décimale être ce qu’elle se trouve être.

Parce que 1 000 000 000 000 et 1 048 576 ne partagent que des facteurs de deux — la figure décimale en porte douze et la binaire en porte vingt — un téraoctet n’est jamais un nombre entier de mébioctets et ne le sera jamais. Toute capacité qui se divise pair en morceaux binaires a été spécifiée en unités binaires en premier lieu, ce qui est une chose utile à remarquer sur un chiffre que quelqu’un vous a remis.

C’est pourquoi le logiciel de stockage tend à présenter les tailles en unités binaires même quand le matériel en dessous a été vendu en décimal  : il choisit la représentation dans laquelle sa propre arithmétique est exacte. La conversion dans ce sens-ci existe surtout pour le moment où une figure décimale de l’extérieur du système doit être réconciliée avec la figure binaire à l’intérieur.

Un téraoctet est un peu moins d’un million de mébioctets, ce qui rend la version mentale facile  : diviser un million par la taille de morceau en Mio et retirer cinq pour cent. Pour 128 Mio, c’est environ 7 800 moins cinq pour cent, soit environ 7 400, contre 7 450,58 exactement. Pour 64 Mio, c’est environ 14 900, et pour 16 Mio environ 59 600.

L’estimation est assez bonne pour la question à laquelle les comptes de morceau servent d’habitude, qui est de savoir si une limite de parties sera atteinte. Si la figure brute tombe à vingt pour cent près d’un plafond de 10 000 parties, faites l’arithmétique proprement  ; si elle est à un facteur deux de marge dans un sens ou dans l’autre, l’estimation a déjà répondu et le chiffre exact ne changera pas la décision.

La taille de morceau oppose deux coûts l’un à l’autre. Les petits morceaux veulent un grand compte, plus de requêtes, plus de comptabilité et un plafond de compte de parties qui arrive plus tôt  ; les gros morceaux veulent moins de requêtes et une plus grande perte quand l’un d’eux échoue, parce qu’un morceau raté est réessayé en entier. À 128 Mio, une connexion perdue coûte jusqu’à 134 millions d’octets de transfert répété, et sur une liaison peu fiable cette répétition peut l’emporter sur le surcoût que le gros morceau avait été choisi pour éviter.

Convertir la capacité totale est ce qui rend le compromis visible. Un téraoctet à 16 Mio par morceau fait 59 605 morceaux, à 128 Mio il en fait 7 451, et à 512 Mio il en fait 1 863. La figure du milieu est le compromis habituel non pas à cause d’une propriété du chiffre mais parce qu’elle s’assoit entre un plafond de compte de parties de 10 000 et un coût de réessai mesuré en minutes.

Une capacité écrite sans sa taille de morceau n’est qu’une demi-spécification. Deux systèmes tenant un téraoctet en extents de 4 Mio et en blocs de 128 Mio se comportent différemment sous fragmentation, sous écritures partielles et sous récupération, et le chiffre de capacité est identique dans les deux. Les plans de stockage qui ne portent que le chiffre en téraoctets perdent la partie de la conception qui déterminait réellement la performance.

La forme pratique est une ligne donnant la capacité décimale, l’équivalent binaire, la taille de morceau et le compte qui en résulte  : un téraoctet, 953 674,32 Mio, blocs de 128 Mio, 7 451 blocs. Chaque chiffre là est dérivable des autres, ce qui est le but — quiconque le lisant plus tard peut vérifier l’arithmétique au lieu de re-dériver les hypothèses.