As técnicas de compactação envolvidas em um Data Domain usam técnicas de última geração para reduzir o espaço físico exigido pelos dados do cliente. Portanto, as tecnologias e as medições dos níveis de compactação são tópicos complexos. Este documento discute algumas terminologias, compensações e medidas para explicar melhor os tipos de compactação usados, a terminologia e outros aspectos da compactação em um sistema Data Domain.
APLICA-SE A:
Todos os modelos do Data Domain
Última atualização: Janeiro de 2024
A compactação é uma tecnologia de redução de dados que visa armazenar um conjunto de dados usando menos espaço físico. Em sistemas Data Domain (DDOS), fazemos desduplicação e compactação local para compactar dados do usuário. A desduplicação, ou deduplicação, é usada para identificar segmentos de dados redundantes e armazenar apenas segmentos de dados exclusivos. A compactação local compacta ainda mais os segmentos de dados exclusivos com determinados algoritmos de compactação, como lz, gzfast, gz, assim por diante. A compactação geral de dados do usuário no DDOS é o esforço conjunto de desduplicação e compactação local. O DDOS usa a "taxa de compactação" para medir a eficácia da compactação de dados. Geralmente, é a proporção entre o tamanho total dos dados do usuário e o tamanho total dos dados compactados ou o tamanho do espaço físico usado.
O file system do Data Domain é um file system de desduplicação "estruturado por logs". Um file system estruturado por logs só acrescenta dados ao sistema, e a exclusão por si só não pode liberar espaço físico. Esses file systems dependem da coleta de lixo para recuperar o espaço que não é mais necessário. As características do file system estruturado em log e a tecnologia desduplicada combinadas tornam difícil entender claramente todos os aspectos da compactação no DDOS.
Para a compressão, há muitos aspectos que podemos medir. Neste documento, discutiremos os detalhes passo a passo para ajudar a entender a compactação do DDOS. Primeiro, explicamos o efeito geral de compactação do sistema, que nos informa a compactação realista alcançada em um sistema Data Domain, a quantidade de dados do usuário, a quantidade de espaço físico consumido e a proporção deles. Neste documento, essa proporção é chamada de "taxa de compactação efetiva do sistema". O DDOS realiza a desduplicação em linha e rastreia as estatísticas dos segmentos de dados do usuário originais, segmentos de dados exclusivos pós-desduplicação e o efeito de compactação local nos segmentos de dados exclusivos. Essas estatísticas de compactação em linha são usadas para medir o efeito da compactação em linha. As estatísticas de compactação em linha podem ser medidas para cada gravação. Além disso, o DDOS mantém o controle das estatísticas em diferentes níveis; arquivos, MTrees e todo o sistema.
O conteúdo deste documento pode ser aplicado a todas as versões do DDOS até a publicação deste documento, até o DDOS 7.13. Não há garantias de que todo o conteúdo seja preciso para versões futuras. Nas versões anteriores à 5.0, todo o sistema tem apenas uma mtree e o termo mtree não é explicitamente chamado.
O efeito geral de compactação em todo o sistema é medido pela taxa de compactação efetiva do sistema, que é a proporção do tamanho dos dados do usuário para o tamanho do espaço físico usado. Isso é relatado pelo comando filesys show compression (FSC) da CLI (as informações correspondentes também estão disponíveis na interface do usuário). Um exemplo de resultado do FSC é mostrado abaixo:
# 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.
A taxa de compactação efetiva do sistema é relatada na linha 1 da seção de resultados na saída da CLI. A linha é destacada acima. O tamanho total dos dados do usuário é rotulado como "Pre-Comp". O espaço físico total consumido (por dados e metadados) é rotulado como "Post-Comp".
Os números "Pre-Comp" e "Post-Comp" são lidos em tempo de execução. O FSC sincroniza implicitamente o sistema inteiro e, então, consulta os dois números. Esses dois números são medidos da mesma forma que o comando "filesys show space".
Taxa de compactação efetiva do sistema = Pré-compactação/Pós-compactação
O restante da saída do FSC descreve as estatísticas de compactação em linha, e vamos discuti-las posteriormente.
Há algumas operações que podem afetar a taxa de compactação efetiva do sistema:
Fastcopy
Quando uma cópia rápida é feita a partir de um arquivo no namespace ativo (não em um snapshot), é uma desduplicação perfeita, pois não é necessário espaço físico extra para o arquivo de destino. Uma cópia rápida permite aumentar o tamanho dos dados do usuário sem consumir espaço físico adicional. Isso aumenta a taxa de compactação efetiva do sistema. Quando muitas cópias rápidas são feitas, a taxa de compressão efetiva do sistema pode se tornar artificialmente alta.
Sintéticos virtuais
Os backups sintéticos virtuais tendem a mostrar uma alta taxa de compactação efetiva do sistema. Isso ocorre porque os sintéticos virtuais fazem backups lógicos completos, mas apenas transferem dados alterados ou novos para sistemas Data Domain. O impacto na taxa de compressão efetiva do sistema de sintéticos virtuais é um pouco parecido com o efeito de fastcopy.
Substitui
As substituições consomem mais espaço físico, mas não aumentam o tamanho lógico do conjunto de dados, portanto, as substituições diminuem a taxa de compactação efetiva do sistema.
Armazenando arquivos fragmentados
Os arquivos fragmentados contêm grandes "furos" que são contabilizados no tamanho lógico, mas não consomem espaço físico devido à compactação. Como resultado, eles podem fazer com que a taxa de compactação efetiva do sistema pareça alta.
Armazenando arquivos pequenos
O DDOS adiciona quase 1 KB de sobrecarga a cada arquivo para determinados metadados internos. Quando um sistema armazena um número significativo de arquivos pequenos (tamanhos inferiores a 1 KB ou em KB de um dígito), a sobrecarga de metadados arrasta a taxa de compactação efetiva para baixo.
Armazenando arquivos pré-compactados ou pré-criptografados
A compactação e a criptografia podem amplificar o nível de alteração de dados e reduzir a possibilidade de desduplicação. Esses arquivos geralmente não podem ser desduplicados bem e fazem com que a taxa de compactação efetiva do sistema seja menor.
Exclui
As exclusões reduzem o tamanho lógico do sistema, mas o sistema só recupera o espaço não utilizado correspondente quando a coleta de lixo é executada. Muitos arquivos excluídos tornam a taxa de compactação baixa até que a coleta de lixo (GC) seja executada.
Coleta de lixo (GC) ou limpeza
A GC recupera o espaço consumido pelos segmentos de dados que não são mais visíveis por nenhum arquivo. Se muitos arquivos foram excluídos recentemente, a GC poderá aumentar a taxa de compactação do sistema reduzindo o espaço físico consumido.
Captura agressiva de snapshots
Quando tiramos um snapshot de um Mtree, não alteramos o tamanho lógico do conjunto de dados. No entanto, todos os segmentos de dados referidos pelo snapshot devem ser bloqueados, mesmo que todos os arquivos capturados pelo snapshot sejam excluídos após a captura do snapshot. A GC não consegue recuperar o espaço que ainda é necessário para snapshots; Portanto, ter muitos snapshots pode fazer com que a taxa de compactação efetiva do sistema pareça baixa. No entanto, os snapshots são recursos úteis de recuperação de falhas. Nós nunca devemos hesitar em capturar snapshots nem configurar agendamentos de snapshot adequados quando necessário.
O DDOS realiza a desduplicação em linha, pois os dados são gravados no sistema. Ele rastreia os efeitos da desduplicação em linha e da compactação local para cada gravação e acumula as estatísticas no nível do arquivo. As estatísticas de compactação em linha por arquivo são agregadas ainda mais no nível da MTree e no nível do sistema. A compactação é medida com base em três números nas estatísticas em linha:
Com base nos três números acima, o DDOS define mais duas taxas de compactação de granularidade fina:
As estatísticas acumuladas de compactação em linha fazem parte dos metadados de arquivo do DDOS e são armazenadas no inode de arquivo. O DDOS fornece ferramentas para verificar as compressões em linha em todos os três níveis; file, MTree e em todo o sistema. Nós os detalhamos nas seções a seguir.
3.1 Compactação
de arquivos A compactação de arquivos pode ser verificada com o comando da CLI "filesys show compression <path>", que relata as estatísticas de compactação acumuladas armazenadas no inode do arquivo. Quando um diretório é especificado, as estatísticas de compactação em linha de todos os arquivos nesse diretório são somadas e relatadas. No resultado da CLI, raw_bytes é rotulado como "Bytes originais"; pre_lc_size é rotulado como "globalmente compactado"; post_lc_bytes é marcado como "Locally Compressed"; as outras sobrecargas são relatadas como "metadados". Os dois exemplos são capturados de um DD:
Exemplo 1 real: Estatísticas de compactação em linha de um arquivo
# 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
Exemplo 2: Estatísticas de compactação em linha de todos os arquivos de um diretório, inclusive de todos os subdiretórios
# 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
O sistema relata a taxa geral de compactação em linha no resultado da CLI acima como "bytes/storage_used". No entanto, é necessário ter cuidado ao interpretar as informações acima, pois elas podem ser falsas por vários motivos. Um dos motivos é que pre_lc_size e post_lc_size são registrados quando as operações de dados são processadas. Quando o arquivo que originalmente adicionou esses segmentos é excluído, o número de segmentos de dados exclusivos no arquivo restante deve ser aumentado.
Por exemplo, suponha que um arquivo sample.file seja feito em backup em um Data Domain e, no primeiro backup, as informações de compactação do arquivo sejam pre_lc_size=10GiB, post_lc_size=5Gib.
Em seguida, suponha que os dados desse arquivo são exclusivos, sem compartilhamento de dados com qualquer outro arquivo. No segundo backup do arquivo, suponha ainda que o arquivo obtenha a desduplicação ideal, de modo que tanto o pre_lc_size quanto o post_lc_size devem ser zero porque todos os segmentos do arquivo já existiam no sistema. Quando o primeiro backup é excluído, o segundo backup do arquivo se torna o único arquivo que faz referência aos 5 GiB de segmentos de dados. Nesse caso, o ideal é que o pre_lc_size e o post_lc_size do arquivo no segundo backup sejam atualizados de zero para 10 GiB e 5 GiB, respectivamente. No entanto, não há como detectar para quais arquivos isso deve ser feito, portanto, as estatísticas de compactação em linha dos arquivos existentes são deixadas inalteradas.
Outro fator que afeta os números acima são as estatísticas cumulativas. Quando um arquivo recebe muitas sobregravações, é impossível controlar até que ponto as estatísticas cumulativas refletem as gravações que introduziram os dados em tempo real. Assim, durante um longo tempo, as estatísticas de compactação em linha só podem ser tratadas como uma heurística para estimar aproximadamente a compactação de um arquivo específico.
Outro fato que vale a pena destacar é que a compactação em linha de um arquivo não pode ser medida para um intervalo de tempo arbitrário. As estatísticas de compactação em linha do arquivo são um resultado cumulativo e abrangem todas as gravações que o arquivo já recebeu. Quando um arquivo recebe muitas substituições, o raw_bytes pode ser muito maior do que o tamanho lógico do arquivo. Para arquivos fragmentados, os tamanhos de arquivo podem ser maiores do que os "bytes originais".
3.2 Compactação
de MTree Podemos verificar a compactação de um MTreeespecífico com o comando "mtree show compression" (MSC) Comando CLI. Os valores absolutos das estatísticas de compactação em linha são cumulativos ao longo da vida útil do MTree. Dado que a vida útil de um MTree pode ser de muitos anos, esses valores se tornam cada vez menos informativos ao longo do tempo. Para resolver esse problema, usamos a quantidade de alterações (deltas) das estatísticas de compactação em linha e relatamos a compactação apenas para determinados intervalos de tempo. A abordagem subjacente é despejar periodicamente as estatísticas de compactação em linha do MTree em um log. Quando um cliente consulta a compactação de MTree com o comando MSC, usamos o log para calcular os deltas dos números para a geração de relatórios de compactação. Por padrão, o MSC relata a compactação para os últimos 7 dias e as últimas 24 horas, embora o período de interesse a qualquer momento possa ser especificado.
Para demonstrar, suponha o seguinte log para 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
Então a compactação do MTree A para essa hora é:
g_comp = (12000-11000)/(200-100) = 10x l_comp = (200-100)/(100-50) = 2x overall compression ratio = (12000-11000)/(100-50) = 20x
O cálculo da taxa de compactação acima não faz nada com o tamanho do conjunto de dados. Por exemplo, a mtree acima pode ter apenas 500 GB de dados lógicos.
O MSC é compatível com as opções "daily" e "daily-detailed", assim como o comando "filesys show compression". Quando "daily" é especificado, o comando relata a compactação diária em uma forma de calendário. Ela usa os deltas diários de raw_bytes e post_lc_size para calcular a taxa de compactação diária. Quando "daily-detailed" é especificado, o comando mostra todos os três deltas (do raw_bytes, pre_lc_size e post_lc_size, respectivamente) para cada dia; Ele também calcula o g_comp e o l_comp juntamente com o fator de compactação total.
O exemplo de resultado desses sistemas está no Apêndice.
3.3 Compactação
do sistema Depois de entendermos como a compactação é relatada em MTrees, é simples estender o conceito para todo o sistema. A compactação, a coleta e a geração de relatórios de estatísticas em linha de compactação em todo o sistema são exatamente iguais aos MTrees. A única diferença é o escopo, já que um está em um MTree específico, enquanto outro está em todo o sistema. Os resultados podem ser verificados usando o comando "filesys show compression". Um exemplo disso pode ser encontrado na Seção 2. A compactação do sistema "últimos 7 dias" e "últimas 24 horas" é relatada nas duas últimas linhas da seção de resultados na saída do FSC.
Em DDs com o nível da nuvem implementado, o armazenamento é separado no nível ativo e no nível da nuvem, que são dois domínios de desduplicação independentes. Os usuários podem injetar dados somente no nível ativo. Posteriormente, as funções de movimentação de dados do DDOS podem ser usadas para migrar dados do nível ativo para o nível da nuvem. Assim, a medição e a geração de relatórios de espaço e compactação são tratadas de forma independente em cada nível. Mas, em nível de arquivo, não diferenciamos por nível e reportamos estatísticas de compactação em linha; eles são exatamente os mesmos que descrevemos na Seção 3.1.
O último tópico a destacar são algumas das características da desduplicação, que é chamada de "compactação global" em muitos documentos do Data Domain. Embora contenha a palavra "compactação", ela é totalmente diferente do conceito tradicional de compactação, que também é fornecido pelo DDOS sob o nome de "compactação local".
A compactação local reduz o tamanho de um dado usando um determinado algoritmo (alguns tipos de dados não são compactáveis e aplicar algoritmos de compactação neles pode aumentar ligeiramente o tamanho dos dados). Normalmente, uma vez que um algoritmo é decidido, os dados em si são o único fator da taxa de compactação.
No entanto, a desduplicação é diferente - não é um conceito local, é "global". Um segmento de dados de entrada é desduplicado em relação a todos os segmentos de dados existentes em um domínio desduplicado, o que inclui todos os dados em sistemas Data Domain não em nuvem. O segmento de dados em si não importa no procedimento de desduplicação.
Na prática, raramente vemos uma taxa de desduplicação alta no backup inicial de um conjunto de dados. Nos backups iniciais, muitas vezes, a grande redução de dados vem da compactação local. Quando os backups subsequentes chegam ao Data Domain, a desduplicação mostra sua força e se torna o fator dominante para a compactação. A eficiência da desduplicação baseia-se no fato de que a taxa de alteração de um conjunto de dados é baixa de backup para backup. Por esse motivo, conjuntos de dados com altas taxas de alteração não podem ser bem desduplicados. Quando o aplicativo de backup insere seus próprios fragmentos de metadados (chamados de marcadores pelo Data Domain) nas imagens de backup em alta frequência, ele também pode não obter uma boa taxa de desduplicação. Nossas técnicas de manipulação de marcadores podem ajudar às vezes, mas nem sempre.
Diante dessas observações, o que podemos esperar?
Medir a compactação é difícil em sistemas de arquivos desduplicados, mas é ainda mais difícil em sistemas de arquivos desduplicados estruturados em log. Precisamos entender como a desduplicação funciona e como as estatísticas de compactação são rastreadas. As taxas de compactação são informações úteis para entender o comportamento de um sistema específico. A taxa de compressão efetiva do sistema é a medida mais importante, confiável e informativa. As estatísticas de compactação em linha também podem ser úteis, mas podem não ser mais do que heurísticas em algumas circunstâncias.
Apêndice: Exemplo de resultado de "mtree show compression" Comando
Suponha que haja um MTree segurando 254792,4 GiB de dados. Ele recebeu 4379,3 GiB de novos dados nos últimos 7 dias e 78,4 GiB nas últimas 24 horas (outros intervalos de tempo podem ser especificados). A opção "daily" informa as estatísticas de compactação em linha dos últimos 33 dias. Quando a opção "daily-detailed" é fornecida, as taxas de compactação total são mais detalhadas separando-as em taxas de compactação globais e locais.
Resultado da lista de 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)
------------- -------- --------- ----------- ---------- -------------
Com a opção "diariamente":
# 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
Com a opção "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