De komprimeringstekniker som ingår i en Data Domain använder de senaste teknikerna för att minska det fysiska utrymme som krävs av kunddata. Tekniken och mätningarna av komprimeringsnivåer är i sig komplexa ämnen. I det här dokumentet beskrivs några av terminologierna, kompromisserna och måtten för att bättre förklara de komprimeringstyper som används, terminologi och andra aspekter av komprimering i ett Data Domain-system.
GÄLLER FÖR:
Alla Data Domain-modeller
Uppdaterades senast: Januari 2024
Komprimering är en datareduktionsteknik som syftar till att lagra en datauppsättning med mindre fysiskt utrymme. I Data Domain-system (DDOS) utför vi deduplicering och lokal komprimering för att komprimera användardata. Deduplicering används för att identifiera redundanta datasegment och endast lagra unika datasegment. Lokal komprimering komprimerar de unika datasegmenten ytterligare med vissa komprimeringsalgoritmer, t.ex. lz, gzfast, gz, så vidare. Den övergripande komprimeringen av användardata i DDOS är den gemensamma ansträngningen för deduplicering och lokal komprimering. DDOS använderkomprimeringsförhållandet för att mäta datakomprimeringens effektivitet. I allmänhet är det förhållandet mellan den totala användardatastorleken och den totala storleken på komprimerade data eller den använda fysiska utrymmesstorleken.
Data Domain-filsystemet är ett "loggstrukturerat" dedupliceringsfilsystem. Ett loggstrukturerat filsystem lägger bara till data i systemet, och enbart radering kan inte frigöra fysiskt utrymme. Sådana filsystem förlitar sig på skräpinsamling för att återta utrymme som inte längre behövs. Egenskaperna hos det loggstrukturerade filsystemet och den deduplicerade tekniken tillsammans gör det svårt att tydligt förstå alla aspekter av komprimering i DDOS.
För kompression finns det många aspekter vi kan mäta. I det här dokumentet går vi igenom detaljerna steg för steg för att förstå DDOS-komprimering. Först förklarar vi den övergripande systemkomprimeringseffekten, som berättar för oss den realistiska komprimeringen som uppnås i ett Data Domain-system, mängden användardata, mängden fysiskt utrymme som förbrukas och förhållandet mellan dem. Detta förhållande kallas "systemets effektiva kompressionsförhållande" i detta dokument. DDOS utför infogad deduplicering och spårar statistiken för de ursprungliga användardatasegmenten, unika datasegment efter deduplicering och den lokala komprimeringseffekten på de unika datasegmenten. Denna inlinekomprimeringsstatistik används för att mäta inlinekomprimeringseffekten. Inline-komprimeringsstatistik kan mätas för varje skrivning. DDOS håller också reda på statistiken på olika nivåer; filer, MTrees och hela systemet.
Innehållet i detta dokument kan tillämpas på alla DDOS-versioner fram till publiceringen av detta dokument, upp till DDOS 7.13. Det finns ingen garanti för att allt innehåll är korrekt för framtida utgåvor. I versioner före 5.0 har hela systemet bara en MTree och termen mtree anropas inte uttryckligen.
Den systemomfattande övergripande komprimeringseffekten mäts av systemets effektiva komprimeringsförhållande, vilket är förhållandet mellan användarens datastorlek och storleken på använt fysiskt utrymme. Det rapporteras av CLI-kommandot filesys show compression (FSC) (motsvarande information finns också på UI). Ett exempel på FSC visas nedan:
# 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 effektiva komprimeringsförhållande rapporteras på rad 1 i resultatavsnittet i CLI-utdata. Raden är markerad ovan. Den totala användardatastorleken är märkt som "Pre-Comp". Det totala förbrukade fysiska utrymmet (av både data och metadata) är märkt som "Post-Comp".
Både "Pre-Comp"-numret och "Post-Comp"-numret läses vid körning. FSC synkroniserar implicit hela systemet och frågar sedan efter de två siffrorna. Dessa två tal mäts på samma sätt som kommandot "filesys show space".
Systemets effektiva kompressionsförhållande = Pre-Comp/Post-Comp
Resten av FSC-utdata beskriver inline-komprimeringsstatistiken, och vi diskuterar den senare.
Det finns vissa åtgärder som kan påverka systemets effektiva kompressionsförhållande:
Fastcopy
När en snabbkopia görs från en fil i det aktiva namnområdet (inte en ögonblicksbild) är det en perfekt deduplicering, eftersom det inte behövs något extra fysiskt utrymme för målfilen. Effekten av en snabbkopiering är att vi ökar användardatastorleken utan att använda något ytterligare fysiskt utrymme. Detta ökar systemets effektiva kompressionsförhållande. När många snabbkopior görs kan systemets effektiva komprimeringsgrad bli artificiellt hög.
Virtuell syntetisk
Virtuella syntetiska säkerhetskopior tenderar att visa ett högt effektivt komprimeringsförhållande för systemet. Det beror på att virtuella syntetiska enheter gör logiska fullständiga säkerhetskopior, men överför bara ändrade eller nya data till Data Domain-system. Effekten på systemets effektiva komprimeringsförhållande av virtuell syntetisk är ungefär som effekten av snabbkopiering.
Skriver över
Överskrivningar förbrukar mer fysiskt utrymme men ökar inte den logiska storleken på datauppsättningen, vilket innebär att överskrivningar sänker systemets effektiva komprimeringsförhållande.
Lagra glesa filer
Sparse-filer innehåller stora ”hål” som räknas in i den logiska storleken men som inte använder fysiskt utrymme på grund av komprimering. De kan därför göra att det systemeffektiva komprimeringsförhållandet verkar högt.
Lagra små filer
DDOS lägger till nästan 1 kB overhead för varje fil för vissa interna metadata. När ett system lagrar ett stort antal små filer (storlekar som är mindre än 1 kB eller i ensiffriga kilobyte) drar omkostnaderna för metadata ned det effektiva komprimeringsförhållandet.
Lagra förkomprimerade eller förkrypterade filer
Komprimering och kryptering kan förstärka nivån på dataändringar och minska risken för deduplicering. Sådana filer kan vanligtvis inte dedupliceras på ett bra sätt och sänker systemets effektiva komprimeringsförhållande.
Tar bort
Borttagningar minskar systemets logiska storlek, men systemet återfår inte motsvarande oanvända utrymme förrän skräpinsamling körs. Många borttagna filer gör komprimeringsförhållandet lågt tills skräpinsamling (GC) körs.
Sophämtning (GC) eller rengöring
GC återtar det utrymme som förbrukas av datasegment som inte längre visas av någon fil. Om många filer har tagits bort nyligen kan skräpinsamling öka systemets komprimeringsförhållande genom att minska det fysiska utrymmesbehovet.
Aggressiv tagning av ögonblicksbilder
När vi tar en ögonblicksbild av en MTree ändrar vi inte den logiska storleken på datauppsättningen. Alla datasegment som ögonblicksbilden refererar till måste dock vara låsta, även om alla filer som hämtas av ögonblicksbilden tas bort efter att ögonblicksbilden togs. GC kan inte återta det utrymme som fortfarande behövs av ögonblicksbilder. Om du har många snapshots kan därför systemets effektiva komprimeringsförhållande verka lågt. Ögonblicksbilder är dock användbara funktioner för kraschåterställning. Vi bör aldrig tveka att ta snapshots eller skapa lämpliga snapshot-scheman när det behövs.
DDOS utför deduplicering inline eftersom data skrivs till systemet. Den spårar effekterna av inline deduplicering och lokal komprimering för varje skrivning och ackumulerar statistiken på filnivå. Inline-komprimeringsstatistik per fil aggregeras ytterligare på MTree-nivå och på systemnivå. Komprimering mäts baserat på tre tal i den infogade statistiken:
Baserat på ovanstående tre siffror definierar DDOS ytterligare två komprimeringsförhållanden med fin granularitet:
Den ackumulerade inlinekomprimeringsstatistiken är en del av filmetadata i DDOS och lagras i fil-inoden. DDOS tillhandahåller verktyg för att kontrollera inline-kompressionerna på alla tre nivåerna; fil, MTree och systemomfattande. Vi beskriver dem i följande avsnitt.
3.1 Filkomprimering
Filkomprimering kan kontrolleras med CLI-kommandot "filesys show compression <path>", som rapporterar den ackumulerade komprimeringsstatistiken som lagras i filinoden. När en katalog anges summeras och rapporteras den infogade komprimeringsstatistiken för alla filer i katalogen. I CLI-utdata är raw_bytes märkt som "Original Bytes". pre_lc_size är märkt som "globalt komprimerad". post_lc_bytes är markerat som "Lokalt komprimerat". Övriga omkostnader redovisas som "Metadata". De två exemplen hämtas från en faktisk DD:
Exempel 1: Inline-komprimeringsstatistik för 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
Exempel 2: Infogad komprimeringsstatistik för alla filer i en katalog, inklusive alla 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 rapporterar det övergripande inline-komprimeringsförhållandet i ovanstående CLI-utdata som "byte/storage_used". Man måste dock vara försiktig med att tolka ovanstående information, eftersom den kan vara vilseledande av olika skäl. En orsak är att pre_lc_size och post_lc_size registreras när dataåtgärderna bearbetas. När filen som ursprungligen lade till dessa segment tas bort bör antalet unika datasegment i den återstående filen ökas.
Anta till exempel att en fil sample.file säkerhetskopieras till en Data Domain och i den första säkerhetskopian är komprimeringsinformationen för filen pre_lc_size=10GiB, post_lc_size=5Gib.
Anta sedan att data i den här filen är unika utan datadelning med någon annan fil. I den andra säkerhetskopian av filen antar du vidare att filen får idealisk deduplicering, så att både pre_lc_size och post_lc_size ska vara noll eftersom alla segment i filen redan fanns på systemet. När den första säkerhetskopian tas bort blir den andra säkerhetskopian av filen den enda filen som refererar till 5 GiB för datasegment. I det här fallet bör helst pre_lc_size och post_lc_size för filen i den andra säkerhetskopian uppdateras från att båda är noll till 10 GiB respektive 5 GiB. Det finns dock inget sätt att identifiera vilka filer som ska göras, så den infogade komprimeringsstatistiken för de befintliga filerna lämnas oförändrad.
En annan faktor som påverkar ovanstående siffror är den kumulativa statistiken. När en fil får många överskrivningar är det omöjligt att spåra i vilken utsträckning den kumulativa statistiken återspeglar de skrivningar som introducerade livedata. Således, under lång tid, kan inline-komprimeringsstatistiken endast behandlas som en heuristik för att grovt uppskatta komprimeringen av en viss fil.
Ett annat faktum som är värt att lyfta fram är att inline-komprimeringen av en fil inte kan mätas under ett godtyckligt tidsintervall. Filens infogade komprimeringsstatistik är ett kumulativt resultat och omfattar alla skrivningar som filen någonsin har tagit emot. När en fil får många överskrivningar kan raw_bytes vara mycket större än filens logiska storlek. För glesa filer kan filstorlekarna vara större än "Original Bytes".
3.2 MTree-komprimering
Vi kan kontrollera komprimeringen av ett visst mtree med "mtree show compression" (MSC) CLI-kommandot. De absoluta värdena för inline-komprimeringsstatistiken kumuleras under MTrees livslängd. Med tanke på att livslängden för ett MTree kan vara många år lång, blir dessa värden mindre och mindre informativa med tiden. För att lösa det här problemet använder vi mängden ändringar (delta) i den infogade komprimeringsstatistiken och rapporterar komprimering endast för vissa tidsintervall. Den underliggande metoden är att vi regelbundet dumpar den infogade MTree-komprimeringsstatistiken till en logg. När en klient frågar MTree-komprimering med MSC-kommandot använder vi loggen för att beräkna deltan för siffrorna för komprimeringsrapportering. Som standard rapporterar MSC komprimering för de senaste 7 dagarna och de senaste 24 timmarna, även om när som helst av intresse kan anges.
För att demonstrera, anta följande logg för 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
Då är komprimeringen av MTree A för den här timmen:
g_comp = (12000-11000)/(200-100) = 10x l_comp = (200-100)/(100-50) = 2x overall compression ratio = (12000-11000)/(100-50) = 20x
Ovanstående beräkning av komprimeringsförhållandet gör ingenting med datauppsättningens storlek. Ovanstående mtree kanske till exempel bara har 500 GB logiska data.
MSC har stöd för alternativen "daily" och "daily-detailed", liksom kommandot "filesys show compression". När "daily" anges rapporterar kommandot den dagliga komprimeringen i kalenderformat. Dagliga delta av raw_bytes och post_lc_size används för att beräkna det dagliga komprimeringsförhållandet. När "daily-detailed" anges visar kommandot alla tre deltan (i raw_bytes, pre_lc_size respektive post_lc_size) för varje dag. Den beräknar också g_comp och l_comp tillsammans med den totala komprimeringsfaktorn.
Exempelresultat från dessa system finns i tillägget.
3.3 Systemkomprimering
När vi väl förstår hur komprimering rapporteras på MTrees är det enkelt att utvidga konceptet till hela systemet. Den systemomfattande komprimeringen, inline-statistikinsamlingen och rapporteringen är exakt densamma som med MTrees. Den enda skillnaden är omfånget, eftersom man är i ett visst MTree, medan man är över hela systemet. Resultaten kan kontrolleras med hjälp av kommandot "filesys show compression". Ett exempel på detta finns i avsnitt 2. Systemkomprimeringen "senaste 7 dagarna" och "senaste 24 timmarna" rapporteras på de två sista raderna i resultatavsnittet i FSC-utdata.
På DD:er med molnnivån implementerad är lagringen uppdelad i den aktiva nivån och molnnivån, som är två oberoende dedupliceringsdomäner. Användare kan bara mata in data på den aktiva nivån. Senare kan DDOS-dataförflyttningsfunktioner användas för att migrera data från den aktiva nivån till molnnivån. På så sätt hanteras utrymmes- och kompressionsmätning och rapportering oberoende av varandra i varje nivå. Men på filnivå skiljer vi inte på nivå och rapporterar inline-komprimeringsstatistik. De är exakt desamma som vi beskrev i avsnitt 3.1.
Det sista ämnet att lyfta fram är några av egenskaperna hos deduplicering, som kallas "global komprimering" i många Data Domain-dokument. Även om det innehåller ordet "komprimering" är det helt annorlunda än det traditionella begreppet komprimering, som också tillhandahålls av DDOS under namnet "lokal komprimering".
Lokal komprimering minskar storleken på en databit med hjälp av en viss algoritm (vissa typer av data är inte komprimerbara och användning av komprimeringsalgoritmer på dem kan öka datastorleken något). Vanligtvis, när en algoritm väl har bestämts, är själva data den enda faktorn för komprimeringsförhållandet.
Deduplicering är dock annorlunda – det är inte ett lokalt koncept, det är "globalt". Ett inkommande datasegment dedupliceras mot alla befintliga datasegment i en deduplicerad domän, som innehåller alla data i Data Domain-system som inte är molnbaserade. Själva datasegmentet spelar ingen roll i dedupliceringsproceduren.
I praktiken ser vi sällan höga dedupliceringsförhållanden i den första säkerhetskopieringen av en datauppsättning. Vid inledande säkerhetskopiering kommer ofta den största datareduceringen från lokal komprimering. När efterföljande säkerhetskopieringar hamnar på Data Domain visar dedupliceringen sin styrka och blir den dominerande faktorn för komprimering. Dedupliceringens effektivitet beror på det faktum att ändringshastigheten för en datauppsättning är låg från säkerhetskopiering till säkerhetskopiering. Av denna anledning kan datauppsättningar med hög förändringsfrekvens inte dedupliceras väl. När säkerhetskopieringsprogrammet infogar sina egna metadatasegment (kallas markörer av Data Domain) i säkerhetskopieringsbilderna med hög frekvens kanske det inte heller får ett bra dedupliceringsförhållande. Våra tekniker för markeringshantering kan hjälpa ibland, men inte alltid.
Med tanke på dessa observationer, vad kan vi förvänta oss?
Det är svårt att mäta komprimering i deduplicerade filsystem, men det är ännu svårare i loggstrukturerade deduplicerade filsystem. Vi måste förstå hur deduplicering fungerar och hur komprimeringsstatistik spåras. Komprimeringsförhållanden är användbar information för att förstå beteendet hos ett visst system. Systemets effektiva kompressionsförhållande är det viktigaste, mest tillförlitliga och mest informativa måttet. Inline-komprimeringsstatistiken kan också vara till hjälp, men den kanske inte är mer än heuristik under vissa omständigheter.
Bilaga: Exempel på utdata från "mtree show compression" kommando:
Anta att det finns ett MTree som innehåller 254792,4 GiB data. Den har tagit emot 4379,3 GiB nya data under de senaste 7 dagarna och 78,4 GiB under de senaste 24 timmarna (andra tidsintervall kan anges). Alternativet daily rapporterar inlinekomprimeringsstatistiken för de senaste 33 dagarna. När alternativet "daglig-detaljerad" tillhandahålls, specificeras de totala kompressionsförhållandena ytterligare genom att dela upp dem i globala och lokala kompressionsförhållanden.
Utdata från Mtree-listan:
# 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 "daily":
# 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 "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