TRIM, Garbage Collection e a Morte Silenciosa dos SSDs em RAID

Você já viu esse filme: você compra SSDs Enterprise caríssimos, monta um RAID, e o servidor voa. Seis meses depois, a latência de gravação começa a oscilar violentamente e o throughput cai pela metade. O fornecedor diz que "é normal". Não é.

Isso é física, má configuração e uma falha fundamental na comunicação entre seu Sistema Operacional e o controlador do SSD.

A maioria dos administradores trata SSDs como HDDs rápidos. Esse é o erro fatal. Enquanto um disco magnético pode sobrescrever um setor livremente, a memória NAND Flash sofre de uma limitação arquitetural cruel: ela pode ler e escrever rápido, mas apagar dados é um processo lento e destrutivo que exige manobras complexas. Se você colocar uma controladora RAID burra no meio do caminho, você está condenando seus discos a uma morte lenta por exaustão.

Vamos dissecar o problema do Write Amplification, entender por que o TRIM é vital e, o mais importante, como sobreviver quando o TRIM não é uma opção.

---

O que são TRIM e Garbage Collection?

TRIM é um comando enviado pelo Sistema Operacional (OS) para informar ao SSD quais blocos de dados não são mais necessários (foram deletados) e podem ser limpos. Garbage Collection (GC) é o processo interno do controlador do SSD que consolida dados válidos e apaga os blocos inválidos marcados pelo TRIM, preparando o drive para novas gravações. Sem essa comunicação, o SSD assume que todo dado antigo é válido, resultando em degradação severa de performance e redução da vida útil.

---

A Física do NAND Flash: Por que o SSD não grava como um HD

Para entender o problema, precisamos descer ao nível do silício. Esqueça a ideia de "setores". O SSD organiza dados em Páginas (geralmente 4KB a 16KB) e Blocos (conjunto de muitas páginas, ex: 4MB a 8MB).

Aqui está a armadilha física:

1. Você pode escrever em uma Página vazia instantaneamente.

2. Você NÃO pode sobrescrever uma Página ocupada.

3. Para modificar dados, você precisa apagar o Bloco inteiro onde a página reside.

Imagine que você tem um caderno (o Bloco) escrito a caneta. Para mudar uma única frase (a Página), você não pode usar corretivo. Você precisa copiar todas as frases que ainda valem para um novo caderno em branco e, só então, jogar o caderno velho na trituradora.

Se o SSD estiver cheio de "lixo" (dados que você deletou no OS, mas o SSD não sabe), o controlador precisa mover esse lixo junto com os dados bons. Isso é o Write Amplification (WA). Você pede para gravar 4KB, mas o SSD acaba gravando 4MB internamente para reorganizar a bagunça.

Figura: O custo oculto do Garbage Collection: Sem o TRIM, o SSD move dados deletados (lixo) junto com dados válidos, aumentando a Write Amplification.

O Ciclo da Morte: Write Amplification e Garbage Collection

O Garbage Collection (GC) é o "zelador" do SSD. Ele roda em segundo plano, procurando blocos que contenham dados obsoletos para apagá-los e liberar espaço para novas escritas.

O problema é que o GC é cego.

Quando você deleta um arquivo no Linux (rm arquivo.log) ou Windows, o sistema de arquivos apenas marca aquele espaço como "livre" na tabela de alocação (inode ou MFT). Os dados reais continuam nos chips NAND. O SSD não sabe que aquilo é lixo. Para o controlador do SSD, aqueles bits são tão preciosos quanto seu banco de dados de produção.

Sem intervenção, o GC fica copiando e movendo dados deletados inutilmente, consumindo ciclos de escrita (P/E cycles) e matando a vida útil do drive. É aqui que entra o TRIM.

O Papel do TRIM: A ponte de comunicação vital

O comando TRIM (ou UNMAP em SCSI/SAS) é a única maneira do sistema de arquivos dizer ao SSD: "Ei, os dados nos endereços LBA 5000 a 6000 foram deletados. Pode ignorá-los no próximo Garbage Collection."

Com o TRIM ativado:

1. Você deleta o arquivo.

2. O OS envia o comando TRIM para o SSD.

3. O SSD marca aquelas páginas como inválidas.

4. Na próxima passagem do Garbage Collection, o controlador não copia essas páginas. O bloco é apagado mais rápido e com menos desgaste.

No entanto, em ambientes Enterprise, existe um "pedágio" no meio do caminho que frequentemente bloqueia essa mensagem: o RAID.

O Abismo do Hardware RAID: Bloqueio do comando TRIM

Controladoras RAID de Hardware (aquelas placas PERC, HP SmartArray antigas, MegaRAID) são famosas por mentir para o sistema operacional. Elas apresentam um "Volume Lógico" e abstraem os discos físicos.

Quando o OS envia um comando TRIM para o Volume Lógico, a controladora RAID precisa traduzir esse comando para os endereços físicos dos SSDs individuais. Muitas controladoras (especialmente as fabricadas antes de 2015 ou modelos de entrada) simplesmente descartam o comando porque não sabem como mapeá-lo ou porque a implementação do RAID (ex: Paridade no RAID 5/6) torna o cálculo do TRIM computacionalmente custoso.

Figura: A Barreira do Hardware RAID: Como a abstração do volume lógico impede que o comando TRIM chegue às células de memória NAND.

Se o TRIM não passa, o SSD nunca sabe o que é lixo. Ele enche. Quando ele atinge 100% de ocupação lógica (mesmo que o OS diga que está 50% livre), o SSD entra em pânico.

O Fenômeno do "Write Cliff"

Quando um SSD não tem blocos pré-apagados disponíveis, cada nova gravação força o drive a parar, ler um bloco, consolidar dados, apagar o bloco e só então gravar. A latência salta de 0.1ms para 20ms ou mais. O throughput cai de 500MB/s para 50MB/s. É o "Penhasco de Escrita".

Figura: O 'Write Cliff': O impacto devastador na performance quando o SSD fica sem blocos livres e entra em modo de Garbage Collection forçado durante a escrita.

Estratégias para Software RAID: Configurando TRIM no ZFS e mdadm

A solução moderna é remover a controladora RAID do caminho. Use HBAs (Host Bus Adapters) em modo IT (Initiator Target). Deixe o Sistema Operacional ver os discos crus. ZFS e mdadm (Linux Software RAID) lidam com TRIM muito melhor que hardware proprietário.

Comparativo: Discard Contínuo vs. TRIM Periódico

Método	Como Funciona	Vantagem	Risco/Desvantagem	Veredito
Mount discard	O TRIM é enviado instantaneamente a cada deleção de arquivo.	Espaço liberado na hora.	Pode causar latência severa em operações de deleção de muitos arquivos pequenos.	Evite (exceto em storage muito ocioso).
TRIM Periódico (fstrim)	Um cron/timer roda o TRIM em todo o espaço livre uma vez por dia/semana.	Zero impacto na performance durante o horário de pico.	O SSD pode ficar "sujo" por algumas horas até o job rodar.	Recomendado para a maioria dos casos.
ZFS autotrim	O ZFS agrupa comandos TRIM e os envia de forma assíncrona.	Equilibra liberação de espaço e performance.	Algum overhead de processamento no ZFS.	Recomendado para ZFS modernos.

Implementação Prática

1. Verificando suporte (Linux)

Antes de tudo, verifique se o comando está passando até o disco. Se DISC-GRAN (Discard Granularity) e DISC-MAX forem zero, o TRIM não está funcionando.

lsblk -D

# Teste manual (Cuidado: pode causar I/O wait)
fstrim -v /

2. Configurando no ZFS

No ZFS, a propriedade autotrim vem desligada por padrão na maioria das distribuições para proteger hardwares antigos. Em SSDs modernos (NVMe/SATA Enterprise), deve ser ativada.

# Verificar estado atual
zpool get autotrim tank

# Ativar o TRIM automático
zpool set autotrim=on tank

Nota: O ZFS não faz TRIM agressivo imediato. Ele tenta ser gentil.

3. Configurando no Linux mdadm (RAID)

Se usar mdadm, o RAID level importa. RAID 0, 1 e 10 suportam TRIM bem. RAID 5/6 suportam, mas com penalidade de performance.

Evite a opção discard no /etc/fstab. Prefira o timer do systemd:

# Ativa o timer semanal (padrão na maioria das distros modernas)
systemctl enable --now fstrim.timer

Over-provisioning Manual: O seguro de vida quando o TRIM não é uma opção

E se você é obrigado a usar uma controladora RAID antiga que não suporta HBA mode? Ou se você usa um banco de dados com escritas tão intensas que o TRIM não dá conta?

A resposta é Over-provisioning (OP).

SSDs Enterprise já vêm com OP de fábrica (ex: um drive de 960GB na verdade tem 1024GB de flash, guardando ~7% para manobras). Mas você pode — e deve — aumentar isso manualmente.

A técnica é simples: Não formate o disco todo.

Se você tem um RAID de 10TB brutos:

1. Crie uma partição/volume de apenas 8TB.

2. Deixe 2TB (20%) como "Unallocated Space" (Espaço não alocado).

Por que isso funciona? O controlador do SSD sabe que aqueles endereços LBA nunca foram escritos (ou foram escritos uma vez e nunca mais tocados). Ele usa esses blocos físicos de flash como uma "piscina de manobra" gigante para o Garbage Collection. Isso reduz drasticamente a Write Amplification e mantém a latência estável, mesmo sob carga pesada, ignorando a necessidade do comando TRIM.

Checklist de Sobrevivência para Storage Flash

1. Hardware: Use HBAs (IT Mode) sempre que possível. Evite RAID de Hardware para SSDs.

2. BIOS/Firmware: Atualize o firmware dos SSDs. Bugs na implementação do TRIM são comuns em drives novos.

3. Filesystem: Use fstrim.timer (semanal/diário) em vez de mount -o discard.

4. ZFS: zpool set autotrim=on para pools compostos inteiramente de SSDs.

5. Seguro: Se não puder garantir o TRIM, deixe 10% a 20% da capacidade do disco não particionada (Over-provisioning).

---

Referências & Leitura Complementar

• NVM Express Base Specification (Rev 2.0): Detalhes sobre o comando Dataset Management (onde o Deallocate/TRIM reside no protocolo NVMe).

• SATA-IO ACS-3 Specification: Definição técnica do comando DATA SET MANAGEMENT para drives SATA.

• RFC 3720 (iSCSI): Importante para entender como comandos SCSI (incluindo UNMAP) são encapsulados em redes de storage, onde o suporte a TRIM frequentemente falha.

• Manpages: man fstrim, man zpool-props.