O kernel Linux, desde a versão 6.12, abriu uma porta importante: a capacidade de sistemas de arquivos usarem blocos maiores que o tamanho de página de memória (4k na maioria dos sistemas). O XFS foi o primeiro a aproveitar esse recurso; agora, o onipresente EXT4 está prestes a se juntar à festa. Um novo patchset enviado por Baokun Li (Huawei) introduz suporte a LBS (Large Block Size) no EXT4 — e os resultados de performance formam uma verdadeira “faca de dois gumes”.
Antes de tudo, vale separar as coisas: isso não é o bigalloc. O EXT4 já oferecia bigalloc (grandes clusters) de até 64k, mas tratava-se de uma solução indireta. O LBS é uma mudança mais fundamental: permite que o sistema de arquivos opere nativamente com tamanhos de bloco maiores que a página, como 64k, afetando todo o caminho de I/O e simplificando suposições no código. Em outras palavras, bigalloc agrupa blocos pequenos em clusters; LBS eleva o tamanho do bloco em si.
A faca de dois gumes: o trade-off entre BIO e DIO
Aqui está o ponto crucial: não é bala de prata. Nos testes divulgados junto ao patch, o I/O bufferizado (BIO) — isto é, operações que passam pelo page cache — teve ganho médio de ~50% em relação ao bigalloc. Para fluxos cotidianos (copiar, mover, compilar), isso é um salto relevante, porque blocos maiores reduzem metadados e chamadas, melhorando o throughput do caminho bufferizado.
Mas há o “porém”: para I/O direto (DIO) — típico em bancos de dados (Oracle, PostgreSQL) e VMs (QEMU) — o LBS pode custar até ~30% de performance em alguns cenários. O motivo? Ao pular o page cache, o DIO é sensível a alinhamento, tamanhos de requisição e ao comportamento do dispositivo; blocos muito grandes podem aumentar latency tails e reduzir a eficiência de certas cargas, sobretudo quando o padrão de acesso não casa com o tamanho do bloco. Em suma: BIO voa, DIO pode apanhar.
Por que isso importa agora
A permissão do VFS para blocos maiores que a página, incorporada no Linux 6.12, ficou madura o suficiente para o XFS e abriu caminho para que outros sistemas, como o EXT4, explorem a ideia. O trabalho no EXT4 demandou ajustes em várias partes do código (alocação, writeback, folios grandes etc.) — e vem na esteira de um esforço mais amplo de escalabilidade e redução de contenção no alocador do EXT4, visível em séries recentes de patches. Tudo isso prepara o terreno para que o LBS não seja apenas “compatível”, mas performático sob carga moderna.
Uma nova escolha crítica no mkfs
Se (e quando) essa série for aceita, a escolha do tamanho de bloco na formatação (mkfs.ext4) tende a virar uma das decisões de tuning mais críticas do seu ambiente. Para estações e servidores gerais que fazem muitas operações bufferizadas, LBS maior (ex.: 64k) pode render ganhos imediatos. Já para workloads DIO-heavy (bancos/VMs), talvez seja prudente manter blocos menores — ou, ao menos, testar cuidadosamente antes de padronizar. É a típica situação em que o hardware, o padrão de acesso e o perfil de I/O mandam mais do que qualquer regra universal. Em 2025, desempenho de armazenamento é engenharia de trade-offs, e o LBS do EXT4 adiciona um novo e poderoso knob ao seu painel.
Resumo prático: EXT4 Large Block Size entrega ganhos expressivos em I/O bufferizado (até ~50%), mas pode penalizar DIO (até ~30%). O administrador precisa escolher sabiamente o tamanho de bloco na criação do sistema de arquivos, alinhando-o ao tipo de carga.
