Linux: Corrupção de dados no Ext4 em 6.1.64-1

Artigo original ↗ Discussão no Hacker News ↗

Um bug sério no sistema de arquivos ext4 do Linux 6.1.64 causa corrupção silenciosa de dados quando arquivos são gravados com I/O direto, levando o Debian a adiar seu lançamento 12.3 e bloquear o pacote de kernel afetado. Os comentaristas examinam como um par de patches upstream dessincronizados acabou em kernels estáveis de longo prazo, levantando preocupações mais amplas sobre o processo de backport do Linux estável, os limites das distribuições “estáveis” e quão rapidamente tais problemas podem ser detectados e mitigados por meio da infraestrutura da distribuição e das práticas dos usuários.

Escopo e Natureza do Bug

  • ocorre corrupção de dados do ext4 em certos kernels estáveis Linux 6.1 ao usar I/O direto (O_DIRECT), devido a uma alteração do ext4 portada para trás que dependia de outra alteração de I/O direto que não foi portada para trás.
  • Se ambos os commits estiverem presentes (por exemplo, em kernels mais novos), o comportamento é correto; se apenas o commit do ext4 estiver presente (por exemplo, 6.1.64/65), as gravações podem ir para o deslocamento errado.
  • A corrupção é descrita como “não catastrófica”: os metadados do sistema de arquivos permanecem intactos, mas o conteúdo de arquivos individuais pode ser corrompido silenciosamente, algo especialmente ruim para imagens de VM e bancos de dados que usam O_DIRECT.

Upstream vs Responsabilidade do Debian

  • Vários comentários enfatizam que se trata de um bug do kernel estável upstream, não de um problema de correção apenas no Debian; o Debian acompanha os lançamentos estáveis do kernel.org.
  • Parte da confusão surge no fio; outros esclarecem usando changelogs do kernel e links da lista de discussão que o upstream 6.1.64 é afetado e o 6.1.66 contém a correção.
  • Alguns kernels Ubuntu são ditos como não afetados porque não trazem 6.1 por padrão.

Crítica ao Processo do Kernel Estável

  • Crítica forte ao modelo de backport pesado: milhares de commits são incorporados a ramos LTS antigos, com risco não trivial de dependências.
  • Preocupação de que kernels “estáveis” mudam rápido demais e agora são menos estáveis que o resto do Debian; alguns preferem rodar apenas o kernel mainline mais recente.
  • Incidente relacionado: outro patch dependente ausente em 6.1.66 que quebrou o Wi‑Fi, posteriormente corrigido em 6.1.67, reforçando dúvidas sobre o processo.

Tratamento no Debian e Atualizações

  • Usuários reclamam que o unattended-upgrades instalou o kernel ruim mesmo depois de o bug grave ser conhecido.
  • Explicações dadas: a ferramenta de archive do Debian não foi projetada para revogação instantânea; novos kernels precisam ser compilados para muitas arquiteturas e depois se propagar por espelhos que sincronizam apenas algumas vezes por dia.
  • Workarounds discutidos: fixar 6.1.64-1 com um arquivo de preferências do apt, inicializar com um kernel mais antigo e desativar corretamente unattended-upgrades interrompendo/desativando a unidade .timer ou reconfigurando o pacote.

Sistemas de Arquivos e Recuperação

  • Alguns veem isso como um golpe contra a ideia de que ext4 é inerentemente mais seguro do que ZFS ou btrfs; outros enfatizam que todos os sistemas de arquivos têm bugs.
  • O ext4 é elogiado por seu fsck maduro e layout de metadados simples, alegando permitir recuperação de quase qualquer dano; céticos questionam quanto de dados reais de usuários isso de fato salva.

Severidade e “Perda de Dados Não Séria”

  • Debate sobre os termos do Debian: “grave” vs “perda de dados não séria”, e se a corrupção que pode ser corrigida por fsck (ou backups) conta como “recuperável” na prática.
  • Ênfase de que a corrupção silenciosa é especialmente perigosa porque backups podem absorver dados ruins silenciosamente.