Data Domain: Forstå Data Domain-komprimering

Komprimeringsteknikkene som er involvert i et datadomene, bruker toppmoderne teknikker for å redusere den fysiske plassen som kreves av sikkerhetskopierte data. Teknologien bak og målinger av komprimeringsnivåer er derfor komplekse emner.

Denne artikkelen drøfter noen terminologier, avveininger og tiltak for bedre å forklare komprimeringstypen som brukes, og andre aspekter ved komprimering i et Data Domain-miljø.

GJELDER FOR: Alle Data Domain-modeller

Innledning:

Sist oppdatert: januar 2024

• Komprimering er en datareduksjonsteknologi som tar sikte på å lagre et datasett ved å bruke mindre fysisk plass.
• I Data Domain-systemer (DDOS) utføres deduplisering og lokal komprimering for å komprimere brukerdata. Deduplisering, eller "dedupe", brukes til å identifisere overflødige datasegmenter og lagre bare unike datasegmenter.
• Lokal komprimering komprimerer de unike datasegmentene ytterligere med visse komprimeringsalgoritmer, for eksempel lz, gzfast, gz, så videre.
• Den generelle brukerdatakomprimeringen i DDOS er en felles innsats av deduplisering og lokal komprimering. DDOS bruker "komprimeringsforhold" til å måle effektiviteten av datakomprimeringen.
• Generelt er det forholdet mellom den totale brukerdatastørrelsen og den totale størrelsen på komprimerte data eller den brukte fysiske plassstørrelsen.
• Data Domain-filsystemet er et "log-strukturert" dedupliseringsfilsystem.
• Et loggstrukturert filsystem legger bare til data i systemet, og sletting alene kan ikke frigjøre fysisk plass.
• Slike filsystemer er avhengige av datasanering for å gjenvinne ledig plass.
• Egenskapene til det loggstrukturerte filsystemet og den dedupliserte teknologien kombinert sammen gjør det vanskelig å forstå alle aspekter av komprimering i DDOS.

For komprimering er det mange aspekter som kan måles.

Denne artikkelen drøfter trinnvis informasjon for å forstå DDOS-komprimering.

• Først forklares den generelle systemkomprimeringseffekten, som forteller oss den realistiske komprimeringen som oppnås i et Data Domain-system, mengden brukerdata, mengden fysisk plass som forbrukes og forholdet mellom dem.
• Dette forholdet kalles "system effektivt kompresjonsforhold" i denne artikkelen.
• DDOS utfører deduplisering inline og sporer statistikken over de opprinnelige brukerdatasegmentene, postdedupe unike datasegmenter og den lokale komprimeringseffekten på de unike datasegmentene.
• Denne interne komprimeringsstatistikken brukes til å måle den interne komprimeringseffekten. Innebygd komprimeringsstatistikk kan måles for hver skriving. DDOS sporer også statistikken på forskjellige nivåer: Filer MTrees, og hele systemet.

Det er ingen garanti for at alt innholdet stemmer overens med fremtidige utgivelser.

I utgivelser før 5.0 har hele systemet bare ett mtree og begrepet mtree er ikke eksplisitt kalt ut.

Komprimering: Systemets samlede effekt:

Den totale komprimeringseffekten for hele systemet måles ved det effektive kompresjonsforholdet, som er forholdet mellom størrelsen på brukerdataene og størrelsen på brukt fysisk plass. Det er rapportert av "filesys show compression" (FSC) CLI-kommando (tilsvarende informasjon er også tilgjengelig på UI). Et utvalg av utdata 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.

• •  
  • Det effektive kompresjonsforholdet for systemet rapporteres i rad 1 i resultatdelen i CLI-utdataene. Raden er uthevet ovenfor.
  • Den totale størrelsen på brukerdata er merket som "Pre-Comp".
  • Det totale forbruket av fysisk plass (av både data og metadata) er merket som "Post-Comp."
  • Både "Pre-Comp"-nummeret og "Post-Comp"-nummeret leses under kjøring. FSC Synkroniserer implisitt hele systemet, og spør deretter de to tallene.
    • Disse to tallene måles på samme måte som "filesys show space" kommando.
    • Systemeffektivt kompresjonsforhold = Pre-Comp/Post-Comp

Det er noen operasjoner som kan påvirke systemets effektive kompresjonsforhold:

• Rask kopi
  • Når en fastcopy gjøres fra en fil i det aktive navneområdet (ikke et øyeblikksbilde), er det en perfekt deduplisering, da det ikke er behov for ekstra fysisk plass for målfilen. Effekten av en fastcopy er at størrelsen på brukerdataene økes uten å bruke ekstra fysisk plass. Dette øker systemets effektive kompresjonsforhold. Når mange fastcopies er gjort, kan systemets effektive kompresjonsforhold bli kunstig høyt.
• Virtuell syntetikk
  • Virtuelle syntetiske sikkerhetskopier har en tendens til å vise et høyt systemeffektivt kompresjonsforhold. Dette er fordi virtuelle syntetiske stoffer gir logiske fullstendige sikkerhetskopier, men bare overfører endrede eller nye data til Data Domain-systemer. Virkningen på systemets effektive kompresjonsforhold for virtuell syntetikk er noe som effekten av fastcopy.
• Overskriver
  • Overskrivinger bruker mer fysisk plass, men øker ikke den logiske størrelsen på datasettet, og dermed overskrives det effektive kompresjonsforholdet for systemet
• Lagring av sparsomme filer
  • Spredte filer inneholder store "hull" som regnes med i den logiske størrelsen, men som ikke bruker fysisk plass på grunn av komprimering. Dermed kan de få systemets effektive komprimeringsforhold til å virke høyt.
• Lagring av små filer
  • DDOS legger nesten 1 kB overhead til hver fil for enkelte interne metadata. Når et system lagrer et betydelig antall små filer (størrelser mindre enn 1 KB eller i ensifrede kilobyte), drar overheaden av metadata det effektive komprimeringsforholdet ned.
• Lagring av forhåndskomprimerte eller forhåndskrypterte filer
  • Komprimering og kryptering kan forsterke nivået av dataendring og redusere muligheten for deduplisering. Slike filer kan vanligvis ikke dedupliseres godt og bringe systemets effektive kompresjonsforhold lavere.
• Sletter
  • Sletting reduserer den logiske størrelsen på systemet, men systemet får ikke den tilsvarende ubrukte plassen tilbake før man kjører datasanering. Mange slettede filer gjør kompresjonsforholdet lavt til søppelinnsamling (GC) kjører.
• Søppelrydding (GC) eller rengjøring
  • GC gjenvinner plassen som forbrukes av datasegmenter som ikke lenger ses av noen fil. Hvis mange filer nylig har blitt slettet, kan datasanering øke systemets komprimeringsforhold ved å redusere bruken av fysisk plass.
• Aggressivt ta øyeblikksbilder
  • Når et øyeblikksbilde av en Mtree er tatt, endres ikke den logiske størrelsen på datasettet. Alle datasegmenter som øyeblikksbildet refererer til, må imidlertid være låst, selv om alle filer som registreres av øyeblikksbildet, slettes etter at øyeblikksbildet ble tatt. GC kan ikke gjenvinne plassen som fortsatt trengs av øyeblikksbilder, å ha mange øyeblikksbilder kan gjøre at systemets effektive kompresjonsforhold virker lavt. Øyeblikksbilder er imidlertid nyttige fasiliteter for gjenoppretting av krasj. Ikke nøl med å ta øyeblikksbilder eller sette opp riktige tidsplaner for øyeblikksbilder når det er nødvendig.

Komprimering: Innebygd statistikk:

DDOS utfører deduplisering innebygd, ettersom data skrives til systemet. Den sporer effekten av innebygd deduplisering og lokal komprimering for hver skriving, og akkumulerer statistikken på filnivå. Statistikk for innebygd komprimering per fil aggregeres videre i mtree nivå og på systemnivå. Kompresjon måles basert på tre tall i inline-statistikken:

• Lengden på hver skrive: raw_bytes 
• The length of all unique segments: pre_lc_size
• Lengden på lokalt komprimerte unike segmenter: post_lc_size

• • Global komprimering (g_comp)
    • Er lik (raw_bytes/pre_lc_size), og gjenspeiler dedupliseringsforholdet
  • Lokal komprimering (l_comp)
    • Er lik (pre_lc_size/post_lc_size) og gjenspeiler effekten av den lokale komprimeringsalgoritmen

Den akkumulerte inline komprimeringsstatistikken er en del av filmetadataene i DDOS og lagres i filen inode. DDOS gir verktøy for å kontrollere inline-komprimeringene på alle tre nivåer; Filen MTree, og hele systemet. Disse er beskrevet i avsnittene nedenfor.

Filkomprimering:

• • Filkomprimering kan kontrolleres med "filesys show compression <path>" CLI-kommando, som rapporterer akkumulert komprimeringsstatistikk lagret i filen inode.
  • Når en katalog er angitt, blir innebygd komprimeringsstatistikk for alle filene under denne katalogen oppsummert og rapportert.
  • I CLI-utdataene, raw_bytes er merket som "Original Bytes," pre_lc_size er merket som "Globalt komprimert," post_lc_bytes er merket som "Lokalt komprimert". De andre omkostningene rapporteres som "metadata". De to eksemplene er hentet fra en produksjons-DD:

Eksempel 1: Innebygd komprimeringsstatistikk 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: Innebygd komprimeringsstatistikk for alle filer under en katalog, inkludert alle 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 rapporterer det totale inline-kompresjonsforholdet i CLI-utgangen ovenfor som "byte/storage_used."
    • Informasjonen ovenfor kan imidlertid være misvisende av flere årsaker, så du må være nøye når du skal tolke den.
    • En årsak er at pre_lc_size og post_lc_size registreres på det tidspunktet dataoperasjonene behandles.
    • Når filen som opprinnelig la til disse segmentene, blir slettet, bør antallet unike datasegmenter i den gjenværende filen økes.

Anta for eksempel at en fileksempelfil er sikkerhetskopiert til et datadomene, og i den første sikkerhetskopien er komprimeringsinformasjonen for filen pre_lc_size= 10 GiB, post_lc_size= 5 Gib.

• • • Anta deretter at dataene i denne filen er unike uten datadeling med noen annen fil.
    • I den andre sikkerhetskopien av filen antar du videre at filen får ideell deduplisering, slik at begge deler pre_lc_size og post_lc_size skal være null fordi alle segmenter av filen allerede eksisterte på systemet.
    • Når den første sikkerhetskopien slettes, blir den andre sikkerhetskopien av filen den eneste filen som refererer til 5 GiB datasegmenter.
    • I dette tilfellet, ideelt sett, pre_lc_size og post_lc_size av filen i den andre sikkerhetskopien skal oppdateres fra begge å være henholdsvis null til 10 GiB og 5 GiB.
    • Det er imidlertid ingen måte å oppdage hvilke filer det skal gjøres for, så den innebygde komprimeringsstatistikken for de eksisterende filene blir uendret.

• • En annen faktor som påvirker tallene ovenfor er den kumulative statistikken.
  • Når en fil får mange overskrivinger, er det umulig å spore i hvilken grad den kumulative statistikken gjenspeiler skrivingene som introduserte live-dataene.
  • Dermed kan inline-komprimeringsstatistikken over lang tid bare behandles som en heuristikk for grovt å estimere komprimeringen av en bestemt fil.
  • Et annet faktum som er verdt å fremheve er at den innebygde komprimeringen av en fil ikke kan måles for et vilkårlig tidsintervall.
  • Filene innebygd komprimering statistikk er et kumulativt resultat og dekker alle skriver at filen noensinne har mottatt.
  • Når en fil mottar mange overskrivinger, vises raw_bytes kan være langt større enn den logiske størrelsen på filen. For sparsomme filer kan filstørrelsene være større enn "Original Bytes".

MTree Compression:

• • Komprimeringen av en bestemt mtree kan kontrolleres med "mtree show compression" (MSC) CLI-kommando.
  • De absolutte verdiene for inline-komprimeringsstatistikken er kumulative over levetiden til MTree.
  • Gitt at levetiden til en MTree kan være mange år lang, disse verdiene blir mindre og mindre informative over tid.
  • For å løse dette problemet brukes mengden endring (deltaer) i den innebygde komprimeringsstatistikken og rapporterer komprimering bare for bestemte tidsintervaller.
  • Den underliggende tilnærmingen er at MTree Innebygd komprimeringsstatistikk dumpes periodisk til en logg.
  • Når en klient spør MTree-komprimering med MSC -kommandoen, brukes loggen til å beregne deltaene til tallene for komprimeringsrapportering.
  • Som standard MSC rapporterer komprimering for de siste 7 dagene og de siste 24 timene, men når som helst periode av interesse kan spesifiseres.

Hvis du vil demonstrere, antar du følgende logg 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

Deretter komprimering av MTree A for denne timen er:

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

Beregningen av kompresjonsforholdet ovenfor gjør ingenting med størrelsen på datasettet. Det kan for eksempel hende at mtreet ovenfor bare har 500 GB logiske data.

• • MSC Støtter alternativene "daglig" og "daglig detaljert", det samme gjør "filesys show compression" kommando.
  • Når "daglig" er angitt, rapporterer kommandoen den daglige komprimeringen på en kalendermåte.
  • Den bruker de daglige deltaene i raw_bytes og post_lc_size for å beregne det daglige kompresjonsforholdet.
  • Når "daglig detaljert" er angitt, viser kommandoen alle tre deltaene (av raw_bytes, pre_lc_sizeog post_lc_size, henholdsvis) for hver dag. Den beregner også g_comp og l_comp sammen med den totale kompresjonsfaktoren.

En prøveutgang fra disse systemene er i vedlegget nedenfor.

Systemkomprimering:

• • Når hvordan komprimering rapporteres på MTrees er forstått, er det greit å utvide konseptet til hele systemet.
  • Den systemomfattende komprimeringen, inline statistikkinnsamlingen og rapporteringen er nøyaktig den samme som med MTrees.
  • Den eneste forskjellen er omfanget, som man er i en bestemt MTree, mens en er over hele systemet.
  • Resultatene kan kontrolleres ved hjelp av "filesys show compression" kommando.
  • Et eksempel på dette finnes i avsnitt 2.
  • Systemkomprimeringen "siste 7 dager" og "siste 24 timer" rapporteres i de to siste linjene i resultatdelen i FSC Utgang.

Nettskynivå:

• På DD-er med implementert skynivå deles lagringen inn i aktivt nivå og skynivå, som er to uavhengige dedupliseringsdomener.
• Brukere kan bare sette inn data på det aktive nivået.
• Senere kan DDOS-dataflyttingsfunksjoner brukes til å overføre data fra det aktive nivået til skynivået.
• Dermed håndteres måling og rapportering av plass og kompresjon uavhengig av hverandre i hvert nivå.
• Men på filnivå gjøres ingen differensiering etter nivå- og rapporteringskomprimeringsstatistikk, de er nøyaktig de samme som det som er beskrevet i avsnitt 3.1.

Duplikatfjerning:

Det siste emnet som bør fremheves, er noen av egenskapene til deduplisering, som kalles "global komprimering" i mange Data Domain-artikler.

Selv om den inneholder ordet "komprimering", er det helt annerledes enn det tradisjonelle begrepet komprimering, som også leveres av DDOS under navnet "lokal komprimering."

• Lokal komprimering reduserer størrelsen på et stykke data ved hjelp av en bestemt algoritme (noen typer data er ikke komprimerbare, og bruk av komprimeringsalgoritmer på dem kan øke datastørrelsen litt).
• Vanligvis, når en algoritme er bestemt, er dataene den eneste faktoren for kompresjonsforholdet.
• Deduplisering er imidlertid annerledes - det er ikke et lokalt konsept, det er "globalt".
• Et innkommende datasegment dupliseres mot alle eksisterende datasegmenter i et deduplisert domene, som inkluderer alle dataene på Data Domain-systemer som ikke er i skyen.
• Datasegmentet i seg selv spiller ingen rolle i dedupliseringsprosedyren.
• I praksis ses et høyt dedupliseringsforhold sjelden i den første sikkerhetskopien av et datasett. I første sikkerhetskopiering er den store datareduksjonen ofte et resultat av lokal komprimering.
• Når påfølgende sikkerhetskopier lander på Data Domain, viser deduplisering styrken og blir den dominerende komprimeringsfaktoren.
• Effektiviteten av deduplisering er avhengig av det faktum at endringshastigheten til et datasett er lav fra sikkerhetskopiering til sikkerhetskopiering. Av denne grunn kan datasett med høye endringsfrekvenser ikke bli godt duplisert.
• Når sikkerhetskopieringsprogrammet setter inn sine egne metadatabiter (kalt markører av Data Domain) i sikkerhetskopiavbildningene med høy frekvens, kan det også hende at det heller ikke får et godt dedupliseringsforhold. Våre markørhåndteringsteknikker kan hjelpe noen ganger, men ikke alltid.

Gitt disse observasjonene, hva du kan forvente:

• Innledende sikkerhetskopier kan bare oppnå et lite systemeffektivt kompresjonsforhold, ofte 2x eller 3x. Deduplicate har vanligvis liten mulighet til å vise sin styrke i innledende sikkerhetskopier.
• Det globale komprimeringsforholdet til en trinnvis sikkerhetskopiering er lavere enn komprimeringsforholdet til den tilsvarende fullstendige sikkerhetskopieringen. Grunnen til dette er at en trinnvis sikkerhetskopiering bare inneholder endrede eller nye filer sammenlignet med sikkerhetskopieringen rett før. Det globale komprimeringsforholdet avhenger av prosentandelen nye data i den trinnvise sikkerhetskopieringen.
• Dedupliseringsforholdet for en full sikkerhetskopi (de ikke-innledende) kan også være lavt i noen scenarier. Noen ofte observerte scenarier inkluderer:
  • En høy endringsfrekvens i dataene som sikkerhetskopieres
  • Datasettet domineres av små filer (mindre enn 5 MiB)
  • Sikkerhetskopieringsprogrammer legger til mange markører med tett avstand
  • Databasesikkerhetskopier som er trinnvise eller bruker liten blokkstørrelse
  • Når et lavt kompresjonsforhold observeres i en full sikkerhetskopi med lav dataendringshastighet, må du sjekke om et av tilfellene ovenfor gjelder, eller om ytterligere analyse er nødvendig.
• Komprimering av et senere sikkerhetskopibilde er ikke alltid bedre enn det første. Påfølgende sikkerhetskopieringsbilder kan vise et høyt dedupliseringsforhold fordi de første og tidligere sikkerhetskopiavbildningene allerede har lagt til mesteparten av dataene i systemet. Når alle tidligere sikkerhetskopibilder slettes, kan det globale og lokale komprimeringsforholdet til det tidligste eksisterende sikkerhetskopibildet fortsatt være høyt, men dette betyr bare at det fikk god deduplisering da det ble lagt til systemet, ingenting annet. Når en fil som har et høyt globalt og lokalt komprimeringsforhold, slettes, og som er den siste sikkerhetskopiavbildningen for et bestemt datasett, kan det frigjøre mer plass enn størrelsen som er avledet fra kompresjonsforholdet.
• Kompresjonsforhold for samme datasett på forskjellige systemer kan ikke sammenlignes, uavhengig av hvordan datasettet legges til disse systemene. Dette er fordi at hvert system er et uavhengig dedupliseringsdomene. Det er ingen forventning om at to forskjellige DD-er får samme eller til og med nødvendigvis like kompresjonsforhold, selv om datasettene deres er de samme.

Sammendrag:

• Måling av komprimering er vanskelig i dedupliserte filsystemer, men det er enda vanskeligere i log-strukturerte dedupliserte filsystemer.
• Hvordan deduplisering fungerer og hvordan komprimeringsstatistikk spores, må forstås.
• Kompresjonsforhold er nyttig informasjon for å forstå oppførselen til et bestemt system.
• Systemeffektivt kompresjonsforhold er det viktigste, pålitelige og informative tiltaket.
• Den innebygde komprimeringsstatistikken kan også være nyttig, men de kan ikke være mer enn heuristikk under noen omstendigheter.

Vedlegg:

Utgang av sampling av "mtree show compression" Kommandoen

• Anta at det er en MTree holder 254792,4 GiB data. Den har mottatt 4379,3 GiB nye data de siste 7 dagene, og 78,4 GiB de siste 24 timene (andre tidsintervaller kan spesifiseres).
• Alternativet "daily" (daglig) rapporterer den interne komprimeringsstatistikken for de siste 33 dagene.
• Når alternativet "daglig detaljert" er gitt, blir de totale kompresjonsforholdene ytterligere detaljert ved å separere dem i globale og lokale kompresjonsforhold.

Informasjonen i mtree Listeutgang:

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 alternativer):

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

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

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