Alinhamento de Partições e RAID: O Fim do Read-Modify-Write em Discos 4K

      19 de dezembro de 2025 Marta G. Oliveira 8 min de leitura
      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.

      Compartilhar:

      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.

      Diagrama de Alinhamento de Setores: O custo oculto do desalinhamento é a duplicação de I/O (RMW). 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:

      1. Read: O disco precisa ler os dois setores físicos de 4K afetados.

      2. Modify: Ele coloca esses dados no cache, modifica apenas o pedaço que o OS mandou.

      3. Recalculate: Recalcula o ECC.

      4. 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:

      1. Chunk Size: Configurado na controladora RAID ou no mdadm (ex: 64K, 512K).

      2. 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.

      Geometria RAID 5: A diferença crítica entre Chunk Size e Stripe Width para o mkfs. 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% no parted instrui a ferramenta a buscar o melhor alinhamento inicial automaticamente (geralmente 1MiB). Se quiser ser cirúrgico, use mkpart 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:

      1. IOPS: Em discos rotacionais (HDD), o volume alinhado pode ser 30% a 50% mais rápido.

      2. lat (usec): A latência média de conclusão deve cair drasticamente no volume alinhado.

      3. 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.

      #Alinhamento de Partição #RAID 4K Sectors #Stripe Size vs Chunk Size #Otimização de Storage Linux #Read-Modify-Write Penalty #Advanced Format 512e
      Marta G. Oliveira

      Marta G. Oliveira

      DevOps Engineer & Storage Nerd

      Automatiza provisionamento de storage com Terraform e Ansible. Defensora do 'Infrastructure as Code' para storage.