Convertir des Gio en Tio

Un gibioctet vaut 1 073 741 824 octets, environ 7 % de plus qu’un gigaoctet. Windows mesure en gibioctets tout en les étiquetant « Go », et c’est là tout le mystère de l’espace disque qui s’évapore.

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.

Dans ce sens, l'opération est une division, et par un nombre entier : 1 024 de ces unités entrent dans un tébioctet sans reste. Le seul inconvénient, c'est que les résultats tombent en fractions — un tiers, un douzième — au lieu des chiffres ronds que donne le sens inverse.

Rien ne se perd pour autant : la division est exacte. Si votre résultat refuse de tenir en place en décimal — 0,0833… et compagnie —, c'est la fraction qui transparaît, pas une erreur qui s'installe.

Un GiB vaut 1 024 fois l'unité du dessous ; un GB, 1 000. Sur cette page, c'est l'écart entre 0,001 TiB et 0,0009 TiB — 7,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 7,4 %. Un disque vendu en GB 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,0009 TiB là où la boîte annonçait 0,001 TiB. 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 disques se vendent en téraoctets décimaux et les pools se comptent en unités binaires, de sorte que la première chose qui arrive à un achat est une coupe de dix pour cent qui n’en est pas une. Un disque de 4 To contient exactement 4 000 000 000 000 d’octets comme annoncé, ce qui fait 3 725,29 GiB ou 3,638 TiB. Huit d’entre eux font 29 802 GiB, soit 29,10 TiB, et la facture annonce 32 To. Rien n’a été perdu entre ces deux valeurs ; ce sont les mêmes octets comptés dans deux bases.

La seconde conversion est celle qui retire de la capacité réelle, et elle vient après : parité ou miroir, la réserve que garde le système de fichiers, le plafond de remplissage que quiconque de sensé planifie. Garder les deux séparées est ce qui rend un plan de capacité vérifiable. Posez la valeur brute en tébioctets d’abord, puis chaque déduction avec sa raison, plutôt que de présenter un seul chiffre quarante pour cent en deçà de la facture sans détail.

C’est la source la plus fréquente d’un chiffre en gibioctets qui ne se réconcilie pas. zpool list rapporte la taille brute des vdevs, parité incluse, parce que c’est ce que gère la couche pool. zfs list rapporte ce que la couche dataset peut stocker, parité exclue. Sur un pool raidz2 de huit disques, le premier affichera environ un tiers de plus que le second, et les deux sont justes.

La règle qui s’ensuit est de prendre les chiffres de capacité à la couche qui correspond à la question. Planifier ce qui tiendra en données est une question zfs list. Savoir si un disque de remplacement est assez gros, ou combien une reconstruction doit lire, est une question zpool list. Convertir le mauvais en tébioctet et le poser dans un plan produit un ensemble qui se remplit un tiers plus tôt que ce que le tableur annonçait.

L’arithmétique de tête est simple. Un miroir donne la moitié. RAID 5 et raidz1 donnent n − 1 disques de données. RAID 6 et raidz2 donnent n − 2. Un miroir rayé donne la moitié quelle que soit la largeur. Huit disques de 3 725,29 GiB en raidz2 donnent six disques de données, 22 351 GiB, soit 21,83 TiB, et les mêmes huit en quatre paires miroir donnent 14 901 GiB, soit 14,55 TiB, avec un comportement de reconstruction bien meilleur.

Le remplissage prélève une part supplémentaire que l’arithmétique de tête manque. ZFS alloue selon des unités dérivées de la taille de secteur, de sorte que les enregistrements qui ne se divisent pas équitablement sur les disques de données laissent des trous, et l’effet est pire avec de petits enregistrements sur des vdevs larges. Pour un serveur de fichiers général en taille d’enregistrement par défaut de 128 KiB, la perte est faible ; pour un pool abritant une base de données avec une taille d’enregistrement de 8 KiB sur des disques en ashift=12, elle peut atteindre un cinquième de la capacité nominale, ce qui mérite d’être modélisé avant la construction plutôt que découvert après.

Un système de fichiers copy-on-write ne libère pas un fichier en écrasant un bit en place ; il doit écrire de la métadonnée nouvelle, ce qui requiert de l’espace libre. Un pool qui atteindrait vraiment zéro espace libre serait donc incapable de rien supprimer, et c’est un état sans issue. ZFS l’évite en mettant de côté une part — un trente-deuxième du pool par défaut — que les écritures ordinaires ne peuvent pas toucher.

Sur un pool de 32 TiB, c’est environ 1 TiB mis de côté, et ce n’est pas visible comme espace libre dans le chiffre que voient les utilisateurs. C’est une proportion fixe plutôt qu’une quantité fixe, donc cela croît avec le pool, et c’est une des déductions qui doit apparaître explicitement dans un plan de capacité. Btrfs a un problème analogue et le traite autrement, par une réserve globale et l’opération balance, mais la contrainte sous-jacente est la même pour tout système de fichiers qui n’écrase jamais en place.

La performance d’allocation sur un pool copy-on-write se dégrade quand l’espace libre se fragmente, et elle se dégrade fortement plutôt que graduellement. L’allocateur doit chercher davantage d’espace contigu, les écritures s’éparpillent, et la performance en lecture suit parce que les données ont atterri éparpillées. Le conseil usuel est de planifier à quatre-vingts pour cent pour un pool général, et plus bas pour un pool à forte charge d’écritures aléatoires.

Cela transforme 32 TiB de capacité utilisable en environ 25,6 TiB de capacité de planification, et traiter la différence comme une marge que l’on mangera au cours d’un trimestre chargé est la manière dont un pool finit lent et difficile à récupérer. Convertir le total en gibioctets en tébioctets et appliquer le plafond dans la même étape donne un seul chiffre pour planifier ; garder la valeur brute dans le plan invite quelqu’un à l’utiliser.

Un pool ne grandit pas d’une quantité arbitraire. Ajouter de la capacité veut dire ajouter un autre vdev de même forme, ou remplacer chaque disque d’un vdev existant par un plus grand et laisser l’ensemble s’étendre une fois le dernier fait. Les versions récentes de ZFS savent ajouter un seul disque à un vdev raidz, mais les données préexistantes gardent leur ancien ratio de parité jusqu’à réécriture, de sorte que la valeur utilisable bouge moins que l’arithmétique ne le suggère.

La conséquence pour le plan est que l’incrément de croissance est grand et connu à l’avance. Un vdev raidz2 de huit disques de 4 To ajoute 21,83 TiB à la fois, de sorte qu’un plan qui dépassera la capacité dans dix-huit mois a une décision d’achat à taille discrète plutôt qu’à un débit. Travailler l’incrément en tébioctets tôt rend évident si la prochaine étape est un vdev ou deux, et c’est en général la question qui compte.

Un instantané ne coûte rien à la prise et grandit à mesure que les données vivantes divergent de lui. Un dataset qui contient 4 TiB avec un mois d’instantanés quotidiens et un motif de réécriture intensive peut consommer plusieurs fois cette valeur, et aucune de cette croissance n’est visible dans la taille des données courantes. zfs list -o space la ventile en used, usedbysnapshots, usedbydataset et usedbyrefreservation, et c’est là qu’un manque inexpliqué se loge en général.

La conséquence pour le plan est que le tébioctet utilisable doit être réduit d’une allocation pour la rétention d’instantanés, et cette allocation dépend du taux de réécriture plutôt que de la taille des données. Une archive de médias écrite une fois n’a presque rien à prévoir ; un magasin de machines virtuelles où chaque invité réécrit son système de fichiers chaque jour a besoin d’un grand multiple. Quand le taux est inconnu, deux semaines de mesures coûtent bien moins cher que l’alternative qui consiste à découvrir le moment où le pool se remplit.