Data Domain: Data Domain compressie begrijpen

De compressietechnieken die betrokken zijn bij een Data Domain maken gebruik van geavanceerde technieken om de fysieke ruimte die nodig is voor back-updata te verminderen. De technologieën en metingen van compressieniveaus zijn dan ook complexe onderwerpen.

In dit artikel worden enkele terminologieën, afwegingen en maatregelen besproken om het gebruikte compressietype en andere aspecten van compressie in een Data Domain-omgeving beter uit te leggen.

VAN TOEPASSING OP: Alle Data Domain modellen

Inleiding:

Laatst bijgewerkt: Januari 2024

• Compressie is een technologie voor datareductie die tot doel heeft een dataset op te slaan met minder fysieke ruimte.
• In Data Domain-systemen (DDOS) worden deduplicatie en lokale compressie uitgevoerd om gebruikersdata te comprimeren. Deduplicatie, of 'deduplicatie', wordt gebruikt om redundante datasegmenten te identificeren en alleen unieke datasegmenten op te slaan.
• Lokale compressie comprimeert de unieke datasegmenten verder met bepaalde compressiealgoritmen, zoals lz, gzfast, gz, ga zo maar door.
• De algehele compressie van gebruikersdata in DDOS is de gezamenlijke inspanning van deduplicatie en lokale compressie. DDOS gebruikt 'compressieverhouding' om de effectiviteit van de datacompressie te meten.
• Over het algemeen is dit de verhouding tussen de totale grootte van gebruikersgegevens en de totale grootte van gecomprimeerde gegevens of de gebruikte grootte van de fysieke ruimte.
• Data Domain bestandssysteem is een log-gestructureerd deduplicatiebestandssysteem.
• Een bestandssysteem met logboekstructuur voegt alleen data toe aan het systeem en met verwijdering kan geen fysieke ruimte worden vrijgemaakt.
• Dergelijke bestandssystemen vertrouwen op garbagecollection om niet langer benodigde ruimte vrij te maken.
• De gecombineerde kenmerken van het log-gestructureerde bestandssysteem en de gededupliceerde technologie maken het lastig om alle aspecten van compressie in DDOS duidelijk te begrijpen.

Voor compressie zijn er veel aspecten die kunnen worden gemeten.

In dit artikel worden de stapsgewijze details besproken om DDOS-compressie te begrijpen.

• Eerst wordt het algehele systeemcompressie-effect uitgelegd, dat ons vertelt over de realistische compressie die wordt bereikt in een Data Domain-systeem, de hoeveelheid gebruikersdata, de hoeveelheid gebruikte fysieke ruimte en de verhouding daarvan.
• Deze verhouding wordt in dit artikel "effectieve compressieverhouding van het systeem" genoemd.
• DDOS voert deduplicatie inline uit en houdt de statistieken bij van de oorspronkelijke gebruikersdatasegmenten, postdeduplicatie van unieke datasegmenten en het lokale compressie-effect op de unieke datasegmenten.
• Deze inline compressiestatistieken worden gebruikt om het inline compressie-effect te meten. Inline compressiestatistieken kunnen worden gemeten voor elke schrijfbewerking. DDOS houdt ook de statistieken op verschillende niveaus bij: Bestanden MTrees, en het hele systeem.

Er is geen garantie dat alle inhoud correct is voor toekomstige releases.

In releases vóór 5.0 heeft het hele systeem slechts één mtree en de termijn mtree wordt niet expliciet genoemd.

Compressie: Algemeen effect van het systeem:

Het totale compressie-effect voor het hele systeem wordt gemeten aan de hand van de effectieve compressieverhouding, de verhouding tussen de grootte van de gebruikersdata en de grootte van de gebruikte fysieke ruimte. Het wordt gerapporteerd door de "filesys show compression" (FSC) CLI-opdracht (de bijbehorende informatie is ook beschikbaar in de gebruikersinterface). Een voorbeeld van de uitvoer van FSC wordt hieronder weergegeven:

# 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.

• •  
  • De effectieve compressieverhouding van het systeem wordt gerapporteerd in rij 1 van de resultatensectie in de CLI-uitvoer. De rij is hierboven gemarkeerd.
  • De totale grootte van gebruikersdata wordt aangeduid als 'Pre-Comp'.
  • De totale gebruikte fysieke ruimte (door zowel data als metadata) wordt aangeduid als 'Post-Comp'.
  • Het "Pre-Comp"-nummer en het "Post-Comp"-nummer worden beide tijdens runtime gelezen. FSC Synchroniseert impliciet het hele systeem en vraagt vervolgens de twee nummers op.
    • Deze twee getallen worden op dezelfde manier gemeten als de "filesys show space" commando.
    • Effectieve compressieverhouding van systeem = Pre-Comp/Post-Comp

Er zijn enkele bewerkingen die van invloed kunnen zijn op de effectieve compressieverhouding van het systeem:

• Snel kopiëren
  • Wanneer een fastcopy wordt gedaan vanuit een bestand in de actieve naamruimte (geen snapshot), is het een perfecte deduplicatie, omdat er geen extra fysieke ruimte nodig is voor het doelbestand. Het effect van een fastcopy is dat de grootte van de gebruikersdata wordt vergroot zonder extra fysieke ruimte te verbruiken. Dit verhoogt de effectieve compressieverhouding van het systeem. Wanneer veel fastcopies klaar zijn, kan de effectieve compressieverhouding van het systeem kunstmatig hoog worden.
• Virtual synthetics
  • Virtuele, kunstmatige back-ups hebben meestal een hoge effectieve compressieverhouding van het systeem. Dit komt doordat virtuele kunststoffen logische volledige back-ups maken, maar alleen gewijzigde of nieuwe data overdragen naar Data Domain-systemen. De impact op de effectieve compressieverhouding van virtuele kunststoffen lijkt enigszins op het effect van fastcopy.
• Overschrijft
  • Overschrijvingen nemen meer fysieke ruimte in beslag, maar vergroten de logische grootte van de dataset niet, waardoor overschrijdingen de effectieve compressieverhouding van het systeem verlagen
• Sparse files opslaan
  • Sparse-bestanden bevatten grote 'gaten' die worden meegerekend in de logische grootte, maar geen fysieke ruimte verbruiken als gevolg van compressie. Hierdoor kan de effectieve compressieverhouding van het systeem hoog lijken.
• Kleine bestanden opslaan
  • DDOS voegt bijna 1 KB overhead toe aan elk bestand voor bepaalde interne metadata. Wanneer een systeem een aanzienlijk aantal kleine bestanden opslaat (kleiner dan 1 KB of in kilobytes van één cijfer), haalt de overhead van metadata de effectieve compressieverhouding naar beneden.
• Voorgecomprimeerde of vooraf versleutelde bestanden opslaan
  • Compressie en versleuteling kunnen het niveau van datawijziging versterken en de kans op deduplicatie verkleinen. Dergelijke bestanden kunnen meestal niet goed worden gededupliceerd en brengen de effectieve compressieverhouding van het systeem lager.
• Verwijderd
  • Verwijderingen verminderen de logische grootte van het systeem, maar het systeem krijgt de bijbehorende ongebruikte ruimte pas terug als de garbagecollection wordt uitgevoerd. Bij veel verwijderde bestanden wordt de compressieverhouding laag totdat Garbage Collection (GC) wordt uitgevoerd.
• Garbage Collection (GC) of schoonmaak
  • GC wint de ruimte terug die wordt verbruikt door gegevenssegmenten die door geen enkel bestand meer worden gezien. Als onlangs veel bestanden zijn verwijderd, kan GC de compressieverhouding van het systeem verhogen door de voetafdruk van het fysieke-ruimteverbruik te verminderen.
• Agressief snapshots maken
  • Wanneer een snapshot van een Mtree wordt genomen, wordt de logische grootte van de gegevensset niet gewijzigd. Alle gegevenssegmenten waarnaar wordt verwezen door de snapshot moeten echter worden vergrendeld, zelfs als alle bestanden die door de snapshot zijn vastgelegd, worden verwijderd nadat de snapshot is gemaakt. GC kan de ruimte die nog steeds nodig is voor snapshots niet vrijmaken, als er veel snapshots zijn, kan de effectieve compressieverhouding van het systeem laag lijken. Snapshots zijn echter nuttige herstelfaciliteiten voor crashes. Aarzel nooit om snapshots te maken of de juiste snapshotschema's in te stellen wanneer dat nodig is.

Compressie: Inline statistieken:

DDOS voert deduplicatie inline uit, terwijl data naar het systeem worden geschreven. Het houdt de effecten bij van inline deduplicatie en lokale compressie voor elke schrijfbewerking, en accumuleert de statistieken op bestandsniveau. Statistieken van inline compressie per bestand worden verder geaggregeerd op de mtree niveau en op systeemniveau. Compressie wordt gemeten op basis van drie getallen in de inline-statistieken:

• De lengte van elke schrijfbewerking: raw_bytes 
• The length of all unique segments: pre_lc_size
• De lengte van lokaal gecomprimeerde unieke segmenten: post_lc_size

• • Globale compressie (g_comp)
    • Is gelijk aan (raw_bytes/pre_lc_size), en geeft de deduplicatieratio weer
  • Lokale compressie (l_comp)
    • Is gelijk aan (pre_lc_size/post_lc_size) en weerspiegelt het effect van het lokale compressiealgoritme

De geaccumuleerde inline compressiestatistieken maken deel uit van de bestandsmetadata in DDOS en worden opgeslagen in het bestand inode. DDOS biedt tools om de inline compressies op alle drie de niveaus te controleren; Bestand MTreeen voor het hele systeem. Deze worden in de volgende secties nader toegelicht.

Bestandscompressie:

• • Bestandscompressie kan worden gecontroleerd met de "filesys show compression <path>" CLI-opdracht, die de geaccumuleerde compressiestatistieken rapporteert die in het bestand zijn opgeslagen inode.
  • Wanneer een map is opgegeven, worden de inline compressiestatistieken van alle bestanden in die map opgeteld en gerapporteerd.
  • In de CLI-uitvoer, raw_bytes is aangeduid als 'Original Bytes'. pre_lc_size is gelabeld als 'Globally Compressed', post_lc_bytes is gemarkeerd als 'Locally Compressed'. De overige overheadkosten worden gerapporteerd als 'metadata'. De twee voorbeelden zijn vastgelegd uit een productie-DD:

Voorbeeld 1: Inline compressiestatistieken van een bestand

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

Voorbeeld 2: Inline compressiestatistieken van alle bestanden in een directory, inclusief alle subdirectory's

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

• • • Het systeem rapporteert de algehele inline compressieverhouding in de bovenstaande CLI-uitvoer als "bytes/storage_used."
    • De bovenstaande informatie moet echter zorgvuldig worden geïnterpreteerd, omdat deze om verschillende redenen misleidend kan zijn.
    • Een van de redenen is dat de pre_lc_size als post_lc_size worden geregistreerd op het moment dat de gegevensverwerkingen worden verwerkt.
    • Wanneer het bestand waaraan deze segmenten oorspronkelijk zijn toegevoegd, wordt verwijderd, moet het aantal unieke gegevenssegmenten in het resterende bestand worden verhoogd.

Stel bijvoorbeeld dat er een back-up is van een voorbeeldbestand op een Data Domain en dat in de eerste back-up de compressiegegevens van het bestand pre_lc_size= 10 GiB, post_lc_size= 5 Gib.

• • • Ga er vervolgens van uit dat de gegevens van dit bestand uniek zijn en dat er geen gegevens worden gedeeld met een ander bestand.
    • Ga er in de tweede back-up van het bestand verder van uit dat het bestand een ideale deduplicatie krijgt, zodat zowel pre_lc_size als post_lc_size moet nul zijn omdat alle segmenten van het bestand al op het systeem aanwezig waren.
    • Wanneer de eerste back-up wordt verwijderd, wordt de tweede back-up van het bestand het enige bestand dat verwijst naar de 5 GiB aan gegevenssegmenten.
    • In dit geval is de pre_lc_size als post_lc_size van het bestand in de tweede back-up moet worden bijgewerkt van beide nul naar respectievelijk 10 GiB en 5 GiB.
    • Er is echter geen manier om te detecteren voor welke bestanden dat moet worden gedaan, dus de inline compressiestatistieken van de bestaande bestanden blijven ongewijzigd.

• • Een andere factor die van invloed is op de bovenstaande cijfers zijn de cumulatieve statistieken.
  • Wanneer een bestand veel overschrijvingen krijgt, is het onmogelijk om bij te houden in hoeverre de cumulatieve statistieken de schrijfbewerkingen weerspiegelen die de live-gegevens hebben geïntroduceerd.
  • Over een lange tijd kunnen de inline compressiestatistieken dus alleen worden behandeld als een heuristiek om de compressie van een bepaald bestand ruwweg te schatten.
  • Een ander feit dat het vermelden waard is, is dat de inline compressie van een bestand niet kan worden gemeten voor een willekeurig tijdsinterval.
  • De inline compressiestatistieken van de bestanden zijn een cumulatief resultaat en omvatten alle schrijfbewerkingen die het bestand ooit heeft ontvangen.
  • Wanneer een bestand veel overschrijvingen ontvangt, wordt het raw_bytes kan veel groter zijn dan de logische grootte van het bestand. Voor schaarse bestanden kunnen de bestandsgroottes groter zijn dan de 'Original Bytes'.

MTree-compressie:

• • De compressie van een bepaalde mtree kan worden gecontroleerd met de "mtree show compression" (MSC) CLI-opdracht.
  • De absolute waarden van de inline compressiestatistieken zijn cumulatief over de levensduur van de MTree.
  • Gezien het feit dat de levensduur van een MTree kunnen vele jaren duren, deze waarden worden in de loop van de tijd steeds minder informatief.
  • Om dit probleem op te lossen, wordt de hoeveelheid verandering (delta's) van de inline compressiestatistieken gebruikt en wordt compressie alleen voor bepaalde tijdsintervallen gerapporteerd.
  • De onderliggende benadering is dat de MTree Inline compressiestatistieken worden periodiek in een logboek gedumpt.
  • Wanneer een client MTree-compressie opvraagt met de MSC opdracht, wordt het logboek gebruikt om de delta's van de getallen voor compressierapportage te berekenen.
  • Standaard MSC Rapporteert compressie voor de afgelopen 7 dagen en de afgelopen 24 uur, hoewel op elk moment een interessante periode kan worden opgegeven.

Ga voor dit demonstratie uit van het volgende logboek voor 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

Vervolgens wordt de compressie van MTree A voor dit uur is:

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

De bovenstaande berekening van de compressieverhouding doet niets met de grootte van de dataset. De bovenstaande mtree mag bijvoorbeeld alleen logische data van 500 GB bevatten.

• • MSC Ondersteunt de opties "Dagelijks" en "Dagelijks-gedetailleerd", net als de "filesys show compression" commando.
  • Wanneer "daily" is opgegeven, rapporteert de opdracht de dagelijkse compressie op een kalendermanier.
  • Het maakt gebruik van de dagelijkse delta's van de raw_bytes als post_lc_size om de dagelijkse compressieverhouding te berekenen.
  • Wanneer "daily-detailed" is opgegeven, toont de opdracht alle drie de delta's (van de raw_bytes, pre_lc_sizeen post_lc_size, respectievelijk) voor elke dag. Het berekent ook de g_comp als l_comp naast de totale compressiefactor.

Een voorbeeld van de uitvoer van deze systemen is opgenomen in de bijlage hieronder.

Systeemcompressie:

• • Zodra wordt gerapporteerd over compressie op MTrees wordt begrepen, is het eenvoudig om het concept uit te breiden naar het hele systeem.
  • Het verzamelen en rapporteren van systeembrede compressie-inline statistieken is precies hetzelfde als bij MTrees.
  • Het enige verschil is de reikwijdte, aangezien men zich in een bepaalde MTree, terwijl men over het hele systeem gaat.
  • De resultaten kunnen worden gecontroleerd met behulp van de "filesys show compression" commando.
  • Een voorbeeld hiervan is te vinden in hoofdstuk 2.
  • De systeemcompressie van de afgelopen 7 dagen en de afgelopen 24 uur wordt vermeld op de laatste twee regels van het resultatengedeelte in de FSC Output.

Cloudlaag:

• Op DD's met cloudlaag geïmplementeerd, wordt de storage gescheiden in de actieve laag en de cloudlaag, die twee onafhankelijke deduplicatiedomeinen zijn.
• Gebruikers kunnen alleen gegevens injecteren in de actieve laag.
• Later kunnen DDOS-functies voor dataverplaatsing worden gebruikt om data van de actieve laag naar de cloudlaag te migreren.
• De ruimte- en compressiemeting en -rapportage worden dus onafhankelijk van elkaar afgehandeld in elke laag.
• Maar op bestandsniveau wordt er geen onderscheid gemaakt naar niveau en rapporteer inline compressiestatistieken, ze zijn precies hetzelfde als wat beschreven in paragraaf 3.1.

Deduplicatie:

Het laatste onderwerp dat moet worden belicht, zijn enkele kenmerken van deduplicatie, die in veel Data Domain-artikelen 'globale compressie' wordt genoemd.

Hoewel het het woord 'compressie' bevat, is het totaal anders dan het traditionele concept van compressie, dat ook door DDOS wordt geleverd onder de naam 'lokale compressie'.

• Lokale compressie verkleint de grootte van een stuk gegevens met behulp van een bepaald algoritme (sommige soorten gegevens zijn niet comprimeerbaar en het toepassen van compressiealgoritmen erop kan de gegevensgrootte enigszins vergroten).
• Meestal, als er eenmaal een algoritme is besloten, zijn de gegevens de enige factor van de compressieverhouding.
• Deduplicatie is echter anders - het is geen lokaal concept, het is 'globaal'.
• Een binnenkomend datasegment wordt gededupliceerd tegen alle bestaande datasegmenten in een gededupliceerd domein, dat alle data op niet-cloud Data Domain-systemen omvat.
• Het datasegment zelf doet er niet toe in de deduplicatieprocedure.
• In de praktijk wordt een hoge deduplicatieratio zelden gezien in de initiële back-up van een dataset. In de eerste back-ups is de belangrijkste datareductie vaak afkomstig van lokale compressie.
• Wanneer opeenvolgende back-ups op het Data Domain terechtkomen, toont deduplicatie zijn kracht en wordt het de dominante factor voor compressie.
• De effectiviteit van deduplicatie is afhankelijk van het feit dat de wijzigingssnelheid van een dataset laag is van back-up tot back-up. Om deze reden kunnen datasets met hoge wijzigingssnelheden niet goed worden gededupliceerd.
• Wanneer de back-upapplicatie met hoge frequentie zijn eigen metadatabrokken (door Data Domain markers genoemd) in de back-upimages invoegt, krijgt deze mogelijk ook geen goede deduplicatieratio. Onze technieken voor het hanteren van markers kunnen soms helpen, maar niet altijd.

Wat kunt u, gezien deze observaties, verwachten:

• Met initiële back-ups wordt mogelijk slechts een kleine effectieve compressieverhouding van het systeem bereikt, vaak 2x of 3x. Dedupliceren heeft meestal weinig kans om zijn kracht te tonen in initiële back-ups.
• De algehele compressieverhouding van een incrementele back-up is lager dan de compressieverhouding van de bijbehorende volledige back-up. Dit komt doordat een incrementele back-up alleen gewijzigde of nieuwe bestanden bevat in vergelijking met de directe eerdere back-up. De algehele compressieverhouding is afhankelijk van het percentage nieuwe data binnen de incrementele back-up.
• De deduplicatieratio van een volledige back-up (de niet-originele) kan in sommige scenario's ook laag zijn. Enkele vaak waargenomen scenario's zijn:
  • Een hoge wijzigingssnelheid in de data waarvan een back-up wordt gemaakt
  • De dataset wordt gedomineerd door kleine bestanden (minder dan 5 MiB)
  • Back-upapplicaties die veel dicht bij elkaar geplaatste markeringen toevoegen
  • Databaseback-ups die incrementeel zijn of een kleine blokgrootte gebruiken
  • Wanneer een lage compressieverhouding wordt waargenomen in een volledige back-up met een lage datawijzigingssnelheid, controleert u of een van de bovenstaande gevallen van toepassing is of dat verdere analyse nodig is.
• Compressie van een latere back-upimage is niet altijd beter dan de oorspronkelijke. Opeenvolgende back-upimages kunnen een hoge deduplicatieverhouding weergeven, omdat de eerste en eerdere back-upimages de meeste data al aan het systeem hebben toegevoegd. Wanneer alle eerdere back-upimages zijn verwijderd, kan de algehele en lokale compressieverhouding van de vroegst bestaande back-upimage nog steeds hoog zijn, maar dit betekent alleen dat deze een goede deduplicatie heeft gekregen toen deze aan het systeem werd toegevoegd. Wanneer een bestand wordt verwijderd dat een hoge algemene en lokale compressieverhouding heeft en de laatste back-upimage van een bepaalde dataset is, kan er meer ruimte vrijkomen dan de grootte die is afgeleid van de compressieverhouding.
• Compressieverhoudingen van dezelfde dataset op verschillende systemen kunnen niet worden vergeleken, ongeacht de manier waarop de dataset aan die systemen wordt toegevoegd. Dit komt doordat elk systeem een onafhankelijk deduplicatiedomein is. Er wordt niet verwacht dat twee verschillende DD's dezelfde of zelfs noodzakelijkerwijs vergelijkbare compressieverhoudingen krijgen, zelfs als hun datasets hetzelfde zijn.

Samenvatting:

• Het meten van compressie is moeilijk in gededupliceerde bestandssystemen, maar het is nog moeilijker in gededupliceerde bestandssystemen met logstructuur.
• Hoe deduplicatie werkt en hoe compressiestatistieken worden bijgehouden, moet worden begrepen.
• Compressieverhoudingen zijn nuttige informatie om het gedrag van een bepaald systeem te begrijpen.
• De effectieve compressieverhouding van het systeem is de belangrijkste, betrouwbaarste en meest informatieve maatstaf.
• De inline compressiestatistieken kunnen ook nuttig zijn, maar in sommige omstandigheden zijn ze misschien niet meer dan heuristieken.

Bijlage:

Steekproefuitvoer van "mtree show compression" Opdracht

• Stel dat er sprake is van een MTree met 254792,4 GiB aan gegevens. Het heeft 4379,3 GiB aan nieuwe gegevens ontvangen in de afgelopen 7 dagen en 78,4 GiB in de afgelopen 24 uur (andere tijdsintervallen kunnen worden gespecificeerd).
• Met de optie 'daily' worden de inline compressiestatistieken van de afgelopen 33 dagen gerapporteerd.
• Wanneer de optie "dagelijks-gedetailleerd" is ingeschakeld, worden de totale compressieverhoudingen verder gedetailleerd door ze te scheiden in algemene en lokale compressieverhoudingen.

De mtree Lijst uitvoer:

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 (geen opties):

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

Met de optie "dagelijks":

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

Met de optie "dagelijks-gedetailleerd":

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