Usuários do BCacheFS no openSUSE Tumbleweed podem ter uma surpresa desagradável em breve: a equipe do kernel da distribuição decidiu desabilitar o BCacheFS a partir do Kernel 6.17. O motivo oficial é pragmático e segue uma política de manutenção conhecida: desde que Linus Torvalds marcou o BCacheFS como “externally maintained” (mantido externamente) no arquivo MAINTAINERS, a distro não pretende carregar o fardo de backports e correções para um código que não está mais sendo integrado ao kernel principal. Em outras palavras, se o upstream não integra, o openSUSE não mantém — simples assim. Segundo o anúncio, quem ficar em 6.16 não será afetado; o ramo Slowroll também segue intacto “por enquanto”.
Essa virada acontece num contexto já turbulento: depois de meses de atritos, o BCacheFS deixou de receber mudanças no kernel principal, permanecendo apenas “em árvore” para não quebrar instalações existentes — mas sem novas features e com o sinal claro de que a porta está fechada no curto prazo. Para o openSUSE, a consequência prática é uma só: reduzir risco operacional. Para o usuário final, porém, o impacto pode ser bem concreto — atualizar para o 6.17 e, de repente, não conseguir mais montar aquele volume BCacheFS.
o criador do BCacheFS pede um adiamento
Do outro lado, Kent Overstreet — o desenvolvedor por trás do BCacheFS — publicou um apelo público: “podem segurar por um ciclo?” A proposta: dar tempo para o projeto oferecer o BCacheFS como módulo fora da árvore via DKMS, evitando “tirar o tapete” de quem já está em produção. Overstreet afirma que a base em 6.16 está “muito sólida” e que as correções recentes são majoritariamente de performance e de casos de teste, não de falhas críticas que afetem usuários no dia a dia — ou seja, um período de carência não colocaria ninguém em risco. O plano de DKMS não nasceu agora: ele já vinha sendo discutido publicamente desde junho, como uma rota viável para atravessar a tempestade até retomar o curso upstream.
Há, contudo, um detalhe importante na “logística de kernel” do openSUSE: embora DKMS exista e funcione, ele não é o mecanismo preferencial da distribuição para garantir módulos após cada atualização de kernel. O caminho “nativo” costuma ser empacotar módulos como KMP (Kernel Module Packages), que se integram à infraestrutura do openSUSE/OBS e lidam melhor com atualizações frequentes do kernel — algo essencial num rolling release como o Tumbleweed. Em tese, nada impede que a comunidade ofereça um KMP para o BCacheFS enquanto o módulo fora da árvore amadurece. Na prática, isso exige alguém para construir, assinar, testar e manter o pacote em sincronia com cada kernel novo.
o que está realmente em jogo para o usuário
É aqui que a conversa sai do “processo de manutenção” e encosta na sua máquina. Se você roda openSUSE e usa BCacheFS, a atualização para o Kernel 6.17 pode significar perder o driver no kernel da distro — e ninguém quer descobrir isso numa manhã de trabalho, com o prompt reclamando que o volume não sobe. A recomendação pragmática é pensar como um administrador cuidadoso faria:
— Precisa mesmo do 6.17 agora? Então planeje um caminho com DKMS ou KMP antes de atualizar.
— Pode segurar em 6.16 por mais um ciclo? Isso reduz o risco enquanto a nova forma de distribuição do BCacheFS se consolida.
A tensão aqui não é só técnica: ela expõe dois instintos legítimos que, às vezes, se chocam. De um lado, o instinto de uma distribuição em proteger a estabilidade do conjunto — se o upstream parou, a distro não quer virar mantenedora “acidental”. De outro, o instinto de um desenvolvedor em proteger os usuários que já confiaram no seu sistema de arquivos — pedindo tempo para entregar uma alternativa que não quebre fluxos de trabalho. Quem está certo? Em um ecossistema do tamanho do Linux, a resposta costuma ser: depende do seu ponto de vista. O que dá para afirmar é que decisões assim moldam a adoção: tornar o BCacheFS dependente de módulos fora da árvore (seja DKMS, seja KMP) eleva a barreira de uso no openSUSE, especialmente para quem não tem familiaridade com empacotamento, Secure Boot e re/builds automáticos de módulo — e isso pode “frear” o entusiasmo de parte da comunidade.
No curto prazo, o recado é claro: o “openSUSE BCacheFS” deixa de ser plug-and-play no Kernel 6.17. No médio, o desfecho dependerá de duas frentes andarem: a do upstream (para que o código volte a ser integrado normalmente) e a do empacotamento (para que a experiência do usuário não azede no caminho). Até lá, vale aquela máxima de sysadmin: sem plano de rollback, não há update.
