Convertir des Mo en Tio

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

Le facteur vaut 0,000001, et à peu près personne ne le trimballe. Arrondi à 0,000001, il s'écarte de 0,06 % — invisible sur de petits nombres, et devenu une unité entière vers 10 000 MB.

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

Les fichiers individuels se décrivent naturellement en mégaoctets — une photo, une piste, un scan, une décharge nocturne — et le stockage qui les contient est rapporté par les outils de bassin en tébioctets. Entre les deux nombres se trouvent six crans de préfixe et la ligne décimal-binaire, et l’agrégat est l’endroit où les deux commencent à importer. Un tébioctet contient 1 099 511,63 Mo, de sorte que l’approximation utile est de 1,1 million de mégaoctets par tébioctet.

Ce chiffre fait de la plupart de ces estimations une arithmétique que n’importe qui peut faire debout. Une bibliothèque de 400 000 fichiers d’une moyenne de 4 Mo fait 1 600 000 Mo, ce qui donne 1,46 Tio. Deux ans de vidages nocturnes à 800 Mo chacun font 584 000 Mo, ou 0,53 Tio. La précision qui compte ici est dans la taille moyenne d’un fichier, qui est en général une estimation, plutôt que dans la conversion, qui est exacte.

À 5 Mo par fichier, un tébioctet en contient environ 219 900. À 30 Mo — une image brute issue d’un appareil plein format — il en contient 36 650. À 800 Mo, la taille d’une décompresse de base de données de taille modérée, il en contient 1 374. Ces trois nombres couvrent deux ordres de grandeur et décrivent la même capacité, ce qui explique pourquoi un plan de capacité qui ne précise pas la taille de fichier supposée n’est pas un plan.

Les rythmes d’enregistrement se comportent de la même manière. Une vidéo encodée à 45 Go par heure remplit un tébioctet en un peu plus de vingt-quatre heures de séquences. Un appareil qui produit 1 200 images par jour à 30 Mo le remplit en un mois environ. Aucun de ces chiffres n’est affecté par la question d’unité de plus de dix pour cent, et tous sont affectés par les réglages de l’appareil d’un facteur plusieurs.

Chaque fichier est arrondi au bloc d’allocation entier, de sorte qu’une bibliothèque de petits fichiers occupe plus que son contenu. À une taille de bloc de 4 Kio, le gaspillage moyen est d’environ 2 Kio par fichier, ce qui sur 400 000 fichiers représente 800 Mo — une erreur d’arrondi face à un tébioctet, mais pas face à un bassin proche de la saturation. Les répertoires, les métadonnées et les structures propres du système de fichiers ajoutent encore.

Les bibliothèques multimédia ajoutent leur propre surcharge par-dessus. Les fichiers annexes portant les retouches, les aperçus générés à plusieurs tailles, et une base de catalogue qui croît avec la collection peuvent ajouter un pourcentage substantiel au total brut des fichiers, et rien de tout cela n’apparaît dans le chiffre qu’un appareil photo rapporte par image. Mesurer la taille occupée d’un dossier représentatif et la comparer à la somme des longueurs de fichier donne un coefficient qu’on peut appliquer à l’estimation entière.

Un total statique répond à la mauvaise question. Ce qui détermine un achat, c’est le rythme : mégaoctets par semaine, par sortie, par cycle de sauvegarde. Convertir le rythme dans la même unité que la capacité restante et diviser, et la réponse est une date plutôt qu’un pourcentage. Une capacité restante de 3 Tio face à une croissance de 60 000 Mo par semaine, c’est 3 298 535 Mo divisés par 60 000, ce qui fait 55 semaines.

Les rythmes sont aussi là où une erreur d’unité se compose au lieu de rester immobile. Un chiffre hebdomadaire sous-estimé de dix pour cent parce qu’un tébioctet a été lu comme un téraoctet produit une prévision dix pour cent optimiste chaque semaine, et l’erreur s’accumule dans le même sens que la croissance qu’elle essaie de prédire. Le bassin se remplit plus tôt que ce que le plan annonçait, et le plan a l’air à peu près correct jusqu’à la semaine où il ne l’est plus.

L’écart entre les préfixes décimaux et binaires se compose à chaque pas : 2,43 % au kilo, 4,86 au méga, 7,37 au giga et 9,95 au téra. À l’extrémité mégaoctet de cette conversion, la différence est vraiment négligeable, ce qui explique que personne ne s’en soucie pour un seul fichier. À l’extrémité tébioctet, c’est cent gigaoctets sur un seul bassin.

Cette asymétrie est ce qui rend cette conversion précise plutôt qu’approximative. L’intinct du lecteur, formé à l’échelle du fichier où les unités diffèrent à peine, est qu’un facteur d’un million est assez proche. Il ne l’est pas : 1 000 000 Mo font 0,909 Tio, et un tébioctet contient 1 099 512 Mo plutôt qu’un million rond. Traiter les deux comme interchangeables fausse un bassin d’environ cent gigaoctets, et le sens de l’erreur dépend de l’extrémité de la conversion où quelqu’un a arrondi.

Une moyenne est un mauvais résumé d’une bibliothèque multimédia. Une collection de 200 000 photos peut être surtout des images compressées de 4 Mo avec quelques milliers de panoramas et de composites dans les centaines de mégaoctets, et la moyenne se pose quelque part que ni chiffre ne décrit. Le total reste correct, mais toute conclusion tirée sur un sous-ensemble — une année, un projet, un appareil — sera fausse d’une manière que le total cache.

L’amélioration qui ne coûte rien consiste à prendre la taille occupée totale directement plutôt que multiplier un compte par une moyenne. Tout outil de stockage rapporte le total d’un arbre de répertoires, et ce chiffre inclut déjà l’arrondi par bloc et les fichiers annexes. N’utiliser la moyenne que pour prévoir ce qui n’a pas encore été créé, où c’est la seule information disponible.

Une archive est rarement stockée une seule fois. La discipline de sauvegarde courante garde trois copies sur deux types de média avec une conservée hors site, ce qui transforme une bibliothèque de 1,46 Tio en un peu plus de 4 Tio de capacité engagée avant même qu’une quelconque version n’intervienne. Les instantanés ajoutent encore, et un régime d’instantanés qui conserve des points mensuels sur un an peut détenir plusieurs fois la taille vivante selon combien de la collection change.

Les estimations bâties à partir des tailles de fichier ne décrivent presque toujours que la copie primaire, parce que c’est celle que quelqu’un a mesurée. Écrire le coefficient explicitement — taille vivante, fois copies, plus rétention d’instantanés — transforme un chiffre plausible en un chiffre qu’on peut discuter. Cela rend aussi évident le levier à actionner quand le total est hors de portée, qui est en général le calendrier de rétention plutôt que la résolution à laquelle les fichiers ont été capturés. Le piège classique est de couper la rétention après avoir dimensionné l’infrastructure ; le piège inverse, dimensionner après avoir coupé, est celui qui fait acheter un disque trop petit.