Techniky komprese obsažené v systému Data Domain využívají nejmodernější techniky ke zmenšení fyzického prostoru vyžadovaného zákaznickými daty. Technologie a měření úrovní komprese jsou tedy složitá témata. Tento dokument pojednává o některých terminologiích, kompromisech a opatřeních s cílem lépe vysvětlit používané typy komprese, terminologii a další aspekty komprese v systému Data Domain.
PLATÍ PRO:
Všechny modely Data Domain
Poslední aktualizace: Leden 2024
Komprese je technologie redukce dat, jejímž cílem je ukládat datovou sadu s využitím menšího fyzického prostoru. V systémech Data Domain (DDOS) provádíme deduplikaci a místní kompresi pro kompresi uživatelských dat. Deduplikace identifikuje redundantní datové segmenty a uloží pouze ty jedinečné. Místní komprese dále komprimuje jedinečné segmenty dat pomocí určitých kompresních algoritmů, jako je například lz, gzfast, gza tak dále. Celková komprese uživatelských dat v systému DDOS je společným úsilím deduplikace a místní komprese. Systém DDOS využívá k měření účinnosti komprese dat tzv. kompresní poměr. Obecně se jedná o poměr celkové velikosti uživatelských dat k celkové velikosti komprimovaných dat nebo velikosti využitého fyzického prostoru.
Souborový systém Data Domain je systém souborů s "logovou strukturou". Systém souborů strukturovaný do protokolu pouze přidává data do systému a samotné smazání neuvolní fyzické místo. Tyto systémy souborů se při opětovném získávání nepotřebného místa spoléhají na funkci garbage collection. Vlastnosti souborového systému se strukturou protokolu a technologie deduplikace v kombinaci ztěžují jasné pochopení všech aspektů komprese v systému DDOS.
Pokud jde o kompresi, existuje mnoho aspektů, které můžeme měřit. V tomto dokumentu podrobně popisujeme podrobnosti, které vám pomohou pochopit kompresi DDOS. Nejprve vysvětlíme celkový efekt komprese systému, což nám říká realistickou kompresi dosaženou v systému Data Domain, množství uživatelských dat, množství spotřebovaného fyzického prostoru a jejich poměr. Tento poměr se v tomto dokumentu nazývá "systémově efektivní kompresní poměr". Systém DDOS provádí deduplikaci přímo na webu a sleduje statistiky původních segmentů uživatelských dat, jedinečných datových segmentů po odstranění duplicit a efektu místní komprese u jedinečných datových segmentů. Tyto statistiky vložené komprese se používají k měření účinnosti vložené komprese. Pro každý zápis lze měřit statistiky vložené komprese. DDOS také sleduje statistiky na různých úrovních; soubory, MTree a celý systém.
Obsah tohoto dokumentu lze použít na všechny verze systému DDOS až do jeho vydání, a to až do verze DDOS 7.13. Nezaručujeme, že veškerý zde uvedený obsah bude přesně platný i pro budoucí verze. Ve verzích starších než 5.0 má celý systém pouze jeden fond MTree a termín mtree není explicitně vyvolán.
Celkový efekt komprese v celém systému se měří efektivním kompresním poměrem systému, což je poměr velikosti uživatelských dat k velikosti využitého fyzického prostoru. Hlásí ji příkazem příkazového řádku filesys show compression (FSC) (odpovídající informace jsou také k dispozici v uživatelském rozhraní). Ukázkový výstup FSC je uveden níže:
# 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.
Efektivní kompresní poměr systému je uveden v řádku 1 výsledkové části ve výstupu CLI. Řádek je zvýrazněn výše. Celková velikost uživatelských dat je označena jako "Pre-Comp". Celkový spotřebovaný fyzický prostor (podle dat i metadat) je označen jako "Post-Comp".
Číslo "Pre-Comp" a číslo "Post-Comp" se načítají za běhu. Příkaz FSC implicitně synchronizuje celý systém a poté se dotáže na tyto dva údaje. Tato dvě čísla se měří stejným způsobem jako příkaz "filesys show space".
Systémově efektivní kompresní poměr = Pre-Comp/Post-Comp
Zbytek výstupu FSC popisuje statistiky inline komprese a probereme je později.
Existují některé operace, které mohou ovlivnit efektivní kompresní poměr systému:
Fastcopy (Fastcopy)
Když se fastcopy provádí ze souboru v aktivním oboru názvů (nikoli ze snímku), jedná se o dokonalou deduplikaci, protože pro cílový soubor není potřeba žádný další fyzický prostor. Důsledkem operace fastcopy je to, že je možné zvětšit velikost uživatelských dat, aniž by se spotřebovalo další fyzické místo. Tím se zvyšuje efektivní kompresní poměr systému. Po provedení mnoha fastcopy se může efektivní kompresní poměr systému uměle zvýšit.
Virtual Synthetic
Zálohy Virtual Synthetic obvykle vykazují vysoký efektivní kompresní poměr systému. Důvodem je to, že Virtual Synthetic vytváří logické úplné zálohy, ale pouze přenáší změněná nebo nová data do systémů Data Domain. Dopad virtuální syntetiky na efektivní kompresní poměr systému je podobný efektu fastcopy.
Přepíše
Přepsání spotřebovává více fyzického prostoru, ale nezvětšuje logickou velikost datové sady, proto přepsání snižuje efektivní kompresní poměr systému.
Ukládání řídkých souborů
Řídké soubory obsahují velké „díry“, které se započítávají do logické velikosti, ale kvůli kompresi nespotřebovávají fyzické místo. Kvůli tomu se může účinný kompresní poměr systému jevit jako vysoký.
Ukládání malých souborů
Systém DDOS přidává každému souboru režii téměř 1 kB pro určitá interní metadata. Pokud systém ukládá velký počet malých souborů (o velikosti menší než 1 kB nebo v jednociferných kilobajtech), režie metadat snižuje efektivní kompresní poměr.
Ukládání předem komprimovaných nebo předšifrovaných souborů
Komprese a šifrování mohou zesílit úroveň změny dat a snížit možnost deduplikace. Takové soubory obvykle nelze dobře deduplikovat a snížit efektivní kompresní poměr systému.
Odstraní
Odstranění zmenšují logickou velikost systému, ale dokud se nespustí funkce garbage collection, systém nezíská nevyužité místo zpět. Mnoho odstraněných souborů snižuje kompresní poměr, dokud se nespustí uvolňování paměti (GC).
Uvolňování paměti (GC) nebo čištění
GC uvolní místo spotřebované datovými segmenty, které už žádný soubor nevidí. Pokud bylo v nedávné době odstraněno velké množství souborů, funkce GC může snížením spotřeby fyzického místa zvýšit účinný kompresní poměr systému.
Agresivní pořizování snapshotů
Když pořídíme snímek MTree, nezměníme logickou velikost datové sady. Všechny datové segmenty, na které snímek odkazuje, však musí být uzamčeny, a to i v případě, že všechny soubory zachycené snímkem budou po pořízení snímku odstraněny. GC nemůže uvolnit místo, které je stále potřeba snapshoty. Proto může mít velký počet snímků způsobit, že se efektivní kompresní poměr systému bude jevit jako nízký. Snapshoty jsou však užitečným zařízením pro zotavení po chybě. V případě potřeby bychom s pořizováním snapshotů nebo nastavením vhodných plánů snapshotů neměli nikdy otálet.
Systém DDOS provádí deduplikaci přímo při zápisu dat do systému. Sleduje účinky vložené deduplikace a místní komprese pro každý zápis a shromažďuje statistiky na úrovni souboru. Statistiky vložené komprese jednotlivých souborů jsou dále agregovány na úrovni fondu MTree a na úrovni systému. Komprese se měří na základě tří čísel ve vložených statistikách:
Na základě výše uvedených tří čísel definuje DDOS další dva kompresní poměry s jemnou členitostí:
Nashromážděné statistiky vložené komprese jsou součástí metadat souboru v systému DDOS a ukládají se do struktury inode souboru. DDOS poskytuje nástroje pro kontrolu vložených kompresí na všech třech úrovních; soubor, MTree a v celém systému. Podrobně je popisujeme v následujících částech.
3.1 Komprese souborů Kompresi
souborů lze zkontrolovat příkazem CLI "filesys show compression <path>", který hlásí kumulované statistiky komprese uložené v inode souboru. Po zadání adresáře se sečtou a nahlásí vložené statistiky komprese všech souborů v tomto adresáři. Ve výstupu rozhraní příkazového řádku je raw_bytes označen jako "Original Bytes"; pre_lc_size je označen jako "Globálně komprimovaný"; post_lc_bytes je označen jako "Lokálně komprimovaný"; ostatní režijní náklady jsou hlášeny jako "metadata". Tyto dva příklady jsou zachyceny ze skutečného DD:
Example 1: Statistika vložené komprese souboru
# 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
Příklad 2: Statistika vložené komprese všech souborů v adresáři, včetně všech podadresářů
# 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
Systém hlásí celkový poměr vložené komprese ve výše uvedeném výstupu rozhraní příkazového řádku jako "bajty/storage_used". Při interpretaci výše uvedených informací je však třeba postupovat opatrně, jelikož mohou být z různých důvodů zavádějící. Jedním z důvodů je, že údaje pre_lc_size a post_lc_size se zaznamenávají ve chvíli, kdy dojde ke zpracování dat. Pokud dojde ke smazání souboru, do kterého byly tyto segmenty původně přidány, měl by se počet jedinečných segmentů dat ve zbývajícím souboru zvýšit.
Předpokládejme například, že soubor sample.file je zálohován do systému Data Domain a v první záloze budou informace o kompresi souboru pre_lc_size=10GiB, post_lc_size=5Gib.
Dále předpokládejme, že data tohoto souboru jsou jedinečná a data nejsou sdílena s žádným jiným souborem. Dále předpokládejte, že při druhé záloze souboru dojde k ideální deduplikaci, takže hodnoty pre_lc_size i post_lc_size by měly být nulové, protože všechny segmenty souboru již v systému existovaly. Po odstranění první zálohy se druhá záloha souboru stane jediným souborem, který odkazuje na 5 GiB datových segmentů. V takovém případě by se v ideálním případě měly aktualizovat pre_lc_size a post_lc_size souboru ve druhé záloze z nuly na 10 GiB a 5 GiB. Neexistuje však žádný způsob, jak zjistit, pro které soubory by to mělo být provedeno, takže statistika vložené komprese stávajících souborů zůstane beze změny.
Dalším faktorem, který ovlivňuje výše uvedená čísla, jsou kumulativní statistiky. Když dojde k velkému počtu přepsání souboru, není možné sledovat, do jaké míry kumulativní statistiky odrážejí zápisy, které zavedly živá data. Po dlouhou dobu lze tedy se statistikou vložené komprese zacházet pouze jako s heuristikou pro hrubý odhad komprese konkrétního souboru.
Dalším faktem, který stojí za zmínku, je, že inline kompresi souboru nelze měřit pro libovolný časový interval. Statistika vložené komprese souborů je kumulativním výsledkem a zahrnuje všechny zápisy, které kdy soubor přijal. Pokud dojde k velkému počtu přepsání souboru, může být raw_bytes mnohem větší než logická velikost souboru. U řídkých souborů může být velikost souborů větší než "původní bajty".
3.2 Komprese
MTreeKompresi konkrétního fondu MTree můžeme zkontrolovat pomocí "mtree show compression" (MSC) Příkaz CLI. Absolutní hodnoty statistik vložené komprese se kumulují po celou dobu životnosti fondu MTree. Vzhledem k tomu, že životnost fondu MTree může být dlouhá mnoho let, stávají se tyto hodnoty v průběhu času stále méně vypovídajícími. K vyřešení tohoto problému používáme množství změn (rozdíly) statistik vložené komprese a kompresi sestav pouze pro určité časové intervaly. Základní přístup spočívá v tom, že pravidelně vypisujeme statistiku vložené komprese MTree do protokolu. Když se klient dotazuje na kompresi MTree pomocí příkazu MSC, použijeme protokol k výpočtu rozdílů čísel pro vytváření sestav komprese. Ve výchozím nastavení MSC hlásí kompresi za posledních 7 dní a posledních 24 hodin, i když je možné zadat kdykoli požadované období.
Pro ukázku předpokládejme následující protokol pro 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
Pak komprese MTree A pro tuto hodinu je:
g_comp = (12000-11000)/(200-100) = 10x l_comp = (200-100)/(100-50) = 2x overall compression ratio = (12000-11000)/(100-50) = 20x
Výše uvedený výpočet kompresního poměru nedělá nic s velikostí datové sady. Například výše uvedený fond MTree může obsahovat pouze 500 GB logických dat.
MSC podporuje možnosti "daily" a "daily-detailed", stejně jako příkaz "filesys show compression". Je-li zadána hodnota "daily", příkaz hlásí denní kompresi kalendářním způsobem. K výpočtu denního kompresního poměru využívá denní řetězce delta údajů raw_bytes a post_lc_size. Je-li zadán parametr "denní-podrobný", příkaz zobrazí všechny tři rozdíly (raw_bytes, pre_lc_size a post_lc_size) pro každý den. Počítá také g_comp a l_comp spolu s celkovým kompresním faktorem.
Ukázka výstupu z těchto systémů je v příloze.
3.3 Systémová komprese
Jakmile pochopíme, jak je komprese hlášena na MTree, je snadné rozšířit tento koncept na celý systém. Sběr a hlášení vložených statistik komprese v rámci celého systému jsou úplně stejné jako u MTree. Jediným rozdílem je rozsah, protože jeden je v konkrétním MTree, zatímco druhý je nad celým systémem. Výsledky lze zkontrolovat pomocí příkazu "filesys show compression". Příklad lze nalézt v části 2. Komprese systému "posledních 7 dní" a "posledních 24 hodin" je hlášena na posledních dvou řádcích části výsledků ve výstupu FSC.
V systémech DD s implementovanou cloudovou vrstvou se úložiště rozdělí na aktivní vrstvu a cloudovou vrstvu, což jsou dvě nezávislé domény pro odstranění duplicitních dat. Uživatelé mohou vkládat data pouze do aktivní vrstvy. Později lze funkce přesunu dat DDOS použít k migraci dat z aktivní vrstvy do cloudové vrstvy. Prostorové a kompresní měření a reportování se tak v každé vrstvě zpracovávají nezávisle. Na úrovni souboru ale nerozlišujeme podle úrovně a nehlásíme statistiky vložené komprese. jsou naprosto stejné jako ty, které jsme popsali v oddíle 3.1.
Posledním tématem, které je třeba zdůraznit, jsou některé charakteristiky deduplikace, která se v mnoha dokumentech Data Domain nazývá "globální komprese". Přestože obsahuje slovo "komprese", je zcela odlišný od tradičního konceptu komprese, který DDOS také poskytuje pod názvem "místní komprese".
Lokální komprese zmenšuje velikost části dat pomocí určitého algoritmu (některé druhy dat nejsou komprimovatelné a použití kompresních algoritmů na ně může mírně zvětšit velikost dat). Obvykle, jakmile je rozhodnuto o algoritmu, samotná data jsou jediným faktorem kompresního poměru.
Deduplikace je však jiná – není to lokální koncept, je to "globální". Příchozí datový segment je odstraněn proti všem existujícím segmentům dat v deduplikované doméně, což zahrnuje všechna data v jiných než cloudových systémech Data Domain. Samotný datový segment nehraje v postupu odstranění duplicit žádnou roli.
V praxi se jen zřídka setkáváme s vysokým poměrem deduplikace při počátečním zálohování datové sady. Při počátečních zálohách často hlavní snížení objemu dat pochází z místní komprese. Když se do systému Data Domain dostanou další zálohy, deduplikace ukáže svou sílu a stane se dominantním faktorem komprese. Efektivita odstranění duplicitních dat závisí na skutečnosti, že rychlost změny datové sady mezi zálohováním je nízká. Z tohoto důvodu nelze datové sady s vysokou mírou změn dobře deduplikovat. Když zálohovací aplikace vkládá do bitových kopií záloh své vlastní části metadat (označované systémem Data Domain jako značky) s vysokou frekvencí, nemusí také dosáhnout dobrého poměru deduplikace. Naše techniky manipulace se značkami mohou někdy pomoci, ale ne vždy.
Co můžeme na základě těchto pozorování očekávat?
Měření komprese je obtížné v deduplikovaných souborových systémech, ale ještě obtížnější je v logaritmicky strukturovaných deduplikovaných souborových systémech. Musíme pochopit, jak deduplikace funguje a jak jsou sledovány statistiky komprese. Kompresní poměry jsou užitečné informace pro pochopení chování konkrétního systému. Efektivní kompresní poměr systému je nejdůležitějším, nejspolehlivějším a nejinformativnějším měřítkem. Užitečná může být i statistika vložené komprese, ale za určitých okolností nemusí být ničím jiným než heuristikou.
Příloha: Ukázkový výstup "mtree show compression" Předpokládejme
, že existuje fond MTree, který obsahuje 254792,4 GiB dat. Za posledních 7 dní obdržel 4379,3 GiB nových dat a za posledních 24 hodin 78,4 GiB (je možné zadat jiné časové intervaly). Možnost „daily“ nahlásí statistiky vložené komprese za posledních 33 dní. Pokud je k dispozici možnost "denně podrobné", celkové kompresní poměry jsou dále podrobnější tak, že se rozdělí na globální a místní kompresní poměry.
Výstup seznamu MTree:
# 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)
------------- -------- --------- ----------- ---------- -------------
S možností "denně":
# 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
S možností "denně podrobné":
# 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