Atomic writes no NVMe: o fim do double buffering em bancos de dados

Se existe algo que me tira o sono como engenheiro de performance, é o desperdício de I/O. Ver um subsistema de armazenamento saturado não porque a carga de trabalho exige, mas porque estamos escrevendo os mesmos dados duas vezes por "segurança", é uma ineficiência arquitetural que toleramos por tempo demais. Durante décadas, o medo da corrupção de dados em caso de falha de energia nos obrigou a usar muletas de software como o double buffering.

Com a evolução do protocolo NVMe e a integração correta no kernel do Linux, estamos finalmente removendo essa camada de redundância. As atomic writes (escritas atômicas) delegam a garantia de consistência para quem realmente entende da física do armazenamento: o controlador do SSD. Vamos analisar como isso elimina gargalos de latência e dobra o throughput em cenários de banco de dados intensivos.

Resumo em 30 segundos

O Problema: Bancos de dados escrevem páginas de 16KB, mas discos operam em setores de 4KB. Uma falha de energia no meio da escrita corrompe o dado ("torn page").

A Solução Antiga: O double buffering escreve o dado duas vezes (uma área segura + destino final) para garantir recuperação, sacrificando 50% da largura de banda de escrita.

A Revolução NVMe: O hardware agora garante atomicidade para blocos grandes (16KB, 32KB, 64KB). Se a energia cair, o SSD garante que tudo ou nada seja escrito, permitindo desligar a redundância de software.

A anatomia de uma torn page e o risco de corrupção silenciosa

Para entender por que desperdiçamos tantos ciclos de CPU e IOPS com double buffering, precisamos descer ao nível do bloco. A maioria dos bancos de dados relacionais modernos (MySQL/InnoDB, PostgreSQL) opera com páginas de dados lógicas, geralmente de 16KB. No entanto, o hardware de armazenamento subjacente, historicamente, garantia atomicidade apenas para setores de 512 bytes ou, mais recentemente, 4KB.

Aqui reside o perigo: uma syscall de escrita de 16KB é, na prática, quebrada em quatro operações de 4KB pelo sistema de arquivos ou pelo controlador do disco.

Figura: Visualização do problema da "Torn Page": uma página de banco de dados parcialmente escrita resulta em corrupção fatal.

Se ocorrer um kernel panic ou uma falha de energia exata após a escrita do segundo setor de 4KB, você terá no disco uma página quimera: metade dados novos, metade dados velhos. O banco de dados, ao ler isso na recuperação, encontrará checksums inválidos. Sem um backup ou mecanismo de proteção, essa tabela está corrompida.

O custo oculto do double buffering

Para mitigar esse risco físico, os engenheiros de banco de dados criaram uma solução de software robusta, porém cara: o Doublewrite Buffer (no InnoDB) ou Full Page Writes (no PostgreSQL).

O funcionamento é brutalmente simples e ineficiente:

O banco de dados detecta uma página suja (dirty page) na memória.
Ele escreve essa página primeiro em uma área sequencial segura no disco (o buffer).
Ele chama um fsync() para garantir que o dado persistiu.
Só então ele escreve a página na sua localização real no arquivo de dados (.ibd).
Outro fsync() é chamado.

⚠️ Perigo: Em workloads de escrita pesada (OLTP), o double buffering efetivamente corta pela metade a capacidade de escrita do seu dispositivo. Você comprou um NVMe capaz de 3GB/s, mas seu banco de dados só consegue entregar 1.5GB/s de dados úteis porque está ocupado escrevendo cópias de segurança.

Além da largura de banda, há o custo de latência. Cada operação de escrita envolve mais viagens de ida e volta (round-trips) ao dispositivo e mais interrupções de hardware para a CPU tratar. Em um ambiente de nuvem onde você paga por IOPS provisionado, você está literalmente pagando para escrever lixo de segurança.

Figura: Comparativo de fluxo: a complexidade do Double Buffering versus a simplicidade da Escrita Atômica Direta.

Como as atomic writes delegam a consistência para o controlador

A especificação NVMe evoluiu para resolver isso diretamente no firmware e no hardware. O conceito chave aqui é o AWUPF (Atomic Write Unit Power Fail).

Quando um SSD NVMe anuncia suporte a atomic writes, ele está firmando um contrato com o sistema operacional: "Pode me enviar um bloco de 16KB (ou 32KB, 64KB). Eu garanto que, mesmo se alguém puxar o cabo de força no meio da operação, eu usarei meus capacitores internos e SRAM para finalizar a gravação desse bloco inteiro, ou descartarei tudo."

Não existe mais estado intermediário. Não existe meia página.

O papel do Kernel Linux e Direct I/O

Para que isso funcione, não basta ter o SSD certo. O kernel do Linux precisa passar essa instrução corretamente. Isso foi introduzido através de novas flags na syscall pwritev2(), especificamente a RWF_ATOMIC.

💡 Dica Pro: As atomic writes exigem o uso de Direct I/O (O_DIRECT). Se você usar Buffered I/O, o Page Cache do Linux pode fragmentar ou agrupar suas escritas de maneiras imprevisíveis, quebrando a garantia de atomicidade antes mesmo de chegar ao driver NVMe.

O banco de dados precisa alinhar seus buffers de memória exatamente com os limites de alinhamento atômico do dispositivo. Se o SSD exige alinhamento de 16KB e o banco envia uma escrita deslocada em 512 bytes, a operação falhará ou reverterá para o modo não atômico.

Figura: Arquitetura interna de um SSD Enterprise: capacitores garantem que o buffer atômico seja persistido mesmo sem energia externa.

Mensurando o ganho: throughput e latência

Quando removemos a redundância de software, os ganhos não são apenas teóricos. Testes realizados com MariaDB (que foi pioneiro na implementação disso com a Western Digital e Samsung) mostram resultados agressivos.

Ao desativar o innodb_doublewrite e habilitar o suporte atômico nativo:

Aumento de Throughput: Em cenários de escrita 100% (como ingestão de logs ou carregamento em lote), o throughput frequentemente dobra. Em cargas mistas (TPC-C), observamos ganhos entre 30% a 50%.
Redução de Latência de Cauda (p99): O tempo que a aplicação espera pelo commit diminui drasticamente porque eliminamos um fsync inteiro do caminho crítico.
Vida Útil do SSD (Endurance): Escrever metade dos dados significa que você consome metade dos ciclos de P/E (Program/Erase) da memória NAND. Seu SSD dura o dobro do tempo.

Tabela Comparativa: Padrão Atual vs Atomic Writes

Característica	Double Buffering (Legado)	NVMe Atomic Writes (Inovação)
Amplificação de Escrita	2.0x (mínimo)	1.0x (Nativo)
Latência de Commit	Alta (2x fsync + seek)	Baixa (1x fsync direto)
Uso de CPU	Elevado (gerenciamento de buffer extra)	Reduzido (pass-through direto)
Requisito de Hardware	Qualquer disco	SSD NVMe com suporte a AWUPF
Complexidade de Software	Alta (lógica de recuperação complexa)	Baixa (delega ao hardware)
Risco de Torn Page	Eliminado via software	Eliminado via hardware

Figura: Gráfico de performance: o impacto direto no aumento de TPS e redução de latência ao ativar escritas atômicas.

O ecossistema atual e compatibilidade

Não pense que basta atualizar o kernel e tudo funcionará magicamente. O suporte a atomic writes exige uma cadeia de compatibilidade alinhada:

Hardware: O SSD deve suportar a especificação NVMe (geralmente 1.4 ou superior, mas verifique o datasheet para Atomic Write Unit Power Fail). Drives Enterprise (como a série Ultrastar da WD ou PM17xx da Samsung) são os alvos principais. Drives de consumidor (M.2 genéricos) raramente possuem os capacitores necessários para garantir AWUPF grandes.
Sistema de Arquivos: XFS e EXT4 receberam patches recentes para permitir que a flag RWF_ATOMIC passe através deles sem interferência, desde que em modo Direct I/O.
Aplicação: O banco de dados deve ser compilado e configurado para usar as novas chamadas de sistema. No MySQL/MariaDB, isso envolve parâmetros específicos de configuração de tablespace.

Otimização não é opcional

A era de tratar o armazenamento como uma "caixa preta" lenta acabou. Com dispositivos NVMe entregando latências na casa dos microssegundos, o gargalo subiu para o software. Manter o double buffering ativo em hardware moderno é como comprar uma Ferrari e instalar um limitador de velocidade de 50km/h.

Se você gerencia infraestrutura de dados de alta performance, sua tarefa de casa é clara: verifique se seus SSDs suportam atomicidade de 16KB ou superior. Se suportarem, planeje a migração do seu kernel e banco de dados. O ganho de performance "gratuito" — recuperando ciclos que você já pagou, mas estava desperdiçando — é a vitória mais doce para um engenheiro de sistemas.

Referências & Leitura Complementar

NVM Express Base Specification 2.0: Detalhes sobre o comando Write e garantias de atomicidade (AWUPF).
MariaDB Knowledge Base: Atomic Write Support in InnoDB.
Linux Kernel Archives: Patches de Block Layer para suporte a RWF_ATOMIC (Jens Axboe et al.).
SNIA (Storage Networking Industry Association): Whitepapers sobre performance de SSDs em cargas transacionais.

Perguntas Frequentes (FAQ)

O que acontece se a energia cair durante uma atomic write?

O controlador do NVMe garante, via capacitores internos ou log persistente na própria controladora, que o bloco de dados (ex: 16KB) seja escrito integralmente na NAND ou nada seja escrito. Isso elimina estados parciais e corrupção de página.

Preciso de um SSD específico para usar atomic writes?

Sim. O SSD deve ser Enterprise-grade e suportar a especificação NVMe com suporte explícito a Atomic Write Unit Power Fail (AWUPF) em tamanhos iguais ou superiores ao tamanho da página do seu banco de dados (geralmente 16KB).

O ganho de performance é perceptível em qualquer carga de trabalho?

O ganho é massivo em workloads write-heavy (muitas escritas), como sistemas OLTP transacionais. Em cargas puramente de leitura (OLAP) ou onde o gargalo é CPU/Rede, o impacto é negligenciável, pois o double buffering afeta primariamente o caminho de escrita.