De komprimeringsteknikker, der er involveret i et Data Domain, bruger de nyeste teknikker til at reducere den fysiske plads, der kræves af kundedata. Teknologier og målinger af komprimeringsniveauer er komplekse emner. I dette dokument beskrives nogle af terminologierne, afvejningerne og målingerne for bedre at forklare de anvendte komprimeringstyper, terminologi og andre aspekter af komprimering i et Data Domain-system.
GÆLDER FOR:
Alle Data Domain-modeller
Senest opdateret: Januar 2024
Komprimering er en datareduktionsteknologi, der sigter mod at gemme et datasæt, der bruger mindre fysisk plads. I Data Domain-systemer (DDOS) udfører vi deduplikering og lokal komprimering for at komprimere brugerdata. Deduplikering eller "dedupe" bruges til at identificere redundante datasegmenter og til kun at gemme unikke datasegmenter. Lokal komprimering komprimerer yderligere de unikke datasegmenter med visse komprimeringsalgoritmer, såsom lz, gzfast, gz, så videre. Den overordnede brugerdatakomprimering i DDOS er den fælles indsats for deduplikering og lokal komprimering. DDOS bruger "komprimeringsforhold" til at måle effektiviteten af deres datakomprimering. Generelt er det forholdet mellem den samlede brugerdatastørrelse og den samlede størrelse af komprimerede data eller den anvendte fysiske pladsstørrelse.
Data Domain-filsystemet er et "logstruktureret" deduplikeret filsystem. Et logstruktureret filsystem føjer kun data til systemet, og sletning kan i sig selv ikke frigøre fysisk plads. Sådanne filsystemer er afhængige af Garbage Collection for at kunne frigøre plads, der ikke længere er brug for. Egenskaberne ved det logstrukturerede filsystem og den deduplikerede teknologi kombineret gør det vanskeligt klart at forstå alle aspekter af komprimering i DDOS.
Til komprimering er der mange aspekter, vi kan måle. I dette dokument diskuterer vi detaljerne trin for trin for at hjælpe med at forstå DDOS-komprimering. Først forklarer vi den overordnede systemkomprimeringseffekt, som fortæller os den realistiske komprimering, der opnås i et Data Domain-system, mængden af brugerdata, mængden af forbrugt fysisk plads og forholdet mellem dem. Dette forhold kaldes "system effective compression ratio" i dette dokument. DDOS udfører deduplikering indbygget og sporer statistikken for de oprindelige brugerdatasegmenter, unikke datasegmenter efter deduplikering og den lokale komprimeringseffekt på de unikke datasegmenter. Denne direkte komprimeringsstatistik bruges til at måle den direkte komprimeringseffekt. Indlejret komprimeringsstatistik kan måles for hver skrivning. DDOS holder også styr på statistikken på forskellige niveauer; filer, MTrees og hele systemet.
Indholdet af dette dokument kan anvendes på alle DDOS-udgivelser indtil udgivelsen af dette dokument, op til DDOS 7.13. Der er ingen garanti for, at alt indhold er nøjagtigt ved fremtidige udgivelser. I udgivelser før 5.0 har hele systemet kun et mtree, og udtrykket mtree kaldes ikke eksplicit.
Den samlede kompressionseffekt for hele systemet måles ved systemets effektive kompressionsforhold, som er forholdet mellem brugerdatastørrelsen og størrelsen af den brugte fysiske plads. Det rapporteres af filesys show compression (FSC) CLI-kommandoen (de tilsvarende oplysninger er også tilgængelige på UI). Et eksempel på output af FSC er vist nedenfor:
# 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.
Systemets effektive kompressionsforhold rapporteres i række 1 i resultatafsnittet i CLI-outputtet. Rækken er fremhævet ovenfor. Den samlede brugerdatastørrelse er mærket som "Pre-Comp." Den samlede forbrugte fysiske plads (af både data og metadata) er mærket som "Post-Comp."
"Pre-Comp"-nummeret og "Post-Comp"-nummeret læses begge under kørsel. FSC synkroniserer implicit hele systemet og forespørger derefter de to tal. Disse to tal måles på samme måde som kommandoen "filesys show space".
Systemeffektivt kompressionsforhold = Pre-Comp/Post-Comp
Resten af FSC-outputtet beskriver inline-komprimeringsstatistikkerne, og vi diskuterer dem senere.
Der er nogle operationer, der kan påvirke systemets effektive kompressionsforhold:
Hurtig kopi
Når en hurtig kopi udføres fra en fil i det aktive navneområde (ikke et snapshot), er det en perfekt deduplikering, da der ikke er behov for ekstra fysisk plads til målfilen. Effekten af en hurtigkopiering er, at vi øger brugerdatastørrelsen uden at forbruge ekstra fysisk plads. Dette øger systemets effektive kompressionsforhold. Når mange hurtige kopier er færdige, kan systemets effektive kompressionsforhold blive kunstigt højt.
Virtuel syntetisk
Virtuelle syntetiske sikkerhedskopier har tendens til at vise et højt systemeffektivt komprimeringsforhold. Dette skyldes, at virtuel syntetisk foretager logiske komplette sikkerhedskopier, men kun overfører ændrede eller nye data til Data Domain-systemer. Virkningen på systemets effektive kompressionsforhold af virtuel syntetisk er lidt som effekten af hurtig kopi.
Overskriver
Overskrivninger optager mere fysisk plads, men øger ikke datasættets logiske størrelse, og overskrivninger sænker således systemets effektive komprimeringsforhold.
Lagring af sparsomme filer
Sparsomme filer indeholder store "huller", der medregnes i den logiske størrelse, men ikke bruger fysisk plads pga. komprimering. Som følge heraf kan de få systemets effektive komprimeringsforhold til at synes højt.
Lagring af små filer
DDOS tilføjer næsten 1 KB overhead til hver fil for visse interne metadata. Når et system gemmer et betydeligt antal små filer (størrelse mindre end 1 KB eller i encifrede kilobyte), trækker de faste omkostninger til metadata det effektive komprimeringsforhold ned.
Lagring af forkomprimerede eller forudkrypterede filer
Komprimering og kryptering kan forstærke niveauet af dataændringer og reducere muligheden for deduplikering. Sådanne filer kan normalt ikke deduplikeres godt og bringe systemets effektive komprimeringsforhold lavere.
Sletter
Sletninger reducerer systemets logiske størrelse, men systemet får ikke den tilsvarende ubrugte plads tilbage, før Garbage Collection kører. Mange slettede filer gør komprimeringsforholdet lavt, indtil Garbage Collection (GC) kører.
Garbage Collection (GC) eller rengøring
GC genvinder den plads, der forbruges af datasegmenter, der ikke længere ses af nogen fil. Hvis der er blevet slettet mange filer for nylig, kan GC øge systemets komprimeringsforhold ved at reducere størrelsen af det fysiske pladsforbrug.
Aggressiv optagelse af snapshots
Når vi tager et snapshot af et Mtree, ændrer vi ikke datasættets logiske størrelse. Alle datasegmenter, der refereres til i snapshottet, skal dog låses, selvom alle filer, der er hentet af snapshottet, slettes, efter snapshottet blev taget. GC kan ikke genvinde den plads, der stadig er nødvendig af snapshots; Derfor kan mange snapshots få systemets effektive komprimeringsforhold til at virke lavt. Snapshots er dog nyttige værktøjer til gendannelse efter nedbrud. Vi bør aldrig tøve med at tage snapshots eller konfigurere ordentlige snapshottidsplaner efter behov.
DDOS udfører deduplikering inline, da data skrives til systemet. Det sporer virkningerne af indbygget deduplikering og lokal komprimering for hver skrivning og akkumulerer statistikken på filniveau. Inline-komprimeringsstatistikker pr. fil aggregeres yderligere på MTree-niveau og på systemniveau. Komprimering måles ud fra tre tal i inline-statistikken:
Baseret på ovenstående tre tal definerer DDOS yderligere to komprimeringsforhold med fingranularitet:
Den akkumulerede direkte komprimeringsstatistik er en del af filens metadata i DDOS og gemmes i filens inode. DDOS giver værktøjer til at kontrollere inline-komprimeringerne på alle tre niveauer; fil, MTree og hele systemet. Vi detaljerer dem i de følgende afsnit.
3.1 Filkomprimering
Filkomprimering kan kontrolleres med CLI-kommandoen "filesys show compression <path>", som rapporterer de akkumulerede komprimeringsstatistikker, der er gemt i filinoden. Når der er angivet en mappe, opsummeres og rapporteres den indbyggede komprimeringsstatistik for alle filerne under den pågældende mappe. I CLI-outputtet er raw_bytes mærket som "Original Bytes"; pre_lc_size er mærket som "Globalt komprimeret"; post_lc_bytes er markeret som "Lokalt komprimeret"; de øvrige faste omkostninger rapporteres som "metadata". De to eksempler er hentet fra en faktisk DD:
Eksempel 1: Indlejret komprimeringsstatistik for en fil
# 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
Eksempel 2: Integreret komprimeringsstatistik for alle filer under en mappe, herunder alle undermapper
# 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
Systemet rapporterer det samlede indbyggede komprimeringsforhold i ovenstående CLI-output som "bytes/storage_used". Der skal dog udvises forsigtighed ved fortolkningen af ovenstående oplysninger, da de kan være misvisende af forskellige årsager. En af grundene er, at pre_lc_size og post_lc_size registreres på det tidspunkt, hvor datahandlingerne behandles. Når den fil, der oprindeligt tilføjede disse segmenter, slettes, øges antallet af de entydige datasegmenter i den resterende fil.
Antag f.eks., at filen sample.file sikkerhedskopieres til et Data Domain, og at komprimeringsoplysningerne for filen i den første sikkerhedskopiering er pre_lc_size=10GiB, post_lc_size=5Gib.
Antag derefter, at dataene i denne fil er unikke uden datadeling med nogen anden fil. I den anden sikkerhedskopi af filen antages det endvidere, at filen får ideel deduplikering, således at både pre_lc_size og post_lc_size skal være nul, fordi alle segmenter af filen allerede eksisterede på systemet. Når den første sikkerhedskopi slettes, bliver den anden sikkerhedskopi af filen den eneste fil, der refererer til datasegmenterne på 5 GiB. I dette tilfælde skal ideelt set pre_lc_size og post_lc_size af filen i den anden sikkerhedskopi opdateres fra begge at være nul til henholdsvis 10 GiB og 5 GiB. Der er dog ingen måde at registrere, hvilke filer der skal gøres for, så den indbyggede komprimeringsstatistik for de eksisterende filer forbliver uændret.
En anden faktor, der påvirker ovenstående tal, er den kumulative statistik. Når en fil får mange overskrivninger, er det umuligt at spore, i hvilket omfang den kumulative statistik afspejler de skrivninger, der introducerede de levende data. Således kan inline-komprimeringsstatistikken over lang tid kun behandles som en heuristik for groft at estimere komprimeringen af en bestemt fil.
En anden kendsgerning, der er værd at fremhæve, er, at inline-komprimeringen af en fil ikke kan måles i et vilkårligt tidsinterval. Filens indbyggede komprimeringsstatistik er et kumulativt resultat og dækker alle de skrivninger, som filen nogensinde har modtaget. Når en fil modtager mange overskrivninger, kan raw_bytes være langt større end filens logiske størrelse. For sparsomme filer kan filstørrelserne være større end "Original Bytes".
3.2 MTree-komprimering
Vi kan kontrollere komprimeringen af et bestemt mtree med "mtree show compression" (MSC) CLI-kommando. De absolutte værdier af inlinekomprimeringsstatistikken akkumuleres i MTree's levetid. I betragtning af at levetiden for et MTree kan være mange år langt, bliver disse værdier mindre og mindre informative over tid. For at løse dette problem bruger vi ændringsmængden (deltaer) i indlejringskomprimeringsstatistikken og rapporterer kun komprimering for bestemte tidsintervaller. Den underliggende tilgang er, at vi med jævne mellemrum dumper MTree inline-komprimeringsstatistikken til en logfil. Når en klient forespørger MTree-komprimering med MSC-kommandoen, bruger vi loggen til at beregne deltaerne i tallene til komprimeringsrapportering. Som standard rapporterer MSC komprimering for de sidste 7 dage og de sidste 24 timer, men når som helst kan interesseperioden angives.
Antag følgende logfil for MTree A for at demonstrere:
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
Derefter er komprimeringen af MTree A for denne time:
g_comp = (12000-11000)/(200-100) = 10x l_comp = (200-100)/(100-50) = 2x overall compression ratio = (12000-11000)/(100-50) = 20x
Ovenstående beregning af komprimeringsforhold gør intet med datasætstørrelsen. For eksempel kan ovenstående MTree kun have 500 GB logiske data.
MSC understøtter indstillingerne "dagligt" og "dagligt-detaljeret", ligesom kommandoen "filesys show compression". Når "dagligt" er angivet, rapporterer kommandoen den daglige komprimering på en kalendermåde. Den bruger de daglige deltaer i raw_bytes og post_lc_size til at beregne det daglige komprimeringsforhold. Når "daily-detailed" er angivet, viser kommandoen alle tre deltaer (af henholdsvis raw_bytes, pre_lc_size og post_lc_size) for hver dag; Det beregner også g_comp og l_comp sammen med den samlede komprimeringsfaktor.
Eksempler på output fra disse systemer findes i tillægget.
3.3 Systemkomprimering
Når vi først har forstået, hvordan komprimering rapporteres på MTrees, er det ligetil at udvide konceptet til hele systemet. Den systemdækkende komprimering inline statistikindsamling og rapportering er nøjagtig den samme som med MTrees. Den eneste forskel er omfanget, da man er i et bestemt MTree, mens man er over hele systemet. Resultaterne kan kontrolleres ved hjælp af kommandoen "filesys show compression". Et eksempel herpå findes i afsnit 2. Systemkomprimeringen "sidste 7 dage" og "sidste 24 timer" rapporteres i de sidste to linjer i resultatafsnittet i FSC-outputtet.
På DD'er, hvor cloudniveauet er implementeret, adskilles lageret i det aktive niveau og cloudniveauet, som er to uafhængige deduplikeringsdomæner. Brugere kan kun indsætte data på det aktive niveau. Senere kan DDOS-dataflytningsfunktioner bruges til at migrere data fra det aktive niveau til cloudniveauet. Således håndteres rum- og kompressionsmåling og rapportering uafhængigt på hvert niveau. Men på filniveau skelner vi ikke efter niveau og rapporterer indbyggede komprimeringsstatistikker. de er nøjagtig de samme som det, vi beskrev i afsnit 3.1.
Det sidste emne, der skal fremhæves, er nogle af egenskaberne ved deduplikering, som kaldes "global komprimering" i mange Data Domain-dokumenter. Selvom det indeholder ordet "komprimering", er det helt anderledes end det traditionelle koncept for kompression, som også leveres af DDOS under navnet "lokal komprimering."
Lokal komprimering reducerer størrelsen på et stykke data ved hjælp af en bestemt algoritme (nogle typer data kan ikke komprimeres, og anvendelse af komprimeringsalgoritmer på dem kan øge datastørrelsen lidt). Normalt, når en algoritme er besluttet, er selve dataene den eneste faktor i kompressionsforholdet.
Deduplikering er imidlertid anderledes - det er ikke et lokalt koncept, det er "globalt". Et indgående datasegment trækkes i forhold til alle eksisterende datasegmenter i et deduplikeret domæne, hvilket omfatter alle data på ikke-cloudbaserede Data Domain-systemer. Datasegmentet selv betyder ikke noget i deduplikeringsproceduren.
I praksis ser vi sjældent et højt deduplikeringsforhold i den indledende sikkerhedskopiering af et datasæt. I de første sikkerhedskopieringer kommer den store datareduktion ofte fra lokal komprimering. Når efterfølgende sikkerhedskopier lander på Data Domain, viser deduplikering sin styrke og bliver den dominerende faktor for komprimering. Effektiviteten af deduplikering afhænger af, at ændringshastigheden for et datasæt er lav fra sikkerhedskopiering til sikkerhedskopiering. Derfor kan datasæt med høje ændringshastigheder ikke fjernes ordentligt. Når sikkerhedskopieringsprogrammet indsætter sine egne metadatabidder (kaldet markører af Data Domain) i sikkerhedskopieringsbillederne med høj frekvens, får det muligvis heller ikke et godt deduplikeringsforhold. Vores markørhåndteringsteknikker kan hjælpe nogle gange, men ikke altid.
Hvad kan vi forvente i lyset af disse observationer?
Måling af komprimering er vanskelig i deduplikerede filsystemer, men det er endnu sværere i logstrukturerede deduplikerede filsystemer. Vi skal forstå, hvordan deduplikering fungerer, og hvordan komprimeringsstatistikker spores. Kompressionsforhold er nyttige oplysninger til at forstå et bestemt systems opførsel. Systemets effektive kompressionsforhold er den vigtigste, pålidelige og informative foranstaltning. Inline-komprimeringsstatistikken kan også være nyttig, men de er muligvis ikke mere end heuristik under nogle omstændigheder.
Tillæg: Prøveoutput af "mtree show compression" kommando
Antag, at der er et MTree med 254792,4 GiB data. Det har modtaget 4379.3 GiB nye data i de sidste 7 dage og 78.4 GiB i de sidste 24 timer (andre tidsintervaller kan specificeres). Den "daglige" indstilling rapporterer den direkte komprimeringsstatistik for de sidste 33 dage. Når den "dagligt detaljerede" mulighed leveres, beskrives de samlede kompressionsforhold yderligere ved at opdele dem i globale og lokale kompressionsforhold.
Output fra Mtree-liste:
# 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)
------------- -------- --------- ----------- ---------- -------------
Med "daglig" mulighed:
# 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
Med mulighed for "daglige detaljer":
# 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