Komprimeringsteknikkene som er involvert i et datadomene, bruker toppmoderne teknikker for å redusere den fysiske plassen som kreves av kundedata. Teknologien bak og målinger av komprimeringsnivåer er derfor komplekse emner. Dette dokumentet drøfter noen av terminologiene, avveiningene og tiltakene for bedre å forklare komprimeringstypene som brukes, terminologien og andre aspekter ved komprimering i et Data Domain-system.
GJELDER FOR:
Alle Data Domain-modeller
Sist oppdatert: januar 2024
Compression er en datareduksjonsteknologi som tar sikte på å lagre et datasett ved å bruke mindre fysisk plass. I Data Domain-systemer (DDOS) utfører vi deduplisering og lokal komprimering for å komprimere brukerdata. Deduplisering brukes til å identifisere overflødige datasegmenter og kun lagre unike datasegmenter. Lokal komprimering komprimerer de unike datasegmentene ytterligere med visse komprimeringsalgoritmer, for eksempel lz, gzfast, gz, så videre. Den generelle brukerdatakomprimeringen i DDOS er en felles innsats av deduplisering og lokal komprimering. DDOS bruker "komprimeringsforhold" til å måle effektiviteten av datakomprimeringen. Generelt er det forholdet mellom den totale brukerdatastørrelsen og den totale størrelsen på komprimerte data eller den brukte fysiske plassstørrelsen.
Data Domain-filsystemet er et "log-strukturert" dedupliseringsfilsystem. Et loggstrukturert filsystem legger bare til data i systemet, og sletting alene kan ikke frigjøre fysisk plass. Slike filsystemer er avhengige av datasanering for å gjenvinne ledig plass. Egenskapene til det loggstrukturerte filsystemet og den dedupliserte teknologien kombinert sammen gjør det vanskelig å forstå alle aspekter av komprimering i DDOS.
For kompresjon er det mange aspekter vi kan måle. I dette dokumentet diskuterer vi detaljene trinn for trinn for å forstå DDOS-komprimering. Først forklarer vi den generelle systemkomprimeringseffekten, som forteller oss den realistiske komprimeringen som oppnås i et Data Domain-system, mengden brukerdata, mengden fysisk plass som brukes og forholdet mellom dem. Dette forholdet kalles "system effektivt kompresjonsforhold" i dette dokumentet. DDOS utfører deduplisering inline og sporer statistikken til de opprinnelige brukerdatasegmentene, unike datasegmenter etter deduplisering og den lokale komprimeringseffekten på de unike datasegmentene. Denne interne komprimeringsstatistikken brukes til å måle den interne komprimeringseffekten. Innebygd komprimeringsstatistikk kan måles for hver skriving. DDOS holder også oversikt over statistikken på forskjellige nivåer; filer, MTrees og hele systemet.
Innholdet i dette dokumentet kan brukes på alle DDOS-utgivelser frem til publisering av dette dokumentet, opp til DDOS 7.13. Det er ingen garanti for at alt innholdet stemmer overens med fremtidige utgivelser. I utgivelser før 5.0 har hele systemet bare ett mtree, og termen mtree er ikke eksplisitt nevnt.
Den systemomfattende samlede komprimeringseffekten måles av systemets effektive kompresjonsforhold, som er forholdet mellom brukerdatastørrelsen og størrelsen på brukt fysisk plass. Det rapporteres av filesys show compression (FSC) CLI-kommandoen (tilsvarende informasjon er også tilgjengelig på UI). Et eksempel på 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.
Det effektive kompresjonsforholdet for systemet rapporteres i rad 1 i resultatdelen i CLI-utdataene. Raden er uthevet ovenfor. Den totale størrelsen på brukerdata er merket som "Pre-Comp". Det totale forbruket av fysisk plass (av både data og metadata) er merket som "Post-Comp."
Både "Pre-Comp"-nummeret og "Post-Comp"-nummeret leses under kjøring. FSC synkroniserer hele systemet implisitt og utfører deretter spørringer av de to tallene. Disse to tallene måles på samme måte som kommandoen "filesys show space".
Systemeffektivt kompresjonsforhold = Pre-Comp/Post-Comp
Resten av FSC-utgangen beskriver inline-komprimeringsstatistikken, og vi diskuterer dem senere.
Det er noen operasjoner som kan påvirke systemets effektive kompresjonsforhold:
Fastcopy
Når en hurtigkopi utføres fra en fil i det aktive navneområdet (ikke et øyeblikksbilde), er det en perfekt deduplisering, siden det ikke er behov for ekstra fysisk plass for målfilen. Effekten av en rask kopi er at vi øker brukerdatastørrelsen uten å bruke mer fysisk plass. Dette øker systemets effektive kompresjonsforhold. Når mange hurtigkopier er ferdige, kan systemets effektive kompresjonsforhold bli kunstig høyt.
Virtuell syntetikk
Virtuelle syntetiske sikkerhetskopier har en tendens til å vise et høyt systemeffektivt kompresjonsforhold. Dette er fordi virtuelle syntetiske stoffer gir logiske fullstendige sikkerhetskopier, men bare overfører endrede eller nye data til Data Domain-systemer. Virkningen på systemets effektive kompresjonsforhold for virtuell syntetikk er noe som effekten av fastcopy.
Overskriver
Overskrivinger bruker mer fysisk plass, men øker ikke den logiske størrelsen på datasettet, og dermed overskrives det effektive komprimeringsforholdet for systemet.
Lagring av sparsomme filer
Spredte filer inneholder store "hull" som regnes med i den logiske størrelsen, men som ikke bruker fysisk plass på grunn av komprimering. Dermed kan de få systemets effektive komprimeringsforhold til å virke høyt.
Lagring av små filer
DDOS legger nesten 1 kB overhead til hver fil for enkelte interne metadata. Når et system lagrer et betydelig antall små filer (størrelser mindre enn 1 KB eller i ensifrede kilobyte), drar overheaden av metadata det effektive komprimeringsforholdet ned.
Lagring av forhåndskomprimerte eller forhåndskrypterte filer
Komprimering og kryptering kan forsterke nivået av dataendring og redusere muligheten for deduplisering. Slike filer kan vanligvis ikke dedupliseres godt og bringe systemets effektive kompresjonsforhold lavere.
Sletter
Sletting reduserer den logiske størrelsen på systemet, men systemet får ikke den tilsvarende ubrukte plassen tilbake før man kjører datasanering. Mange slettede filer gjør kompresjonsforholdet lavt til søppelinnsamling (GC) kjører.
Søppelrydding (GC) eller rengjøring
GC gjenvinner plassen som forbrukes av datasegmenter som ikke lenger ses av noen fil. Hvis mange filer nylig har blitt slettet, kan datasanering øke systemets komprimeringsforhold ved å redusere bruken av fysisk plass.
Aggressivt ta øyeblikksbilder
Når vi tar et øyeblikksbilde av et Mtree, endrer vi ikke den logiske størrelsen på datasettet. Alle datasegmenter som øyeblikksbildet refererer til, må imidlertid være låst, selv om alle filer som registreres av øyeblikksbildet, slettes etter at øyeblikksbildet ble tatt. GC kan ikke gjenvinne plassen som fortsatt trengs av øyeblikksbilder; Å ha mange øyeblikksbilder kan derfor gjøre at systemets effektive kompresjonsforhold virker lavt. Øyeblikksbilder er imidlertid nyttige fasiliteter for gjenoppretting av krasj. Vi bør aldri nøle med å ta øyeblikksbilder eller konfigurere passende tidsplaner for øyeblikksbilder ved behov.
DDOS utfører deduplisering innebygd, ettersom data skrives til systemet. Den sporer effekten av innebygd deduplisering og lokal komprimering for hver skriving, og akkumulerer statistikken på filnivå. Statistikk for innebygd komprimering per fil aggregeres videre på mtree-nivå og systemnivå. Kompresjon måles basert på tre tall i inline-statistikken:
Basert på de tre tallene ovenfor, definerer DDOS ytterligere to kompresjonsforhold med fingranularitet:
Den akkumulerte interne komprimeringsstatistikken er en del av filmetadataene i DDOS og lagres i fil-inoden. DDOS gir verktøy for å kontrollere inline-komprimeringene på alle tre nivåer; -fil, MTree og hele systemet. Vi detaljerer dem i de følgende avsnittene.
3.1 Filkomprimering Filkomprimering
kan kontrolleres med CLI-kommandoen "filesys show compression <path>", som rapporterer den akkumulerte komprimeringsstatistikken som er lagret i filinoden. Når en katalog er angitt, blir innebygd komprimeringsstatistikk for alle filene under denne katalogen oppsummert og rapportert. I CLI-utgangen er raw_bytes merket som "Original Bytes"; pre_lc_size er merket som "Globally Compressed"; post_lc_bytes er merket som "Lokalt komprimert"; de andre omkostningene rapporteres som "Metadata". De to eksemplene er hentet fra en faktisk DD:
Eksempel 1: Innebygd komprimeringsstatistikk 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: Innebygd komprimeringsstatistikk for alle filer under en katalog, inkludert alle underkataloger
# 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 totale inline-kompresjonsforholdet i CLI-utgangen ovenfor som "byte/storage_used". Informasjonen ovenfor kan imidlertid være misvisende av flere årsaker, så du må være nøye når du skal tolke den. En av årsakene er at pre_lc_size og post_lc_size registreres på det tidspunktet da dataoperasjonene behandles. Når filen som opprinnelig la til disse segmentene, blir slettet, bør antallet unike datasegmenter i den gjenværende filen økes.
Anta for eksempel at en fil sample.file er sikkerhetskopiert til et datadomene, og i den første sikkerhetskopien er komprimeringsinformasjonen for filen pre_lc_size=10GiB, post_lc_size=5Gib.
Anta deretter at dataene i denne filen er unike uten datadeling med noen annen fil. I den andre sikkerhetskopien av filen antar du videre at filen får ideell deduplisering, slik at både pre_lc_size og post_lc_size skal være null fordi alle segmenter av filen allerede eksisterte på systemet. Når den første sikkerhetskopien slettes, blir den andre sikkerhetskopien av filen den eneste filen som refererer til 5 GiB datasegmenter. I dette tilfellet bør ideelt sett pre_lc_size og post_lc_size til filen i den andre sikkerhetskopien oppdateres fra begge å være henholdsvis 10 GiB og 5 GiB. Det er imidlertid ingen måte å oppdage hvilke filer det skal gjøres for, så den innebygde komprimeringsstatistikken for de eksisterende filene blir uendret.
En annen faktor som påvirker tallene ovenfor er den kumulative statistikken. Når en fil får mange overskrivinger, er det umulig å spore i hvilken grad den kumulative statistikken gjenspeiler skrivingene som introduserte live-dataene. Dermed kan inline-komprimeringsstatistikken over lang tid bare behandles som en heuristikk for grovt å estimere komprimeringen av en bestemt fil.
Et annet faktum som er verdt å fremheve er at den innebygde komprimeringen av en fil ikke kan måles for et vilkårlig tidsintervall. Filen innebygd komprimering statistikk er et kumulativt resultat og dekker alle skriver at filen noensinne har mottatt. Når en fil mottar mange overskrivninger, kan raw_bytes være langt større enn den logiske størrelsen på filen. For sparsomme filer kan filstørrelsene være større enn "Original Bytes".
3.2 MTree-komprimering
Vi kan sjekke komprimeringen av et bestemt mtree med "mtree show compression" (VG Nett) CLI-kommando. De absolutte verdiene for inline-komprimeringsstatistikken er kumulative over MTrees levetid. Gitt at levetiden til en MTree kan være mange år lang, blir disse verdiene mindre og mindre informative over tid. For å løse dette problemet bruker vi mengden endring (deltaer) i den innebygde komprimeringsstatistikken og rapporterer komprimering bare for bestemte tidsintervaller. Den underliggende tilnærmingen er at vi med jevne mellomrom dumper MTree inline komprimeringsstatistikk til en logg. Når en klient spør MTree-komprimering med MSC-kommandoen, bruker vi loggen til å beregne deltaene til tallene for komprimeringsrapportering. Som standard rapporterer MSC komprimering for de siste 7 dagene og de siste 24 timene, selv om en hvilken som helst tidsperiode av interesse kan spesifiseres.
Anta følgende logg for å demonstrere 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
Da er komprimeringen av MTree A for denne timen:
g_comp = (12000-11000)/(200-100) = 10x l_comp = (200-100)/(100-50) = 2x overall compression ratio = (12000-11000)/(100-50) = 20x
Beregningen av kompresjonsforholdet ovenfor gjør ingenting med størrelsen på datasettet. Det kan for eksempel hende at mtreet ovenfor bare har 500 GB logiske data.
MSC støtter alternativene "daglig" og "daglig detaljert", og det samme gjør kommandoen "filesys show compression". Når "daglig" er angitt, rapporterer kommandoen den daglige komprimeringen på en kalendermåte. Det bruker de daglige deltaene i raw_bytes og post_lc_size til å beregne det daglige komprimeringsforholdet. Når "daglig detaljert" er angitt, viser kommandoen alle tre deltaene (av henholdsvis raw_bytes, pre_lc_size og post_lc_size) for hver dag. Den beregner også g_comp og l_comp sammen med den totale kompresjonsfaktoren.
Prøveutdata fra disse systemene finnes i vedlegget.
3.3 Systemkompresjon
Når vi forstår hvordan komprimering rapporteres på MTrees, er det enkelt å utvide konseptet til hele systemet. Den systemomfattende komprimeringen, inline-statistikkinnsamlingen og rapporteringen er nøyaktig den samme som med MTrees. Den eneste forskjellen er omfanget, som man er i en bestemt MTree, mens man er over hele systemet. Resultatene kan kontrolleres ved hjelp av kommandoen "filesys show compression". Et eksempel på dette finnes i avsnitt 2. Systemkomprimeringen "siste 7 dager" og "siste 24 timer" rapporteres i de to siste linjene i resultatdelen i FSC-utdataene.
På DD-er med implementert skynivå deles lagringen inn i aktivt nivå og skynivå, som er to uavhengige dedupliseringsdomener. Brukere kan bare sette inn data på det aktive nivået. Senere kan DDOS-dataflyttingsfunksjoner brukes til å overføre data fra det aktive nivået til skynivået. Dermed håndteres måling og rapportering av plass og kompresjon uavhengig av hverandre i hvert nivå. Men på filnivå skiller vi ikke etter nivå og rapporterer innebygd komprimeringsstatistikk; de er nøyaktig de samme som det vi beskrev i avsnitt 3.1.
Det siste emnet som bør fremheves, er noen av egenskapene til deduplisering, som kalles "global komprimering" i mange Data Domain-dokumenter. Selv om den inneholder ordet "komprimering", er det helt annerledes enn det tradisjonelle begrepet komprimering, som også leveres av DDOS under navnet "lokal komprimering."
Lokal komprimering reduserer størrelsen på et stykke data ved hjelp av en bestemt algoritme (noen typer data er ikke komprimerbare, og bruk av komprimeringsalgoritmer på dem kan øke datastørrelsen litt). Vanligvis, når en algoritme er bestemt, er selve dataene den eneste faktoren for kompresjonsforholdet.
Deduplisering er imidlertid annerledes - det er ikke et lokalt konsept, det er "globalt". Et innkommende datasegment dupliseres mot alle eksisterende datasegmenter i et deduplisert domene, som inkluderer alle dataene på Data Domain-systemer som ikke er skybaserte. Datasegmentet i seg selv spiller ingen rolle i dedupliseringsprosedyren.
I praksis ser vi sjelden høyt dedupliseringsforhold i den første sikkerhetskopien av et datasett. I første sikkerhetskopiering er den store datareduksjonen ofte et resultat av lokal komprimering. Når påfølgende sikkerhetskopier lander på Data Domain, viser deduplisering styrken og blir den dominerende komprimeringsfaktoren. Effektiviteten av deduplisering er avhengig av det faktum at endringshastigheten til et datasett er lav fra sikkerhetskopiering til sikkerhetskopiering. Av denne grunn kan datasett med høye endringsfrekvenser ikke bli godt duplisert. Når sikkerhetskopieringsprogrammet setter inn sine egne metadatabiter (kalt markører av Data Domain) i sikkerhetskopiavbildningene med høy frekvens, kan det også hende at det heller ikke får et godt dedupliseringsforhold. Våre markørhåndteringsteknikker kan hjelpe noen ganger, men ikke alltid.
Gitt disse observasjonene, hva kan vi forvente?
Måling av komprimering er vanskelig i dedupliserte filsystemer, men det er enda vanskeligere i log-strukturerte dedupliserte filsystemer. Vi må forstå hvordan deduplisering fungerer og hvordan komprimeringsstatistikk spores. Kompresjonsforhold er nyttig informasjon for å forstå oppførselen til et bestemt system. Systemeffektivt kompresjonsforhold er det viktigste, pålitelige og informative tiltaket. Den innebygde komprimeringsstatistikken kan også være nyttig, men de kan ikke være mer enn heuristikk under noen omstendigheter.
Vedlegg: Utgang av sampling av "mtree show compression" kommando
Anta at det er en MTree som inneholder 254792,4 GiB data. Den har mottatt 4379,3 GiB nye data de siste 7 dagene, og 78,4 GiB de siste 24 timene (andre tidsintervaller kan spesifiseres). Alternativet "daily" (daglig) rapporterer den interne komprimeringsstatistikken for de siste 33 dagene. Når alternativet "daglig detaljert" er gitt, blir de totale kompresjonsforholdene ytterligere detaljert ved å separere dem i globale og lokale kompresjonsforhold.
Utdata fra Mtree-listen:
# 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 alternativet "daglig":
# 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 alternativet "daglig detaljert":
# 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