O desenvolvimento do Kernel Linux é um palco constante para debates acalorados sobre a melhor forma de construir o coração de milhões de sistemas. Recentemente, uma discussão intensa emergiu nas listas de e-mail, colocando frente a frente Linus Torvalds, o criador do Linux, e Kent Overstreet, o principal desenvolvedor do inovador sistema de arquivos bcachefs. O cerne do conflito? A inclusão de novas funcionalidades, como a ferramenta de recuperação journal_rewind, em uma release candidate (RC) — neste caso, o Linux 6.16-rc3.
Linus, fiel à sua filosofia de que RCs devem focar estritamente em correções de bugs, argumenta contra a introdução de código novo nesse estágio. Kent, por outro lado, defende que, para sistemas de arquivos que lidam com dados críticos e não têm o “luxo de um reboot para apagar erros”, ferramentas de recuperação e depuração, mesmo que novas, são vitais e devem chegar às mãos dos usuários o mais cedo possível.
Este artigo mergulhará fundo nesse debate, explorando as filosofias de desenvolvimento contrastantes, a prioridade da recuperação de dados em sistemas de arquivos, a confiança dos usuários em tecnologias como bcachefs, e as implicações para o futuro do desenvolvimento do Kernel Linux.
O dilema do bcachefs e a regra do ‘rc’: um conflito de filosofias
A visão de Linus Torvalds: ‘RCs são para fixes, não para features’
Para Linus Torvalds, a filosofia é clara e inflexível: “RCs são apenas para correções de bugs”. Em resposta ao pull request enviado por Kent Overstreet, Linus foi direto:
“Você parece ter esquecido qual era o propósito da janela de fusão novamente. Nós não começamos a adicionar novas funcionalidades só porque você encontrou outros bugs.”
A lógica por trás dessa posição é a manutenção da estabilidade. As Release Candidates (RCs) servem para testar e consolidar mudanças introduzidas durante a merge window, corrigindo regressões e refinando o que já foi aceito. A introdução de novos recursos nesse estágio compromete a previsibilidade do ciclo de lançamento e pode introduzir novos bugs — algo que Linus se recusa a permitir, principalmente com a complexidade dos subsistemas modernos.
Além disso, Linus enfatizou que o bcachefs ainda é experimental. Para ele, usuários que optam por testá-lo devem estar cientes dos riscos inerentes. A estabilidade do Kernel Linux como um todo não pode ser comprometida por exceções, mesmo que justificáveis.
A defesa de Kent Overstreet: a realidade dos sistemas de arquivos
Kent Overstreet, por sua vez, traz uma perspectiva visceral do que é manter um sistema de arquivos moderno na vida real. Para ele, o objetivo é simples e urgente:
“O ponto aqui é: conseguir código para os usuários que funcione.”
Sistemas de arquivos, diferentemente de outros subsistemas do kernel, não têm o luxo do reboot como solução para falhas. Um bug em um filesystem pode significar perda permanente de dados — o tipo de problema que nenhuma política de ciclo de release deve ignorar.
Ele cita casos anteriores em que precisou “correr para incluir funcionalidades inteiras de formato de disco” em tempo recorde, como no caso do btree bitmap na seção info de membro. Essas mudanças não eram “luxos”, mas ferramentas críticas para salvar dados de usuários reais em produção.
journal_rewind como ferramenta de recuperação
A nova funcionalidade proposta, journal_rewind, permite resetar o sistema de arquivos a um ponto anterior no tempo, funcionando como uma espécie de “time machine” emergencial. Kent relatou que a ferramenta já restaurou com sucesso o sistema de um usuário afetado por um bug crítico de deleção de subvolumes (i_nlink 0). O usuário não tinha backup, e journal_rewind foi a única salvação.
Kent argumenta que esperar três meses para que uma ferramenta dessas esteja em uma versão estável é negligenciar o suporte aos usuários — algo que, segundo ele, os outros filesystems têm feito mal.
Além disso, ele destaca o valor de ferramentas de introspecção, tracepoints e debugging facilitado, que tornam possível manter um projeto como bcachefs funcional mesmo em cenários extremos de campo.
A confiança do usuário e as falhas dos sistemas de arquivos
Usuários ‘queimados’ por outros filesystems
Kent Overstreet traz à tona a fragilidade da confiança dos usuários em sistemas de arquivos modernos. Ele menciona explicitamente os traumas causados por tecnologias anteriores:
- Btrfs: “Muitas pessoas foram queimadas”, diz Kent, referindo-se à reputação de perdas de dados e bugs de juventude que o acompanharam por anos.
- XFS: Surpreendentemente, Kent observa um crescimento nos relatos de problemas de recuperação de dados com XFS, um filesystem historicamente considerado robusto.
- ext4: Ele entende por que muitos ainda se agarram ao ext4 — “Eu não os culpo”, afirma.
No caso do bcachefs, Kent garante que as únicas histórias públicas de perda de dados são as que ele mesmo divulgou como forma de alerta e documentação, justamente para evitar repetições.
A responsabilidade do desenvolvedor de filesystem
Kent vê a responsabilidade do mantenedor de um sistema de arquivos como uma missão quase pessoal. Suas declarações são carregadas de senso de dever:
“Eu sou o responsável por garantir que os usuários do bcachefs tenham um sistema de arquivos que funcione.”
Ele se define como alguém que “ativamente caça relatórios de bugs” e insiste que, mesmo quando o problema parecer ser hardware ou erro do usuário (PEBCAK), o filesystem deve resistir.
O objetivo? Criar algo em que os usuários possam confiar. E, segundo ele, isso exige entregar ferramentas de recuperação o mais cedo possível, mesmo que em um RC.
Os fixes para 6.16-rc3 e o ‘journal_rewind’ em detalhes
Correções e melhorias principais
Apesar da polêmica, o pull request também trazia várias correções legítimas:
- Bugs de regressão: Um raro UAF (Use-After-Free) no alocador de foreground foi corrigido.
- Logging de erros aprimorado: Melhorias no sistema de log de erros no journal — reflexo de uma “lição aprendida” após o bug de subvolumes.
- Check/repair: Correções significativas nos loops de subvolumes e estrutura de diretórios, especialmente com snapshots.
- rcu_pending.c compatível com PREEMPT_RT: Garantindo operação correta com real-time kernel.
- bcachefs device add: Corrige a emissão de uevent para detecção correta de dispositivos.
- Autofix de fsck: Mais situações agora são marcadas como corrigíveis automaticamente.
- Tracepoints de btree: Ferramentas novas para debugar livelocks no caminho de escrita.
journal_rewind: uma ferramenta de recuperação de desastres
A funcionalidade journal_rewind é o ponto focal do debate:
- Caveats: Requer que discards estejam desabilitados (por ora), mas há planos para reestruturar o caminho de discard para maior confiabilidade.
- Prova de eficácia: Já evitou a perda total de dados em um caso real.
- Função estratégica: Pode representar a linha entre recuperar ou perder dados, especialmente em sistemas sem backup.
Conclusão: o coração do Linux, entre a regra e a resiliência
O debate entre Linus Torvalds e Kent Overstreet é mais do que uma disputa técnica; é um reflexo das tensões e paixões que moldam o desenvolvimento do Kernel Linux. De um lado, uma disciplina férrea sobre ciclos de release, que protege a estabilidade do sistema. Do outro, a realidade crua dos usuários em campo, que precisam de ferramentas de resgate agora — não na próxima versão.
Esse embate sublinha a difícil arte de manter um sistema operacional vivo, confiável e útil. Em especial, sistemas de arquivos como o bcachefs não podem se dar ao luxo de seguir as mesmas regras dos demais subsistemas. Quando tudo falha, são essas ferramentas de recuperação que podem significar a diferença entre continuar ou perder tudo.
A comunidade Linux deve refletir: até onde regras rígidas de desenvolvimento devem ir quando a confiança dos usuários e a integridade dos dados estão em jogo?
Para quem acompanha a evolução do Kernel Linux, essa é uma discussão que certamente ainda renderá ecos. E no SempreUpdate, você encontrará a análise completa, técnica e imparcial de cada um desses momentos cruciais.
