Compressão no ZFS: A mecânica da 'Performance Grátis' (e quando a conta chega)

No mundo da engenharia de sistemas, a frase "almoço grátis" costuma disparar todos os alarmes de ceticismo. Se algo promete aumentar a velocidade e economizar espaço simultaneamente, assumimos que há uma pegadinha oculta, geralmente na forma de latência de CPU ou complexidade operacional.

No entanto, a compressão no ZFS (especificamente com LZ4 e ZSTD) é frequentemente citada como essa exceção mágica. A premissa é sedutora: ativar a compressão torna o seu sistema de armazenamento mais rápido, não mais lento.

Mas como engenheiros de performance, não operamos com magia. Operamos com física, latência e gargalos. Vamos dissecar a mecânica dessa afirmação, entender a arbitragem entre ciclos de processador e tempo de busca em disco, e identificar o momento exato em que essa curva de benefício se inverte.

A Física da Arbitragem: Trocando Nanossegundos por Milissegundos

Para entender por que a compressão acelera o I/O, precisamos olhar para a hierarquia de memória e a disparidade brutal de velocidade entre a CPU e o disco.

O conceito fundamental aqui não é "fazer o disco ir mais rápido", mas sim "pedir menos ao disco".

Quando você grava um bloco de 128KB que, comprimido, vira 64KB, você acabou de dobrar a largura de banda efetiva do seu subsistema de armazenamento para aquela operação. A CPU gastou alguns milhares de ciclos para realizar a compressão. Em uma CPU moderna, isso é medido em nanossegundos ou microssegundos. Em contrapartida, escrever aqueles 64KB extras no disco (especialmente em HDDs mecânicos) custaria milissegundos.

Figura: A matemática da velocidade: gastar nanossegundos de CPU para economizar milissegundos de disco.

Essa é a matemática da arbitragem. Estamos comprando tempo de I/O (caro) pagando com tempo de CPU (barato). Enquanto o custo da CPU for inferior ao tempo economizado no transporte dos dados, o sistema experimenta um aumento líquido de throughput e uma redução na latência percebida pela aplicação.

A Ilusão do Bloco Fixo: Como o ZFS Aloca Dados

Diferente de sistemas de arquivos tradicionais ou controladores RAID de hardware que operam com stripes fixos, o ZFS é um alocador de objetos Copy-on-Write. Ele não precisa reescrever dados no mesmo lugar físico, o que lhe dá uma flexibilidade enorme.

Quando a compressão está ativa, o ZFS não aloca o tamanho lógico do bloco (recordsize), mas sim o tamanho físico comprimido (arredondado para o setor físico do disco, ou ashift).

Se você tem um recordsize=128k e o algoritmo LZ4 comprime isso para 50KB:

O ZFS aloca setores físicos suficientes para armazenar 50KB (mais metadados).
Ele escreve esses setores sequencialmente.
Não há "buracos" ou desperdício de espaço alocado aguardando dados descomprimidos.

Isso gera um efeito colateral crítico: Densidade de IOPs. Ao escrever fisicamente menos dados, o disco passa menos tempo ocupado com cada transação, liberando a fila de I/O mais rapidamente para a próxima requisição.

O Elenco de Algoritmos: Escolhendo a Ferramenta Certa

Nem todos os algoritmos de compressão nascem iguais. A escolha errada aqui pode transformar seu servidor em uma carroça presa por CPU.

Algoritmo	Tipo de Carga	Custo de CPU	Razão de Compressão	Veredito
LZ4	Uso Geral	Baixíssimo	Média	O Padrão. Use sempre, a menos que tenha um motivo muito específico para não usar. Frequentemente, descomprimir LZ4 é mais rápido do que a latência de memória RAM (memcpy).
ZSTD	Moderno / Flexível	Médio/Alto	Alta	O Sucessor. Excelente para datasets que precisam de mais economia de espaço que o LZ4, mas sem a penalidade do GZIP. Configurável (zstd-1 a zstd-19).
GZIP	Legado / Arquival	Altíssimo	Alta	Evite. O custo de CPU é punitivo. Use apenas para dados "Write Once, Read Never" (logs antigos, backups frios) onde o espaço é a única métrica que importa.
GLE (Off)	N/A	Zero	Nenhuma	Use apenas se seus dados já forem comprimidos e criptografados na origem (ex: streaming de vídeo pré-processado), embora o ZFS tenha proteções para isso.

Nota de Engenharia: O ZSTD (Zstandard) introduzido nas versões mais recentes do OpenZFS oferece um trade-off superior ao GZIP. Se você estava considerando GZIP, use zstd-3 ou superior.

O Mecanismo de "Early Abort": Protegendo a CPU

O maior medo de ativar compressão globalmente é: "E se eu gravar arquivos .zip, .mp4 ou dados criptografados?". Tentar comprimir dados de alta entropia é um desperdício inútil de ciclos de CPU.

O ZFS implementa um mecanismo de segurança para isso. Antes de comprometer recursos pesados tentando comprimir o bloco inteiro, o algoritmo faz uma passagem rápida ou tenta comprimir apenas a parte inicial do buffer.

Se o ganho de espaço não atingir um limiar mínimo (geralmente 12.5%, ou 1/8 do tamanho do bloco), o ZFS aborta imediatamente a operação e grava o bloco não comprimido.

Figura: O mecanismo de segurança: por que gravar arquivos .zip em um dataset com compressão ativada não destrói sua CPU.

Isso significa que o custo de ter compressão ativada em um dataset cheio de vídeos já comprimidos é insignificante. O sistema detecta a incompressibilidade e desiste antes que isso afete a latência de gravação.

O Multiplicador de RAM: Compressed ARC

Aqui reside um dos ganhos de performance mais subestimados do ZFS. O ARC (Adaptive Replacement Cache) é o cache de leitura em RAM do ZFS. Diferente do Page Cache do Linux, que armazena páginas de memória como o sistema as vê (descomprimidas), o ARC do ZFS armazena os dados comprimidos na RAM (com exceção de blocos em uso imediato).

Pense nas implicações:

Se você tem 64GB de RAM dedicada ao ARC.
Seu compressratio médio é de 2.0x.
Você efetivamente tem 128GB de cache.

Isso dobra a probabilidade de um cache hit. E um cache hit (ler da RAM) é ordens de magnitude mais rápido do que qualquer disco NVMe. Portanto, a compressão não apenas acelera o disco, ela evita que você precise ir ao disco.

Quando vira "Imposto": Onde a conta chega

Dissemos que não existe almoço grátis, apenas arbitragem. Quando essa arbitragem falha? Quando o custo da CPU excede o custo do I/O.

Isso acontece principalmente em dois cenários:

CPUs Anêmicas com Storage Rápido: Se você está rodando um array All-Flash NVMe Gen4/Gen5 em um processador de baixa potência (ex: sistemas embarcados, Atoms antigos ou VMs com vCPUs limitadas), o gargalo se inverte. O disco é capaz de aceitar dados mais rápido do que a CPU consegue comprimi-los. Nesse cenário, ativar zstd-19 vai destruir sua latência de gravação. O LZ4 ainda costuma ser seguro, mas deve ser testado.
Latência Ultra-Baixa (Bancos de Dados HFT): Em cenários onde cada microssegundo conta e a CPU está saturada pela aplicação (banco de dados), roubar ciclos para compressão pode causar jitter na latência da aplicação.

Diagnóstico: Medindo a Realidade

Não confie na teoria. Valide a eficiência da compressão no seu ambiente de produção.

1. Verificando a taxa de compressão

O primeiro passo é ver se está funcionando. O comando abaixo mostra a razão de compressão (ex: 1.50x significa que você economizou 33% de espaço).

zfs get compressratio,used,logicalused poolname/dataset

2. Medindo o "Throughput Fantasma"

Para ver a diferença entre o que a aplicação envia e o que realmente chega ao disco, observe as colunas de largura de banda.

# Observe o tráfego em tempo real
zpool iostat -v 2

Se sua aplicação está enviando 500MB/s de escritas, mas o zpool iostat mostra apenas 250MB/s de escrita física nos discos (alloc), sua compressão está dobrando sua vida útil de disco e liberando banda.

3. Detectando CPU Bound

Se você suspeita que a compressão está atrapalhando, o sintoma será alta latência de disco correlacionada com alto uso de CPU em kernel space (sys). Ferramentas como perf ou visualização de FlameGraphs podem mostrar tempo excessivo gasto em chamadas lz4_compress ou zstd_compress.

Veredito Técnico Operacional

A compressão no ZFS deve ser o padrão ("default on"). O algoritmo LZ4 é seguro o suficiente para ser esquecido ligado em 99% dos casos, transformando ciclos ociosos de CPU em performance de I/O e capacidade de armazenamento.

Use ZSTD quando o custo de armazenamento for alto (SSDs Enterprise caros) e você tiver CPU sobrando. Desligue a compressão apenas se tiver evidências empíricas de que ela é o gargalo — o que, em hardware moderno, é cada vez mais raro.