NVMe flexible data placement: O fim da amplificação de escrita e latência

A mentira mais conveniente que contamos a nós mesmos no mundo do armazenamento é que o disco obedece ao sistema operacional. Desde os tempos dos pratos magnéticos, e exacerbado pela era do NAND Flash, existe uma camada de abstração opaca — o FTL (Flash Translation Layer) — que atua como uma "caixa preta" entre a syscall de escrita e o elétron preso na célula de memória.

Para engenheiros focados em latência de cauda (tail latency) e QoS (Quality of Service), essa caixa preta é um pesadelo. Você otimiza seu código, alinha suas estruturas de dados, usa io_uring para evitar context switches desnecessários, mas, de repente, uma operação de escrita de 4KB leva 50ms porque o firmware do SSD decidiu iniciar uma coleta de lixo (Garbage Collection) agressiva naquele exato milissegundo.

O NVMe Flexible Data Placement (FDP), ratificado na proposta técnica TP4146, surge não como uma revolução de marketing, mas como uma necessidade arquitetural para expor a geometria do NAND ao host sem a complexidade brutal do ZNS (Zoned Namespaces). É a tentativa de parar de lutar contra a física do dispositivo.

Resumo em 30 segundos

O Problema: SSDs misturam dados "quentes" (atualizados frequentemente) e "frios" (estáticos) nos mesmos blocos físicos, forçando o Garbage Collection a copiar dados válidos desnecessariamente, gerando picos de latência.

A Solução FDP: O host envia "dicas" (Placement IDs) junto com a escrita, instruindo o SSD a segregar dados com ciclos de vida diferentes em blocos físicos distintos.

O Resultado: Amplificação de Escrita (WAF) cai drasticamente (próximo de 1.0), a vida útil do drive aumenta e a latência de cauda (p99) se torna previsível.

A mecânica destrutiva da Garbage Collection

Para entender por que o FDP é crítico, precisamos revisitar a falha fundamental dos SSDs modernos em workloads mistos. O NAND Flash tem uma assimetria irritante: lemos e escrevemos em páginas (ex: 4KB ou 16KB), mas só podemos apagar em blocos (que contém centenas de páginas).

Quando seu banco de dados (RocksDB, MySQL, Cassandra) escreve dados, o FTL espalha esses dados no próximo bloco livre. Em um cenário de servidor real, dados de log (escrita sequencial, vida curta) se misturam com tabelas de metadados (escrita aleatória, vida longa) no mesmo bloco físico.

Quando o bloco enche e precisamos recuperá-lo, o SSD encontra um "queijo suíço": páginas inválidas (dados deletados ou atualizados) misturadas com páginas válidas. Antes de apagar o bloco, o controlador precisa copiar as páginas válidas para um novo local.

⚠️ Perigo: Esse processo de "copiar para apagar" é a Amplificação de Escrita (WAF). Se o WAF é 3.0, para cada 1GB que seu app escreve, o SSD queima 3GB de durabilidade e consome largura de banda interna, bloqueando I/O novo. É aqui que sua latência p99 explode.

Figura: Visualização do impacto do Garbage Collection em blocos mistos versus blocos segregados.

Por que Over-provisioning e ZNS não resolveram

Durante anos, tentamos mitigar isso com força bruta ou complexidade excessiva.

Over-provisioning (OP): Reservamos 7%, 28% ou até 50% da capacidade do SSD para que o controlador tenha "espaço de manobra".
- O problema: É caro. Você está comprando Flash para não usar. Em escala de Petabytes, isso é um desperdício financeiro inaceitável.
Zoned Namespaces (ZNS): Remove o FTL quase inteiramente e obriga o host a escrever sequencialmente em zonas.
- O problema: Exige reescrita completa da stack de software. Sistemas de arquivos convencionais (ext4, xfs) e bancos de dados precisam ser adaptados para gerenciar zonas abertas e fechadas. A barreira de entrada é altíssima.

O FDP é o "caminho do meio". Ele mantém a compatibilidade com escritas aleatórias (ao contrário do ZNS) mas dá ao host o controle sobre onde os dados pousam (ao contrário do SSD convencional).

Arquitetura do NVMe FDP (TP4146)

O FDP introduz o conceito de Reclaim Groups (RG) e Placement Handles (PH).

Em vez de o host saber exatamente qual bloco físico (PBA) está sendo usado, ele apenas indica uma intenção. Imagine que o SSD expõe 128 "baldes" (Placement Handles). O software do host (seja o kernel ou uma aplicação como o CacheLib do Meta) pode decidir:

PH 1: Logs de transação (WAL) - Vida curtíssima.
PH 2: Tabelas SST nível 0 - Vida média.
PH 3: Imagens estáticas / Arquivos - Vida longa.

Ao enviar o comando de escrita NVMe, o host anexa o ID do Placement Handle (PID). O controlador do SSD garante que dados com o mesmo PID sejam gravados no mesmo Reclaim Unit (basicamente, um superbloco alinhado ao hardware).

Figura: Fluxo de dados no NVMe FDP: Do Host para os Reclaim Groups específicos.

Quando chega a hora do Garbage Collection, o bloco associado ao PH 1 (Logs) provavelmente estará 100% inválido (porque os logs já foram rotacionados). O SSD pode simplesmente apagar o bloco. Zero cópia de dados. WAF = 1.0.

Tabela Comparativa: Padrão vs ZNS vs FDP

Característica	NVMe Convencional	ZNS (Zoned Namespaces)	FDP (Flexible Data Placement)
Gerenciamento de Flash	Caixa Preta (FTL decide)	Host decide (Zonas)	Cooperativo (Host sugere, FTL executa)
Padrão de Escrita	Aleatório permitido	Estritamente Sequencial	Aleatório permitido
Complexidade de SW	Nula (Driver padrão)	Alta (Requer FS/App adaptado)	Média (Driver + Hints na App)
WAF Típico	2.5x - 4.0x	~1.0x	~1.05x - 1.2x
Latência de Cauda	Imprevisível (Picos de GC)	Baixa e Estável	Baixa e Estável

Implementação no Kernel e User Space

O suporte ao FDP não é mágica; requer orquestração. No ecossistema Linux, o suporte começou a amadurecer a partir do Kernel 6.x.

A beleza do FDP é que ele pode ser implementado via passthrough usando io_uring. Isso permite que bancos de dados modernos (como versões recentes do RocksDB ou forks proprietários) gerenciem o posicionamento de dados sem esperar que o sistema de arquivos (XFS/EXT4) suporte a feature nativamente.

Para o engenheiro de performance, o comando nvme-cli se torna o melhor amigo para inspecionar a configuração:

nvme fdp status /dev/nvme0n1
# Saída esperada mostraria Reclaim Groups ativos e mapeamento de PIDs

💡 Dica Pro: Em ambientes virtualizados (KVM/QEMU), o FDP pode ser repassado para a VM. Isso permite que uma instância de banco de dados dentro de uma VM controle o posicionamento físico dos dados no host, algo impossível anteriormente sem PCI Passthrough completo.

Resultados Práticos: O fim do ruído

Testes realizados pela indústria (Samsung, Meta, Google) mostram que habilitar o FDP em workloads de escrita intensiva (como caching tier de CDNs ou ingestão de logs) reduz o WAF de ~3.0 para ~1.1.

Mas o ganho real não é apenas a vida útil do SSD (que triplica), mas a estabilidade da latência.

Figura: Comparativo de estabilidade de latência: NVMe Legado (com picos) vs FDP (estável).

Em um teste de saturação, um SSD convencional começa a engasgar assim que o espaço livre (OP) se esgota e o GC forçado entra em ação. Com FDP, como os blocos são invalidados em massa (devido ao agrupamento correto por tempo de vida), o controlador sempre tem blocos livres disponíveis. O throughput se mantém na velocidade de linha do meio físico, não na velocidade do processador ARM do controlador tentando desfragmentar dados.

O Veredito do Engenheiro

O NVMe FDP é a evolução sóbria do armazenamento. Ele reconhece que o Host sabe o que são os dados, e o SSD sabe como armazená-los.

Para arquitetos de infraestrutura e engenheiros de kernel, a recomendação é clara: comece a validar SSDs compatíveis com TP4146 em seus próximos ciclos de refresh de hardware, especialmente para nós de banco de dados e cache. A redução de OP (Over-provisioning) sozinha pode pagar o investimento, mas a paz de espírito de não ser acordado de madrugada por um alerta de latência causado por Garbage Collection é impagável.

Não estamos mais em 2015. Deixar o FTL adivinhar seus padrões de acesso é um desperdício de ciclos de CPU e de células de silício.

Referências & Leitura Complementar

NVM Express Technical Proposal 4146 (TP4146): Flexible Data Placement. Disponível no site da nvmexpress.org.
OCP (Open Compute Project) Datacenter NVMe SSD Specification: Capítulos referentes a FDP e requisitos de latência para Hyperscalers.
JEDEC JESD218: Solid-State Drive (SSD) Requirements and Endurance Test Method (para entender as métricas base de WAF).
Linux Kernel Archives: Commits relacionados ao subsistema NVMe e suporte a FDP (drivers/nvme/host).

Perguntas Frequentes (FAQ)

O que é NVMe Flexible Data Placement (FDP)?

É uma especificação técnica do padrão NVMe (TP4146) que permite ao sistema host enviar "dicas" (Placement Identifiers) para o SSD. Isso agrupa dados com expectativas de vida semelhantes nos mesmos blocos físicos, reduzindo drasticamente a necessidade de desfragmentação interna e, consequentemente, a amplificação de escrita (WAF) e a latência.

Qual a diferença entre FDP e ZNS (Zoned Namespaces)?

A principal diferença é a flexibilidade. O ZNS exige que o host escreva estritamente de forma sequencial e gerencie zonas explicitamente, o que quebra a compatibilidade com muitos softwares legados. O FDP permite escritas aleatórias e funciona como uma extensão retrocompatível, oferecendo a maioria dos benefícios de redução de WAF do ZNS, mas com uma complexidade de implementação muito menor.

O FDP requer drivers especiais?

O suporte básico ao FDP foi integrado ao Kernel Linux (a partir da versão 6.x) e ferramentas como `nvme-cli`. No entanto, para extrair o benefício real, a aplicação (banco de dados, cache) deve ser capaz de passar os Placement Identifiers (PIDs) através da stack de I/O, geralmente utilizando interfaces modernas como `io_uring` em modo passthrough.