Data Domain: Om Data Domain-komprimering

De komprimeringsteknikker, der er involveret i et Data Domain, bruger de nyeste teknikker til at reducere den fysiske plads, der kræves af sikkerhedskopierede data. Teknologier og målinger af komprimeringsniveauer er komplekse emner.

I denne artikel beskrives nogle terminologier, afvejninger og foranstaltninger til bedre at forklare den anvendte komprimeringstype og andre aspekter af komprimering i et Data Domain-miljø.

GÆLDER FOR: Alle Data Domain-modeller

Indledning:

Senest opdateret: Januar 2024

• Komprimering er en datareduktionsteknologi, der sigter mod at gemme et datasæt ved hjælp af mindre fysisk plads.
• I Data Domain-systemer (DDOS) udføres deduplikering og lokal komprimering for at komprimere brugerdata. Deduplikering eller "deduplikering" bruges til at identificere overflødige datasegmenter og kun gemme unikke datasegmenter.
• Lokal komprimering komprimerer yderligere de unikke datasegmenter med visse komprimeringsalgoritmer, såsom lz, gzfast, gz, så videre.
• Den overordnede brugerdatakomprimering i DDOS er den fælles indsats for deduplikering og lokal komprimering. DDOS bruger "komprimeringsforhold" til at måle effektiviteten af deres datakomprimering.
• Generelt er det forholdet mellem den samlede brugerdatastørrelse og den samlede størrelse af komprimerede data eller den anvendte fysiske pladsstørrelse.
• Data Domain-filsystemet er et "logstruktureret" deduplikeret filsystem.
• Et logstruktureret filsystem føjer kun data til systemet, og sletning kan i sig selv ikke frigøre fysisk plads.
• Sådanne filsystemer er afhængige af Garbage Collection for at kunne frigøre plads, der ikke længere er brug for.
• Egenskaberne ved det logstrukturerede filsystem og den deduplikerede teknologi kombineret gør det vanskeligt klart at forstå alle aspekter af komprimering i DDOS.

Til kompression er der mange aspekter, der kan måles.

Denne artikel beskriver de trinvise detaljer, der kan hjælpe med at forstå DDOS-komprimering.

• Først forklares den overordnede systemkomprimeringseffekt, som fortæller os den realistiske komprimering, der opnås i et Data Domain-system, mængden af brugerdata, mængden af forbrugt fysisk plads og forholdet mellem dem.
• Dette forhold kaldes "systemeffektivt kompressionsforhold" i denne artikel.
• DDOS udfører deduplikering indbygget og sporer statistikken for de oprindelige brugerdatasegmenter, postdeduplikering af unikke datasegmenter og den lokale komprimeringseffekt på de unikke datasegmenter.
• Denne direkte komprimeringsstatistik bruges til at måle den direkte komprimeringseffekt. Indlejret komprimeringsstatistik kan måles for hver skrivning. DDOS sporer også statistikken på forskellige niveauer: Filer MTreesog hele systemet.

Der er ingen garanti for, at alt indhold er nøjagtigt ved fremtidige udgivelser.

I versioner før 5.0 har hele systemet kun én mtree og udtrykket mtree ikke udtrykkeligt fremhæves.

Komprimering: Systemets samlede effekt:

Den samlede kompressionseffekt for hele systemet måles ved hjælp af det effektive kompressionsforhold, som er forholdet mellem brugerdatastørrelsen og størrelsen af det brugte fysiske rum. Det rapporteres af "filesys show compression" (FSC) CLI-kommando (de tilsvarende oplysninger findes også på brugergrænsefladen). Et prøveoutput på FSC er vist nedenfor:

# filesys show compression

From: 2023-12-31 03:00 To: 2024-01-07 03:00

Active Tier:
                   Pre-Comp   Post-Comp   Global-Comp   Local-Comp      Total-Comp
                      (GiB)       (GiB)        Factor       Factor          Factor
                                                                     (Reduction %)
----------------   --------   ---------   -----------   ----------   -------------
Currently Used:*     6439.6       113.4             -            -    56.8x (98.2)
Written:
  Last 7 days      135421.3      1782.0         35.1x         2.2x    76.0x (98.7)
  Last 24 hrs         532.5         1.5        334.3x         1.1x   356.5x (99.7)
----------------   --------   ---------   -----------   ----------   -------------
 * Does not include the effects of pre-comp file deletes/truncates
   since the last cleaning on 2024/01/05 11:34:13.

• •  
  • Systemets effektive kompressionsforhold rapporteres i række 1 i resultatafsnittet i CLI-outputtet. Rækken er fremhævet ovenfor.
  • Den samlede brugerdatastørrelse er mærket som "Pre-Comp."
  • Den samlede forbrugte fysiske plads (af både data og metadata) er mærket som "Post-Comp."
  • "Pre-Comp"-nummeret og "Post-Comp"-nummeret læses begge under kørsel. FSC synkroniserer implicit hele systemet og forespørger derefter på de to tal.
    • Disse to tal måles på samme måde som "filesys show space" kommando.
    • Systemeffektivt kompressionsforhold = Pre-Comp/Post-Comp

Der er nogle operationer, der kan påvirke systemets effektive kompressionsforhold:

• Hurtig kopiering
  • Når en fastcopy udføres fra en fil i det aktive navneområde (ikke et øjebliksbillede), er det en perfekt deduplikering, da der ikke er behov for ekstra fysisk plads til målfilen. Virkningen af en fastcopy er, at brugerdatastørrelsen øges uden at forbruge yderligere fysisk plads. Dette øger systemets effektive kompressionsforhold. Når mange fastcopies er færdige, kan systemets effektive kompressionsforhold blive kunstigt højt.
• Virtuel syntetisk
  • Virtuelle syntetiske sikkerhedskopier har tendens til at vise et højt systemeffektivt komprimeringsforhold. Dette skyldes, at virtuel syntetisk foretager logiske komplette sikkerhedskopier, men kun overfører ændrede eller nye data til Data Domain-systemer. Virkningen på systemets effektive kompressionsforhold af virtuel syntetisk er lidt som effekten af fastcopy.
• Overskriver
  • Overskrivninger optager mere fysisk plads, men øger ikke datasættets logiske størrelse, og overskrivninger sænker således systemets effektive komprimeringsforhold
• Lagring af sparsomme filer
  • Sparsomme filer indeholder store "huller", der medregnes i den logiske størrelse, men ikke bruger fysisk plads pga. komprimering. Som følge heraf kan de få systemets effektive komprimeringsforhold til at synes højt.
• Lagring af små filer
  • DDOS tilføjer næsten 1 KB overhead til hver fil for visse interne metadata. Når et system gemmer et betydeligt antal små filer (størrelse mindre end 1 KB eller i encifrede kilobyte), trækker de faste omkostninger til metadata det effektive komprimeringsforhold ned.
• Lagring af forudkomprimerede eller forudkrypterede filer
  • Komprimering og kryptering kan forstærke niveauet af dataændringer og reducere muligheden for deduplikering. Sådanne filer kan normalt ikke deduplikeres godt og bringe systemets effektive komprimeringsforhold lavere.
• Sletter
  • Sletninger reducerer systemets logiske størrelse, men systemet får ikke den tilsvarende ubrugte plads tilbage, før Garbage Collection kører. Mange slettede filer gør komprimeringsforholdet lavt, indtil Garbage Collection (GC) kører.
• Garbage Collection (GC) eller rengøring
  • GC genvinder den plads, der forbruges af datasegmenter, der ikke længere ses af nogen fil. Hvis der er blevet slettet mange filer for nylig, kan GC øge systemets komprimeringsforhold ved at reducere størrelsen af det fysiske pladsforbrug.
• Aggressiv optagelse af snapshots
  • Når et snapshot af en Mtree tages, ændres datasættets logiske størrelse ikke. Alle datasegmenter, der refereres til i snapshottet, skal dog låses, selvom alle filer, der er hentet af snapshottet, slettes, efter snapshottet blev taget. GC kan ikke genvinde den plads, der stadig er brug for til snapshots, men hvis der er mange snapshots, kan det få systemets effektive komprimeringsforhold til at virke lavt. Snapshots er dog nyttige værktøjer til gendannelse efter nedbrud. Tøv aldrig med at tage snapshots eller oprette passende tidsplaner for snapshots, når det er nødvendigt.

Komprimering: Inline statistik:

DDOS udfører deduplikering inline, da data skrives til systemet. Det sporer virkningerne af indbygget deduplikering og lokal komprimering for hver skrivning og akkumulerer statistikken på filniveau. Inlinekomprimeringsstatistikker pr. fil aggregeres yderligere på mtree niveau og på systemniveau. Komprimering måles ud fra tre tal i inline-statistikken:

• Længden af hver skrivning: raw_bytes 
• The length of all unique segments: pre_lc_size
• Længden af lokalt komprimerede unikke segmenter: post_lc_size

• • Global komprimering (g_comp)
    • Lig med (raw_bytes/pre_lc_size) og afspejler deduplikeringsforholdet
  • Lokal komprimering (l_comp)
    • Lig med (pre_lc_size/post_lc_size) og afspejler effekten af den lokale komprimeringsalgoritme

Den akkumulerede indbyggede komprimeringsstatistik er en del af filmetadataene i DDOS og gemmes i filen inode. DDOS giver værktøjer til at kontrollere inline-komprimeringerne på alle tre niveauer; Fil MTree, og hele systemet. Disse er detaljeret beskrevet i de følgende afsnit.

Filkomprimering:

• • Filkomprimering kan kontrolleres med "filesys show compression <path>" CLI-kommando, som rapporterer de akkumulerede komprimeringsstatistikker, der er gemt i filen inode.
  • Når der er angivet en mappe, opsummeres og rapporteres den indbyggede komprimeringsstatistik for alle filerne under den pågældende mappe.
  • I CLI-outputtet raw_bytes er mærket som "Original Bytes," pre_lc_size er mærket som "Globalt komprimeret," post_lc_bytes er markeret som "Lokalt komprimeret". De øvrige faste omkostninger rapporteres som "metadata". De to eksempler er hentet fra en produktions-DD:

Eksempel 1: Indlejret komprimeringsstatistik for en fil

filesys show compression /data/col1/main/dir1/file_1

Total files: 1;  bytes/storage_used: 7.1
        Logical Bytes:       53,687,091,200
       Original Bytes:       11,463,643,380
  Globally Compressed:        4,373,117,751
   Locally Compressed:        1,604,726,416
            Meta-data:           18,118,232

Eksempel 2: Integreret komprimeringsstatistik for alle filer under en mappe, herunder alle undermapper

filesys show compression /data/col1/main/dir1 

Total files: 13;  bytes/storage_used: 7.1
        Logical Bytes:       53,693,219,809
       Original Bytes:       11,501,978,884
  Globally Compressed:        4,387,212,404
   Locally Compressed:        1,608,444,046
            Meta-data:           18,241,880

• • • Systemet rapporterer det samlede indbyggede komprimeringsforhold i ovenstående CLI-output som "bytes/storage_used."
    • Der skal dog udvises forsigtighed ved fortolkningen af ovenstående oplysninger, da de kan være misvisende af forskellige årsager.
    • En af grundene er, at pre_lc_size og post_lc_size registreres på det tidspunkt, hvor datahandlingerne behandles.
    • Når den fil, der oprindeligt tilføjede disse segmenter, slettes, øges antallet af de entydige datasegmenter i den resterende fil.

Antag f.eks., at en fileksempelfil sikkerhedskopieres til et Data Domain, og at komprimeringsoplysningerne for filen i den første sikkerhedskopiering pre_lc_size= 10 GiB post_lc_size= 5 Gib.

• • • Antag derefter, at dataene i denne fil er unikke uden datadeling med nogen anden fil.
    • I den anden sikkerhedskopi af filen antager du yderligere, at filen får ideel deduplikering, således at begge pre_lc_size og post_lc_size skal være nul, fordi alle segmenter af filen allerede eksisterede på systemet.
    • Når den første sikkerhedskopi slettes, bliver den anden sikkerhedskopi af filen den eneste fil, der refererer til datasegmenterne på 5 GiB.
    • I dette tilfælde er ideelt set pre_lc_size og post_lc_size af filen i den anden sikkerhedskopi skal opdateres fra begge at være nul til at være henholdsvis 10 GiB og 5 GiB.
    • Der er dog ingen måde at registrere, hvilke filer der skal gøres for, så den indbyggede komprimeringsstatistik for de eksisterende filer forbliver uændret.

• • En anden faktor, der påvirker ovenstående tal, er den kumulative statistik.
  • Når en fil får mange overskrivninger, er det umuligt at spore, i hvilket omfang den kumulative statistik afspejler de skrivninger, der introducerede de levende data.
  • Således kan inline-komprimeringsstatistikken over lang tid kun behandles som en heuristik for groft at estimere komprimeringen af en bestemt fil.
  • En anden kendsgerning, der er værd at fremhæve, er, at inline-komprimeringen af en fil ikke kan måles i et vilkårligt tidsinterval.
  • Filernes indbyggede komprimeringsstatistik er et kumulativt resultat og dækker alle de skrivninger, som filen nogensinde har modtaget.
  • Når en fil modtager mange overskrivninger, vises ikonet raw_bytes kan være langt større end filens logiske størrelse. For sparsomme filer kan filstørrelserne være større end "Original Bytes".

MTree-komprimering:

• • Komprimeringen af en bestemt mtree kan kontrolleres med "mtree show compression" (MSC) CLI-kommando.
  • De absolutte værdier af inlinekomprimeringsstatistikken kumuleres i løbet af levetiden for MTree.
  • I betragtning af at levetiden for en MTree kan være mange år lange, bliver disse værdier mindre og mindre informative over tid.
  • For at løse dette problem bruges mængden af ændring (deltaer) i den indbyggede komprimeringsstatistik, og komprimering rapporteres kun for bestemte tidsintervaller.
  • Den underliggende tilgang er, at MTree Indlejret komprimeringsstatistik dumpes periodisk til en log.
  • Når en klient forespørger MTree-komprimering med MSC kommando, bruges loggen til at beregne deltaerne i tallene til komprimeringsrapportering.
  • Som standard, MSC Rapporterer komprimering for de sidste 7 dage og de sidste 24 timer, men når som helst periode af interesse kan angives.

For at demonstrere skal du antage følgende log for MTree Sv.:

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

Derefter komprimeres MTree A for denne time er:

g_comp = (12000-11000)/(200-100) = 10x
l_comp = (200-100)/(100-50) = 2x
overall compression ratio = (12000-11000)/(100-50) = 20x

Ovenstående beregning af komprimeringsforhold gør intet med datasætstørrelsen. For eksempel kan ovenstående MTree kun have 500 GB logiske data.

• • MSC understøtter indstillingerne "daglig" og "daglig detaljeret", ligesom "filesys show compression" kommando.
  • Når "dagligt" er angivet, rapporterer kommandoen den daglige komprimering på en kalendermåde.
  • Det bruger de daglige deltaer i raw_bytes og post_lc_size for at beregne det daglige kompressionsforhold.
  • Når "daily-detailed" er angivet, viser kommandoen alle tre deltaer (af raw_bytes, pre_lc_sizeog post_lc_size, henholdsvis) for hver dag. Det beregner også g_comp og l_comp sammen med den samlede kompressionsfaktor.

Et eksempel på output fra disse systemer findes i tillægget nedenfor.

Systemkomprimering:

• • Når komprimering rapporteres på MTrees forstås, er det ligetil at udvide konceptet til hele systemet.
  • Den systemdækkende komprimering af inline-statistikindsamling og -rapportering er nøjagtig den samme som med MTrees.
  • Den eneste forskel er omfanget, da man er i en bestemt MTree, mens man er over hele systemet.
  • Resultaterne kan kontrolleres ved hjælp af "filesys show compression" kommando.
  • Et eksempel herpå findes i afsnit 2.
  • Systemkomprimeringen "sidste 7 dage" og "sidste 24 timer" rapporteres i de sidste to linjer i resultatafsnittet i FSC Output.

Cloud-niveau:

• På DD'er, hvor cloudniveauet er implementeret, adskilles lageret i det aktive niveau og cloudniveauet, som er to uafhængige deduplikeringsdomæner.
• Brugere kan kun indsætte data på det aktive niveau.
• Senere kan DDOS-dataflytningsfunktioner bruges til at migrere data fra det aktive niveau til cloudniveauet.
• Således håndteres rum- og kompressionsmåling og rapportering uafhængigt på hvert niveau.
• Men på filniveau skelnes der ikke mellem niveau og rapporterer indbyggede komprimeringsstatistikker, de er nøjagtigt de samme som beskrevet i afsnit 3.1.

Deduplication:

Det sidste emne, der skal fremhæves, er nogle af kendetegnene ved deduplikering, som kaldes "global komprimering" i mange Data Domain-artikler.

Selvom det indeholder ordet "komprimering", er det helt anderledes end det traditionelle koncept for kompression, som også leveres af DDOS under navnet "lokal komprimering."

• Lokal komprimering reducerer størrelsen på et stykke data ved hjælp af en bestemt algoritme (nogle typer data kan ikke komprimeres, og anvendelse af komprimeringsalgoritmer på dem kan øge datastørrelsen lidt).
• Normalt, når en algoritme er besluttet, er dataene den eneste faktor i kompressionsforholdet.
• Deduplikering er imidlertid anderledes - det er ikke et lokalt koncept, det er "globalt".
• Et indgående datasegment trækkes i forhold til alle eksisterende datasegmenter i et deduplikeret domæne, hvilket omfatter alle data på ikke-cloudbaserede Data Domain-systemer.
• Datasegmentet selv betyder ikke noget i deduplikeringsproceduren.
• I praksis ses et højt deduplikeringsforhold sjældent i den indledende sikkerhedskopiering af et datasæt. I de første sikkerhedskopieringer kommer den store datareduktion ofte fra lokal komprimering.
• Når efterfølgende sikkerhedskopier lander på Data Domain, viser deduplikering sin styrke og bliver den dominerende faktor for komprimering.
• Effektiviteten af deduplikering afhænger af, at ændringshastigheden for et datasæt er lav fra sikkerhedskopiering til sikkerhedskopiering. Derfor kan datasæt med høje ændringshastigheder ikke fjernes ordentligt.
• Når sikkerhedskopieringsprogrammet indsætter sine egne metadatabidder (kaldet markører af Data Domain) i sikkerhedskopieringsbillederne med høj frekvens, får det muligvis heller ikke et godt deduplikeringsforhold. Vores markørhåndteringsteknikker kan hjælpe nogle gange, men ikke altid.

I betragtning af disse observationer, hvad kan man forvente:

• Indledende sikkerhedskopiering opnår muligvis kun et lille systems effektive kompressionsforhold, ofte 2x eller 3x. Deduplicate har normalt ringe mulighed for at vise sin styrke i indledende sikkerhedskopier.
• Det globale komprimeringsforhold i en trinvis sikkerhedskopiering er mindre end komprimeringsforholdet i den tilsvarende komplette sikkerhedskopi. Dette skyldes, at en trinvis sikkerhedskopiering kun indeholder ændrede eller nye filer sammenlignet med den umiddelbare tidligere sikkerhedskopiering. Det globale komprimeringsforhold afhænger af procentdelen af nye data i den trinvise sikkerhedskopiering.
• Deduplikeringsforholdet for en fuld sikkerhedskopi (de ikke-startende) kan også være lavt i nogle scenarier. Nogle ofte observerede scenarier omfatter:
  • En høj ændringshastighed i de data, der sikkerhedskopieres
  • Datasættet domineres af små filer (mindre end 5 MiB)
  • Sikkerhedskopieringsprogrammer, der tilføjer en masse markører med tæt afstand
  • Databasesikkerhedskopier, der er trinvise eller bruger en lille blokstørrelse
  • Når der observeres et lavt komprimeringsforhold i en fuld sikkerhedskopi med en lav dataændringshastighed, skal du kontrollere, om et af ovenstående tilfælde gælder, eller om der er behov for yderligere analyse.
• Komprimering af et senere backupbillede er ikke altid bedre end det oprindelige. Fortløbende sikkerhedskopieringsbilleder kan vise et højt deduplikeringsforhold, fordi de første og tidligere sikkerhedskopieringsbilleder allerede har føjet de fleste data til systemet. Når alle de tidligere sikkerhedskopieringsbilleder slettes, kan det globale og lokale komprimeringsforhold for det tidligste eksisterende sikkerhedskopieringsbillede stadig være højt, men det betyder kun, at det fik god deduplikering, da det blev tilføjet til systemet, intet andet. Når en fil slettes, der har et højt globalt og lokalt komprimeringsforhold og er det sidste sikkerhedskopieringsbillede af et bestemt datasæt, kan det frigive mere plads end den størrelse, der stammer fra komprimeringsforholdet.
• Komprimeringsforhold for det samme datasæt på forskellige systemer kan ikke sammenlignes, uanset hvordan datasættet føjes til disse systemer. Dette skyldes, at hvert system er et uafhængigt deduplikeringsdomæne. Der er ingen forventning om, at to forskellige DD'er får de samme eller endda nødvendigvis ens komprimeringsforhold, selvom deres datasæt er de samme.

Opsummering:

• Måling af komprimering er vanskelig i deduplikerede filsystemer, men det er endnu sværere i logstrukturerede deduplikerede filsystemer.
• Hvordan deduplikering fungerer, og hvordan komprimeringsstatistikker spores, skal forstås.
• Kompressionsforhold er nyttige oplysninger til at forstå et bestemt systems opførsel.
• Systemets effektive kompressionsforhold er den vigtigste, pålidelige og informative foranstaltning.
• Inline-komprimeringsstatistikken kan også være nyttig, men de er muligvis ikke mere end heuristik under nogle omstændigheder.

Bilag:

Prøveoutput af "mtree show compression" Kommando

• Antag, at der er en MTree med 254792,4 GiB data. Det har modtaget 4379.3 GiB nye data i de sidste 7 dage og 78.4 GiB i de sidste 24 timer (andre tidsintervaller kan specificeres).
• Den "daglige" indstilling rapporterer den direkte komprimeringsstatistik for de sidste 33 dage.
• Når den "dagligt detaljerede" mulighed leveres, beskrives de samlede kompressionsforhold yderligere ved at opdele dem i globale og lokale kompressionsforhold.

Ikonet mtree Liste output:

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 (ingen muligheder):

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 "daglig" mulighed:

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 mulighed for "daglige detaljer":

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