Convertir des Tio en Mo

Un tébioctet vaut 1 024 gibioctets. L’écart avec le téraoctet grandit à chaque échelon : 2,4 % au kilo, 4,9 % au méga, 7,4 % au giga, 10 % au téra.

Un mégaoctet vaut un million d’octets. Les fabricants de stockage ont toujours compté en décimal, et c’est pourquoi leurs chiffres paraissent plus grands que ce qu’affiche l’ordinateur.

Un TiB vaut 1 024 fois l'unité du dessous ; un TB, 1 000. Sur cette page, c'est l'écart entre 1099511,6278 MB et 1000000 MB — 10 % — 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 10 %. Un disque vendu en TB contient exactement ce qui est annoncé ; Windows divise ensuite par 1 024 au lieu de 1 000, garde le nom décimal, et affiche 1000000 MB là où la boîte annonçait 1099511,6278 MB. 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.

Toute estimation de transfert est une division, et ses deux entrées viennent de systèmes d’unités différents. Le volume est rapporté par ce qui contient les données — un dépôt de sauvegarde, un ensemble, un système de fichiers — et tous comptent en puissances de 1 024, donc le chiffre arrive en tébioctets. Le débit vient d’une spécification réseau ou de périphérique, et celles-là sont décimales sans exception.

Diviser l’un par l’autre sans convertir produit une réponse presque dix pour cent trop optimiste, ce qui sur une fenêtre de migration est la différence entre finir dans une période de maintenance ou non. Un tébioctet fait 1 099 511,63 Mo, donc la première étape honnête est de convertir le volume en mégaoctets décimaux et seulement ensuite de diviser par le débit.

Avant que l’arithmétique binaire n’ait la moindre importance, il y a un piège bien plus grand dans la même phrase. Les débits de lien sont annoncés en bits par seconde et les débits de transfert en octets par seconde, et un octet fait huit bits. Un lien à 1 000 Mbit/s déplace au plus 125 Mo par seconde ; un lien à 100 Mbit/s en déplace 12,5 ; un lien à 10 Gbit/s en déplace 1 250. La distinction tient entièrement à la casse d’une seule lettre.

Se tromper là est une erreur d’un facteur huit, environ soixante-dix fois plus grande que l’écart décimal/binaire dont cette page traite par ailleurs. Cela vaut la peine d’être résolu d’abord et explicitement : inscrivez le débit en Mo par seconde, avec le calcul, avant de toucher au volume. Une estimation qui est fausse d’un facteur huit se repère généralement ; une qui est fausse de dix pour cent ne se repère pas, et c’est pourquoi les deux étapes méritent d’être visibles.

L’arithmétique est courte une fois que les deux côtés sont décimaux. Un tébioctet fait 1 099 512 Mo ; à 100 Mo par seconde cela fait 10 995 secondes, ou 3 heures et 3 minutes. Dix tébioctets au même débit font 30 heures et 32 minutes. À 1 250 Mo par seconde — un lien dix gigabits à son plafond théorique — dix tébioctets prennent 2 heures et 27 minutes.

Ces chiffres sont des planchers, et ils devraient être étiquetés comme tels partout où ils sont cités. Ils supposent un seul flux continu au plein débit sans coût par fichier, ce qu’aucun transfert réel n’atteint. Présenter un plancher comme une estimation est comment une fenêtre de migration se trouve dimensionnée exactement au chiffre qui ne peut pas être tenu, et ajouter le qualificatif coûte un mot.

L’écart entre l’arithmétique et l’horloge est dominé par le nombre de fichiers plutôt que par le volume. Chaque fichier coûte une création, une écriture de métadonnées et, via un protocole réseau, au moins un aller-retour ; un million de petits fichiers peut passer plus de temps là-dessus qu’à déplacer leur contenu. Un seul gros fichier au même volume tournera près du débit du lien. Deux transferts de taille identique peuvent donc différer d’un ordre de grandeur en durée.

Les autres soustractions sont plus régulières et plus faciles à anticiper. L’overhead de protocole prend quelques pour cent. Le chiffrement et les sommes de contrôle coûtent du CPU qui peut être ou non le goulot d’étranglement. Le stockage récepteur a un plafond d’écriture qui est souvent inférieur à celui du réseau. Le parallélisme récupère une grande partie de cela et introduit sa propre limite, puisque cent flux concurrents ne vont pas cent fois plus vite.

Quand un transfert sort d’un fournisseur, le coût est au gigaoctet décimal et le compteur est le sien. Un dépôt déclaré à 10 Tio fait 10 995 Go d’egress facturable si tout y passe, ce qui est 9,95 % au-dessus du chiffre rond qu’on estimerait à partir du nombre en tébioctets. Sur une migration d’envergure, ce pourcentage est un poste que quelqu’un doit expliquer.

Le compteur du fournisseur compte aussi des choses que votre propre chiffre ne compte pas : les réessais, l’overhead de protocole, et tout le trafic que l’outillage génère en listant et en vérifiant. Ces postes sont en général faibles face à un transfert en masse et ne sont pas toujours faibles face à un travail qui redémarre. Estimer à partir du volume converti et traiter l’écart comme une contingence est plus honnête que de présenter un chiffre converti comme la facture.

Les longs transferts sont interrompus, et ce qui est re-dérivé après une interruption est là que les estimations dérivent. Le volume restant est en général rapporté par la source en tébioctets à nouveau, le débit observé jusque-là est en mégaoctets par seconde, et la personne qui fait l’arithmétique à deux heures du matin est celle qui a le plus de chances de diviser les deux directement. La correction est le même 9,95 %, appliqué à un nombre plus petit, dans un état d’esprit pire.

Inscrire la conversion dans la procédure d’exécution plutôt que dans l’estimation est ce qui empêche cela. Une ligne disant « Tio restants × 1 099 512 = Mo ; ÷ Mo/s observés = secondes » prend une ligne, se vérifie, et produit la même réponse à deux heures du matin qu’elle produisait en réunion de planification.

Les chiffres qui rendent une estimation auditable sont les intermédiaires. Le volume en Tio tel que rapporté par la source ; ce même volume en Mo ; le débit en Mo par seconde avec la conversion bit-octet montrée s’il y en a eu une ; le plancher théorique ; l’efficacité supposée ; la fenêtre qui en résulte. Six lignes, et chacune est un nombre que quelqu’un peut contester sans re-dériver tout l’ensemble.

L’alternative est une durée unique, qui est incontestable dans le mauvais sens : quand le transfert déborde, personne ne peut dire si le débit était optimiste, le volume était périmé ou les unités étaient mélangées. Les estimations de stockage et de transfert sont reprises sous pression plus que toute autre sorte, et c’est précisément quand une chaîne d’étapes visibles rattrape la minute qu’elle a coûtée à écrire.

Une estimation qui s’arrête au transfert est en général trop courte d’une passe entière. Tout ce qui vaut la peine d’être migré vaut normalement la peine d’être vérifié, et une comparaison de sommes de contrôle relit le volume complet des deux côtés. Si le transfert de 10 Tio prend trente heures, la vérification est une autre lecture de 10 995 116 Mo de chaque côté, bornée par le débit du disque plutôt que par le réseau et souvent plus lente que la copie elle-même côté source.

Il existe des variantes moins coûteuses et elles méritent d’être choisies délibérément plutôt que par défaut. Vérifier un échantillon donne une assurance probabiliste en une fraction du temps. Les outils qui calculent une somme de contrôle pendant le transfert évitent entièrement la seconde lecture, au prix d’une partie du débit. Se fier aux contrôles d’intégrité propres du protocole est défendable pour un saut unique et bien moins pour une migration à plusieurs étapes. Quelle que soit celle choisie, la fenêtre doit l’inclure, parce que la découvrir après coup est comment une période de maintenance déborde.