Hoje, 31 jan 2026,
O linux kernel 6.18.5 acabou de subir para os repositórios do Debian testing – futuro Forky – substituindo o 6.17.13.
O 6.18 é uma versão principal, com muito mais coisa que um patch qualquer. É também LTS, ou seja, será suportada por muito mais tempo (até dezembro de 2027).
Principais novidades do 6.18 como um todo
a) Foco em performance e memória
- Novo esquema de caching de memória (“sheaves”) melhorando a responsividade geral.
- Melhorias no gerenciamento de memória e swapping que ajudam sob carga pesada.
b) Armazenamento e sistemas de arquivos
- Remoção do Bcachefs do kernel (agora fora do upstream).
- Btrfs ganha suporte inicial a tamanhos de bloco maiores, o XFS agora permite verificação de filesystem online por padrão, e o EXT4 traz capacidades extras de gerenciamento.
c) Rede e segurança
- AccECN no TCP para sinais de congestionamento mais precisos.
- Opção para PSP-encrypted TCP — tentativa de trazer segurança de transporte nativa.
- Assinatura criptográfica para programas eBPF, fortalecendo a segurança do BPF.
- Multi-LSM (vários sistemas de segurança como SELinux/AppArmor simultâneos) ficou mais robusto.
d) Suporte a hardware e drivers
- Novos drivers e atualizações para muitos dispositivos, incluindo suporte melhor para Apple M2 Pro/Max/Ultra (devicetrees), várias GPUs ARM Mali, e melhorias gerais de energia/power-state.
- AMD: melhorias de virtualização (ex. Secure AVIC para SEV-SNP), correção em detecção de topologia em grandes VMs.
e) Rust no kernel
- Mais código e drivers escritos em Rust começam a aparecer (ex. novas abstrações USB e driver Tyr).
Mudanças notáveis no EXT4
1) Alocação de espaço mais esperta (menos fragmentação)
O EXT4 vem refinando o delayed allocation e o multiblock allocator.
O que muda na prática:
- Arquivos grandes (VMs, bancos, ISOs) ficam menos fragmentados.
- Menos I/O inútil.
- Performance mais estável ao longo do tempo, não só logo após formatar.
Tradução: o filesystem envelhece melhor.
2) fallocate() e operações “zero” mais eficientes
O EXT4 melhorou a forma como lida com:
- pré-alocação
- zeroing de blocos
- expansão de arquivos grandes
Resultado:
- Criar ou expandir arquivos grandes ficou mais rápido.
- Menos escrita real em SSD/NVMe → menos desgaste.
- Melhor comportamento para bancos de dados e imagens de disco.
Isso é EXT4 se adaptando ao mundo de SSD, sem virar um Frankenstein experimental.
3) Melhor controle de quotas e contabilidade
As quotas (usuário, grupo, projeto) ficaram mais consistentes internamente.
Impacto real:
- Menos chance de quota “desandar” após crash.
- Melhor integração com workloads modernos (containers, VMs).
- Contabilidade de espaço mais confiável.
EXT4 sempre foi conservador aqui — agora está conservador e afiado.
4) fsck mais rápido e previsível
Houve avanços contínuos em:
- verificação de metadata
- paralelismo interno
- detecção de inconsistências específicas
Na prática:
fsck.ext4em volumes grandes dói menos.- Menos tempo parado em manutenção.
- Menos surpresas após desligamento forçado.
5) Journaling mais robusto (menos corrupção silenciosa)
O journaling do EXT4 vem sendo refinado há anos:
- Melhor ordenação de commits
- Menos janelas de inconsistência
- Melhor comportamento sob carga pesada e crash
Resultado:
- Menos arquivos “meio escritos”.
- Recuperação mais previsível.
EXT4 continua jogando no time da confiabilidade, não da moda.
6) Escalabilidade silenciosa
Nada de feature chamativa, mas importante:
- Melhoria em diretórios gigantes
- Melhor uso de CPUs modernas
- Menos contenção interna em workloads paralelos
Ou seja: EXT4 não brilha em benchmark de blog, mas aguenta pancada.
Lembrando que em HDs, aqueles trambolhos magnéticos do século passado, ainda muito usados em NAS e backup de dados, o EXT4 se sai melhor que o BTRFS, por exemplo.
O que mudou de mais relevante no BTRFS
1) Blocos maiores (big win técnico)
Uma das mudanças mais importantes:
- Suporte inicial a tamanhos de bloco maiores
- Melhor alinhamento com SSDs/NVMes modernos
- Menos overhead de metadata em arquivos grandes
Na prática:
- Workloads grandes (VMs, containers, backups) ficam mais eficientes
- Menos CPU para gerenciar metadata
- Caminho aberto para escalabilidade melhor no longo prazo
2) RAID mais estável (finalmente)
O Btrfs vem consertando a casa, especialmente em RAID:
- Melhorias em RAID1 / RAID1C3 / RAID1C4
- Detecção mais confiável de erros de leitura
- Rebalance e scrub menos propensos a surpresas desagradáveis
Importante dizer:
- RAID5/6 ainda é terreno pantanoso
- Mas RAID1 já é utilizável sem rezar antes
Quem usa Btrfs como ZFS-wannabe começa a dormir melhor.
3) Scrub, repair e recovery mais previsíveis
Houve avanços graduais (mas constantes) em:
- Scrub mais eficiente
- Correções menos destrutivas
- Melhor diagnóstico de corrupção
Tradução honesta:
- Ainda não é ZFS em tooling
- Mas está longe do Btrfs “roleta russa” de anos atrás
Hoje ele erra menos — e quando erra, avisa melhor.
4) Subvolumes e snapshots: menos custo escondido
O Btrfs sempre amou snapshot. O problema era o custo invisível.
Melhorias recentes focaram em:
- Menos impacto de muitos snapshots
- Melhor limpeza de snapshots antigos
- Menos fragmentação causada por COW excessivo
Resultado:
- Sistemas com snapshots frequentes (ex.: root + rollback) ficam mais utilizáveis
- Menos degradação silenciosa ao longo do tempo
Ainda exige disciplina. Mas agora dá para manter.
5) Envio e recebimento (send/receive) mais robustos
O btrfs send ganhou correções importantes:
- Menos falhas em árvores grandes
- Melhor consistência em incrementais
- Menos “surpresas” em backups longos
Para quem usa snapshot + backup incremental:
- Isso é ouro
- E é um dos motivos reais para usar Btrfs
Finalizando
Eu uso BTRFS, gosto muito, mas EXT4 é segurança, previsibilidade e estabilidade certa, e ainda é o FS mais usado. E também uso o Debian Testing no meu desktop, é como ter uma rolling release sem as surpresas de um bleeding edge.
Abraços e bom fim de semana!
