Data Domain: Principy komprese systému Data Domain

Techniky komprese v systému Data Domain využívají nejmodernější techniky ke zmenšení fyzického prostoru vyžadovaného zálohovanými daty. Technologie a měření úrovní komprese jsou tedy složitá témata.

Tento článek pojednává o některých terminologiích, kompromisech a opatřeních pro lepší vysvětlení použitého typu komprese a dalších aspektů komprese v prostředí Data Domain.

PLATÍ PRO: Všechny modely Data Domain

Úvod:

Poslední aktualizace: Leden 2024

• Komprese je technologie redukce dat, jejímž cílem je uložit datovou sadu s využitím menšího fyzického prostoru.
• V systémech Data Domain (DDOS) se deduplikace a místní komprese provádí za účelem komprese uživatelských dat. Deduplikace neboli "deduplikace" se používá k identifikaci redundantních datových segmentů a ukládání pouze jedinečných datových segmentů.
• 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.

U komprese existuje mnoho aspektů, které lze měřit.

Tento článek popisuje podrobné podrobnosti, které vám pomohou pochopit kompresi DDOS.

• Nejprve je vysvětlen celkový efekt komprese systému, což nám sděluje 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 článku nazývá "systémově efektivní kompresní poměr".
• DDOS provádí deduplikaci přímo a sleduje statistiky původních segmentů uživatelských dat, jedinečných datových segmentů po deduplikaci 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 MTreesa celý systém.

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 mtree a termín mtree není explicitně vyvolán.

Komprese: Celkový efekt systému:

Celkový kompresní efekt celého systému je měřen efektivním kompresním poměrem, což je poměr velikosti uživatelských dat k velikosti využitého fyzického prostoru. Uvádí to "filesys show compression" (FSC) CLI (odpovídající informace jsou také k dispozici v uživatelském rozhraní). Ukázkový výstup FSC je zobrazen 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. FSC implicitně synchronizuje celý systém a pak se dotazuje na dvě čísla.
    • Tato dvě čísla se měří stejným způsobem jako "filesys show space" příkaz.
    • Efektivní kompresní poměr systému = Pre-Comp/Post-Comp

Existují některé operace, které mohou ovlivnit efektivní kompresní poměr systému:

• Rychlá kopie
  • Když a fastcopy se 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. Účinek fastcopy je, že se zvětší velikost uživatelských dat, aniž by se spotřeboval další fyzický prostor. Tím se zvyšuje efektivní kompresní poměr systému. Když mnoho fastcopies jsou hotové, efektivní kompresní poměr systému se může 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 na systém je podobný účinku 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řepisy snižují 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ředkomprimovaný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ž je pořízen snímek Mtree , logická velikost datové sady se nezmění. 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 znovu uvolnit místo, které snapshoty stále potřebují, a velký počet snapshotů může způsobit, že efektivní kompresní poměr systému bude vypadat nízký. Snapshoty jsou však užitečným zařízením pro zotavení po chybě. Nikdy neváhejte pořizovat snapshoty nebo v případě potřeby nastavit správné plány snapshotů.

Komprese: Vložené statistiky:

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 v mtree a na úrovni systému. Komprese se měří na základě tří čísel ve vložených statistikách:

• Délka každého zápisu: raw_bytes 
• The length of all unique segments: pre_lc_size
• Délka místně komprimovaných jedinečných segmentů: post_lc_size

• • Globální komprese (g_comp)
    • Rovná se (raw_bytes/pre_lc_size) a odráží poměr deduplikace
  • Lokální komprese (l_comp)
    • Rovná se (pre_lc_size/post_lc_size) a odráží účinek algoritmu lokální komprese

Kumulované statistiky vložené komprese jsou součástí metadat souboru v systému DDOS a jsou uloženy v souboru inode. DDOS poskytuje nástroje pro kontrolu vložených kompresí na všech třech úrovních; Soubor MTreea v celém systému. Ty jsou podrobně popsány v následujících částech.

Komprese souborů:

• • Kompresi souboru lze zkontrolovat pomocí "filesys show compression <path>" CLI, který hlásí kumulované statistiky komprese uložené v souboru inode.
  • 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 raw_bytes je označen jako "Původní bajty", pre_lc_size je označen jako "Globálně komprimovaný", post_lc_bytes je označen jako "Místně komprimovaný". Ostatní režijní náklady jsou hlášeny jako metadata. Tyto dva příklady jsou zachyceny z produkčního systému DD:

Příklad 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 "bytes/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 pre_lc_size a post_lc_size jsou zaznamenány v době zpracování datových operací.
    • 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 ukázkový soubor je zálohován do systému Data Domain a v první záloze jsou informace o kompresi souboru pre_lc_size= 10 GiB, post_lc_size= 5 Gib.

• • • Dále předpokládejme, že data tohoto souboru jsou jedinečná a data nejsou sdílena s žádným jiným souborem.
    • Při druhé záloze souboru dále předpokládejte, že soubor získá ideální deduplikaci, takže oba pre_lc_size a post_lc_size by měla 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 tomto případě by v ideálním případě pre_lc_size a post_lc_size souboru ve druhé záloze by se měl aktualizovat 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.
  • Když dojde k velkému počtu přepsání souboru, raw_bytes může být mnohem větší než logická velikost souboru. U řídkých souborů může být velikost souborů větší než "původní bajty".

Komprese MTree:

• • Komprese konkrétního mtree lze zkontrolovat pomocí "mtree show compression" (MSC) Příkaz CLI.
  • Absolutní hodnoty statistik vložené komprese se kumulují po celou dobu životnosti MTree.
  • Vzhledem k tomu, že životnost MTree může trvat mnoho let, tyto hodnoty se postupem času stávají méně a méně informativními.
  • K vyřešení tohoto problému se používá množství změn (rozdíly) statistik vložené komprese a komprese sestav pouze pro určité časové intervaly.
  • Základním přístupem je, že MTree Statistiky vložené komprese se pravidelně ukládají do protokolu.
  • Když se klient dotazuje na kompresi MTree pomocí MSC se protokol používá k výpočtu rozdílů čísel pro vytváření sestav komprese.
  • Ve výchozím nastavení MSC Komprese sestav za posledních 7 dní a posledních 24 hodin, i když je možné zadat jakékoli časové období, které vás zajímá.

Pro demonstraci předpokládejme následující protokol pro MTree Odpověď:

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

Poté 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 "filesys show compression" příkaz.
  • Je-li zadána hodnota "daily", příkaz hlásí denní kompresi kalendářním způsobem.
  • Využívá denní delty raw_bytes a post_lc_size pro výpočet denního kompresního poměru.
  • Je-li zadán parametr "daily-detailed", příkaz zobrazí všechny tři rozdíly (z raw_bytes, pre_lc_sizea post_lc_size, resp.) pro každý den. Rovněž vypočítá g_comp a l_comp spolu s celkovým kompresním faktorem.

Ukázkový výstup z těchto systémů je uveden v příloze níže.

Komprese systému:

• • Jakmile je komprese hlášena na MTrees je srozumitelné, je jednoduché rozšířit koncept na celý systém.
  • Sběr a vykazování inline statistik komprese v rámci celého systému jsou úplně stejné jako u MTrees.
  • Jediným rozdílem je rozsah, jak je tomu v konkrétním případě MTree, zatímco jeden je nad celým systémem.
  • Výsledky lze zkontrolovat pomocí tlačítka "filesys show compression" příkaz.
  • 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ů v FSC .

Vrstva Cloud:

• 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 se ale nerozlišuje podle statistik vložené komprese vrstev a sestav, ty jsou úplně stejné jako ty, které jsou popsány v části 3.1.

Odstranění duplicit:

Posledním tématem, které je třeba zdůraznit, jsou některé charakteristiky deduplikace, která se v mnoha článcích 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, 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 datovým segmentům 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 vysoký poměr odstranění duplicit při počáteční záloze datové sady vyskytuje jen zřídka. 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ůžete vzhledem k těmto pozorováním očekávat:

• Počáteční zálohy mohou dosáhnout pouze malého efektivního kompresního poměru systému, často 2x nebo 3x. Deduplikace má obvykle malou příležitost ukázat svou sílu při počátečních zálohách.
• Globální kompresní poměr přírůstkového zálohování je nižší než kompresní poměr odpovídajícího úplného zálohování. Důvodem je, že přírůstkové zálohování obsahuje ve srovnání s okamžitým starším zálohováním pouze změněné nebo nové soubory. Globální kompresní poměr závisí na procentuálním podílu nových dat v rámci přírůstkového zálohování.
• Poměr deduplikace úplné zálohy (nepočáteční) může být v některých scénářích také nízký. Mezi často pozorované scénáře patří:
  • Vysoká rychlost změn v zálohovaných datech
  • V datové sadě převládají malé soubory (méně než 5 MiB)
  • Zálohovací aplikace přidávající velké množství značek umístěných blízko sebe
  • Zálohy databáze, které jsou přírůstkové nebo používají malé bloky
  • Pokud je u úplné zálohy s nízkou rychlostí změn dat pozorován nízký kompresní poměr, zkontrolujte, zda platí jeden z výše uvedených případů, nebo zda je nutná další analýza.
• Komprese pozdější bitové kopie zálohy není vždy lepší než původní bitová kopie. Po sobě jdoucí bitové kopie záloh mohou vykazovat vysoký poměr deduplikace, protože původní a dřívější záložní bitové kopie již přidaly do systému většinu dat. Když jsou odstraněny všechny starší bitové kopie zálohy, globální a místní kompresní poměr nejstarší existující bitové kopie zálohy může být stále vysoký, ale to znamená pouze to, že při přidání do systému došlo k dobré deduplikaci, nic jiného. Při odstranění souboru, který má vysoký globální a místní kompresní poměr a je poslední záložní bitovou kopií určité datové sady, může uvolnit více místa, než je velikost odvozená z kompresního poměru.
• Kompresní poměry stejné datové sady v různých systémech nelze porovnávat bez ohledu na způsob, jakým je datová sada do těchto systémů přidána. Je to proto, že každý systém je nezávislou doménou odstranění duplicit. Neočekává se, že dva různé systémy DD budou mít stejné nebo dokonce nutně podobné kompresní poměry, a to ani v případě, že jsou jejich datové sady stejné.

Shrnutí:

• 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.
• Je třeba pochopit, jak odstranění duplicit funguje a jak se sledují 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 MTree obsahující 254 792,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.

Skript mtree Výstup seznamu:

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

MSC (bez možností):

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