Flexible Data Placement: reduzindo a amplificação de escrita sem a complexidade do ZNS

Se você já olhou para a fatura da sua nuvem ou para o orçamento de hardware do seu data center e se perguntou por que está comprando tantos SSDs NVMe de alta resistência (e alto custo) para cargas de trabalho que nem são tão intensas assim, a resposta provavelmente está escondida em três letras: WAF (Write Amplification Factor).

Durante anos, a indústria de armazenamento tentou nos vender a ideia de que para resolver o problema do "vizinho barulhento" dentro do próprio SSD, precisávamos reescrever toda a nossa stack de software. Eles chamaram isso de ZNS (Zoned Namespaces). A promessa era linda, mas a execução exigia que você demitisse seus desenvolvedores de banco de dados ou os trancasse numa sala por dois anos.

Felizmente, o consórcio NVMe acordou e nos trouxe o Flexible Data Placement (FDP). É a solução elegante para quem quer performance de hyperscaler sem precisar gerenciar fisicamente onde cada bit é gravado.

Resumo em 30 segundos

O Problema: SSDs tradicionais misturam dados "quentes" (alterados frequentemente) e "frios" (estáticos) nos mesmos blocos físicos, forçando o Garbage Collection a trabalhar dobrado e desgastando o disco prematuramente (WAF alto).

A Solução Antiga (ZNS): Removeu a camada de tradução (FTL), mas obrigou o sistema operacional e as aplicações a gerenciarem a geometria física do disco. Complexidade proibitiva para a maioria.

A Solução FDP: Mantém a FTL (compatibilidade), mas permite que o host envie "dicas" (Placement IDs) para agrupar dados semelhantes. Reduz a amplificação de escrita drasticamente com mudanças mínimas de software.

O imposto oculto do Garbage Collection

Para entender por que o FDP é revolucionário, precisamos revisitar como um SSD funciona. Diferente de um disco magnético (HDD), onde você pode sobrescrever um setor específico, a memória NAND Flash exige que você apague um bloco inteiro (que contém várias páginas) antes de escrever nele novamente.

Aqui reside o caos. O seu sistema operacional vê um espaço de endereçamento lógico contínuo. Mas, fisicamente, o controlador do SSD (a FTL - Flash Translation Layer) está espalhando esses dados onde der.

Quando você atualiza um pequeno registro no banco de dados, o SSD grava a nova versão em outro lugar e marca a antiga como inválida. O bloco original agora é um queijo suíço: cheio de buracos (dados inválidos) e alguns pedaços de queijo (dados válidos de outros arquivos).

Para recuperar esse espaço, o processo de Garbage Collection (GC) entra em cena. Ele precisa ler os dados válidos restantes, copiá-los para um novo bloco e apagar o bloco antigo.

⚠️ Perigo: Esse processo de copiar dados válidos é a Amplificação de Escrita. Se você escreve 1GB e o SSD precisa mover internamente mais 2GB para limpar a bagunça, seu WAF é 3.0. Você está pagando por 3GB de desgaste e consumindo largura de banda interna, mas só usou 1GB efetivamente.

Isso não apenas mata a vida útil do seu SSD (DWPD), mas cria picos de latência imprevisíveis. Tente explicar para o seu cliente por que a query demorou 500ms em vez de 2ms; a culpa é do SSD fazendo faxina na hora errada.

Figura: O pesadelo da fragmentação: dados quentes e frios misturados forçam o controlador a reescrever dados desnecessariamente durante a coleta de lixo.

Por que o ZNS não dominou o mundo (ainda)

A indústria tentou resolver isso com o ZNS (Zoned Namespaces). A ideia era radical: remover a FTL. O SSD expõe zonas sequenciais e diz ao host: "Escreva sequencialmente aqui. Se quiser sobrescrever, apague a zona toda".

Isso elimina o WAF causado pelo GC interno. O WAF cai para quase 1.0. Perfeito, certo?

Errado. O custo de engenharia foi transferido do fabricante do SSD para você. Para usar ZNS, você precisa de sistemas de arquivos compatíveis (como F2FS ou zonas no Btrfs) e, muitas vezes, modificar o próprio motor de armazenamento do banco de dados (RocksDB, por exemplo) para entender zonas.

A maioria das empresas não tem uma equipe de engenharia dedicada a otimizar drivers de armazenamento. O ZNS é excelente para hyperscalers como Dropbox ou Meta, que controlam a stack inteira, mas é um pesadelo logístico para o resto do mercado corporativo.

FDP: A inteligência do meio-termo

O Flexible Data Placement (ratificado no TP4146 do NVMe) surge como o equilíbrio ideal. Ele mantém a FTL. Isso significa que, se você plugar um SSD com FDP em um sistema legado que não sabe o que é FDP, ele funciona como um SSD normal. Sem telas azuis, sem kernel panic.

Mas, se o seu sistema for "iluminado", ele pode usar o FDP para segregar dados.

Como funciona a mágica dos Placement IDs

Em vez de ditar o endereço físico exato (como no ZNS), o host envia os dados acompanhados de um Placement ID. Pense nisso como uma etiqueta colorida na sua mudança.

Imagine que você está mudando de casa.

SSD Padrão: Você joga todas as caixas no caminhão misturadas. Cozinha, quarto, banheiro. Ao chegar, você tem que separar tudo (Garbage Collection).
ZNS: Você mesmo tem que dirigir o caminhão e colocar cada caixa na prateleira exata da casa nova.
FDP: Você coloca uma etiqueta "Cozinha" nas caixas. O carregador (SSD) garante que todas as caixas com a etiqueta "Cozinha" fiquem juntas no caminhão e sejam descarregadas na mesma área.

No contexto técnico, o FDP permite criar Reclaim Groups. O host pode dizer: "Este fluxo de escrita é o Journal do banco de dados (sobrescrita frequente)" e "Este fluxo são fotos de perfil (estático)".

O SSD coloca o Journal em um bloco físico e as fotos em outro. Quando o Journal for sobrescrito, o bloco inteiro se torna inválido rapidamente. O SSD pode apagá-lo sem precisar copiar as fotos para outro lugar.

💡 Dica Pro: O objetivo do FDP não é microgerenciar a NAND, mas sim sincronizar a morte dos dados. Se todos os dados em um bloco físico "morrem" (são deletados ou atualizados) ao mesmo tempo, o custo de GC é zero.

Figura: Comparativo de eficiência: Enquanto SSDs convencionais sofrem com WAF exponencial em cargas mistas, o FDP mantém a amplificação próxima do ideal teórico de 1.0.

Comparativo: Padrão vs. ZNS vs. FDP

Para os arquitetos que precisam justificar a escolha tecnológica, aqui está a tabela que vai no slide do PowerPoint:

Característica	SSD NVMe Convencional	ZNS (Zoned Namespaces)	FDP (Flexible Data Placement)
Gerenciamento de Flash	FTL Interna (Caixa Preta)	Host (Aplicação/OS)	Híbrido (FTL com Dicas do Host)
Amplificação de Escrita (WAF)	Alta (2.0 - 4.0+)	Mínima (~1.0)	Baixa (~1.05 - 1.2)
Complexidade de Integração	Nenhuma (Plug & Play)	Altíssima (Requer refatoração)	Baixa (Pequenas alterações no driver/app)
Compatibilidade Retroativa	Total	Nenhuma	Total (Funciona como drive padrão)
Over-provisioning Necessário	Alto (para mitigar GC)	Quase Zero	Reduzido
Caso de Uso Ideal	Boot, General Purpose	Storage Engines Customizados	Bancos de Dados, Caches, Big Data

Resultados no mundo real: O fim da latência de cauda

Testes iniciais com implementações de FDP (como as realizadas pela Samsung e Western Digital em parceria com a Meta) mostram resultados que justificam o hype.

Em cargas de trabalho mistas (escrita aleatória + leitura), o FDP conseguiu reduzir o WAF de 3.0 para algo próximo de 1.05. Mas o ganho financeiro de durabilidade é apenas metade da história.

A verdadeira vitória é a QoS (Qualidade de Serviço). Em um SSD convencional sob carga, a latência p99 (os 1% dos pedidos mais lentos) dispara porque o controlador suspende leituras para mover dados internamente. Com o FDP segregando dados quentes de frios, o volume de dados movidos pelo GC cai drasticamente.

Isso significa que seus SLAs de latência se tornam muito mais fáceis de cumprir, sem precisar superdimensionar a infraestrutura.

O ecossistema atual

O suporte ao FDP já está aterrissando no Linux. O Kernel 6.2+ já traz primitivas para passar essas "dicas" de posicionamento através da interface io_uring e comandos passthrough do NVMe.

Aplicações como RocksDB (o motor por trás de gigantes como CockroachDB e streams do Kafka) já possuem patches experimentais para usar FDP. Cachelib (usado pelo Facebook) também.

Estamos vendo uma transição onde a inteligência de armazenamento sai do firmware proprietário e fechado e vai para uma colaboração aberta entre o Kernel e o dispositivo.

O veredito do arquiteto

O FDP não é apenas uma nova feature legal; é uma correção necessária para a física da NAND Flash moderna. À medida que avançamos para QLC (Quad-Level Cell) e futuramente PLC (Penta-Level Cell), a durabilidade dos blocos diminui e a penalidade de escrita aumenta. Sem mecanismos como o FDP, SSDs de alta densidade seriam inutilizáveis para qualquer coisa além de armazenamento frio (WORM).

Se você está desenhando a próxima geração de clusters de banco de dados ou armazenamento de objetos de alta performance, coloque "Suporte a NVMe TP4146 (FDP)" nos seus requisitos de compra. Você vai economizar em substituição de hardware e ganhar performance de graça. É a rara situação "win-win" em infraestrutura.

Referências & Leitura Complementar

NVM Express Base Specification 2.0c: Detalhes sobre o comando de Placement Identifiers.
NVMe Technical Proposal 4146 (TP4146): A especificação oficial do Flexible Data Placement.
OCP (Open Compute Project) Global Summit: Apresentações da Meta e Google sobre a implementação de FDP em hiperescala.
SNIA (Storage Networking Industry Association): Whitepapers sobre a redução de WAF em ambientes multi-tenant.

Perguntas Frequentes (FAQ)

Qual a principal diferença entre ZNS e FDP?

O ZNS remove a camada de tradução (FTL) e exige que o host gerencie sequencialmente os dados, o que requer reescrita pesada de software e drivers. O FDP mantém a FTL, mas permite que o host envie "dicas" (Placement IDs) de onde agrupar os dados, mantendo a compatibilidade total com sistemas legados que não suportam a tecnologia.

O FDP requer hardware específico?

Sim, o SSD precisa suportar a especificação NVMe TP4146 (integrada às versões mais recentes do NVMe 2.0+). No entanto, a grande vantagem é que, ao contrário do ZNS, um drive FDP pode funcionar como um drive NVMe padrão se conectado a um host que não suporte o recurso.

Como o FDP melhora a vida útil do SSD?

Ao agrupar dados com tempos de vida semelhantes (ex: logs que mudam muito vs. arquivos estáticos) no mesmo bloco físico, o FDP reduz drasticamente a necessidade de mover dados internamente (Garbage Collection). Isso diminui a amplificação de escrita (WAF), fazendo com que o disco escreva menos fisicamente para a mesma quantidade de dados lógicos.