Convertir des Tio en Mio

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

Dans ce sens, l'opération est une multiplication, et par un nombre entier : un tébioctet fait 1 048 576 mébioctets, exactement, et 1 048 576 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 TiB vaut 1 024 fois l'unité du dessous ; un TB, 1 000. Sur cette page, c'est l'écart entre 1048576 MiB et 953674,3164 MiB — 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 953674,3164 MiB là où la boîte annonçait 1048576 MiB. 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.

Diviser un tébioctet par un mebioctet donne 1 048 576, et dans presque tous les contextes où quelqu’un effectue cette conversion ce quotient est la raison d’être. Combien de parties aura le téléversement. Combien de fragments détiendra l’index de sauvegarde. Combien de fichiers produira la découpe. L’arithmétique des octets est exacte et sans intérêt ; le compte de parts rencontre une limite, et la limite est en général sur le compte.

Cela redéfinit ce qu’est une taille de fragment. Ce n’est pas une unité ni un bouton de performance isolément — c’est le diviseur qui décide si l’opération est possible. Le choisir en recopiant une valeur par défaut et en ne découvrant le plafond qu’au bout d’un transfert de plusieurs heures est la manière la plus commune dont cela tourne mal, et l’arithmétique qui l’aurait évité prend quelques secondes.

Le protocole de téléversement en parties multiples de S3 et les nombreuses implémentations qui le recopient autorisent au plus 10 000 parties par téléversement, une taille minimale de 5 Mio pour toute partie sauf la dernière, une taille maximale de partie de 5 Gio, et un objet maximal de 5 Tio. Trois de ces quatre sont des limites de taille et celui qui mord réellement est le compte, parce qu’un client choisit une taille de fragment une fois et continue ensuite à produire des parts jusqu’à en manquer.

La conséquence est un plafond qui est une propriété de la configuration plutôt que du service : taille de fragment multipliée par 10 000. À 5 Mio cela fait 48,83 Gio. À 8 Mio cela fait 78,125 Gio. À 64 Mio cela fait 625 Gio, à 128 Mio cela fait 1,22 Tio et à 512 Mio cela fait 4,88 Tio, où c’est le plafond d’objet lui-même qui commence à être la contrainte liante. Chacun de ces chiffres est la taille du fragment en mebioctets multipliée par dix mille, divisée par 1 024 pour un gibioctet et par 1 048 576 pour un tébioctet.

L’AWS CLI prend par défaut un fragment de 8 Mio avec un seuil de 8 Mio, et la plupart des SDK choisissent quelque chose de similaire. C’est une valeur par défaut sensée pour les fichiers que les gens téléversent d’habitude, et elle échoue à 78,125 Gio, ce qui est suffisamment au-dessus de l’usage ordinaire pour qu’une équipe puisse fonctionner des années avant de la rencontrer. Quand elle la rencontre, la défaillance arrive après que soixante-dix-huit gibioctets ont déjà été transférés, ce qui est le pire endroit possible pour elle.

L’augmenter est une seule ligne de configuration — aws configure set default.s3.multipart_chunksize 128MB — et la valeur doit être choisie en regard du plus grand objet que le système produira jamais, et non du plus grand qu’il produit aujourd’hui. Un fragment de 128 Mio couvre 1,22 Tio et un fragment de 512 Mio couvre essentiellement toute la plage permise, au prix d’une unité de reprise plus grande et de plus de mémoire détenue par partie concurrente.

Le plancher est le total divisé par 10 000. Un tébioctet exige au moins des parties de 104,86 Mio ; un objet de 5 Tio exige au moins 524,29 Mio. Arrondir à la puissance de deux supérieure donne 128 Mio et 1 024 Mio respectivement, et le chiffre rond vaut la peine d’être pris parce qu’il maintient le compte de parts à un net 8 192 ou 5 120 plutôt qu’à un chiffre qu’il faut recalculer à chaque fois que l’objet grandit.

Le plafond est fixé par la mémoire et par le coût d’une reprise plutôt que par le protocole. Un client qui détient huit parties concurrentes de 128 Mio a un gibioctet en vol, ce qui va sur un serveur et ne va pas dans un conteneur avec une limite de 512 Mio. Là où le téléverseur tourne lui-même sous une limite de mémoire, la taille de partie multipliée par la concurrence doit y tenir avec de la place pour tout le reste, et c’est ce produit qu’il faut vérifier plutôt que l’un ou l’autre des facteurs.

Une partie qui échoue est retransmise entière. Sur une connexion qui tombe de temps en temps, de petites parties signifient qu’un échec coûte peu et de grandes parties signifient qu’il coûte beaucoup — une coupure à 90 % d’une partie de 1 Gio jette 900 Mio de travail. Sur un lien très fiable le calcul s’inverse, parce que chaque partie porte une requête, une signature et un aller-retour, et 131 072 d’entre elles représente beaucoup d’overhead de protocole pour un seul tébioctet.

Le milieu pratique est de dimensionner les parties pour qu’une prenne entre une et cinq secondes sur le lien dont on dispose réellement. À 100 Mbit/s cela fait environ 16 à 64 Mio ; sur un lien gigabit cela fait 128 à 512 Mio. Le calculer à partir du débit du lien plutôt qu’à partir d’un tableau signifie que la taille de fragment s’adapte quand le transfert passe d’une connexion de bureau à un centre de données, ce qui est en général là que les hypothèses cassent.

Le débit en stockage objet vient des parties en vol, et non de la taille de partie. Un flux unique est limité par le temps d’aller-retour et par le comportement par connexion du point d’arrivée, et il ne saturera pas un lien rapide, quelle que soit la taille des fragments. Huit ou seize parties concurrentes le saturent en général, et l’amélioration entre un flux et huit est bien plus grande que tout ce qui peut être obtenu en changeant la taille de fragment.

Cela signifie que les deux réglages doivent être choisis dans le bon ordre : la taille de partie à partir du total et de la limite de parties, puis la concurrence à partir du lien et du budget mémoire. Faire l’inverse — augmenter la taille de fragment en espérant de la vitesse — produit un transfert qui n’est pas plus rapide, consomme plus de mémoire, et perd plus de travail à chaque reprise.

Les outils de sauvegarde qui dédupliquent découpent avec l’objectif opposé. Plutôt qu’une taille fixe en mebioctets, ils utilisent des frontières définies par le contenu avec une cible moyenne — souvent autour d’un mebioctet — pour que l’insertion d’octets au début d’un fichier ne décale que les frontières proches du changement plutôt que toutes les frontières qui suivent. Un découpage à taille fixe réécrirait le flux de fragments entier pour une insertion d’un octet, ce qui explique pourquoi il n’est pas utilisé là où la déduplication compte.

Le compte de parts continue de régner sur le coût. Un tébioctet à un mebioctet moyen représente environ un million de fragments, chacun nécessitant une entrée d’index avec un hachage, donc l’index du dépôt court sur des dizaines ou des centaines de mebioctets et doit être tenu en mémoire pendant une sauvegarde. Doubler la taille moyenne de fragment divise l’index par deux et réduit le taux de déduplication, et là où un dépôt est devenu lent plutôt que plein, c’est en général le compromis qu’il vaut la peine de revoir.