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 client. Par conséquent, les technologies et les mesures des niveaux de compression sont des sujets complexes. Ce document traite de certaines terminologies, compromis et mesures afin de mieux expliquer les types de compression utilisés, la terminologie et d’autres aspects de la compression dans un système Data Domain.
S’APPLIQUE À :
Tous les modèles Data Domain
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), nous procédons à la déduplication et à la compression locale pour compresser les données utilisateur. La 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, il y a beaucoup d’aspects que nous pouvons mesurer. Dans ce document, nous abordons les détails étape par étape pour vous aider à comprendre la compression DDOS. Dans un premier temps, nous expliquons l’effet global de la compression du système, qui 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 de ces données. Ce taux est appelé « taux de compression effectif du système » dans ce document. 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. De plus, DDOS assure le suivi des statistiques à différents niveaux ; fichiers, MTrees et l’ensemble du système.
Le contenu de ce document peut s’appliquer à toutes les versions de DDOS jusqu’à sa publication, jusqu’à DDOS 7.13. 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 n’a qu’une seule structure mtree et le terme mtree n’est pas explicitement défini.
L’effet global de la compression à l’échelle du système est mesuré par le taux de compression effectif du système, qui est le rapport entre la taille des données utilisateur et la taille de l’espace physique utilisé. Il est signalé par la commande CLI filesys show compression (FSC) (les informations correspondantes sont également disponibles dans l’interface utilisateur). Vous trouverez ci-dessous un exemple de sortie FSC :
# 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 valeurs. Ces deux nombres sont mesurés de la même manière que la commande « filesys show space ».
Taux de compression effectif du système = Pre-Comp/Post-Comp
Le reste de la sortie FSC décrit les statistiques de compression à la volée, et nous en discuterons plus tard.
Certaines opérations peuvent affecter le taux de compression effectif du système :
Copie rapide
Lorsqu’une fastcopy est effectuée à 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. FastCopy a pour effet d’augmenter la taille des données utilisateur sans consommer d’espace physique supplémentaire. Cela augmente le taux de compression effectif du système. Lorsque de nombreuses copies rapides sont effectuées, 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 la copie rapide.
Remplace
Les écrasements consomment plus d’espace physique, mais n’augmentent pas la taille logique du jeu de données, ce qui réduit 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
Lorsque nous prenons un snapshot d’une structure Mtree, nous ne modifions pas la taille logique du jeu de données. 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 qui est encore nécessaire pour les snapshots ; Par conséquent, le fait d’avoir un grand nombre de snapshots peut faire paraître le taux de compression effectif du système faible. Toutefois, les snapshots sont des fonctions de récupération en cas de panne utiles. Il ne faut jamais hésiter à prendre des snapshots ou à configurer des plannings de snapshots appropriés en cas de besoin.
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 au niveau de la structure MTree et au niveau du système. La compression est mesurée à partir de trois chiffres dans les statistiques en ligne :
Sur la base des trois chiffres ci-dessus, DDOS définit deux autres taux de compression à granularité fine :
Les statistiques de compression au fil de l’eau accumulées font partie des métadonnées de fichier dans DDOS et sont stockées dans l’inode de fichier. DDOS fournit des outils pour vérifier les compressions à la volée aux trois niveaux ; fichier, MTree et à l’échelle du système. Nous les détaillons dans les sections suivantes.
3.1 Compression des fichiers La
compression des fichiers peut être vérifiée à l’aide de la commande CLI « filesys show compression <path> », qui signale les statistiques de compression cumulées stockées dans l’inode de fichier. 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 la CLI, raw_bytes est étiqueté comme « Original Bytes » ; pre_lc_size est étiqueté comme « Globalement compressé » ; post_lc_bytes est marqué comme « Localement compressé » ; les autres frais généraux sont signalés en tant que « métadonnées ». Les deux exemples sont extraits d’un DD réel :
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 « octets/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. En effet, les valeurs de 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 fichier sample.file est sauvegardé sur un Data Domain et que, lors de la première sauvegarde, les informations de compression du fichier sont 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 bénéficie d’une déduplication idéale, de sorte que pre_lc_size et post_lc_size soient nuls, 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, les pre_lc_size et post_lc_size du fichier de la deuxième sauvegarde doivent ê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 de remplacements, la 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 ».
3.2 Compression
de la structure MTreeNous pouvons vérifier la compression d’une MTree particulière avec la commande "mtree show compression" (MSC) Commande CLI. Les valeurs absolues des statistiques de compression à la volée sont cumulatives tout au long de la durée de vie de la structure MTree. Étant donné que la durée de vie d’une structure MTree peut durer plusieurs années, ces valeurs deviennent de moins en moins informatives au fil du temps. Pour résoudre ce problème, nous utilisons la quantité de changement (deltas) des statistiques de compression à la volée et rapportons la compression uniquement pour certains intervalles de temps. L’approche sous-jacente consiste à vider régulièrement les statistiques de compression à la volée de la structure MTree dans un log. Lorsqu’un client interroge la compression MTree avec la commande MSC, nous utilisons le log pour calculer les écarts des nombres pour la création de rapports de compression. Par défaut, MSC signale la compression pour les 7 derniers jours et les dernières 24 heures, bien qu’une période d’intérêt puisse être spécifiée à tout moment.
Pour effectuer la démonstration, utilisez le log suivant pour la structure MTree A :
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 la structure MTree A pour cette heure est la suivante :
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 « daily » et « daily-detailed », tout comme la commande « filesys show compression ». Lorsque « daily » est spécifié, la commande signale la compression quotidienne selon un calendrier. Elle utilise les nombres deltas quotidiens de raw_bytes et de post_lc_size pour calculer le taux de compression quotidien. Lorsque « daily-detailed » est spécifié, la commande affiche les trois deltas (des raw_bytes, pre_lc_size et post_lc_size, respectivement) pour chaque jour ; Il calcule également le g_comp et le l_comp ainsi que le facteur de compression total.
Des exemples de résultats de ces systèmes sont présentés dans l’annexe.
3.3 Compression
du systèmeUne fois que nous avons compris comment la compression est signalée sur les structures MTree, 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 les structures MTree. La seule différence est le champ d’application : l’un se trouve dans une structure MTree particulière tandis que l’autre se trouve sur l’ensemble du système. Les résultats peuvent être vérifiés à l’aide de la commande « filesys show compression ». Vous trouverez un exemple dans la section 2. Les compressions du système « 7 derniers jours » et « dernières 24 heures » sont indiquées dans les deux dernières lignes de la section des résultats de la sortie FSC.
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 des fichiers, nous ne faisons pas de différence par niveau et rapportons des statistiques de compression à la volée ; ils sont exactement les mêmes que ceux que nous avons décrits à la section 3.1.
Le dernier point à souligner concerne certaines caractéristiques de la déduplication, appelée « compression globale » dans de nombreux documents 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 elles-mêmes 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, nous constatons rarement 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.
Compte tenu de ces observations, à quoi peut-on s’attendre ?
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. Nous devons comprendre comment fonctionne la déduplication et comment les statistiques de compression sont suivies. 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" commande
Supposons qu’il existe une structure MTree contenant 254 792,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.
Sortie de la liste de structures MTree :
# 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
# 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