Die in einer Data Domain verwendeten Komprimierungstechniken nutzen modernste Techniken, um den physischen Speicherplatzbedarf für Kundendaten zu reduzieren. Daher sind die Technologien und Messungen der Komprimierungsstufen komplexe Themen. In diesem Dokument werden einige der Terminologien, Kompromisse und Maßnahmen erläutert, um die verwendeten Komprimierungstypen, die Terminologie und andere Aspekte der Komprimierung in einem Data Domain-System besser zu erläutern.
GILT FÜR:
Alle Data Domain-Modelle
Letzte Aktualisierung: Januar 2024
Die Komprimierung ist eine Datenreduzierungstechnologie, die darauf abzielt, ein Datenvolumen mit weniger physischem Speicherplatz zu speichern. In Data Domain-Systemen (DDOS) führen wir Deduplizierung und lokale Komprimierung durch, um Nutzerdaten zu komprimieren. Die Deduplizierung oder „dedupe“ wird verwendet, um redundante Datensegmente zu identifizieren und nur eindeutige Datensegmente zu speichern. Bei der lokalen Komprimierung werden die eindeutigen Datensegmente mit bestimmten Komprimierungsalgorithmen weiter komprimiert, z. B. lz, gzfast, gz, und so weiter. Die allgemeine Nutzerdatenkomprimierung in DDOS ist die gemeinsame Anstrengung von Deduplizierung und lokaler Komprimierung. DDOS verwendet das Komprimierungsverhältnis, um die Effektivität der Datenkomprimierung zu messen. Im Allgemeinen handelt es sich um das Verhältnis der Gesamtgröße der Nutzerdaten zur Gesamtgröße der komprimierten Daten oder des verwendeten physischen Speicherplatzes.
Das Data Domain-Dateisystem ist ein "protokollstrukturiertes" Deduplizierungsdateisystem. Ein protokollstrukturiertes Dateisystem hängt nur Daten an das System an und durch Löschen allein kann kein physischer Speicherplatz freigegeben werden. Solche Dateisysteme verlassen sich auf die automatische Speicherbereinigung, um nicht mehr benötigten Speicherplatz zurückzugewinnen. Die Kombination der Merkmale des protokollstrukturierten Dateisystems und der deduplizierten Technologie macht es schwierig, alle Aspekte der Komprimierung in DDOS klar zu verstehen.
Bei der Komprimierung gibt es viele Aspekte, die wir messen können. In diesem Dokument werden die Details Schritt für Schritt erläutert, um die DDOS-Komprimierung zu verstehen. Zunächst erläutern wir den Komprimierungseffekt des gesamten Systems, der uns die realistische Komprimierung in einem Data Domain-System angibt, die Menge der Nutzerdaten, die Menge des verbrauchten physischen Speicherplatzes und das Verhältnis davon. Dieses Verhältnis wird in diesem Dokument als "effektives Systemkomprimierungsverhältnis" bezeichnet. DDOS führt eine Inline-Deduplizierung durch und verfolgt die Statistiken der ursprünglichen Nutzerdatensegmente, eindeutiger Datensegmente nach der Deduplizierung und den lokalen Komprimierungseffekt auf die eindeutigen Datensegmente. Diese Inline-Komprimierungsstatistiken werden verwendet, um den Inline-Komprimierungseffekt zu messen. Inline-Komprimierungsstatistiken können für jeden Schreibvorgang gemessen werden. Außerdem verfolgt DDOS die Statistiken auf verschiedenen Ebenen. Dateien, MTrees und das gesamte System.
Der Inhalt dieses Dokuments kann bis zur Veröffentlichung auf alle DDOS-Versionen angewendet werden, bis zu DDOS 7.13. Es gibt keine Garantie dafür, dass alle Inhalte für zukünftige Versionen korrekt sind. In Versionen vor 5.0 verfügt das gesamte System nur über einen MTree und der Begriff MTree wird nicht explizit erwähnt.
Der systemweite Komprimierungseffekt wird anhand des effektiven Komprimierungsverhältnisses des Systems gemessen, bei dem es sich um das Verhältnis der Nutzerdatengröße zur Größe des verwendeten physischen Speicherplatzes handelt. Sie wird vom FSC-CLI-Befehl (filesys show compression) gemeldet (die entsprechenden Informationen sind auch auf der Benutzeroberfläche verfügbar). Ein Beispiel für eine FSC-Ausgabe ist unten dargestellt:
# 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.
Das effektive Komprimierungsverhältnis des Systems wird in Zeile 1 des Ergebnisabschnitts in der CLI-Ausgabe gemeldet. Die Zeile ist oben hervorgehoben. Die Gesamtgröße der Nutzerdaten wird als "Pre-Comp" bezeichnet. Der gesamte belegte physische Speicherplatz (sowohl von Daten als auch von Metadaten) wird als "Post-Comp" bezeichnet.
Die "Pre-Comp"-Nummer und die "Post-Comp"-Nummer werden beide zur Laufzeit gelesen. FSC synchronisiert implizit das gesamte System und fragt dann die beiden Zahlen ab. Diese beiden Zahlen werden auf die gleiche Weise gemessen wie der Befehl "filesys show space".
Effektives Systemkomprimierungsverhältnis = Pre-Comp/Post-Comp
Der Rest der FSC-Ausgabe beschreibt die Inline-Komprimierungsstatistiken, auf die wir später noch eingehen werden.
Es gibt einige Vorgänge, die sich auf das effektive Komprimierungsverhältnis des Systems auswirken können:
Fastcopy
Wenn eine Fastcopy-Kopie von einer Datei im aktiven Namespace (nicht von einem Snapshot) durchgeführt wird, handelt es sich um eine perfekte Deduplizierung, da kein zusätzlicher physischer Speicherplatz für die Zieldatei benötigt wird. Der Effekt von Fastcopy ist, dass wir die Größe der Nutzerdaten erhöhen, ohne zusätzlichen physischen Speicherplatz zu verbrauchen. Dadurch erhöht sich das effektive Komprimierungsverhältnis des Systems. Wenn viele Fastcopies erstellt werden, kann das effektive Komprimierungsverhältnis des Systems künstlich hoch werden.
Virtuelle synthetische Backups
Virtuelle synthetische Backups weisen in der Regel ein hohes effektives Komprimierungsverhältnis im System auf. Dies liegt daran, dass virtuelle synthetische Backups logische vollständige Backups durchführen, aber nur geänderte oder neue Daten an Data Domain-Systeme übertragen. Die Auswirkung auf das effektive Komprimierungsverhältnis des Systems von virtuellen synthetischen Backups ähnelt in etwa dem Effekt von FastCopy.
Überschreibt
Überschreiben verbrauchen mehr physischen Speicherplatz, erhöhen jedoch nicht die logische Größe des Datenvolumens, sodass Überschreibungen das effektive Komprimierungsverhältnis des Systems verringern.
Speichern von Dateien mit geringer Datendichte
Dateien mit geringer Datendichte enthalten große „Löcher“, die in der logischen Größe gezählt werden, aber aufgrund der Komprimierung keinen physischen Speicherplatz belegen. Infolgedessen können sie das effektive Komprimierungsverhältnis des Systems hoch wirken lassen.
Speichern kleiner Dateien
DDOS fügt fast 1 KB Overhead zu jeder Datei für bestimmte interne Metadaten hinzu. Wenn ein System eine beträchtliche Anzahl kleiner Dateien speichert (Größen unter 1 KB oder in einstelligen Kilobyte), zieht der Overhead von Metadaten das effektive Komprimierungsverhältnis nach unten.
Speichern vorkomprimierter oder verschlüsselter Dateien
Komprimierung und Verschlüsselung können den Umfang der Datenänderungen verstärken und die Möglichkeit einer Deduplizierung verringern. Solche Dateien können in der Regel nicht gut dedupliziert werden und senken das effektive Komprimierungsverhältnis des Systems.
Löscht
Durch Löschungen wird die logische Größe des Systems reduziert, aber das System erhält erst dann den entsprechenden ungenutzten Speicherplatz zurück, wenn die automatische Speicherbereinigung ausgeführt wird. Bei vielen gelöschten Dateien ist das Komprimierungsverhältnis niedrig, bis die automatische Speicherbereinigung (GC) ausgeführt wird.
Garbage Collection (GC) oder Bereinigung
GC gewinnt den Speicherplatz zurück, der von Datensegmenten belegt wird, die von keiner Datei mehr erkannt werden. Wenn viele Dateien kürzlich gelöscht wurden, kann die automatische Speicherbereinigung das Komprimierungsverhältnis des Systems erhöhen, indem der Speicherplatzverbrauch reduziert wird.
Aggressives Erstellen von Snapshots
Wenn wir einen Snapshot eines MTree erstellen, wird die logische Größe des Datenvolumens nicht geändert. Allerdings müssen alle Datensegmente, die vom Snapshot referenziert werden, gesperrt werden, selbst wenn alle vom Snapshot erfassten Dateien gelöscht werden, nachdem der Snapshot erstellt wurde. GC kann den Speicherplatz, der noch von Snapshots benötigt wird, nicht zurückgewinnen. Aus diesem Grund kann das effektive Komprimierungsverhältnis des Systems durch viele Snapshots niedrig erscheinen. Snapshots sind jedoch nützliche Funktionen für die Wiederherstellung nach einem Absturz. Wir sollten niemals zögern, Snapshots zu erstellen oder die richtigen Snapshot-Zeitpläne nach Bedarf einzurichten.
DDOS führt die Deduplizierung inline durch, wenn Daten in das System geschrieben werden. Es verfolgt die Auswirkungen der Inline-Deduplizierung und der lokalen Komprimierung für jeden Schreibvorgang und sammelt die Statistiken auf Dateiebene. Die Inline-Komprimierungsstatistiken pro Datei werden auf MTree-Ebene und auf Systemebene weiter aggregiert. Die Komprimierung wird basierend auf drei Zahlen in den Inline-Statistiken gemessen:
Basierend auf den obigen drei Zahlen definiert DDOS zwei weitere Komprimierungsverhältnisse mit feiner Granularität:
Die gesammelten Inline-Komprimierungsstatistiken sind Teil der Dateimetadaten in DDOS und werden im Datei-Inode gespeichert. DDOS bietet Tools zur Überprüfung der Inline-Komprimierung auf allen drei Ebenen. Datei, MTree und systemweit. Wir beschreiben sie in den folgenden Abschnitten.
3.1 Dateikomprimierung
Die Dateikomprimierung kann mit dem CLI-Befehl "filesys show compression <path>" überprüft werden, der die im Datei-Inode gespeicherten komprimierten Komprimierungsstatistiken meldet. Wenn ein Verzeichnis angegeben wird, werden die Inline-Komprimierungsstatistiken aller Dateien in diesem Verzeichnis summiert und gemeldet. In der CLI-Ausgabe wird raw_bytes als "Original Bytes" bezeichnet. pre_lc_size wird als "Global komprimiert" bezeichnet. post_lc_bytes ist als "Lokal komprimiert" gekennzeichnet. Die anderen Gemeinkosten werden als "Metadaten" gemeldet. Die beiden Beispiele stammen aus einem tatsächlichen DD:
Beispiel 1: Inline-Komprimierungsstatistiken einer Datei
# 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
Beispiel 2: Inline-Komprimierungsstatistiken für alle Dateien in einem Verzeichnis, einschließlich aller Unterverzeichnisse
# 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
Das System meldet das gesamte Inline-Komprimierungsverhältnis in der obigen CLI-Ausgabe als "Byte/storage_used". Bei der Interpretation der oben genannten Informationen ist jedoch Vorsicht geboten, da sie aus verschiedenen Gründen irreführend sein können. Ein Grund dafür ist, dass pre_lc_size und post_lc_size zum Zeitpunkt der Datenverarbeitung aufgezeichnet werden. Wenn die Datei, die diese Segmente ursprünglich hinzugefügt hat, gelöscht wird, sollte die Anzahl der eindeutigen Datensegmente in der verbleibenden Datei erhöht werden.
Angenommen, eine Datei sample.file wird auf einer Data Domain gesichert und im ersten Backup sind die Komprimierungsinformationen der Datei pre_lc_size = 10 GiB, post_lc_size = 5 Gib.
Nehmen Sie als Nächstes an, dass die Daten dieser Datei eindeutig sind und nicht mit einer anderen Datei geteilt werden. Gehen Sie außerdem davon aus, dass die Datei beim zweiten Backup der Datei eine ideale Deduplizierung erhält, sodass sowohl pre_lc_size als auch post_lc_size Null sein sollten, da alle Segmente der Datei bereits auf dem System vorhanden waren. Wenn das erste Backup gelöscht wird, ist das zweite Backup der Datei die einzige Datei, die die 5 GiB an Datensegmenten referenziert. In diesem Fall sollten idealerweise die pre_lc_size und post_lc_size der Datei im zweiten Backup von null auf 10 GiB bzw. 5 GiB aktualisiert werden. Es gibt jedoch keine Möglichkeit zu erkennen, für welche Dateien dies getan werden sollte, sodass die Inline-Komprimierungsstatistiken der vorhandenen Dateien unverändert bleiben.
Ein weiterer Faktor, der sich auf die oben genannten Zahlen auswirkt, sind die kumulierten Statistiken. Wenn eine Datei häufig überschrieben wird, kann nicht nachverfolgt werden, inwieweit die kumulativen Statistiken die Schreibvorgänge widerspiegeln, die die Live-Daten eingeführt haben. Daher können die Inline-Komprimierungsstatistiken über einen langen Zeitraum nur als Heuristik behandelt werden, um die Komprimierung einer bestimmten Datei grob abzuschätzen.
Eine weitere erwähnenswerte Tatsache ist, dass die Inline-Komprimierung einer Datei nicht für ein beliebiges Zeitintervall gemessen werden kann. Die Datei-Inline-Komprimierungsstatistiken sind ein kumulatives Ergebnis und decken alle Schreibvorgänge ab, die die Datei jemals erhalten hat. Wenn eine Datei häufig überschrieben wird, kann die raw_bytes die logische Größe der Datei erheblich überschreiten. Bei Dateien mit geringer Datendichte können die Dateigrößen größer als die ursprünglichen Bytes sein.
3.2 MTree-Komprimierung
Wir können die Komprimierung eines bestimmten MTree mit dem Befehl "mtree show compression" (MSC) CLI-Befehl. Die absoluten Werte der Inline-Komprimierungsstatistiken sind über die Lebensdauer des MTree kumulativ. Da die Lebensdauer eines MTree viele Jahre lang sein kann, verlieren diese Werte mit der Zeit an Aussagekraft. Um dieses Problem zu beheben, verwenden wir die Menge der Änderungen (Deltas) der Inline-Komprimierungsstatistiken und melden die Komprimierung nur für bestimmte Zeitintervalle an. Der zugrunde liegende Ansatz besteht darin, dass wir die MTree-Inline-Komprimierungsstatistiken in regelmäßigen Abständen in einem Protokoll speichern. Wenn ein Client die MTree-Komprimierung mit dem MSC-Befehl abfragt, wird das Protokoll verwendet, um die Deltas der Zahlen für das Komprimierungsreporting zu berechnen. Standardmäßig meldet MSC die Komprimierung für die letzten 7 Tage und die letzten 24 Stunden, obwohl ein beliebiger Zeitraum von Interesse angegeben werden kann.
Gehen Sie zur Veranschaulichung vom folgenden Protokoll für MTree A aus:
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
Dann ist die Komprimierung von MTree A für diese Stunde:
g_comp = (12000-11000)/(200-100) = 10x l_comp = (200-100)/(100-50) = 2x overall compression ratio = (12000-11000)/(100-50) = 20x
Die obige Berechnung des Komprimierungsverhältnisses hat keine Auswirkungen auf die Größe des Datenvolumens. Beispielsweise kann der obige MTree nur 500 GB logische Daten enthalten.
MSC unterstützt die Optionen "daily" und "daily-detailed" sowie den Befehl "filesys show compression". Wenn "daily" angegeben ist, meldet der Befehl die tägliche Komprimierung kalenderweise. Sie verwendet die täglichen Deltas der raw_bytes und post_lc_size, um das tägliche Komprimierungsverhältnis zu berechnen. Wenn "daily-detailed" angegeben ist, zeigt der Befehl alle drei Deltas (der raw_bytes, pre_lc_size bzw. post_lc_size) für jeden Tag an. Außerdem werden neben dem Gesamtkomprimierungsfaktor auch der g_comp und der l_comp berechnet.
Beispiele für die Ausgabe dieser Systeme finden Sie im Anhang.
3.3 Systemkomprimierung
Sobald wir wissen, wie die Komprimierung auf MTrees gemeldet wird, können wir das Konzept ganz einfach auf das gesamte System ausweiten. Die systemweite Erfassung von Inline-Statistiken für die Komprimierung und das Reporting sind identisch mit MTrees. Der einzige Unterschied ist der Umfang, da sich der eine in einem bestimmten MTree befindet, während sich der eine über das gesamte System erstreckt. Die Ergebnisse können mit dem Befehl "filesys show compression" überprüft werden. Ein Beispiel hierfür finden Sie in Abschnitt 2. Die Systemkomprimierung "letzte 7 Tage" und "letzte 24 Stunden" wird in den letzten beiden Zeilen des Ergebnisabschnitts in der FSC-Ausgabe gemeldet.
Auf DDs mit Cloud-Tier wird der Speicher in den aktiven Tier und den Cloud-Tier getrennt, die zwei unabhängige Deduplizierungsdomains sind. Nutzer können Daten nur in den aktiven Tier einfügen. Später können DDOS-Datenverschiebungsfunktionen verwendet werden, um Daten vom aktiven Tier zum Cloud-Tier zu migrieren. Somit werden die Raum- und Druckmessung und -berichterstattung in jeder Ebene unabhängig voneinander durchgeführt. Auf Dateiebene unterscheiden wir jedoch nicht nach Tier und melden keine Inline-Komprimierungsstatistiken. sie sind genau die gleichen wie das, was wir in Abschnitt 3.1 beschrieben haben.
Das letzte Thema, das hervorgehoben werden soll, sind einige Merkmale der Deduplizierung, die in vielen Data Domain-Dokumenten als "globale Komprimierung" bezeichnet wird. Obwohl es das Wort "Komprimierung" enthält, unterscheidet es sich grundlegend vom traditionellen Konzept der Komprimierung, das auch von DDOS unter dem Namen "lokale Komprimierung" bereitgestellt wird.
Die lokale Komprimierung reduziert die Größe eines Datenelements mithilfe eines bestimmten Algorithmus (einige Arten von Daten sind nicht komprimierbar und die Anwendung von Komprimierungsalgorithmen auf sie kann die Datengröße geringfügig erhöhen). Sobald ein Algorithmus festgelegt wurde, sind in der Regel die Daten selbst der einzige Faktor des Komprimierungsverhältnisses.
Deduplizierung ist jedoch anders – sie ist kein lokales, sondern ein "globales" Konzept. Ein eingehendes Datensegment wird anhand aller vorhandenen Datensegmente in einer deduplizierten Domain dedupliziert, die alle Daten auf Data Domain-Systemen enthält, die nicht in der Cloud enthalten sind. Das Datensegment selbst spielt bei der Deduplizierung keine Rolle.
In der Praxis kommt es selten zu hohen Deduplizierungsraten beim ersten Backup eines Datenvolumens. Beim ersten Backup resultiert die hohe Datenreduzierung oft aus der lokalen Komprimierung. Wenn nachfolgende Backups auf Data Domain landen, zeigt die Deduplizierung ihre Stärke und wird zum dominierenden Faktor für die Komprimierung. Die Effektivität der Deduplizierung beruht auf der Tatsache, dass die Änderungsrate eines Datenvolumens von Backup zu Backup niedrig ist. Aus diesem Grund können Datensätze mit hohen Änderungsraten nicht gut dedupliziert werden. Wenn die Backupanwendung ihre eigenen Metadatenblöcke (von Data Domain als Markierungen bezeichnet) mit hoher Frequenz in die Backup-Images einfügt, erhält sie möglicherweise auch kein gutes Deduplizierungsverhältnis. Unsere Techniken zur Handhabung von Markern können manchmal, aber nicht immer, hilfreich sein.
Was können wir angesichts dieser Beobachtungen erwarten?
Die Messung der Komprimierung ist in deduplizierten Dateisystemen schwierig, aber in protokollstrukturierten deduplizierten Dateisystemen noch schwieriger. Wir müssen verstehen, wie Deduplizierung funktioniert und wie Komprimierungsstatistiken nachverfolgt werden. Komprimierungsverhältnisse sind nützliche Informationen, um das Verhalten eines bestimmten Systems zu verstehen. Das effektive Komprimierungsverhältnis des Systems ist die wichtigste, zuverlässigste und informativste Messgröße. Die Inline-Komprimierungsstatistiken können ebenfalls hilfreich sein, sind aber unter bestimmten Umständen möglicherweise nicht mehr als Heuristiken.
Anhang: Beispielausgabe von "mtree show compression" -Befehl
Angenommen, es gibt einen MTree mit 254792,4 GiB Daten. Es hat 4.379,3 GiB an neuen Daten in den letzten 7 Tagen und 78,4 GiB in den letzten 24 Stunden erhalten (andere Zeitintervalle können angegeben werden). Die Option daily meldet die Inline-Komprimierungsstatistiken für die letzten 33 Tage. Wenn die Option "daily-detailed" bereitgestellt wird, werden die Gesamtkomprimierungsverhältnisse weiter detailliert, indem sie in globale und lokale Komprimierungsverhältnisse unterteilt werden.
MTree-Listenausgabe:
# 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)
------------- -------- --------- ----------- ---------- -------------
Mit Option "Täglich":
# 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
Mit der Option "daily-detailed":
# 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