Le tecniche di compressione coinvolte in un Data Domain utilizzano tecniche all'avanguardia per ridurre lo spazio fisico richiesto dai dati del cliente. Come tali, le tecnologie e le misurazioni dei livelli di compressione sono argomenti complessi. In questo documento vengono illustrate alcune terminologie, compromessi e misure per spiegare meglio i tipi di compressione utilizzati, la terminologia e altri aspetti della compressione in un sistema Data Domain.
SI APPLICA A:
Tutti i modelli Data Domain
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), eseguiamo la deduplica e la compressione locale per comprimere i dati dell'utente. La deduplica viene utilizzata per identificare segmenti di dati ridondanti in modo che vengano salvati 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 possiamo misurare. In questo documento descriveremo i dettagli passo dopo passo per comprendere meglio la compressione DDOS. Innanzitutto, spieghiamo l'effetto complessivo della compressione 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 documento. DDOS esegue la deduplica in linea e tiene traccia delle statistiche dei segmenti di dati utente originali, dei segmenti di dati univoci post-deduplica 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; MTrees e l'intero sistema.
Il contenuto di questo documento può essere applicato a tutte le versioni di DDOS fino alla pubblicazione del presente documento, fino a DDOS 7.13. 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 indicato.
L'effetto di compressione complessivo a livello di sistema viene misurato dal rapporto di compressione effettivo del sistema, ovvero il rapporto tra la dimensione dei dati utente e la dimensione dello spazio fisico utilizzato. Viene segnalato dal comando della CLI filesys show compression (FSC) (le informazioni corrispondenti sono disponibili anche nell'interfaccia utente). Di seguito è riportato un esempio di output di FSC:
# 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 questi due valori. Questi due numeri vengono misurati nello stesso modo del comando
"filesys show space".Rapporto di compressione effettivo del sistema = Pre-Comp/Post-Comp
Il resto dell'output FSC descrive le statistiche di compressione in linea, di cui parleremo più avanti.
Alcune operazioni possono influire sul rapporto di compressione effettivo del sistema:
Copia veloce
Quando viene eseguita una copia rapida da un file nel namespace attivo (non da un'istantanea), si tratta di una deduplica perfetta, in quanto non è necessario spazio fisico aggiuntivo per il file di destinazione. L'effetto di una fastcopy è che le dimensioni dei dati dell'utente aumentano senza occupare ulteriore spazio fisico. Ciò aumenta il rapporto di compressione effettivo del sistema. Quando vengono eseguite molte copie rapide, il rapporto di compressione effettivo del sistema può diventare artificialmente elevato.
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 sintetici virtuali è in qualche modo simile all'effetto di 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 pre-compressi o pre-crittografati
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 si esegue un'istantanea di un MTree, non viene modificata la dimensione logica del set di dati. 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; Pertanto, la presenza di molte istantanee può far apparire basso il rapporto di compressione effettivo del sistema. Tuttavia, le snapshot sono utili strutture di ripristino in caso di arresto anomalo. Pertanto, è sempre opportuno creare snapshot o pianificare la creazione di snapshot.
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 a livello di MTree e a livello di sistema. La compressione viene misurata in base a tre numeri nelle statistiche in linea:
Sulla base dei tre numeri precedenti, DDOS definisce altri due rapporti di compressione con granularità fine:
Le statistiche di compressione in linea aggregate sono incluse nei metadati dei file in DDOS e vengono salvate nell'inode dei file. DDOS fornisce strumenti per controllare le compressioni in linea a tutti e tre i livelli; file, MTree e a livello di sistema. Li descriviamo in dettaglio nelle sezioni seguenti.
3.1 Compressione
dei file La compressione dei file può essere verificata con il comando CLI "filesys show compression <path>", che riporta le statistiche di compressione accumulate memorizzate nell'inode del file. 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 è contrassegnato come "Byte originali"; pre_lc_size è etichettato come "Globally Compressed"; post_lc_bytes è contrassegnato come "Compresso localmente"; le altre spese generali sono indicate come "metadati". I due esempi vengono acquisiti da un DD:
Esempio 1 effettivo: 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 "byte/storage_used". Occorre tuttavia prestare attenzione nell'interpretare queste informazioni perché possono essere fuorvianti per diversi motivi. Uno è che i valori pre_lc_size e post_lc_size vengono registrati nel momento in cui le operazioni sui dati vengono elaborate. Quando il file che originariamente ha aggiunto tali segmenti viene eliminato, il numero dei segmenti di dati univoci nel file rimanente deve essere aumentato.
Si supponga, ad esempio, che venga eseguito il backup di un file sample.file 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 sia pre_lc_size che post_lc_size siano pari a 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, la pre_lc_size e il post_lc_size del file nel secondo backup dovrebbero essere aggiornati da zero 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 del 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".
3.2 Compressione
MTreePossiamo controllare la compressione di un particolare mtree con il comando "mtree show compression" (MSC) Comando CLI. I valori assoluti delle statistiche di compressione in linea sono cumulativi per l'intera durata dell MTree. Dato che la durata di un MTree può durare diversi anni, questi valori diventano sempre meno informativi nel tempo. Per risolvere questo problema, utilizziamo la quantità di modifiche (delta) delle statistiche di compressione in linea e segnaliamo la compressione solo per determinati intervalli di tempo. L'approccio sottostante consiste nel scaricare periodicamente le statistiche di compressione in linea MTree in un log. Quando un client esegue una query sulla compressione MTree con il comando MSC, utilizziamo il log per calcolare i delta dei numeri per il reporting della 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 l 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
La compressione dell 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 il comando "filesys show compression". Quando si specifica "daily", il comando segnala la compressione giornaliera secondo una modalità di calendario. Per calcolare il rapporto di compressione giornaliero vengono utilizzati i delta giornalieri dei valori raw_bytes e post_lc_size. Quando viene specificato "daily-detailed", il comando mostra tutti e tre i delta (rispettivamente dei raw_bytes, pre_lc_size e post_lc_size) per ogni giorno; Inoltre, calcola il g_comp e l_comp insieme al fattore di compressione totale.
Un esempio di output di questi sistemi si trova nell'Appendice.
3.3 Compressione
del sistema Una volta compreso come viene riportata la compressione sugli MTrees, è 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 degli MTrees. L'unica differenza è l'ambito, in quanto uno si trova in un particolare MTree, mentre l'altro è sull'intero sistema. È possibile controllare i risultati utilizzando il comando "filesys show compression". 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 nell'output di FSC.
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 facciamo alcuna distinzione in base al tier e non riportiamo le statistiche di compressione in linea; sono esattamente uguali a quelli descritti nella Sezione 3.1.
L'ultimo argomento da evidenziare sono alcune delle caratteristiche della deduplica, chiamata "compressione globale" in molti documenti 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 stessi 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 possiamo aspettarci?
Misurare la compressione è difficile nei file system deduplicati, ma lo è ancora di più nei file system deduplicati con struttura log. È necessario comprendere il funzionamento della deduplica e il modo in cui 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" comando
: 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.
Output dell'elenco MTree:
# 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
# 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