Data Domain : Comprendre la compression Data Domain

Les techniques de compression impliquées dans un Data Domain utilisent des techniques de pointe pour réduire l’espace physique requis par les données de sauvegarde. Par conséquent, les technologies et les mesures des niveaux de compression sont des sujets complexes.

Cet article présente certaines terminologies, compromis et mesures pour mieux expliquer le type de compression utilisé, ainsi que d’autres aspects de la compression dans un environnement Data Domain.

S’APPLIQUE À : Tous les modèles Data Domain

Introduction :

Dernière mise à jour : Janvier 2024

• La compression est une technologie de réduction des données qui vise à stocker un jeu de données en utilisant moins d’espace physique.
• Dans les systèmes Data Domain (DDOS), la déduplication et la compression locale sont effectuées pour compresser les données utilisateur. La déduplication, ou « déduplication », est utilisée pour identifier les segments de données redondants et stocker uniquement les segments de données uniques.
• La compression locale compresse davantage les segments de données uniques à l’aide de certains algorithmes de compression, tels que lz, gzfast, gz, et ainsi de suite.
• La compression globale des données utilisateur dans DDOS est le résultat d’un effort conjoint de déduplication et de compression locale. DDOS utilise le « taux de compression » pour mesurer l’efficacité de la compression de ses données.
• En règle générale, il s’agit du rapport entre la taille totale des données utilisateur et la taille totale des données compressées ou la taille de l’espace physique utilisé.
• Le système de fichiers Data Domain est un système de fichiers de déduplication « structuré en log ».
• Un système de fichiers structuré en journaux ajoute uniquement des données au système et la suppression par elle-même ne peut pas libérer d’espace physique.
• Ces systèmes de fichiers s’appuient sur le nettoyage de la mémoire pour récupérer l’espace qui n’est plus utilisé.
• Les caractéristiques du système de fichiers structuré en journaux et de la technologie dédupliquée combinées compliquent la compréhension de tous les aspects de la compression dans DDOS.

Pour la compression, de nombreux aspects peuvent être mesurés.

Cet article présente les détails étape par étape pour vous aider à comprendre la compression DDOS.

• Dans un premier temps, l’effet global de la compression du système est expliqué, ce qui nous indique la compression réaliste obtenue dans un système Data Domain, la quantité de données utilisateur, la quantité d’espace physique consommée et le rapport entre celles-ci.
• Ce taux est appelé « taux de compression effectif du système » dans cet article.
• DDOS effectue la déduplication à la volée et suit les statistiques des segments de données utilisateur d’origine, des segments de données uniques après déduplication et de l’effet de compression locale sur les segments de données uniques.
• Ces statistiques de compression au fil de l’eau sont utilisées pour mesurer l’effet de la compression au fil de l’eau. Les statistiques de compression à la volée peuvent être mesurées pour chaque écriture. En outre, DDOS suit les statistiques à différents niveaux : Fichiers MTreeset l’ensemble du système.

Il n’est pas garanti que la totalité du contenu soit exacte pour les futures versions.

Dans les versions antérieures à 5.0, l’ensemble du système dispose d’un seul mtree et le terme mtree n’est pas explicitement mentionnée.

Compression : Effet global sur le système :

L’effet global de la compression à l’échelle du système est mesuré par le taux de compression effectif, qui est le rapport entre la taille des données utilisateur et la taille de l’espace physique utilisé. Il est rapporté par le «filesys show compression" (FSC) (les informations correspondantes sont également disponibles sur l’interface utilisateur). Exemple de sortie de FSC est illustré ci-dessous :

# filesys show compression

From: 2023-12-31 03:00 To: 2024-01-07 03:00

Active Tier:
                   Pre-Comp   Post-Comp   Global-Comp   Local-Comp      Total-Comp
                      (GiB)       (GiB)        Factor       Factor          Factor
                                                                     (Reduction %)
----------------   --------   ---------   -----------   ----------   -------------
Currently Used:*     6439.6       113.4             -            -    56.8x (98.2)
Written:
  Last 7 days      135421.3      1782.0         35.1x         2.2x    76.0x (98.7)
  Last 24 hrs         532.5         1.5        334.3x         1.1x   356.5x (99.7)
----------------   --------   ---------   -----------   ----------   -------------
 * Does not include the effects of pre-comp file deletes/truncates
   since the last cleaning on 2024/01/05 11:34:13.

• •  
  • Le taux de compression effectif du système est indiqué à la ligne 1 de la section des résultats de la sortie de l’interface de ligne de commande. La ligne est mise en surbrillance au-dessus.
  • La taille totale des données utilisateur est étiquetée comme « Pre-Comp ».
  • L’espace physique total consommé (par données et métadonnées) est étiqueté « Post-Comp ».
  • Les numéros « pré-compression » et « post-compression » sont tous deux lus lors de l’exécution. FSC synchronise implicitement l’ensemble du système, puis interroge les deux nombres.
    • Ces deux nombres sont mesurés de la même manière que le "filesys show space" commande.
    • Taux de compression effectif du système = Pre-Comp/Post-Comp

Certaines opérations peuvent affecter le taux de compression effectif du système :

• Copie rapide
  • Lorsqu’un fastcopy S’effectue à partir d’un fichier de l’espace de nommage actif (et non d’un snapshot), il s’agit d’une déduplication parfaite, car aucun espace physique supplémentaire n’est nécessaire pour le fichier cible. L’effet d’un fastcopy est que la taille des données utilisateur est augmentée sans consommer d’espace physique supplémentaire. Cela augmente le taux de compression effectif du système. Lorsque de nombreux fastcopies Si c’est fait, le taux de compression effectif du système peut devenir artificiellement élevé.
• Sauvegardes synthétiques virtuelles
  • Les sauvegardes synthétiques virtuelles ont tendance à afficher un taux de compression efficace du système élevé. Cela est dû au fait que les sauvegardes synthétiques virtuelles effectuent des sauvegardes logiques complètes, mais transfèrent uniquement les données modifiées ou nouvelles vers les systèmes Data Domain. L’impact des sauvegardes synthétiques virtuelles sur le taux de compression effectif du système est similaire à celui de fastcopy.
• Remplace
  • Les écrasements consomment plus d’espace physique, mais n’augmentent pas la taille logique du jeu de données. Par conséquent, les écrasements réduisent le taux de compression effectif du système
• Stockage des fichiers sparse
  • Les fichiers sparse contiennent des « trous » volumineux qui sont comptabilisés dans la taille logique, mais qui ne consomment pas d’espace physique en raison de la compression. Par conséquent, ils peuvent donner l’impression que le taux de compression effectif du système est élevé.
• Stockage de petits fichiers
  • DDOS ajoute près de 1 Ko de surcharge à chaque fichier pour certaines métadonnées internes. Lorsqu’un système stocke un nombre important de petits fichiers (d’une taille inférieure à 1 Ko ou en kilo-octets à un chiffre), la surcharge des métadonnées entraîne le taux de compression effectif vers le bas.
• Stockage de fichiers précompressés ou préchiffrés
  • La compression et le chiffrement peuvent amplifier le niveau de modification des données et réduire les possibilités de déduplication. Ces fichiers ne peuvent généralement pas être correctement dédupliqués et réduisent le taux de compression effectif du système.
• Supprime
  • Les suppressions réduisent la taille logique du système, mais le système ne considère pas cet espace comme inutilisé tant que l’exécution du nettoyage de la mémoire n’a pas été exécuté. De nombreux fichiers supprimés entraînent un taux de compression faible jusqu’à ce que le nettoyage de la mémoire (GC) s’exécute.
• Nettoyage ou nettoyage de la mémoire
  • GC récupère l’espace utilisé par les segments de données qui ne sont plus visibles par aucun fichier. Si un grand nombre de fichiers ont été supprimés récemment, le nettoyage de la mémoire peut augmenter le taux de compression du système en réduisant l’encombrement de la consommation d’espace physique.
• Prise agressive de snapshots
  • Lorsqu’un snapshot d’un Mtree est prise, la taille logique du jeu de données n’est pas modifiée. Toutefois, tous les segments de données référencés par le snapshot doivent être verrouillés, même si tous les fichiers capturés par le snapshot sont supprimés après la création du snapshot. GC ne peut pas récupérer l’espace encore nécessaire pour les snapshots. Le fait d’avoir beaucoup de snapshots peut faire paraître faible le taux de compression effectif du système. Toutefois, les snapshots sont des fonctions de récupération en cas de panne utiles. N’hésitez jamais à prendre des snapshots ou à configurer des plannings de snapshots appropriés si nécessaire.

Compression : Statistiques en ligne :

DDOS effectue la déduplication à la volée, au fur et à mesure que les données sont écrites sur le système. Il suit les effets de la déduplication à la volée et de la compression locale pour chaque écriture, et accumule les statistiques au niveau du fichier. Les statistiques de compression à la volée par fichier sont agrégées à la page mtree et au niveau du système. La compression est mesurée à partir de trois chiffres dans les statistiques en ligne :

• Longueur de chaque écriture : raw_bytes 
• The length of all unique segments: pre_lc_size
• Longueur des segments uniques compressés localement : post_lc_size

• • Compression globale (g_comp)
    • Est égal à (raw_bytes/pre_lc_size) et reflète le taux de déduplication
  • Compression locale (l_comp)
    • Est égal à (pre_lc_size/post_lc_size) et reflète l’effet de l’algorithme de compression local

Les statistiques de compression à la volée cumulées font partie des métadonnées du fichier dans DDOS et sont stockées dans le fichier inode. DDOS fournit des outils pour vérifier les compressions à la volée aux trois niveaux ; Fichier MTreeet à l’échelle du système. Ceux-ci sont détaillés dans les sections suivantes.

Compression des fichiers :

• • La compression des fichiers peut être vérifiée à l’aide de la commande "filesys show compression <path>" CLI , qui signale les statistiques de compression cumulées stockées dans le fichier inode.
  • Lorsqu’un répertoire est spécifié, les statistiques de compression à la volée de tous les fichiers sous ce répertoire sont additionnées et signalées.
  • Dans la sortie de l’interface de ligne de commande, raw_bytes est étiqueté comme « Octets d’origine », pre_lc_size est étiqueté « Globalement compressé », post_lc_bytes est marqué comme « Localement compressé ». Les autres surcharges sont signalées en tant que « métadonnées ». Les deux exemples sont capturés à partir d’un DD de production :

Exemple 1 : Statistiques de compression à la volée d’un fichier

filesys show compression /data/col1/main/dir1/file_1

Total files: 1;  bytes/storage_used: 7.1
        Logical Bytes:       53,687,091,200
       Original Bytes:       11,463,643,380
  Globally Compressed:        4,373,117,751
   Locally Compressed:        1,604,726,416
            Meta-data:           18,118,232

Exemple 2 : Statistiques de compression à la volée de tous les fichiers d’un répertoire, y compris tous les sous-répertoires

filesys show compression /data/col1/main/dir1 

Total files: 13;  bytes/storage_used: 7.1
        Logical Bytes:       53,693,219,809
       Original Bytes:       11,501,978,884
  Globally Compressed:        4,387,212,404
   Locally Compressed:        1,608,444,046
            Meta-data:           18,241,880

• • • Le système signale le taux de compression à la volée global dans la sortie CLI ci-dessus comme étant « bytes/ ».storage_used. »
    • Toutefois, il faut être prudent lors de l’interprétation des informations ci-dessus, car elles peuvent être trompeuses pour différentes raisons.
    • L’une des raisons est que le pre_lc_size et post_lc_size sont enregistrées au moment où les opérations de données sont traitées.
    • Lorsque le fichier qui a initialement ajouté ces segments est supprimé, le nombre de segments de données uniques dans le fichier restant doit être augmenté.

Par exemple, supposons qu’un exemple de fichier soit sauvegardé sur un système Data Domain et que, lors de la première sauvegarde, les informations de compression du fichier soient pre_lc_size= 10 Gio, post_lc_size= 5 Gio.

• • • Supposons ensuite que les données de ce fichier soient uniques et qu’elles ne soient partagées avec aucun autre fichier.
    • Lors de la deuxième sauvegarde du fichier, partez du principe que le fichier obtient une déduplication idéale, de sorte que les deux pre_lc_size et post_lc_size doit être égal à zéro, car tous les segments du fichier existaient déjà sur le système.
    • Lorsque la première sauvegarde est supprimée, la deuxième sauvegarde du fichier devient le seul fichier qui référence les 5 Gio de segments de données.
    • Dans ce cas, idéalement, le pre_lc_size et post_lc_size du fichier de la deuxième sauvegarde doit être mis à jour de zéro à 10 Gio et 5 Gio, respectivement.
    • Cependant, il n’y a aucun moyen de détecter pour quels fichiers cela doit être fait, de sorte que les statistiques de compression à la volée des fichiers existants restent inchangées.

• • Les statistiques cumulatives sont un autre facteur qui affecte les chiffres ci-dessus.
  • Lorsqu’un fichier subit un grand nombre d’écrasements, il est impossible de déterminer dans quelle mesure les statistiques cumulées reflètent les écritures qui ont introduit les données en direct.
  • Ainsi, sur une longue période, les statistiques de compression en ligne ne peuvent être traitées que comme une heuristique permettant d’estimer grossièrement la compression d’un fichier particulier.
  • Un autre fait qui mérite d’être souligné est que la compression à la volée d’un fichier ne peut pas être mesurée pour un intervalle de temps arbitraire.
  • Les statistiques de compression à la volée des fichiers sont un résultat cumulatif et couvrent toutes les écritures reçues par le fichier.
  • Lorsqu’un fichier reçoit un grand nombre d’écrasements, la commande raw_bytes peut être bien supérieure à la taille logique du fichier. Pour les fichiers sparse, la taille du fichier peut être supérieure aux « Original Bytes ».

Compression de la structure MTree :

• • La compression d’un objet mtree peut être vérifié à l’aide de la commande "mtree show compression" (MSC) de l’interface de ligne de commande.
  • Les valeurs absolues des statistiques de compression à la volée sont cumulées tout au long de la durée de vie du MTree.
  • Étant donné que la durée de vie d’un MTree Pouvant durer plusieurs années, ces valeurs deviennent de moins en moins informatives au fil du temps.
  • Pour résoudre ce problème, la quantité de modification (deltas) des statistiques de compression à la volée est utilisée et signale la compression uniquement pour certains intervalles de temps.
  • L’approche sous-jacente est que l' MTree Les statistiques de compression à la volée sont régulièrement vidées dans un log.
  • Lorsqu’un client interroge la compression de structure MTree à l’aide de MSC , le log est utilisé pour calculer les deltas des nombres pour le reporting de compression.
  • Par défaut, MSC Compile les 7 derniers jours et les dernières 24 heures, bien que la période d’intérêt puisse être spécifiée à tout moment.

Pour le démontrer, supposons le log suivant pour MTree R :

3:00AM, raw_bytes=11000GB, pre_lc_size=100GB, post_lc_size=50GB 4:00AM, raw_bytes=12000GB, pre_lc_size=200GB, post_lc_size=100GB

Ensuite, la compression de MTree A pour cette heure est :

g_comp = (12000-11000)/(200-100) = 10x
l_comp = (200-100)/(100-50) = 2x
overall compression ratio = (12000-11000)/(100-50) = 20x

Le calcul du taux de compression ci-dessus n’affecte en rien la taille du jeu de données. Par exemple, la structure mtree ci-dessus peut n’avoir que 500 Go de données logiques.

• • MSC prend en charge les options « quotidien » et « quotidien-détaillé », tout comme le fait le »filesys show compression" commande.
  • Lorsque « daily » est spécifié, la commande signale la compression quotidienne selon un calendrier.
  • Il utilise les deltas quotidiens de la raw_bytes et post_lc_size pour calculer le taux de compression journalier.
  • Lorsque « daily-detailed » est spécifié, la commande affiche les trois deltas (de la raw_bytes, pre_lc_sizeet post_lc_size, respectivement) pour chaque jour. Il calcule également l’attribut g_comp et l_comp en plus du facteur de compression total.

Un exemple de résultat de ces systèmes se trouve à l’annexe ci-dessous.

Compression du système :

• • Une fois que la compression est signalée sur MTrees est compris, il est facile d’étendre le concept à l’ensemble du système.
  • La compression à l’échelle du système, la collecte et le reporting des statistiques à la volée sont exactement les mêmes qu’avec MTrees.
  • La seule différence est la portée, car on se trouve dans une MTree, alors que l’un d’entre eux est sur l’ensemble du système.
  • Les résultats peuvent être vérifiés à l’aide de l’icône "filesys show compression" commande.
  • Vous trouverez un exemple dans la section 2.
  • Les compressions du système « 7 derniers jours » et « dernières 24 heures » sont signalées dans les deux dernières lignes de la section des résultats du FSC résultat.

niveau Cloud :

• Sur les systèmes DD sur lesquels Cloud Tier est implémenté, le stockage est séparé entre le niveau actif et le niveau Cloud, qui sont deux domaines de déduplication indépendants.
• Les utilisateurs peuvent injecter des données uniquement dans le niveau actif.
• Par la suite, les fonctions de déplacement des données de DDOS peuvent être utilisées pour migrer les données du niveau actif vers le niveau Cloud.
• Par conséquent, les mesures et le reporting de l’espace et de la compression sont gérés indépendamment dans chaque niveau.
• Mais au niveau du fichier, aucune différenciation n’est faite par niveau et les statistiques de compression à la volée sont exactement les mêmes que celles décrites dans la section 3.1.

Déduplication:

Le dernier point à souligner concerne certaines caractéristiques de la déduplication, appelée « compression globale » dans de nombreux articles Data Domain.

Bien qu’il contienne le mot « compression », il est totalement différent du concept traditionnel de compression, qui est également fourni par DDOS sous le nom de « compression locale ».

• La compression locale réduit la taille d’un élément de données à l’aide d’un certain algorithme (certains types de données ne sont pas compressibles et l’application d’algorithmes de compression sur ceux-ci peut légèrement augmenter la taille des données).
• Habituellement, une fois qu’un algorithme est décidé, les données sont le seul facteur du taux de compression.
• Toutefois, la déduplication est différente : il ne s’agit pas d’un concept local, mais d’un concept « global ».
• Un segment de données entrant est dédupliqué par rapport à tous les segments de données existants dans un domaine dédupliqué, qui inclut toutes les données des systèmes Data Domain non cloud.
• Le segment de données lui-même n’a pas d’importance dans la procédure de déduplication.
• En pratique, il est rare d’observer un taux de déduplication élevé lors de la sauvegarde initiale d’un jeu de données. Dans les sauvegardes initiales, la réduction majeure des données provient souvent de la compression locale.
• Lorsque les sauvegardes suivantes atterrissent sur le système Data Domain, la déduplication montre sa puissance et devient le facteur de compression dominant.
• L’efficacité de la déduplication repose sur le fait que le taux de modification d’un jeu de données est faible d’une sauvegarde à l’autre. Pour cette raison, les jeux de données avec des taux de modification élevés ne peuvent pas être correctement dédupliqués.
• Lorsque l’application de sauvegarde insère ses propres fragments de métadonnées (appelés marqueurs par Data Domain) dans les images de sauvegarde à haute fréquence, elle risque également de ne pas obtenir un bon taux de déduplication. Nos techniques de manipulation des marqueurs peuvent parfois aider, mais pas toujours.

À la lumière de ces observations, à quoi s’attendre :

• Les sauvegardes initiales peuvent n’atteindre qu’un faible taux de compression effectif du système, souvent 2 ou 3 fois. La déduplication a généralement peu d’occasions de montrer sa puissance lors des sauvegardes initiales.
• Le taux de compression global d’une sauvegarde incrémentielle est inférieur au taux de compression de la sauvegarde complète correspondante. Cela est dû au fait qu’une sauvegarde incrémentielle contient uniquement des fichiers modifiés ou nouveaux par rapport à la sauvegarde immédiate antérieure. Le taux de compression global dépend du pourcentage de nouvelles données au sein de la sauvegarde incrémentielle.
• Le taux de déduplication d’une sauvegarde complète (les sauvegardes non initiales) peut également être faible dans certains scénarios. Voici quelques scénarios fréquemment observés :
  • Taux de modification élevé des données sauvegardées
  • Le jeu de données est dominé par de petits fichiers (moins de 5 Mio)
  • Applications de sauvegarde ajoutant un grand nombre de marqueurs rapprochés
  • Sauvegardes de base de données incrémentielles ou utilisant des blocs de petite taille
  • Lorsqu’un taux de compression faible est observé dans une sauvegarde complète avec un faible taux de modification des données, vérifiez si l’un des cas ci-dessus s’applique ou si une analyse plus approfondie est nécessaire.
• La compression d’une image de sauvegarde ultérieure n’est pas toujours meilleure que la compression initiale. Les images de sauvegarde consécutives peuvent afficher un taux de déduplication élevé, car les images de sauvegarde initiales et antérieures ont déjà ajouté la plupart des données au système. Lorsque toutes les premières images de sauvegarde sont supprimées, le taux de compression global et local de la première image de sauvegarde existante peut encore être élevé, mais cela signifie uniquement qu’elle a obtenu une bonne déduplication lorsqu’elle a été ajoutée au système, rien d’autre. Lorsqu’un fichier supprimé qui a un taux de compression global et local élevé et qui est la dernière image de sauvegarde d’un jeu de données particulier, il peut libérer plus d’espace que la taille dérivée du taux de compression.
• Les taux de compression d’un même jeu de données sur différents systèmes ne peuvent pas être comparés, quelle que soit la façon dont le jeu de données est ajouté à ces systèmes. En effet, chaque système est un domaine de déduplication indépendant. On ne s’attend pas à ce que deux DD obtiennent des taux de compression identiques, voire nécessairement similaires, même si leurs jeux de données sont identiques.

Résumé :

• Il est difficile de mesurer la compression dans les systèmes de fichiers dédupliqués, mais c’est encore plus difficile dans les systèmes de fichiers dédupliqués structurés en logs.
• Il faut comprendre le fonctionnement de la déduplication et le suivi des statistiques de compression.
• Les taux de compression sont des informations utiles pour comprendre le comportement d’un système particulier.
• Le taux de compression effectif du système est la mesure la plus importante, la plus fiable et la plus informative.
• Les statistiques de compression à la volée peuvent également être utiles, mais elles peuvent n’être rien de plus qu’une heuristique dans certaines circonstances.

Annexe :

Exemple de sortie de "mtree show compression" .

• Supposons qu’il existe un MTree contenant 254792.4 Gio de données. Il a reçu 4 379,3 Gio de nouvelles données au cours des 7 derniers jours et 78,4 Gio au cours des dernières 24 heures (d’autres intervalles de temps peuvent être spécifiés).
• L’option « daily » signale les statistiques de compression au fil de l’eau pour les 33 derniers jours.
• Lorsque l’option « daily-detailed » est fournie, les taux de compression totaux sont détaillés en les séparant en taux de compression global et local.

La commande mtree Liste de sortie :

mtree list /data/col1/main 

Name              Pre-Comp (GiB)   Status
---------------   --------------   ------
/data/col1/main         254792.4   RW
---------------   --------------   ------
 D    : Deleted
 Q    : Quota Defined
 RO   : Read Only
 RW   : Read Write
 RD   : Replication Destination
 IRH  : Retention-Lock Indefinite Retention Hold Enabled
 ARL  : Automatic-Retention-Lock Enabled
 RLGE : Retention-Lock Governance Enabled
 RLGD : Retention-Lock Governance Disabled
 RLCE : Retention-Lock Compliance Enabled
 M    : Mobile
 m    : Migratable

MSC (pas d’options) :

mtree show compression /data/col1/main

From: 2023-09-07 12:00 To: 2023-09-14 12:00

                Pre-Comp   Post-Comp   Global-Comp   Local-Comp      Total-Comp
                   (GiB)       (GiB)        Factor       Factor          Factor
                                                                  (Reduction %)
-------------   --------   ---------   -----------   ----------   -------------
Written:
  Last 7 days     4379.3       883.2          3.4x         1.5x     5.0x (79.8)
  Last 24 hrs      784.6       162.1          3.3x         1.4x     4.8x (79.3)
-------------   --------   ---------   -----------   ----------   -------------

Avec l’option « tous les jours » :

mtree show compression /data/col1/main daily

From: 2023-08-12 12:00 To: 2023-09-14 12:00

  Sun     Mon     Tue     Wed     Thu     Fri     Sat   Weekly
-----   -----   -----   -----   -----   -----   -----   ------   -----------------
 -13-    -14-    -15-    -16-    -17-    -18-    -19-            Date
432.0   405.9   284.1   438.8   347.0   272.7   331.4   2511.8   Pre-Comp
 85.5    66.2    45.3    81.9    61.4    57.4    66.3    464.1   Post-Comp
 5.0x    6.1x    6.3x    5.4x    5.7x    4.7x    5.0x     5.4x   Total-Comp Factor

 -20-    -21-    -22-    -23-    -24-    -25-    -26-
478.0   387.8   450.2   533.1   386.0   258.4   393.6   2887.1
100.6    81.5   100.8   119.0    84.0    40.6    75.3    601.8
 4.8x    4.8x    4.5x    4.5x    4.6x    6.4x    5.2x     4.8x

 -27-    -28-    -29-    -30-    -31-     -1-     -2-
 27.6     1.0     0.4   470.7   467.3   517.7   641.9   2126.7
  4.9     0.2     0.1    83.9    92.3    89.8   140.1    411.2
 5.6x    5.6x    4.3x    5.6x    5.1x    5.8x    4.6x     5.2x

  -3-     -4-     -5-     -6-     -7-     -8-     -9-
539.6   495.0   652.8   658.7   537.1   398.7   305.5   3587.3 
110.8   108.0   139.4   137.0   111.5    78.3    48.3    733.3 
 4.9x    4.6x    4.7x    4.8x    4.8x    5.1x    6.3x     4.9x 

 -10-    -11-    -12-    -13-    -14-   
660.2   738.3   787.2   672.9   796.9                   3655.5
143.9   152.5   167.6   126.9   163.3                    754.2 
 4.6x    4.8x    4.7x    5.3x    4.9x                     4.8x 
-----   -----   -----   -----   -----   -----   -----   ------   -----------------
                 Pre-Comp   Post-Comp   Global-Comp   Local-Comp      Total-Comp
                    (GiB)       (GiB)        Factor       Factor          Factor
                                                                   (Reduction %)
--------------   --------   ---------   -----------   ----------   -------------
Written:
  Last 33 days    14768.3      2964.5          3.4x         1.5x     5.0x (79.9)
  Last 24 hrs       784.6       162.1          3.3x         1.4x     4.8x (79.3)
--------------   --------   ---------   -----------   ----------   -------------

Key:
       Pre-Comp = Data written before compression
       Post-Comp = Storage used after compression
       Global-Comp Factor = Pre-Comp / (Size after de-dupe)
       Local-Comp Factor = (Size after de-dupe) / Post-Comp
       Total-Comp Factor = Pre-Comp / Post-Comp
       Reduction % = ((Pre-Comp - Post-Comp) / Pre-Comp) * 100

Avec l’option « détaillée au quotidien » :

mtree show compression /data/col1/main daily-detailed 

From: 2023-08-12 12:00 To: 2023-09-14 12:00

  Sun     Mon     Tue     Wed     Thu    Fri     Sat    Weekly
-----   -----   -----   -----   -----   -----   -----   ------   -----------------
 -13-    -14-    -15-    -16-    -17-    -18-    -19-            Date
432.0   405.9   284.1   438.8   347.0   272.7   331.4   2511.8   Pre-Comp
 85.5    66.2    45.3    81.9    61.4    57.4    66.3    464.1   Post-Comp
 3.5x    4.1x    4.3x    3.6x    3.8x    3.3x    3.4x     3.7x   Global-Comp Factor
 1.4x    1.5x    1.5x    1.5x    1.5x    1.4x    1.5x     1.5x   Local-Comp Factor
 5.0x    6.1x    6.3x    5.4x    5.7x    4.7x    5.0x     5.4x   Total-Comp Factor
 80.2    83.7    84.1    81.3    82.3    78.9    80.0     81.5   Reduction %

 -20-    -21-    -22-    -23-    -24-    -25-    -26-
478.0   387.8   450.2   533.1   386.0   258.4   393.6   2887.1
100.6    81.5   100.8   119.0    84.0    40.6    75.3    601.8
 3.3x    3.3x    3.0x    3.0x    3.3x    4.1x    3.6x     3.3x 
 1.4x    1.5x    1.5x    1.5x    1.4x    1.5x    1.4x     1.5x 
 4.8x    4.8x    4.5x    4.5x    4.6x    6.4x    5.2x     4.8x
 79.0    79.0    77.6    77.7    78.2    84.3    80.9     79.2

 -27-    -28-    -29-    -30-    -31-    -1-     -2-
 27.6     1.0     0.4   470.7   467.3   517.7   641.9   2126.7
  4.9     0.2     0.1    83.9    92.3    89.8   140.1    411.2
 4.4x    3.7x    2.6x    3.8x    3.5x    3.9x    3.2x     3.5x 
 1.3x    1.5x    1.6x    1.5x    1.4x    1.5x    1.5x     1.5x
 5.6x    5.6x    4.3x    5.6x    5.1x    5.8x    4.6x     5.2x
 82.1    82.2    76.8    82.2    80.3    82.7    78.2     80.7

  -3-     -4-     -5-     -6-     -7-    -8-     -9-
539.6   495.0   652.8   658.7   537.1   398.7   305.5   3587.3 
110.8   108.0   139.4   137.0   111.5    78.3    48.3    733.3 
 3.4x    3.1x    3.2x    3.4x    3.3x    3.4x    4.1x     3.3x 
 1.4x    1.5x    1.5x    1.4x    1.4x    1.5x    1.6x     1.5x
 4.9x    4.6x    4.7x    4.8x    4.8x    5.1x    6.3x     4.9x 
 79.5    78.2    78.6    79.2    79.2    80.4    84.2     79.6

 -10-    -11-    -12-    -13-    -14-   
660.2   738.3   787.2   672.9   796.9                   3655.5
143.9   152.5   167.6   126.9   163.3                    754.2
 3.1x    3.4x    3.2x    3.7x    3.4x                      .3x 
 1.5x    1.4x    1.5x    1.4x    1.5x                     1.5x
 4.6x    4.8x    4.7x    5.3x    4.9x                     4.8x
 78.2    79.3    78.7    81.1    79.5                     79.4
-----   -----   -----   -----   -----   -----   -----   ------   -----------------
                 Pre-Comp   Post-Comp   Global-Comp   Local-Comp      Total-Comp
                    (GiB)       (GiB)        Factor       Factor          Factor
                                                                   (Reduction %)
--------------   --------   ---------   -----------   ----------   -------------
Written:
  Last 33 days    14768.3      2964.5          3.4x         1.5x     5.0x (79.9)
  Last 24 hrs       784.6       162.1          3.3x         1.4x     4.8x (79.3)
--------------   --------   ---------   -----------   ----------   -------------

Key:
       Pre-Comp = Data written before compression
       Post-Comp = Storage used after compression
       Global-Comp Factor = Pre-Comp / (Size after de-dupe)
       Local-Comp Factor = (Size after de-dupe) / Post-Comp
       Total-Comp Factor = Pre-Comp / Post-Comp
       Reduction % = ((Pre-Comp - Post-Comp) / Pre-Comp) * 100