De compressietechnieken die betrokken zijn bij een Data Domain maken gebruik van geavanceerde technieken om de fysieke ruimte die nodig is voor klantdata te verminderen. De technologieën en metingen van compressieniveaus zijn dan ook complexe onderwerpen. In dit document worden enkele terminologieën, afwegingen en maatregelen besproken om de gebruikte compressietypen, terminologie en andere aspecten van compressie in een Data Domain-systeem beter uit te leggen.
VAN TOEPASSING OP:
Alle Data Domain modellen
Laatst bijgewerkt: Januari 2024
Compressie is een technologie voor datareductie die tot doel heeft een dataset op te slaan met minder fysieke ruimte. In Data Domain-systemen (DDOS) doen we aan deduplicatie en lokale compressie om gebruikersdata te comprimeren. Deduplicatie, of 'dedupe', wordt gebruikt om overbodige datasegmenten te identificeren en alleen unieke datasegmenten op te slaan. Lokale compressie comprimeert de unieke datasegmenten verder met bepaalde compressiealgoritmen, zoals lz, gzfast, gz, ga zo maar door. De algehele compressie van gebruikersdata in DDOS is de gezamenlijke inspanning van deduplicatie en lokale compressie. DDOS gebruikt 'compressieverhouding' om de effectiviteit van de datacompressie te meten. Over het algemeen is dit de verhouding tussen de totale grootte van gebruikersgegevens en de totale grootte van gecomprimeerde gegevens of de gebruikte grootte van de fysieke ruimte.
Data Domain bestandssysteem is een log-gestructureerd deduplicatiebestandssysteem. Een bestandssysteem met logboekstructuur voegt alleen data toe aan het systeem en met verwijdering kan geen fysieke ruimte worden vrijgemaakt. Dergelijke bestandssystemen vertrouwen op garbagecollection om niet langer benodigde ruimte vrij te maken. De gecombineerde kenmerken van het log-gestructureerde bestandssysteem en de gededupliceerde technologie maken het lastig om alle aspecten van compressie in DDOS duidelijk te begrijpen.
Voor compressie zijn er veel aspecten die we kunnen meten. In dit document bespreken we de details stap voor stap om meer inzicht te krijgen in DDOS-compressie. Eerst leggen we het algehele systeemcompressie-effect uit, dat ons vertelt over de realistische compressie die wordt bereikt in een Data Domain-systeem, de hoeveelheid gebruikersdata, de hoeveelheid gebruikte fysieke ruimte en de verhouding daarvan. Deze verhouding wordt in dit document "effectieve compressieverhouding van het systeem" genoemd. DDOS voert deduplicatie inline uit en houdt de statistieken bij van de oorspronkelijke gebruikersdatasegmenten, post-deduplicatie van unieke datasegmenten en het lokale compressie-effect op de unieke datasegmenten. Deze inline compressiestatistieken worden gebruikt om het inline compressie-effect te meten. Inline compressiestatistieken kunnen worden gemeten voor elke schrijfbewerking. Ook houdt DDOS de statistieken op verschillende niveaus bij; bestanden, MTrees en het hele systeem.
De inhoud van dit document kan worden toegepast op alle DDOS-releases tot publicatie van dit document, tot DDOS 7.13. Er is geen garantie dat alle inhoud correct is voor toekomstige releases. In releases vóór 5.0 heeft het hele systeem slechts één mtree en wordt de term mtree niet expliciet genoemd.
Het algehele compressie-effect voor het hele systeem wordt gemeten aan de hand van de effectieve compressieverhouding van het systeem. Dit is de verhouding tussen de grootte van de gebruikersdata en de grootte van de gebruikte fysieke ruimte. Dit wordt gemeld door de CLI-opdracht filesys show compression (FSC) (de bijbehorende informatie is ook beschikbaar in de gebruikersinterface). Een voorbeeld van de uitvoer van FSC wordt hieronder weergegeven:
# 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.
De effectieve compressieverhouding van het systeem wordt gerapporteerd in rij 1 van de resultatensectie in de CLI-uitvoer. De rij is hierboven gemarkeerd. De totale grootte van gebruikersdata wordt aangeduid als 'Pre-Comp'. De totale gebruikte fysieke ruimte (door zowel data als metadata) wordt aangeduid als 'Post-Comp'.
Het "Pre-Comp"-nummer en het "Post-Comp"-nummer worden beide tijdens runtime gelezen. FSC synchroniseert impliciet het hele systeem en voert vervolgens een query uit op de twee cijfers. Deze twee getallen worden op dezelfde manier gemeten als de opdracht
"filesys show space".Effectieve compressieverhouding van het systeem = Pre-Comp/Post-Comp
De rest van de FSC-uitvoer beschrijft de inline compressiestatistieken, en we bespreken ze later.
Er zijn enkele bewerkingen die van invloed kunnen zijn op de effectieve compressieverhouding van het systeem:
Fastcopy
Wanneer een fastcopy wordt uitgevoerd vanuit een bestand in de actieve naamruimte (geen snapshot), is dit een perfecte deduplicatie, omdat er geen extra fysieke ruimte nodig is voor het doelbestand. Het effect van een fastcopy is dat we de grootte van de gebruikersdata vergroten zonder extra fysieke ruimte in beslag te nemen. Dit verhoogt de effectieve compressieverhouding van het systeem. Wanneer er veel fastcopies worden gemaakt, kan de effectieve compressieverhouding van het systeem kunstmatig hoog worden.
Virtual synthetics
Virtuele, kunstmatige back-ups hebben meestal een hoge effectieve compressieverhouding van het systeem. Dit komt doordat virtuele kunststoffen logische volledige back-ups maken, maar alleen gewijzigde of nieuwe data overdragen naar Data Domain-systemen. De impact op de effectieve compressieverhouding van virtuele kunststoffen lijkt enigszins op het effect van fastcopy.
Overschrijft
Overschrijvingen nemen meer fysieke ruimte in beslag, maar vergroten de logische grootte van de dataset niet, waardoor overschrijven de effectieve compressieverhouding van het systeem verlaagt.
Sparse files opslaan
Sparse-bestanden bevatten grote 'gaten' die worden meegerekend in de logische grootte, maar geen fysieke ruimte verbruiken als gevolg van compressie. Hierdoor kan de effectieve compressieverhouding van het systeem hoog lijken.
Kleine bestanden opslaan
DDOS voegt bijna 1 KB overhead toe aan elk bestand voor bepaalde interne metadata. Wanneer een systeem een aanzienlijk aantal kleine bestanden opslaat (kleiner dan 1 KB of in kilobytes van één cijfer), haalt de overhead van metadata de effectieve compressieverhouding naar beneden.
Voorgecomprimeerde of vooraf versleutelde bestanden opslaan
Compressie en versleuteling kunnen het niveau van datawijziging versterken en de kans op deduplicatie verkleinen. Dergelijke bestanden kunnen meestal niet goed worden gededupliceerd en brengen de effectieve compressieverhouding van het systeem lager.
Verwijderd
Verwijderingen verminderen de logische grootte van het systeem, maar het systeem krijgt de bijbehorende ongebruikte ruimte pas terug als de garbagecollection wordt uitgevoerd. Bij veel verwijderde bestanden wordt de compressieverhouding laag totdat Garbage Collection (GC) wordt uitgevoerd.
Garbage Collection (GC) of schoonmaak
GC wint de ruimte terug die wordt verbruikt door gegevenssegmenten die door geen enkel bestand meer worden gezien. Als onlangs veel bestanden zijn verwijderd, kan GC de compressieverhouding van het systeem verhogen door de voetafdruk van het fysieke-ruimteverbruik te verminderen.
Agressief snapshots maken
Wanneer we een snapshot van een Mtree maken, veranderen we de logische grootte van de dataset niet. Alle gegevenssegmenten waarnaar wordt verwezen door de snapshot moeten echter worden vergrendeld, zelfs als alle bestanden die door de snapshot zijn vastgelegd, worden verwijderd nadat de snapshot is gemaakt. GC kan de ruimte die nog nodig is voor snapshots niet terugwinnen; Daarom kan het hebben van veel snapshots ervoor zorgen dat de effectieve compressieverhouding van het systeem laag lijkt. Snapshots zijn echter nuttige herstelfaciliteiten voor crashes. Aarzel niet om snapshots te maken of de juiste snapshotschema's in te stellen wanneer dat nodig is.
DDOS voert deduplicatie inline uit, terwijl data naar het systeem worden geschreven. Het houdt de effecten bij van inline deduplicatie en lokale compressie voor elke schrijfbewerking, en accumuleert de statistieken op bestandsniveau. Statistieken van inline compressie per bestand worden verder geaggregeerd op mtree-niveau en op systeemniveau. Compressie wordt gemeten op basis van drie getallen in de inline-statistieken:
Op basis van de bovenstaande drie getallen definieert DDOS nog twee compressieverhoudingen voor fijne granulariteit:
De verzamelde inline compressiestatistieken maken deel uit van de bestandsmetadata in DDOS en worden opgeslagen in de bestands-inode. DDOS biedt tools om de inline compressies op alle drie de niveaus te controleren; bestand, MTree en systeembreed. We beschrijven ze in de volgende secties.
3.1 Compressie van
bestanden De compressie van bestanden kan worden gecontroleerd met het CLI-commando "filesys show compression <path>", dat de geaccumuleerde compressiestatistieken rapporteert die zijn opgeslagen in de bestandsinode. Wanneer een map is opgegeven, worden de inline compressiestatistieken van alle bestanden in die map opgeteld en gerapporteerd. In de CLI-uitvoer wordt raw_bytes aangeduid als "Original Bytes"; pre_lc_size is aangeduid als "Globally Compressed"; post_lc_bytes is gemarkeerd als "Locally Compressed"; de overige overheadkosten worden gerapporteerd als 'metadata'. De twee voorbeelden zijn vastgelegd uit een echt DD:
Voorbeeld 1: Inline compressiestatistieken van een bestand
# 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
Voorbeeld 2: Inline compressiestatistieken van alle bestanden in een directory, inclusief alle subdirectory's
# 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
Het systeem rapporteert de algehele inline compressieverhouding in de bovenstaande CLI-uitvoer als "bytes/storage_used". De bovenstaande informatie moet echter zorgvuldig worden geïnterpreteerd, omdat deze om verschillende redenen misleidend kan zijn. Een van de redenen is dat de pre_lc_size en post_lc_size worden vastgelegd op het moment dat de databewerkingen worden verwerkt. Wanneer het bestand waaraan deze segmenten oorspronkelijk zijn toegevoegd, wordt verwijderd, moet het aantal unieke gegevenssegmenten in het resterende bestand worden verhoogd.
Stel bijvoorbeeld dat er een back-up is gemaakt van een bestand sample.file in een Data Domain, en dat in de eerste back-up de compressiegegevens van het bestand pre_lc_size=10GiB, post_lc_size=5Gib zijn.
Ga er vervolgens van uit dat de gegevens van dit bestand uniek zijn en dat er geen gegevens worden gedeeld met een ander bestand. Ga er bij de tweede back-up van het bestand verder van uit dat het bestand een ideale deduplicatie krijgt, waarbij zowel pre_lc_size als post_lc_size nul moeten zijn omdat alle segmenten van het bestand al op het systeem aanwezig waren. Wanneer de eerste back-up wordt verwijderd, wordt de tweede back-up van het bestand het enige bestand dat verwijst naar de 5 GiB aan gegevenssegmenten. In dit geval zouden idealiter de pre_lc_size en post_lc_size van het bestand in de tweede back-up moeten worden bijgewerkt van beide nul naar respectievelijk 10 GiB en 5 GiB. Er is echter geen manier om te detecteren voor welke bestanden dat moet worden gedaan, dus de inline compressiestatistieken van de bestaande bestanden blijven ongewijzigd.
Een andere factor die van invloed is op de bovenstaande cijfers zijn de cumulatieve statistieken. Wanneer een bestand veel overschrijvingen krijgt, is het onmogelijk om bij te houden in hoeverre de cumulatieve statistieken de schrijfbewerkingen weerspiegelen die de live-gegevens hebben geïntroduceerd. Over een lange tijd kunnen de inline compressiestatistieken dus alleen worden behandeld als een heuristiek om de compressie van een bepaald bestand ruwweg te schatten.
Een ander feit dat het vermelden waard is, is dat de inline compressie van een bestand niet kan worden gemeten voor een willekeurig tijdsinterval. De inline compressiestatistieken van het bestand zijn een cumulatief resultaat en omvatten alle schrijfbewerkingen die het bestand ooit heeft ontvangen. Wanneer een bestand veel overschrijvingen ontvangt, kan de raw_bytes veel groter zijn dan de logische grootte van het bestand. Voor schaarse bestanden kunnen de bestandsgroottes groter zijn dan de 'Original Bytes'.
3.2 MTree-compressie
We kunnen de compressie van een bepaalde mtree controleren met de "mtree show compression" (MSC) CLI-opdracht. De absolute waarden van de inline compressiestatistieken zijn cumulatief over de levensduur van de MTree. Aangezien de levensduur van een MTree vele jaren kan duren, worden deze waarden na verloop van tijd steeds minder informatief. Om dit probleem op te lossen, gebruiken we de hoeveelheid verandering (delta's) van de inline compressiestatistieken en rapporteren we compressie alleen voor bepaalde tijdsintervallen. De onderliggende benadering is dat we periodiek de MTree inline compressiestatistieken in een logbestand dumpen. Wanneer een client MTree-compressie opvraagt met de MSC-opdracht, gebruiken we het logboek om de delta's van de getallen voor compressierapportage te berekenen. Standaard rapporteert MSC compressie voor de laatste 7 dagen en de laatste 24 uur, hoewel u op elk moment een interessante periode kunt opgeven.
Om dit te demonstreren, neemt u het volgende logboek voor MTree A aan:
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
Dan is de compressie van MTree A voor dit uur:
g_comp = (12000-11000)/(200-100) = 10x l_comp = (200-100)/(100-50) = 2x overall compression ratio = (12000-11000)/(100-50) = 20x
De bovenstaande berekening van de compressieverhouding doet niets met de grootte van de dataset. De bovenstaande mtree mag bijvoorbeeld alleen logische data van 500 GB bevatten.
MSC ondersteunt de opties "dagelijks" en "dagelijks gedetailleerd", net als de opdracht "filesys show compression". Wanneer "daily" is opgegeven, rapporteert de opdracht de dagelijkse compressie op een kalendermanier. Het gebruikt de dagelijkse delta's van de raw_bytes en post_lc_size om de dagelijkse compressieverhouding te berekenen. Wanneer "daily-detailed" is opgegeven, toont de opdracht alle drie de delta's (van respectievelijk de raw_bytes, pre_lc_size en post_lc_size) voor elke dag; Het berekent ook de g_comp en l_comp naast de totale compressiefactor.
Voorbeelden van de uitvoer van deze systemen zijn opgenomen in het aanhangsel.
3.3 Systeemcompressie
Als we eenmaal begrijpen hoe compressie wordt gerapporteerd op MTrees, is het eenvoudig om het concept uit te breiden naar het hele systeem. De systeembrede compressie inline statistische verzameling en rapportage zijn precies hetzelfde als bij MTrees. Het enige verschil is de reikwijdte, aangezien men zich in een bepaalde MTree bevindt, terwijl men over het hele systeem gaat. De resultaten kunnen worden gecontroleerd met de opdracht "filesys show compression". Een voorbeeld hiervan is te vinden in hoofdstuk 2. De systeemcompressie van de afgelopen 7 dagen en de afgelopen 24 uur wordt vermeld op de laatste twee regels van de resultatensectie in de FSC-uitvoer.
Op DD's met cloudlaag geïmplementeerd, wordt de storage gescheiden in de actieve laag en de cloudlaag, die twee onafhankelijke deduplicatiedomeinen zijn. Gebruikers kunnen alleen gegevens injecteren in de actieve laag. Later kunnen DDOS-functies voor dataverplaatsing worden gebruikt om data van de actieve laag naar de cloudlaag te migreren. De ruimte- en compressiemeting en -rapportage worden dus onafhankelijk van elkaar afgehandeld in elke laag. Maar op bestandsniveau maken we geen onderscheid per niveau en rapporteren we inline compressiestatistieken; ze zijn precies hetzelfde als wat we in paragraaf 3.1 hebben beschreven.
Het laatste onderwerp dat moet worden belicht, zijn enkele kenmerken van deduplicatie, die in veel Data Domain-documenten 'globale compressie' wordt genoemd. Hoewel het het woord 'compressie' bevat, is het totaal anders dan het traditionele concept van compressie, dat ook door DDOS wordt geleverd onder de naam 'lokale compressie'.
Lokale compressie verkleint de grootte van een stuk gegevens met behulp van een bepaald algoritme (sommige soorten gegevens zijn niet comprimeerbaar en het toepassen van compressiealgoritmen erop kan de gegevensgrootte enigszins vergroten). Meestal, als er eenmaal een algoritme is besloten, zijn de gegevens zelf de enige factor van de compressieverhouding.
Deduplicatie is echter anders - het is geen lokaal concept, het is 'globaal'. Een binnenkomend datasegment wordt gededupliceerd tegen alle bestaande datasegmenten in een gededupliceerd domein, dat alle data op niet-cloud Data Domain-systemen bevat. Het datasegment zelf doet er niet toe in de deduplicatieprocedure.
In de praktijk zien we zelden een hoge deduplicatieratio in de initiële back-up van een dataset. In de eerste back-ups is de belangrijkste datareductie vaak afkomstig van lokale compressie. Wanneer opeenvolgende back-ups op het Data Domain terechtkomen, toont deduplicatie zijn kracht en wordt het de dominante factor voor compressie. De effectiviteit van deduplicatie is afhankelijk van het feit dat de wijzigingssnelheid van een dataset laag is van back-up tot back-up. Om deze reden kunnen datasets met hoge wijzigingssnelheden niet goed worden gededupliceerd. Wanneer de back-upapplicatie met hoge frequentie zijn eigen metadatabrokken (door Data Domain markers genoemd) in de back-upimages invoegt, krijgt deze mogelijk ook geen goede deduplicatieratio. Onze technieken voor het hanteren van markers kunnen soms helpen, maar niet altijd.
Wat kunnen we, gezien deze observaties, verwachten?
Het meten van compressie is moeilijk in gededupliceerde bestandssystemen, maar het is nog moeilijker in gededupliceerde bestandssystemen met logstructuur. We moeten begrijpen hoe deduplicatie werkt en hoe compressiestatistieken worden bijgehouden. Compressieverhoudingen zijn nuttige informatie om het gedrag van een bepaald systeem te begrijpen. De effectieve compressieverhouding van het systeem is de belangrijkste, betrouwbaarste en meest informatieve maatstaf. De inline compressiestatistieken kunnen ook nuttig zijn, maar in sommige omstandigheden zijn ze misschien niet meer dan heuristieken.
Bijlage: Steekproefuitvoer van "mtree show compression" command
Stel dat er een MTree is met 254792.4 GiB aan data. Het heeft 4379,3 GiB aan nieuwe gegevens ontvangen in de afgelopen 7 dagen en 78,4 GiB in de afgelopen 24 uur (andere tijdsintervallen kunnen worden gespecificeerd). Met de optie 'daily' worden de inline compressiestatistieken van de afgelopen 33 dagen gerapporteerd. Wanneer de optie "dagelijks-gedetailleerd" is ingeschakeld, worden de totale compressieverhoudingen verder gedetailleerd door ze te scheiden in algemene en lokale compressieverhoudingen.
Uitvoer van Mtree-lijst:
# 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)
------------- -------- --------- ----------- ---------- -------------
Met de optie "dagelijks":
# 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
Met de optie "dagelijks-gedetailleerd":
# 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