O fim do garbage collection: dominando a latência com NVMe Zoned Namespaces

Você já passou madrugadas depurando um pico de latência no percentil 99.99 (p99.99) que não aparecia nos logs da aplicação? O banco de dados diz que escreveu, o sistema operacional diz que enviou o buffer, mas o disco decidiu, naquele exato milissegundo, que era hora de arrumar a casa.

Estamos falando do "Garbage Collection" (GC) interno do SSD. Para a maioria dos sysadmins, o SSD é uma caixa preta mágica que engole dados aleatórios e cospe IOPS. Para nós, engenheiros de performance, essa abstração é um pesadelo de indeterminismo. A camada de tradução de flash (FTL - Flash Translation Layer) é um "imposto" de latência que pagamos para fingir que a memória NAND se comporta como um disco magnético antigo.

A especificação NVMe Zoned Namespaces (ZNS) não é apenas uma nova feature; é a admissão da indústria de que a abstração falhou para cargas de trabalho de hiperescala. Ao remover a FTL do caminho e expor a geometria das zonas diretamente ao host, recuperamos o controle sobre o silício. Vamos dissecar como isso elimina a latência de cauda e por que o comando Zone Append no Linux é a revolução silenciosa do I/O.

Resumo em 30 segundos

O Problema: SSDs convencionais usam uma camada de tradução (FTL) que realiza Garbage Collection interno, causando picos imprevisíveis de latência e desperdício de espaço (Over-provisioning).

A Solução: O ZNS (Zoned Namespaces) remove a FTL e expõe "Zonas" de escrita sequencial obrigatória, passando a responsabilidade do gerenciamento de dados para o Host (SO/Aplicação).

O Resultado: Eliminação da latência de cauda causada pelo GC do drive, redução drástica da Amplificação de Escrita (WAF) e aumento da vida útil do dispositivo.

Figura: Comparação arquitetural: A confusão da FTL convencional versus a linearidade do ZNS.

O Custo Oculto da Abstração FTL

Para entender o ZNS, precisamos primeiro odiar a FTL com a intensidade correta. A memória NAND Flash tem uma limitação física fundamental: você pode ler e escrever em páginas (ex: 4KB ou 16KB), mas só pode apagar em blocos (ex: 16MB ou mais). Como o sistema de arquivos (ext4, XFS) insiste em sobrescrever dados no mesmo endereço lógico (LBA), o SSD precisa escrever os novos dados em outro lugar físico e marcar o antigo como inválido.

Isso cria fragmentação. Eventualmente, o controlador do SSD precisa parar o que está fazendo, copiar as páginas válidas de um bloco sujo para um novo e apagar o bloco antigo. Esse é o Garbage Collection.

Quando isso acontece durante uma carga alta de I/O, sua latência de leitura, que era de 80 microssegundos, salta para 20 ou 30 milissegundos. Para um banco de dados em tempo real, isso é uma eternidade. Pior ainda: para mitigar isso, fabricantes reservam de 7% a 28% da capacidade do disco (Over-provisioning) apenas para dar espaço de manobra para esse processo. Estamos pagando por terabytes que nunca usamos.

A Colisão "Log-on-Log"

O cenário piora em arquiteturas modernas de banco de dados. Engines como RocksDB e LevelDB usam LSM-trees (Log-Structured Merge-trees). Elas já transformam escritas aleatórias em sequenciais no nível da aplicação.

Temos então uma ironia cruel:

A aplicação serializa os dados (Log-structured).
O Filesystem fragmenta isso em blocos de 4k.
A FTL do SSD tenta remontar isso, mas acaba espalhando dados em diferentes canais e dies para paralelismo.
O SSD roda seu próprio Garbage Collection.
A aplicação roda sua própria compactação (outro nome para GC).

Chamamos isso de "Log-on-Log". É um desperdício massivo de ciclos de CPU e de ciclos de programação/apagamento (P/E cycles) da flash. O Write Amplification Factor (WAF) — a relação entre o que o host pede para escrever e o que o disco realmente escreve — frequentemente ultrapassa 4x. Você desgasta seu SSD 4 vezes mais rápido do que deveria.

Figura: O fenômeno Log-on-Log: Onde a organização da aplicação é destruída pelo sistema de arquivos e pela FTL.

Arquitetura ZNS: Expondo a Realidade Física

O NVMe Zoned Namespaces (TP 4053), ratificado em 2020, muda as regras. O SSD é dividido em zonas (geralmente alinhadas ao tamanho dos blocos de apagamento da NAND).

As regras são estritas:

Escrita Sequencial: Dentro de uma zona, você só pode escrever sequencialmente. Não há sobrescrita aleatória.
Reset Explícito: Para sobrescrever, você deve resetar (apagar) a zona inteira.
Estado da Zona: O host deve gerenciar se a zona está cheia, aberta ou fechada.

Ao aceitar essas regras, o SSD pode remover a FTL complexa. O mapeamento LBA-físico torna-se trivial. O Garbage Collection interno desaparece porque o host garante que não há "buracos" de dados inválidos dentro de uma zona ativa.

💡 Dica Pro: Em um ambiente ZNS, a capacidade utilizável do disco é praticamente igual à capacidade física bruta. Aquele SSD de "3.84TB" (com OP oculto) pode expor quase 4TB reais ou mais, dependendo da densidade dos dies.

O Comando Zone Append e o Kernel Linux

A implementação inicial de dispositivos zonados (como SMR HDDs) tinha um gargalo de performance: o bloqueio de fila. Se você tem múltiplos threads tentando escrever na mesma zona, precisa serializá-los para garantir a ordem sequencial. Isso matava o paralelismo do NVMe.

O Linux 5.9 e a especificação NVMe 1.4 introduziram o comando Zone Append.

Diferente de um Write normal onde você especifica o LBA exato (ex: "escreva no endereço 100"), no Zone Append você diz: "Escreva estes dados nesta Zona, e me diga onde eles caíram". O controlador do SSD aloca o próximo slot disponível e retorna o LBA efetivo na conclusão do comando.

Isso permite que múltiplos threads disparem escritas para a mesma zona sem locks pesados no host. O SSD ordena a chegada. O resultado é uma saturação de banda similar a SSDs convencionais, mas sem a penalidade do GC.

Figura: Fluxo do Zone Append: Paralelismo sem bloqueio, delegando o endereçamento final ao controlador.

ZenFS: O Elo Perdido

Não adianta ter um hardware ZNS se você tentar formatá-lo com ext4. O sistema de arquivos tradicional vai falhar ao tentar escrever metadados aleatoriamente.

A solução atual para bancos de dados é o ZenFS. Ele é um backend de sistema de arquivos para o RocksDB que implementa a interface libzbd (biblioteca de dispositivos de bloco zonados do Linux).

O ZenFS mapeia os arquivos SST (Sorted String Tables) do RocksDB diretamente para zonas físicas.

Quando o RocksDB quer fazer uma compactação, o ZenFS aloca uma nova zona.
Os dados são escritos sequencialmente.
A zona antiga é resetada instantaneamente.

Testes da Western Digital e da comunidade mostram que o WAF cai de ~4.0 (em SSDs convencionais com ext4) para ~1.1 com ZenFS em ZNS. A latência de cauda p99.99 torna-se uma linha reta, limitada apenas pela velocidade do barramento PCIe.

Tabela Comparativa: SSD Convencional vs. NVMe ZNS

Característica	SSD NVMe Convencional	SSD NVMe ZNS (Zoned Namespaces)
Gerenciamento de Flash	FTL Interna (Caixa Preta)	Host / Aplicação (Controle Total)
Padrão de Escrita	Aleatório (Random Write)	Sequencial Obrigatório por Zona
Garbage Collection	Interno, imprevisível	Gerenciado pelo Host (Determinístico)
Over-provisioning	7% a 28% (Oculto)	~0% (Exposto ao usuário)
Write Amplification	Alta (3x - 4x típico)	Mínima (~1x)
Caso de Uso Ideal	Boot, OS, General Purpose	DBs (RocksDB), Logs, Caches CDN
Complexidade	Baixa (Plug & Play)	Alta (Requer software compatível)

Figura: Redução drástica da Amplificação de Escrita: De 4x para quase 1x com ZNS.

Veredito Técnico

O ZNS não é para o seu desktop de jogos, nem para o disco de boot do seu servidor web. Ele é uma ferramenta de precisão para arquitetos de armazenamento que cansaram de lutar contra o firmware do SSD.

Se você gerencia clusters de Ceph, bancos de dados baseados em LSM-tree ou sistemas de log de alta ingestão, a migração para ZNS é inevitável. A economia em OP (Over-provisioning) paga o hardware, mas é a eliminação da latência de cauda que salva o seu SLA. O futuro do armazenamento de alta performance não é sobre fazer o hardware mais rápido, é sobre remover o software inútil que roda dentro dele.

Perguntas Frequentes (FAQ)

O ZNS funciona em qualquer sistema operacional?

Atualmente, o suporte robusto é exclusivo do ecossistema Linux (Kernel 5.9+), utilizando bibliotecas como libzbd e sistemas de arquivos compatíveis como F2FS e Btrfs (em modo zoned). O Windows não possui suporte nativo para consumidores ou entusiastas neste momento.

Posso usar um SSD ZNS como disco de boot?

Não é recomendado nem trivial. Discos ZNS exigem que as escritas sejam estritamente sequenciais, o que quebra a lógica da maioria dos bootloaders e sistemas de arquivos convencionais (como ext4 ou NTFS padrão). Eles são projetados especificamente para armazenamento de dados de aplicação (bancos de dados, logs, cache).

Qual a diferença entre ZNS e Open-Channel SSDs?

O ZNS é a padronização oficial da organização NVMe que sucedeu o conceito de Open-Channel. Enquanto o Open-Channel expunha a geometria física bruta e proprietária (canais, dies, voltagens), o ZNS abstrai isso em "Zonas" lógicas padronizadas, simplificando a implementação no host enquanto mantém os benefícios de performance e isolamento.

Referências & Leitura Complementar

NVM Express Base Specification 2.0 – Seção sobre Zoned Namespace Command Set.
Bjørling, M., et al. (2019). "ZNS: Avoiding the Block Interface Tax for Flash-based SSDs". USENIX ATC.
Western Digital Whitepaper (2020): "Zoned Namespaces (ZNS) SSDs: The Next Step in Storage Architecture".
Kernel.org Documentation: "Zoned Block Device Support" (Documentation/block/zoned.rst).