Data Domain: Informazioni sulla compressione di Data Domain

Le tecniche di compressione coinvolte in un Data Domain utilizzano tecniche all'avanguardia per ridurre lo spazio fisico richiesto dai dati di backup. Come tali, le tecnologie e le misurazioni dei livelli di compressione sono argomenti complessi.

Questo articolo illustra alcune terminologie, compromessi e misure per spiegare meglio il tipo di compressione utilizzato e altri aspetti della compressione in un'ambiente Data Domain.

SI APPLICA A: Tutti i modelli Data Domain

Introduzione:

Ultimo aggiornamento: Gennaio 2024

• La compressione è una tecnologia di riduzione dei dati che ha lo scopo di archiviare un dataset utilizzando meno spazio fisico.
• Nei sistemi Data Domain (DDOS), la deduplica e la compressione locale vengono eseguite per comprimere i dati dell'utente. La deduplica, o "deduplica", viene utilizzata per identificare segmenti di dati ridondanti e archiviare solo segmenti di dati univoci.
• La compressione locale comprime ulteriormente i segmenti di dati univoci con determinati algoritmi di compressione, come lz, gzfast, gzcosì via.
• La compressione complessiva dei dati dell'utente in DDOS è lo sforzo congiunto di deduplica e compressione locale. DDOS utilizza un "rapporto di compressione" per misurare l'efficacia della compressione dei dati.
• In genere, è il rapporto tra la dimensione totale dei dati utente e la dimensione totale dei dati compressi o la dimensione dello spazio fisico utilizzato.
• Il file system di Data Domain è un file system di deduplica con struttura log.
• Un file system strutturato in log si limita ad aggiungere i dati al sistema e l'eliminazione da sola non libera spazio fisico.
• Questo tipo di file system si basa sulla garbage collection per recuperare lo spazio che non è più necessario.
• Le caratteristiche del file system con struttura logaritmica e la tecnologia di deduplica combinate rendono difficile comprendere chiaramente tutti gli aspetti della compressione in DDOS.

Per quanto riguarda la compressione, ci sono molti aspetti che possono essere misurati.

Questo articolo illustra i dettagli dettagliati per comprendere la compressione DDOS.

• Innanzitutto, viene illustrato l'effetto di compressione complessivo del sistema, che indica la compressione realistica raggiunta in un sistema Data Domain, la quantità di dati dell'utente, la quantità di spazio fisico utilizzato e il loro rapporto.
• Questo rapporto è chiamato "rapporto di compressione effettivo del sistema" in questo articolo.
• DDOS esegue la deduplica in linea e tiene traccia delle statistiche dei segmenti di dati utente originali, dei segmenti di dati univoci postdedupe e dell'effetto di compressione locale sui segmenti di dati univoci.
• Queste statistiche di compressione in linea vengono utilizzate per misurare l'effetto della compressione in linea. Le statistiche di compressione in linea possono essere misurate per ogni scrittura. Inoltre, DDOS tiene traccia delle statistiche a diversi livelli: File MTreese l'intero sistema.

Non ci sono garanzie che tutto il contenuto sarà accurato anche per le versioni future.

Nelle release precedenti alla 5.0, l'intero sistema dispone di un solo mtree e il termine mtree non è esplicitamente richiamato.

Compressione: Effetto complessivo del sistema:

L'effetto di compressione complessivo a livello di sistema è misurato dal rapporto di compressione effettivo, ovvero il rapporto tra le dimensioni dei dati utente e le dimensioni dello spazio fisico utilizzato. Lo riporta il "filesys show compression" (FSC) Comando CLI (le informazioni corrispondenti sono disponibili anche nell'interfaccia utente). Un output di esempio di FSC è mostrato di seguito:

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

• •  
  • Il rapporto di compressione effettivo del sistema viene riportato nella riga 1 della sezione dei risultati nell'output della CLI. La riga è evidenziata sopra.
  • La dimensione totale dei dati dell'utente è etichettata come "Pre-Comp".
  • Lo spazio fisico totale utilizzato (sia in termini di dati sia di metadati) è etichettato come "Post-Comp".
  • Il numero "Pre-Comp" e il numero "Post-Comp" vengono entrambi letti in fase di runtime. FSC Sincronizza implicitamente l'intero sistema, quindi interroga i due numeri.
    • Questi due numeri sono misurati allo stesso modo del "filesys show space" comando.
    • Rapporto di compressione effettivo del sistema = Pre-Comp/Post-Comp

Alcune operazioni possono influire sul rapporto di compressione effettivo del sistema:

• Copia rapida
  • Quando un fastcopy viene eseguita da un file nel namespace attivo (non da un'istantanea), è una deduplica perfetta, in quanto non è necessario spazio fisico aggiuntivo per il file di destinazione. L'effetto di un fastcopy è che le dimensioni dei dati dell'utente vengono aumentate senza consumare spazio fisico aggiuntivo. Ciò aumenta il rapporto di compressione effettivo del sistema. Quando molti fastcopies sono fatto, il rapporto di compressione effettivo del sistema può diventare artificialmente alto.
• Backup sintetici virtuali
  • I backup sintetici virtuali tendono a mostrare un elevato rapporto di compressione effettivo del sistema. Ciò è dovuto al fatto che i backup sintetici virtuali eseguono backup logici completi, ma trasferiscono solo i dati nuovi o modificati ai sistemi Data Domain. L'impatto sul rapporto di compressione effettivo del sistema dei supporti sintetici virtuali è simile a quello del fastcopy.
• Sovrascrive
  • Le sovrascritture utilizzano più spazio fisico ma non aumentano le dimensioni logiche del dataset, riducendo così il rapporto di compressione effettivo del sistema
• Archiviazione di file sparse
  • I file sparse contengono grandi "buchi" che vengono conteggiati nelle dimensioni logiche ma che, per via della compressione, non occupano spazio fisico. Di conseguenza, possono far apparire alto il rapporto di compressione effettivo nel sistema.
• Archiviazione di file di piccole dimensioni
  • DDOS aggiunge quasi 1 KB di overhead a ciascun file per determinati metadati interni. Quando un sistema archivia un numero significativo di file di piccole dimensioni (dimensioni inferiori a 1 KB o in kilobyte a una cifra), l'overhead dei metadati trascina verso il basso il rapporto di compressione effettivo.
• Archiviazione di file precompressi o precrittografati
  • La compressione e la crittografia possono amplificare il livello di modifica dei dati e ridurre la possibilità di deduplica. Tali file in genere non possono essere deduplicati correttamente e portare il rapporto di compressione effettivo del sistema più basso.
• Elimina
  • Le eliminazioni riducono le dimensioni logiche del sistema ma il sistema non può recuperare lo spazio inutilizzato corrispondente fino a quando non viene eseguita una garbage collection. Molti file eliminati riducono il rapporto di compressione fino a quando non viene eseguita la garbage collection (GC).
• Garbage Collection (GC) o pulizia
  • GC recupera lo spazio utilizzato dai segmenti di dati che non sono più visualizzati da alcun file. Se molti file sono stati eliminati di recente, la GC può far aumentare il rapporto di compressione nel sistema riducendo lo spazio fisico utilizzato.
• Acquisizione aggressiva di snapshot
  • Quando l'istantanea di un Mtree , la dimensione logica del dataset non viene modificata. Tuttavia, tutti i segmenti di dati a cui fa riferimento la snapshot devono essere bloccati, anche se tutti i file acquisiti dalla snapshot vengono eliminati dopo la creazione della snapshot. GC non può recuperare lo spazio ancora necessario per le istantanee. La presenza di molte istantanee potrebbe ridurre il rapporto di compressione effettivo del sistema. Tuttavia, le snapshot sono utili strutture di ripristino in caso di arresto anomalo. Non esitare mai a scattare istantanee o a impostare pianificazioni appropriate quando necessario.

Compressione: Statistiche in linea:

DDOS esegue la deduplica in linea, man mano che i dati vengono scritti nel sistema. Tiene traccia degli effetti della deduplica in linea e della compressione locale per ogni scrittura e accumula le statistiche a livello di file. Le statistiche di compressione in linea per file vengono ulteriormente aggregate in mtree a livello di sistema e a livello di sistema. La compressione viene misurata in base a tre numeri nelle statistiche in linea:

• La lunghezza di ogni scrittura: raw_bytes 
• The length of all unique segments: pre_lc_size
• La lunghezza dei segmenti univoci compressi localmente: post_lc_size

• • Compressione globale (g_comp)
    • È uguale a (raw_bytes/pre_lc_size) e riflette il rapporto di deduplica
  • Compressione locale (l_comp)
    • È uguale a (pre_lc_size/post_lc_size) e riflette l'effetto dell'algoritmo di compressione locale

Le statistiche di compressione in linea accumulate fanno parte dei metadati del file in DDOS e sono archiviate nel file inode. DDOS fornisce strumenti per controllare le compressioni in linea a tutti e tre i livelli; File MTreee a livello di sistema. Questi sono descritti in dettaglio nelle sezioni seguenti.

Compressione dei file:

• • La compressione dei file può essere verificata con "filesys show compression <path>" CLI, che riporta le statistiche di compressione accumulate memorizzate nel file inode.
  • Quando viene specificata una directory, vengono riepilogate e segnalate le statistiche di compressione in linea di tutti i file in tale directory.
  • Nell'output della CLI, raw_bytes è etichettato come "Byte originali", pre_lc_size è etichettato come "Globally Compressed," post_lc_bytes è contrassegnato come "Compresso localmente". Gli altri overhead vengono segnalati come "metadati". I due esempi vengono acquisiti da un DD di produzione:

Esempio 1: Statistiche di compressione in linea di un file

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

Esempio 2: Statistiche di compressione in linea di tutti i file in una directory, incluse tutte le sottodirectory

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

• • • Il sistema riporta il rapporto di compressione in linea complessivo nell'output della CLI precedente come "bytes/storage_used".
    • Occorre tuttavia prestare attenzione nell'interpretare queste informazioni perché possono essere fuorvianti per diversi motivi.
    • Uno dei motivi è che il pre_lc_size e post_lc_size sono registrati al momento del trattamento dei dati.
    • Quando il file che originariamente ha aggiunto tali segmenti viene eliminato, il numero dei segmenti di dati univoci nel file rimanente deve essere aumentato.

Ad esempio, si supponga che sia stato eseguito il backup di un file di esempio in un Data Domain e che nel primo backup le informazioni di compressione del file siano pre_lc_size= 10 GiB, post_lc_size= 5 Gib.

• • • Si supponga poi che i dati di questo file siano univoci e che non vengano condivisi con altri file.
    • Nel secondo backup del file, si supponga inoltre che il file ottenga la deduplica ideale, in modo che entrambi pre_lc_size e post_lc_size Deve essere zero perché tutti i segmenti del file esistono già nel sistema.
    • Quando viene eliminato il primo backup, il secondo backup del file diventa l'unico file che fa riferimento ai 5 GiB di segmenti di dati.
    • In questo caso, idealmente, il pre_lc_size e post_lc_size del file nel secondo backup deve essere aggiornato da entrambi a 10 GiB e 5 GiB, rispettivamente.
    • Tuttavia, non esiste alcun modo per rilevare quali file devono essere eseguiti, quindi le statistiche di compressione in linea dei file esistenti rimangono invariate.

• • Un altro fattore che influisce sui numeri di cui sopra sono le statistiche cumulative.
  • Quando un file riceve molte sovrascritture, è impossibile tenere traccia della misura in cui le statistiche cumulative riflettono le scritture che hanno introdotto i dati in tempo reale.
  • Pertanto, per un lungo periodo di tempo, le statistiche di compressione in linea possono essere trattate solo come un'euristica per stimare approssimativamente la compressione di un particolare file.
  • Un altro dato che vale la pena sottolineare è che la compressione in linea di un file non può essere misurata per un intervallo di tempo arbitrario.
  • Le statistiche di compressione in linea dei file sono un risultato cumulativo e coprono tutte le scritture che il file ha ricevuto.
  • Quando un file riceve molte sovrascritture, il raw_bytes può essere molto più grande della dimensione logica del file. Per i file sparse, le dimensioni dei file possono essere superiori ai "byte originali".

Compressione MTree:

• • La compressione di un particolare mtree può essere verificato con il "mtree show compression" (MSC) Comando CLI.
  • I valori assoluti delle statistiche di compressione in linea sono cumulativi per l'intera durata di MTree.
  • Dato che la durata di vita di un MTree possono durare molti anni, questi valori diventano sempre meno informativi nel tempo.
  • Per risolvere questo problema, viene utilizzata la quantità di modifica (delta) delle statistiche di compressione in linea e segnala la compressione solo per determinati intervalli di tempo.
  • L'approccio di fondo è che il MTree Le statistiche di compressione in linea vengono scaricate periodicamente in un registro.
  • Quando un client esegue una query sulla compressione MTree con MSC , il log viene utilizzato per calcolare i delta dei numeri per il reporting di compressione.
  • Per impostazione predefinita, MSC Segnala la compressione degli ultimi 7 giorni e delle ultime 24 ore, anche se è possibile specificare qualsiasi periodo di interesse.

Per la dimostrazione, si supponga il seguente registro per MTree R.

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

Quindi la compressione di MTree A per quest'ora è:

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

Il calcolo del rapporto di compressione di cui sopra non esegue alcuna operazione con le dimensioni del dataset. Ad esempio, l'mtree precedente potrebbe avere solo 500 GB di dati logici.

• • MSC supporta le opzioni "Daily" e "Daily-Detailed", così come "filesys show compression" comando.
  • Quando si specifica "daily", il comando segnala la compressione giornaliera secondo una modalità di calendario.
  • Utilizza i delta giornalieri del raw_bytes e post_lc_size per calcolare il rapporto di compressione giornaliero.
  • Quando viene specificato "daily-detailed", il comando mostra tutti e tre i delta (di raw_bytes, pre_lc_sizee post_lc_size, rispettivamente) per ogni giorno. Inoltre, calcola la proprietà g_comp e l_comp insieme al fattore di compressione totale.

Nell'appendice seguente è riportato un esempio di output di questi sistemi.

Compressione del sistema:

• • Una volta in che modo viene segnalata la compressione MTrees è compreso, è semplice estendere il concetto all'intero sistema.
  • La raccolta e il reporting delle statistiche in linea di compressione a livello di sistema sono esattamente gli stessi di MTrees.
  • L'unica differenza è l'ambito di applicazione, in quanto ci si trova in un particolare MTree, mentre uno è sull'intero sistema.
  • I risultati possono essere verificati utilizzando il pulsante "filesys show compression" comando.
  • Un esempio di ciò è riportato nella sezione 2.
  • La compressione di sistema "ultimi 7 giorni" e "ultime 24 ore" viene riportata nelle ultime due righe della sezione dei risultati in FSC .

Cloud Tier:

• Nei DD con cloud tier implementato, lo storage è separato in tier attivo e cloud tier, che sono due domini di deduplica indipendenti.
• Gli utenti possono inserire dati solo nel tier attivo.
• Successivamente, è possibile utilizzare le funzioni di spostamento dei dati DDOS per migrare i dati dall'Active Tier al Cloud Tier.
• Pertanto, la misurazione e il reporting dello spazio e della compressione vengono gestiti in modo indipendente in ogni tier.
• Tuttavia, a livello di file, non viene fatta alcuna differenziazione in base al tier e alle statistiche di compressione in linea del report, che sono esattamente le stesse descritte nella Sezione 3.1.

Deduplicazione:

L'ultimo argomento da evidenziare sono alcune delle caratteristiche della deduplica, chiamata "compressione globale" in molti articoli di Data Domain.

Sebbene contenga il termine "compressione", è completamente diverso dal concetto tradizionale di compressione, fornito anche da DDOS con il nome di "compressione locale".

• La compressione locale riduce le dimensioni di un dato utilizzando un determinato algoritmo (alcuni tipi di dati non sono comprimibili e l'applicazione di algoritmi di compressione su di essi può aumentare leggermente le dimensioni dei dati).
• Di solito, una volta deciso un algoritmo, i dati sono l'unico fattore del rapporto di compressione.
• Tuttavia, la deduplica è diversa: non è un concetto locale, è "globale".
• Un segmento di dati in ingresso viene deduplicato rispetto a tutti i segmenti di dati esistenti in un dominio deduplicato, che include tutti i dati sui sistemi Data Domain non cloud.
• Il segmento di dati in sé non è importante nella procedura di deduplica.
• In pratica, raramente si riscontra un rapporto di deduplica elevato nel backup iniziale di un dataset. Nei backup iniziali, la principale riduzione dei dati spesso deriva dalla compressione locale.
• Quando i backup successivi arrivano su Data Domain, la deduplica mostra i suoi punti di forza e diventa il fattore dominante per la compressione.
• L'efficacia della deduplica si basa sul fatto che la frequenza di modifica di un dataset da backup a backup è bassa. Per questo motivo, i set di dati con tassi di modifica elevati non possono essere deduplicati.
• Quando l'applicazione di backup inserisce i propri blocchi di metadati (denominati marcatori da Data Domain) nelle immagini di backup ad alta frequenza, potrebbe anche non ottenere un buon rapporto di deduplica. Le nostre tecniche di manipolazione dei marcatori possono aiutare a volte, ma non sempre.

Alla luce di queste osservazioni, cosa aspettarsi:

• I backup iniziali possono raggiungere solo un piccolo rapporto di compressione effettivo del sistema, spesso 2 o 3 volte. La deduplica in genere ha poche opportunità di mostrare la propria efficacia nei backup iniziali.
• Il rapporto di compressione globale di un backup incrementale è inferiore al rapporto di compressione del corrispondente backup completo. Ciò è dovuto al fatto che un backup incrementale contiene solo file nuovi o modificati rispetto al backup immediatamente precedente. Il rapporto di compressione globale dipende dalla percentuale di nuovi dati inclusi nel backup incrementale.
• Anche il rapporto di deduplica di un backup completo (quelli non iniziali) può essere basso in alcuni scenari. Alcuni scenari osservati di frequente includono:
  • Un elevato tasso di modifica nei dati sottoposti a backup
  • Il dataset è dominato da file di piccole dimensioni (meno di 5 MiB)
  • Applicazioni di backup che aggiungono molti marcatori ravvicinati
  • Backup di database incrementali o che utilizzano blocchi di piccole dimensioni
  • Quando si osserva un basso rapporto di compressione in un backup completo con un basso tasso di modifica dei dati, verificare se si applica uno dei casi precedenti o se sono necessarie ulteriori analisi.
• La compressione di un'immagine di backup successiva non è sempre migliore di quella iniziale. Le immagini di backup consecutive possono mostrare un rapporto di deduplica elevato perché le immagini di backup iniziali e precedenti hanno già aggiunto la maggior parte dei dati al sistema. Quando tutte le immagini di backup precedenti vengono eliminate, il rapporto di compressione globale e locale della prima immagine di backup esistente potrebbe essere ancora elevato, ma ciò significa solo che ha ottenuto una buona deduplica quando è stata aggiunta al sistema, nient'altro. Quando viene eliminato un file con un elevato rapporto di compressione globale e locale ed è l'ultima immagine di backup di un particolare dataset, potrebbe liberare più spazio rispetto alle dimensioni derivate dal rapporto di compressione.
• I rapporti di compressione dello stesso dataset su sistemi diversi non possono essere confrontati, indipendentemente dal modo in cui il dataset viene aggiunto a tali sistemi. Ciò è dovuto al fatto che ogni sistema è un dominio di deduplica indipendente. Non ci si aspetta che due DD diversi ottengano rapporti di compressione uguali o necessariamente simili, anche se i loro dataset sono gli stessi.

Riepilogo:

• Misurare la compressione è difficile nei file system deduplicati, ma lo è ancora di più nei file system deduplicati con struttura log.
• È necessario comprendere come funziona la deduplica e come vengono monitorate le statistiche di compressione.
• I rapporti di compressione sono informazioni utili per comprendere il comportamento di un particolare sistema.
• Il rapporto di compressione effettivo del sistema è la misura più importante, affidabile e informativa.
• Anche le statistiche di compressione in linea possono essere utili, ma in alcune circostanze potrebbero non essere altro che euristiche.

Appendice:

Esempio di output di "mtree show compression" .

• Si supponga che sia presente un MTree contenente 254792,4 GiB di dati. Ha ricevuto 4.379,3 GiB di nuovi dati negli ultimi 7 giorni e 78,4 GiB nelle ultime 24 ore (è possibile specificare altri intervalli di tempo).
• L'opzione "daily" riporta le statistiche di compressione in linea relative agli ultimi 33 giorni.
• Quando viene fornita l'opzione "daily-detailed", i rapporti di compressione totali vengono ulteriormente dettagliati separandoli in rapporti di compressione globali e locali.

La colonna mtree Output dell'elenco:

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 (nessuna opzione):

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

Con l'opzione "giornaliero":

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

Con l'opzione "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