Data Domain: Förstå komprimering i Data Domain

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 säkerhetskopierade data. Tekniken och mätningarna av komprimeringsnivåer är i sig komplexa ämnen.

I den här artikeln beskrivs några terminologier, kompromisser och åtgärder för att bättre förklara vilken komprimeringstyp som används och andra aspekter av komprimering i en Data Domain-miljö.

GÄLLER FÖR: Alla Data Domain-modeller

Inledning:

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örs deduplicering och lokal komprimering för att komprimera användardata. Deduplicering, eller "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 som kan mätas.

I den här artikeln beskrivs steg-för-steg-information för att förstå DDOS-komprimering.

• Först förklaras den övergripande systemkomprimeringseffekten, vilket talar om för oss den realistiska komprimering 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.
• Det här förhållandet kallas "systemeffektivt kompressionsförhållande" i den här artikeln.
• 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 spårar också statistiken på olika nivåer: Filer MTreesoch hela systemet.

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 inte uttryckligen framhävs.

Komprimering: Systemets övergripande effekt:

Den systemomfattande övergripande komprimeringseffekten mäts med det effektiva komprimeringsförhållandet, som är förhållandet mellan användarens datastorlek och storleken på använt fysiskt utrymme. Det rapporteras av "filesys show compression" (FSC) CLI-kommando (motsvarande information finns också på UI). Ett exempel på utdata av 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 de två talen.
    • Dessa två tal mäts på samma sätt som "filesys show space"-kommandot.
    • Systemets effektiva kompressionsförhållande = Före Comp/Post-Comp

Det finns vissa åtgärder som kan påverka systemets effektiva kompressionsförhållande:

• Snabb kopiering
  • När en fastcopy görs från en fil i det aktiva namnområdet (inte en ögonblicksbild), är det en perfekt deduplicering, eftersom inget extra fysiskt utrymme behövs för målfilen. Effekten av en fastcopy är att användardatastorleken ökas utan att förbruka ytterligare fysiskt utrymme. Detta ökar systemets effektiva kompressionsförhållande. När många fastcopies görs, kan systemets effektiva kompressionsförhållande bli artificiellt högt.
• 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 kompressionsförhållande av virtuell syntetisk är ungefär som effekten av fastcopy.
• 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 en ögonblicksbild av en Mtree tas ändras 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 snapshots. Om du har många snapshots kan systemets effektiva komprimeringsförhållande verka lågt. Ögonblicksbilder är dock användbara funktioner för kraschåterställning. Tveka aldrig att ta snapshots eller ställa in ordentliga snapshot-scheman när det behövs.

Komprimering: Inline-statistik:

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:

• Längden på varje skrivning: raw_bytes 
• The length of all unique segments: pre_lc_size
• Längden på lokalt komprimerade unika segment: post_lc_size

• • Global komprimering (g_comp)
    • Lika med (raw_bytes/pre_lc_size) och återspeglar dedupliceringsförhållandet
  • Lokal komprimering (l_comp)
    • Lika med (pre_lc_size/post_lc_size) och återspeglar effekten av den lokala komprimeringsalgoritmen

Den ackumulerade infogade komprimeringsstatistiken är en del av filens metadata i DDOS och lagras i filen inode. DDOS tillhandahåller verktyg för att kontrollera inline-kompressionerna på alla tre nivåerna; Filen MTreeoch systemomfattande. Dessa beskrivs i följande avsnitt.

Filkomprimering:

• • Filkomprimering kan kontrolleras med "filesys show compression <path>" CLI-kommando, som rapporterar den ackumulerade komprimeringsstatistiken som lagras i filen inode.
  • När en katalog anges summeras och rapporteras den infogade komprimeringsstatistiken för alla filer i katalogen.
  • I CLI-utdata, raw_bytes är märkt som "Ursprungliga byte", pre_lc_size är märkt som "globalt komprimerad", post_lc_bytes är markerad som "Lokalt komprimerad". De andra omkostnaderna rapporteras som "metadata". De två exemplen hämtas från en produktions-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 anledning är att pre_lc_size och post_lc_size registreras vid den tidpunkt då dataoperationerna behandlas.
    • 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 filexempelfil säkerhetskopieras till en Data Domain och att komprimeringsinformationen för filen är i den första säkerhetskopian pre_lc_size= 10 GiB post_lc_size= 5 Gib.

• • • 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 filsegment redan fanns i 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 är det helst pre_lc_size och post_lc_size av filen i den andra säkerhetskopian bör uppdateras från att båda är noll till att vara 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.
  • Filerna infogad komprimeringsstatistik är ett kumulativt resultat och omfattar alla skrivningar som filen någonsin har tagit emot.
  • När en fil tar emot många överskrivningar visas raw_bytes kan vara mycket större än filens logiska storlek. För glesa filer kan filstorlekarna vara större än "Original Bytes".

MTree-komprimering:

• • Komprimering av en viss mtree kan kontrolleras med "mtree show compression" (MSC) CLI-kommando.
  • De absoluta värdena för inline-komprimeringsstatistiken är kumulativa under livslängden för MTree.
  • Med tanke på att en MTree kan vara många år långa, blir dessa värden mindre och mindre informativa med tiden.
  • För att åtgärda det här problemet används mängden ändring (delta) i den infogade komprimeringsstatistiken och rapporterar komprimering endast för vissa tidsintervall.
  • Det bakomliggande tillvägagångssättet är att MTree Infogad komprimeringsstatistik dumpas regelbundet till en logg.
  • När en klient frågar MTree-komprimering med MSC används loggen för att beräkna deltan för siffrorna för komprimeringsrapportering.
  • Som standard, MSC Rapporterar komprimering för de senaste 7 dagarna och de senaste 24 timmarna, även om Anytime Period 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

Sedan komprimeringen av MTree A för den här timmen är:

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 stöder alternativen "daily" och "daily-detailed", liksom "filesys show compression"-kommandot.
  • När "daily" anges rapporterar kommandot den dagliga komprimeringen i kalenderformat.
  • Den använder de dagliga deltan i raw_bytes och post_lc_size för att beräkna det dagliga kompressionsförhållandet.
  • När "daily-detailed" anges visar kommandot alla tre deltan (i raw_bytes, pre_lc_sizeoch post_lc_sizeför varje dag. Den beräknar också g_comp och l_comp tillsammans med den totala kompressionsfaktorn.

Ett exempel på resultat från dessa system finns i tillägget nedan.

Systemkomprimering:

• • När hur komprimering rapporteras om MTrees är förstått, ä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 omfattningen, eftersom man är i en viss MTree, medan en är över hela systemet.
  • Resultaten kan kontrolleras med hjälp av "filesys show compression"-kommandot.
  • 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 Produktionen.

Molnnivå:

• 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å görs ingen differentiering efter nivå och rapporterar inline-komprimeringsstatistik, de är exakt desamma som vad som beskrivs i avsnitt 3.1.

Deduplication:

Det sista ämnet att lyfta fram är några av egenskaperna hos deduplicering, som kallas "global komprimering" i många Data Domain-artiklar.

Ä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 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 är det ovanligt med ett högt dedupliceringsförhållande vid 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 du kan förvänta dig:

• Initiala säkerhetskopieringar kanske bara uppnår ett litet effektivt komprimeringsförhållande för systemet, ofta 2x eller 3x. Deduplicering har vanligtvis små möjligheter att visa sin styrka i de första säkerhetskopiorna.
• Det globala komprimeringsförhållandet i en stegvis säkerhetskopiering är lägre än komprimeringsförhållandet för motsvarande fullständiga säkerhetskopiering. Detta beror på att en stegvis säkerhetskopiering endast innehåller ändrade eller nya filer jämfört med den omedelbara tidigare säkerhetskopieringen. Det globala komprimeringsförhållandet beror på hur många procent nya data det finns i den stegvisa säkerhetskopieringen.
• Dedupliceringsförhållandet för en fullständig säkerhetskopia (de icke-initiala) kan också vara lågt i vissa scenarier. Några ofta observerade scenarier är:
  • En hög förändringshastighet i de data som säkerhetskopieras
  • Datauppsättningen domineras av små filer (mindre än 5 MiB)
  • Säkerhetskopieringsprogram som lägger till många markörer med tätt avstånd
  • Databassäkerhetskopior som är inkrementella eller använder liten blockstorlek
  • När ett lågt komprimeringsförhållande observeras i en fullständig säkerhetskopia med låg dataändringshastighet kontrollerar du om något av ovanstående fall gäller eller om ytterligare analys behövs.
• Komprimering av en senare säkerhetskopia blir inte alltid bättre än den ursprungliga. Efterföljande säkerhetskopieringsbilder kan visa ett högt dedupliceringsförhållande eftersom de första och tidigare säkerhetskopieringsbilderna redan har lagt till det mesta av data i systemet. När alla tidigare säkerhetskopieringsbilder tas bort kan det globala och lokala komprimeringsförhållandet för den tidigaste befintliga säkerhetskopian fortfarande vara högt, men det betyder bara att den fick bra deduplicering när den lades till i systemet, inget annat. När en fil tas bort som har ett högt globalt och lokalt komprimeringsförhållande och är den sista säkerhetskopian av en viss datauppsättning, kan den frigöra mer utrymme än den storlek som härleds från komprimeringsförhållandet.
• Komprimeringsförhållanden för samma datauppsättning på olika system kan inte jämföras, oavsett hur datauppsättningen läggs till i dessa system. Detta beror på att varje system är en oberoende dedupliceringsdomän. Det finns ingen förväntan på att två olika DD:er får samma eller ens nödvändigtvis liknande komprimeringsförhållanden, även om deras datauppsättningar är desamma.

Sammanfattning:

• Det är svårt att mäta komprimering i deduplicerade filsystem, men det är ännu svårare i loggstrukturerade deduplicerade filsystem.
• Man 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" Kommandot

• Anta att det finns en 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.

Informationen mtree Lista utdata:

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 (inga alternativ):

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