ZFS Cache Arc L2Arc E Slog Explicados Sem Mitos

A Filosofia do ZFS: RAM é Lei

Esqueça o que você aprendeu com EXT4 ou NTFS. O ZFS não é apenas um sistema de arquivos; é um gerenciador de memória agressivo que, por acaso, grava dados em disco.

A premissa é brutalmente simples: disco é lento, memória é rápida. Não importa se você tem um array de NVMe de última geração; comparado à RAM, ele é uma tartaruga. Por isso, a filosofia do ZFS é que RAM livre é RAM desperdiçada.

Se você abrir o htop e ver 50% de memória "livre", algo está errado. O ZFS quer devorar cada gigabyte disponível para a ARC (Adaptive Replacement Cache). Ele não pede licença; ele toma a memória para manter seus dados mais usados acessíveis em nanossegundos, evitando a penalidade de I/O físico.

A realidade prática:

• Cache em RAM > Cache em SSD: Não caia no papo de vendedor de storage. Antes de pensar em L2ARC (cache em SSD), encha os slots DIMM da sua placa-mãe.

• Gerenciamento Dinâmico: O ZFS libera memória para aplicações quando necessário, mas a prioridade padrão é performance de leitura.

• O Limite: Se você não alimentar o ZFS com RAM suficiente, especialmente com recursos como Deduplicação ativados, o sistema não apenas fica lento — ele trava.

ARC (Adaptive Replacement Cache): A Primeira Linha

Esqueça o marketing de SSDs por um minuto. A única verdade absoluta em storage é: RAM é rei. O ARC vive na memória do sistema e é a camada mais rápida disponível. Se o dado não está aqui, você está lidando com a latência mecânica ou de flash, que é ordens de magnitude mais lenta.

O "A" de ARC significa Adaptativo. Ao contrário de algoritmos burros de LRU (Least Recently Used), o ZFS não descarta dados cegamente. Ele balanceia duas listas concorrentes:

• MRU (Most Recently Used): O que foi lido agora. Ótimo para acessos sequenciais recentes.

• MFU (Most Frequently Used): O que é lido repetidamente (os "blocos quentes").

O ZFS ajusta o tamanho dessas listas em tempo real. Se sua carga de trabalho muda de arquivamento para banco de dados, o ARC se reequilibra sozinho para proteger os dados mais valiosos.

A regra de ouro: Seu objetivo é um Hit Rate acima de 90%. Se o ARC estiver cheio e o dado solicitado não estiver lá (ARC Miss), a performance despenca. Nunca subestime a necessidade de RAM bruta; adicionar cache em disco (L2ARC) em um sistema faminto por memória é um erro de amador que apenas desperdiça ciclos de CPU.

L2ARC: Extensão, Não Substituto

Pare de tentar economizar em memória RAM achando que um NVMe vai salvar o desempenho do seu pool. O L2ARC não é memória mágica; é apenas um buffer de despejo.

O segredo sujo que o marketing ignora: O L2ARC consome RAM. Para cada bloco de dados armazenado no seu SSD de cache, o ZFS precisa gastar bytes preciosos da sua RAM principal (ARC) para manter o índice (headers) desses dados.

Se você ativar o L2ARC em um sistema com pouca memória (geralmente menos de 64GB), você está canibalizando o ARC. O resultado é catastrófico: o sistema despeja dados "quentes" da RAM ultra-rápida apenas para conseguir gerenciar o índice de dados "mornos" no SSD. Você torna o servidor mais lento ao adicionar o disco de cache.

A regra é binária: Maximize a RAM primeiro. A memória RAM é ordens de magnitude mais rápida que qualquer Optane ou NVMe. O L2ARC só deve ser cogitado quando sua RAM está fisicamente lotada e as estatísticas de cache miss confirmam que o volume de dados acessados frequentemente excede a capacidade da memória principal. Antes disso, é desperdício de dinheiro e latência adicionada.

ZIL e SLOG: Otimizando Escritas Síncronas

Vamos cortar o papo de vendedor: velocidade de escrita e integridade de dados são inimigos naturais.

A maioria das escritas de arquivos (SMB, cópia de arquivos simples) é assíncrona. O ZFS joga tudo na RAM (ARC), diz para a aplicação "tá salvo, confia" e grava nos discos depois (a cada 5 segundos, por padrão). Se a luz acabar nesse intervalo, você perdeu dados, mas a performance foi linda nos benchmarks.

Aplicações sérias (Databases, NFS para VMware/Xen, iSCSI) não aceitam essa mentira. Elas usam escritas síncronas (O_SYNC). Elas exigem que o disco confirme que o dado está fisicamente seguro antes de prosseguir para o próximo bit.

O ZIL (ZFS Intent Log)

Para cumprir essa exigência sem destruir o sistema, o ZFS usa o ZIL. É uma área no disco onde ele grava rapidamente um "diário" das transações síncronas.

• O Problema: Por padrão, o ZIL vive no próprio pool. Se seu pool é feito de HDDs mecânicos, cada escrita síncrona tem que esperar o prato girar e a cabeça posicionar. Sua latência vai para o espaço e seu banco de dados de alta performance começa a rastejar.

O SLOG (Separate Log)

Aqui entra o SLOG. É simplesmente pegar o ZIL e movê-lo para um dispositivo dedicado e rápido.

• O Mito: "SLOG é Write Cache". Mentira. O SLOG não acelera o fluxo total de dados (throughput); ele reduz a latência do acknowledgment (confirmação) de escrita.

• A Realidade: O dado entra na RAM e é escrito simultaneamente no SLOG. Assim que bate no SLOG (que é rápido), o ZFS confirma a gravação para a aplicação. O dado real só vai para o disco final depois, vindo da RAM.

• Função Única: O SLOG só é lido se o servidor travar ou perder energia. No boot seguinte, o ZFS lê o SLOG para recuperar o que estava na RAM e não foi para o disco. Se o servidor nunca cair, o SLOG é um dispositivo "write-only".

Regra de Ouro do Hardware: Não use SSDs de consumidor (NVMe barato) para SLOG. Se o SSD não tiver PLP (Power Loss Protection) — capacitores físicos para garantir que o cache do próprio SSD seja gravado em caso de corte de energia — você só moveu o risco de lugar. Um SLOG sem PLP é inútil para proteção de dados. Use Optane ou SSDs Enterprise.

Resumo Tático: Onde Gastar seu Orçamento

Pare de ouvir vendedor de hardware e foque na hierarquia de latência. O dinheiro deve seguir esta ordem exata:

1. Maximize a RAM (ARC): Antes de pensar em qualquer SSD, lote todos os slots de memória do servidor. A RAM é ordens de magnitude mais rápida que qualquer disco. Se tem slot vazio, você não precisa de cache secundário, precisa de mais RAM. O ARC é o único cache que sempre funciona.

2. SLOG (ZIL) é para Cargas Específicas: Só gaste aqui se você tiver escritas síncronas pesadas (Bancos de Dados, VMware/Proxmox sobre NFS/iSCSI).

   • Regra de Ouro: Não compre SSD de consumo "rápido". Você precisa de baixa latência, não de throughput sequencial. Compre Optane ou NVMe Enterprise de alta durabilidade. Se a carga for assíncrona (ex: servidor de arquivos SMB simples), SLOG é peso de papel.

3. L2ARC com Extrema Cautela: A maioria dos sysadmins implementa isso errado e piora a performance. O L2ARC consome RAM para criar seu índice.

   • O Teste: Só use se você já maximizou a RAM da máquina e seu working set (dados acessados frequentemente) ainda é massivamente maior que a memória disponível. Se a taxa de acerto do ARC (hit rate) for >90%, colocar um L2ARC é jogar dinheiro fora.