ZNS sob o Microscópio: Análise de Desempenho com ZBDBench

A imprevisibilidade é o inimigo silencioso da infraestrutura de armazenamento moderna. Enquanto o marketing de SSDs consumer foca em números de throughput sequencial que raramente se sustentam por mais de alguns segundos, engenheiros de dados e arquitetos de sistemas enfrentam uma realidade diferente: a latência de cauda (tail latency).

A tecnologia Zoned Namespaces (ZNS) surge não como uma evolução incremental de velocidade, mas como uma rearquitetura fundamental da pilha de I/O. Ao remover a Camada de Tradução de Flash (FTL) do caminho crítico, o ZNS promete entregar a performance bruta da memória NAND sem os soluços causados pela coleta de lixo interna. No entanto, validar essas promessas exige abandonar as ferramentas tradicionais. O CrystalDiskMark é inútil aqui.

Neste artigo, dissecamos a metodologia correta para benchmarking de dispositivos ZNS, utilizando o ZBDBench e o ecossistema libzbc para expor a verdadeira face do armazenamento zonado.

Resumo em 30 segundos

O Problema: SSDs convencionais escondem a complexidade da NAND atrás de uma FTL, causando picos de latência imprevisíveis durante a Coleta de Lixo (GC).

A Solução ZNS: Transfere a gestão de dados para o host, exigindo escritas sequenciais em zonas, mas eliminando a WAF (Write Amplification Factor) interna.

O Teste: Ferramentas de bloco padrão falham em ZNS. É necessário usar fio com engines libzbc ou io_uring_cmd para respeitar as regras de escrita sequencial e medir a latência real sem interferência do firmware.

Figura: Comparação arquitetural: A opacidade da FTL convencional versus a transparência do gerenciamento pelo Host no ZNS.

A Mentira da Camada de Tradução de Flash (FTL)

Para entender por que precisamos de uma nova metodologia de teste, primeiro precisamos entender o que estamos testando. Um SSD NVMe convencional é, essencialmente, um computador completo disfarçado de disco. Ele possui processadores multi-core, DRAM e um firmware complexo cuja única função é mentir para o Sistema Operacional.

O SO acredita que está escrevendo em setores lógicos (LBAs) que podem ser sobrescritos a qualquer momento. A física da memória NAND, entretanto, proíbe isso. Você pode escrever em uma página, mas só pode apagar um bloco inteiro (que contém centenas de páginas). A FTL gerencia esse abismo, movendo dados, marcando páginas como inválidas e realizando a Coleta de Lixo (Garbage Collection - GC) em segundo plano.

⚠️ Perigo: Em cargas de trabalho sustentadas, a Coleta de Lixo compete por recursos com as suas operações de I/O. Isso resulta em picos de latência que podem saltar de 100µs para 50ms ou mais, destruindo SLAs de bancos de dados.

O ZNS remove essa camada. O dispositivo expõe a topologia da NAND diretamente ao host. O disco é dividido em zonas (geralmente alinhadas ao tamanho dos blocos de apagamento da NAND). A regra é clara: as escritas dentro de uma zona devem ser sequenciais. Não há sobrescrita aleatória. Se você quiser reescrever dados, deve resetar (apagar) a zona inteira.

Por que Benchmarks Convencionais Falham

Tente rodar um teste de escrita aleatória 4K padrão em um drive ZNS e você receberá um erro de I/O imediato. Isso não é um defeito; é o protocolo funcionando.

Cada zona possui um "Write Pointer" (WP). O WP indica onde o próximo dado deve ser gravado. Se você tentar escrever em um LBA diferente do WP atual, o drive rejeita o comando. Ferramentas como dd, hdparm ou benchmarks gráficos genéricos não têm consciência do conceito de zonas. Eles tratam o espaço de endereçamento como plano e irrestrito.

Para testar ZNS, precisamos de ferramentas que sejam "Zone-Aware". Elas devem:

Identificar o tamanho e a capacidade das zonas.
Monitorar a posição do Write Pointer.
Resetar zonas quando cheias antes de escrever novamente.

Figura: O mecanismo do Write Pointer: A escrita só é permitida estritamente na posição atual do ponteiro.

Metodologia: O Ecossistema libzbc e ZBDBench

A base para qualquer análise séria de ZNS no Linux é a biblioteca libzbc. Ela fornece as primitivas necessárias para interagir com dispositivos de bloco zonados (SMR HDDs e ZNS SSDs). Para benchmarks de desempenho, a ferramenta padrão da indústria é o fio (Flexible I/O Tester), mas configurado especificamente para este propósito.

Embora exista um binário chamado zbdbench em algumas distribuições, ele é frequentemente um wrapper. A prática recomendada é utilizar o fio com engines de I/O compatíveis, como libaio (com suporte a zonas) ou, preferencialmente, io_uring_cmd em kernels modernos (5.19+), que oferece o caminho de dados mais eficiente (passthrough).

Preparação do Ambiente de Teste

Antes de iniciar qualquer medição, o pré-condicionamento é vital. Diferente de SSDs convencionais onde fazemos "fill" para sujar a FTL, no ZNS precisamos garantir que as zonas estejam em um estado conhecido.

# Resetar todas as zonas do dispositivo (CUIDADO: Destrutivo)
blkzone reset /dev/nvme0n1

Verifique a topologia do dispositivo para alinhar seus jobs de teste:

zbc_report /dev/nvme0n1 | head -n 20

Isso retornará o tamanho da zona (ex: 1073 MB) e a capacidade gravável. O alinhamento dos seus jobs de escrita deve respeitar esses limites para evitar erros de "Unaligned Write".

Análise de Desempenho: Latência e Throughput

Vamos configurar um cenário de teste realista. O objetivo é medir a consistência de latência em uma carga de escrita sequencial pesada, simulando um log de banco de dados (WAL - Write Ahead Log) ou ingestão de dados de sensores.

O Script de Teste (FIO)

Abaixo, um exemplo de job file do fio otimizado para ZNS. Note o parâmetro zonemode=zbd.

[global]
name=zns-benchmark
filename=/dev/nvme0n1
ioengine=libaio
direct=1
zonemode=zbd
# Tamanho do bloco deve ser amigável à página NAND (ex: 4k, 16k)
bs=16k
iodepth=32
rw=write
# Importante: Evita que o fio tente ler zonas vazias
flow=128

[zns-seq-write]
numjobs=1
# Escreve sequencialmente, respeitando o WP

Interpretando os Resultados: O Fim da Cauda Longa

Ao executar este teste em um SSD NVMe Enterprise convencional e compará-lo com um SSD ZNS de mesma geração NAND, a diferença no throughput médio pode não ser gigantesca. O segredo está nos percentis de latência.

Em um SSD convencional, você verá o p99 (o pior 1% das latências) flutuar drasticamente assim que o buffer SLC se esgota e a coleta de lixo começa. No ZNS, o gráfico é uma linha plana.

💡 Dica Pro: Ao analisar os logs do fio, foque na métrica clat (completion latency) percentil 99.99. É aqui que os "stalls" de I/O se escondem. Em ZNS, a ausência de movimentação interna de dados mantém esse número próximo da latência física da mídia.

Figura: Estabilidade de Latência: A consistência do ZNS (azul) versus a imprevisibilidade causada pela GC em SSDs convencionais (vermelho).

Amplificação de Escrita (WAF): A Métrica Financeira

A Amplificação de Escrita é a razão entre a quantidade de dados escritos na mídia física e a quantidade de dados enviados pelo host.

SSD Convencional: WAF varia de 1.5 a 4.0 (ou mais em cargas aleatórias). O drive move dados internamente para liberar blocos, desgastando a NAND prematuramente.
SSD ZNS: WAF é virtualmente 1.0.

Como o host controla o reset das zonas, não há movimentação de dados oculta. Se você escreve 1GB, o drive gasta 1GB de ciclos de programação da NAND.

Para data centers, isso se traduz diretamente em TCO (Total Cost of Ownership). Um drive ZNS pode durar 3 a 4 vezes mais que um drive convencional sob a mesma carga de escrita, ou permitir o uso de NAND QLC (mais barata e menos durável) em cenários onde antes apenas TLC seria viável.

Zone Append: Paralelismo sem Bloqueio

Um dos maiores desafios iniciais do ZNS era a serialização. Se múltiplos threads tentarem escrever na mesma zona, eles precisam sincronizar o Write Pointer. O thread A escreve no offset 0, o thread B precisa esperar para saber onde o thread A terminou para escrever no offset 4K. Isso cria um gargalo de software (lock contention).

O comando Zone Append resolve isso. Em vez de dizer "Escreva estes dados no endereço X", o host diz "Escreva estes dados nesta Zona, e me diga onde você colocou".

Isso delega a decisão final do posicionamento para o controlador do SSD, permitindo que múltiplos threads enviem comandos simultaneamente sem locks. O SSD processa a fila e retorna o LBA efetivo onde o dado foi gravado.

Figura: Zone Append em ação: Maximizando a Queue Depth sem a necessidade de locks de sincronização no Host.

Tabela Comparativa: NVMe Convencional vs. ZNS

Característica	NVMe Convencional (Block)	NVMe ZNS (Zoned)
Gerenciamento de Mídia	FTL (Firmware do Drive)	Host (Software/Driver)
Padrão de Escrita	Aleatório ou Sequencial	Estritamente Sequencial (por zona)
Coleta de Lixo (GC)	Interna e Imprevisível	Gerenciada pelo Host (Previsível)
WAF Típico	1.5x - 4.0x	~1.0x
Uso de DRAM no Drive	Alto (1GB por 1TB de storage)	Muito Baixo (Redução de custo)
Complexidade de Integração	Baixa (Plug & Play)	Alta (Requer stack de SW adaptada)

Veredito Técnico

O ZNS não é para o usuário doméstico que quer apenas instalar o Windows. É uma ferramenta de precisão para arquitetos de armazenamento que precisam extrair cada IOPS e cada ciclo de vida da memória flash.

A análise com ZBDBench e fio comprova que, ao assumir o ônus do gerenciamento das zonas, ganhamos em troca uma previsibilidade determinística que SSDs convencionais fisicamente não podem oferecer. Se sua aplicação (como RocksDB, Ceph ou sistemas de arquivos log-structured como F2FS) já serializa escritas, a transição para ZNS elimina uma camada redundante de tradução, reduzindo latência e custos.

Para o futuro próximo, esperamos ver a adoção massiva de ZNS em conjunto com QLC NAND em datacenters, onde a densidade é rei e a durabilidade precisa ser gerenciada cirurgicamente via software, não por uma caixa preta de firmware.

Figura: A física encontra o lógico: A segmentação rígida das zonas aplicada diretamente ao silício da memória.

Referências & Leitura Complementar

NVM Express Base Specification 2.0c – Seção sobre Zoned Namespaces Command Set.
SNIA Zoned Storage Architecture Guide – Documentação técnica sobre modelos de zona e máquinas de estado.
Western Digital ZNS Whitepaper (2023) – Dados sobre redução de DRAM e TCO.
Damien Le Moal (Western Digital) – "Zone Append: A New Way of Writing to Zoned Block Devices" (Linux Kernel Mailing List archives).

Por que não posso usar o CrystalDiskMark em um SSD ZNS?

SSDs ZNS exigem que as escritas dentro de uma zona sejam estritamente sequenciais. Ferramentas convencionais como o CrystalDiskMark emitem escritas aleatórias que violam o 'Write Pointer' da zona, resultando em erros de I/O imediatos.

Qual a principal vantagem do ZNS sobre SSDs NVMe convencionais?

A eliminação da Camada de Tradução de Flash (FTL) no dispositivo. Isso transfere a gestão de dados para o host, reduzindo a Amplificação de Escrita (WAF) para próximo de 1.0 e eliminando os picos de latência causados pela coleta de lixo interna.

O que é o comando Zone Append?

É um comando NVMe específico para ZNS que permite que múltiplos threads escrevam na mesma zona simultaneamente sem bloqueio, delegando ao SSD a decisão final do offset de escrita, o que maximiza o paralelismo.