Alinhamento de Partições e RAID: O Fim do Read-Modify-Write em Discos 4K
Seu RAID está lento? O problema pode ser o desalinhamento entre setores 4K e o stripe size. Aprenda a diagnosticar, calcular e corrigir o Write Penalty.
Se você acha que comprar discos rápidos resolve problemas de performance, tenho más notícias. O hardware é apenas potencial; a configuração é o que entrega a velocidade. Vejo sysadmins veteranos jogando 40% do IOPS no lixo simplesmente porque confiaram nos valores padrão do instalador do Linux ou ignoraram a geometria física do array.
O gargalo mais silencioso e devastador em storage não é a interface SATA/SAS, nem a CPU. É o desalinhamento. Quando o sistema operacional tenta gravar dados sem respeitar as fronteiras físicas do disco ou do RAID, você desencadeia um ciclo de penalidade chamado Read-Modify-Write (RMW). É como tentar estacionar um caminhão ocupando metade de duas vagas: você incomoda todo mundo e dobra o trabalho necessário para qualquer manobra.
Vamos dissecar essa mentira da camada de abstração e aprender a alinhar partições e sistemas de arquivos para a realidade física dos discos 4K e arrays RAID.
O que é Alinhamento de Partições e RAID?
Alinhamento de Armazenamento é a prática de sincronizar o início das partições lógicas e dos blocos do sistema de arquivos com os limites dos setores físicos do disco (4K) e dos "chunks" do RAID. O objetivo é garantir que uma operação de gravação lógica corresponda a exatamente uma (ou múltiplas inteiras) operações de gravação física, eliminando a latência adicional causada pela leitura e reescrita de blocos vizinhos (Read-Modify-Write).
A Mentira dos 512 Bytes: Emulação 512e vs. 4Kn
Durante décadas, o mundo girou em torno de setores de 512 bytes. Mas a física impôs limites e os fabricantes migraram para o "Advanced Format" com setores de 4096 bytes (4K) para aumentar a densidade e a correção de erros (ECC).
O problema? Para não quebrar sistemas operacionais antigos (como o Windows XP ou distros Linux arcaicas), os fabricantes de disco criaram uma mentira no firmware: a emulação 512e.
O disco diz ao sistema operacional: "Oi, eu tenho setores de 512 bytes". O OS acredita e manda gravar um bloco de 512 bytes. Mas, fisicamente, o disco só consegue gravar 4096 bytes por vez.
Figura: Diagrama de Alinhamento de Setores: O custo oculto do desalinhamento é a duplicação de I/O (RMW).
Se a sua partição começar no setor lógico 63 (padrão antigo do MS-DOS), ela estará desalinhada em relação à grade física de 4K. O resultado é que cada cluster de 4K do seu sistema de arquivos vai "cair" sobre a fronteira de dois setores físicos do disco.
O Impacto do Read-Modify-Write (RMW)
Quando ocorre esse desalinhamento, uma operação de escrita simples (Write) se transforma em um pesadelo de quatro etapas para o controlador do disco:
Read: O disco precisa ler os dois setores físicos de 4K afetados.
Modify: Ele coloca esses dados no cache, modifica apenas o pedaço que o OS mandou.
Recalculate: Recalcula o ECC.
Write: Grava os dois setores físicos de volta.
Você acabou de dobrar seu I/O e triplicou sua latência. Em SSDs, isso é ainda pior: chama-se Write Amplification, e você está literalmente queimando a vida útil da sua memória NAND à toa.
Matemática de Storage para RAID: Stripe Unit e Width
Se um disco sozinho já sofre com desalinhamento, um array RAID (5 ou 6) sofre exponencialmente. Aqui, não lidamos apenas com setores, mas com Chunks (ou Stripe Units).
Quando você cria um RAID, os dados são espalhados pelos discos em pedaços (Chunks). Se o seu sistema de arquivos (EXT4, XFS) não souber o tamanho desse pedaço, ele pode tentar gravar metadados ou journals exatamente na fronteira entre dois discos, forçando ambos a acordar e trabalhar para uma gravação minúscula.
Calculando a Geometria Correta
Para formatar corretamente, você precisa de dois números mágicos que dependem do seu hardware:
Chunk Size: Configurado na controladora RAID ou no
mdadm(ex: 64K, 512K).Data Disks: O número de discos que efetivamente guardam dados (exclua a paridade).
A fórmula para o alinhamento do sistema de arquivos é:
Stride (Passo): É o tamanho do Chunk dividido pelo tamanho do bloco do sistema de arquivos (geralmente 4K).
Stripe-Width (Largura da Faixa): É o Stride multiplicado pelo número de discos de dados.
Figura: Geometria RAID 5: A diferença crítica entre Chunk Size e Stripe Width para o mkfs.
Exemplo Prático (RAID 6 com 6 Discos):
Discos Totais: 6
Discos de Dados: 4 (6 total - 2 paridade)
Chunk Size: 64KB (65536 bytes)
Block Size do FS: 4KB (4096 bytes)
$$Stride = \frac{64KB}{4KB} = 16$$ $$Stripe Width = 16 \times 4 = 64$$
Esses são os valores que passaremos ao mkfs para que ele alinhe suas estruturas internas perfeitamente com a geometria do RAID.
Diagnóstico Prático: Identificando Desalinhamento
Não assuma nada. Verifique. O Linux moderno tem ferramentas excelentes para expor a topologia do disco.
1. Verificando a Topologia Física
O comando lsblk -t é o seu melhor amigo aqui.
lsblk -t -o NAME,PHY-SEC,LOG-SEC,MIN-IO,OPT-IO,ALIGNMENT
O que procurar na saída:
PHY-SEC: Deve ser 4096. Se for 512, é um disco antigo ou SSD mentindo muito bem (mas trate como 4K por segurança).
MIN-IO: O tamanho mínimo de I/O físico (geralmente 4096).
OPT-IO: O tamanho ideal de I/O (geralmente o tamanho do Stripe do RAID).
ALIGNMENT: Deve ser 0. Se você ver qualquer número diferente de 0 aqui, sua partição está desalinhada e sua performance está comprometida.
2. Verificando com Blockdev
Para um script ou verificação rápida:
blockdev --getalignoff /dev/sdb1
Se retornar algo diferente de zero, pare tudo. Faça backup. Você precisará reparticionar.
Execução: Particionamento e Formatação Alinhados
Esqueça cilindros, cabeças e setores (CHS). Isso morreu nos anos 90. Hoje falamos em Setores Lógicos (LBA) ou MiB.
Passo 1: Particionamento Correto com Parted
A regra de ouro moderna é: Comece a primeira partição em 1MiB (setor 2048). Isso garante alinhamento com quase qualquer tamanho de bloco físico (4K, 8K, 16K, etc.) e qualquer tamanho de Chunk de RAID comum.
# Evite fdisk se puder, parted é mais explícito com alinhamento
parted /dev/sdb --script mklabel gpt
parted /dev/sdb --script mkpart primary 0% 100%
Nota do Sysadmin: O uso de
0%nopartedinstrui a ferramenta a buscar o melhor alinhamento inicial automaticamente (geralmente 1MiB). Se quiser ser cirúrgico, usemkpart primary 2048s 100%.
Passo 2: Otimizando o Sistema de Arquivos (MKFS)
Aqui separamos os amadores dos profissionais. Passar a geometria do RAID para o sistema de arquivos permite que ele distribua os dados de forma inteligente.
Tabela Comparativa: Opções de Otimização de Geometria
| Sistema de Arquivos | Parâmetro "Stride" (Chunk) | Parâmetro "Stripe Width" (Total Largura) | Comando Exemplo (Baseado no cálculo anterior) |
|---|---|---|---|
| EXT4 | -E stride=X |
-E stripe-width=Y |
mkfs.ext4 -E stride=16,stripe-width=64 /dev/md0 |
| XFS | su=X (Stripe Unit) |
sw=Y (Stripe Width Multiplier) |
mkfs.xfs -d su=64k,sw=4 /dev/md0 |
Atenção no XFS: Note que o XFS usa o valor em bytes/kb (su=64k) e o número de discos de dados (sw=4), o que é muito mais intuitivo que os blocos abstratos do EXT4.
Evidência de Melhora: Benchmark com FIO
Não confie na minha palavra. "Show me the numbers". Vamos usar o fio para simular a carga mais punitiva para desalinhamento: Random Write 4K.
Se estiver desalinhado, o RMW vai destruir o IOPS aqui.
Cenário de Teste: Crie dois volumes lógicos, um alinhado e um propositalmente desalinhado (começando no setor 63, por exemplo), e rode:
fio --name=random-write-test \
--ioengine=libaio \
--rw=randwrite \
--bs=4k \
--direct=1 \
--size=1G \
--numjobs=1 \
--runtime=60 \
--group_reporting \
--filename=/mnt/test_volume/fiotest
O que observar nos resultados:
IOPS: Em discos rotacionais (HDD), o volume alinhado pode ser 30% a 50% mais rápido.
lat (usec): A latência média de conclusão deve cair drasticamente no volume alinhado.
clat (completion latency): Observe o percentil 99th (
clat_percentiles). O desalinhamento causa picos de latência que travam bancos de dados.
Veredito Técnico Pragmática
O custo de corrigir o alinhamento é zero se feito na instalação. O custo de corrigir em produção é uma migração de dados completa.
Discos modernos são rápidos, mas não fazem milagres contra a física. Se você forçar um bloco lógico a ocupar dois blocos físicos, você paga uma taxa ("taxa de RMW") em cada transação. Em um banco de dados transacional com milhares de escritas por segundo, essa taxa é a diferença entre um servidor fluido e um que engasga sob carga.
Alinhe suas partições. Calcule seu Stripe. Meça antes de entrar em produção.
Referências & Leitura Complementar
Red Hat Enterprise Linux Storage Administration Guide - Seção sobre "I/O Limits and Alignment".
Western Digital Whitepaper 2579-850125 - "Advanced Format Technology: The 4K Sector Migration".
The XFS Filesystem Disk Layout Design - Documentação oficial sobre Allocation Groups e alinhamento de stripe.
Man Pages:
man parted,man mkfs.xfs,man lsblk.
Marta G. Oliveira
DevOps Engineer & Storage Nerd
Automatiza provisionamento de storage com Terraform e Ansible. Defensora do 'Infrastructure as Code' para storage.