Linux 7.4 remove o BFS, sistema de arquivos de boot do UnixWare

O kernel Linux vai apagar seu driver do sistema de arquivos BFS na versão 7.4. Ethan Nelson-Moore enviou o patch de remoção para a lista de discussão do kernel em 4 de setembro de 2026, e o mantenedor Christian Brauner já o colocou na fila. É o terceiro sistema de arquivos antigo que o kernel abandona em duas versões.

BFS aqui é o sistema de arquivos de boot que o SCO UnixWare usava na sua partição de inicialização. O UnixWare é um Unix comercial, e o Linux carregava o driver para conseguir ler um disco desses. O patch de Nelson-Moore argumenta que há "very little reason anyone would want to access it from Linux".

O que o patch faz de verdade

O patch mexe em 20 arquivos. Ele apaga 6 e altera 14, retirando 1.275 linhas e acrescentando 4. Os arquivos apagados são a documentação, a entrada do Kconfig, o Makefile, os cabeçalhos e o próprio driver.

Um arquivo sobrevive. O patch mantém include/uapi/linux/bfs_fs.h, o cabeçalho que descreve o formato em disco para programas do espaço de usuário. Remover um driver e remover seu cabeçalho público são decisões separadas, e o kernel trata a segunda como quebra da sua promessa de interface.

O motivo declarado é que quase ninguém pode estar usando. "BFS is the filesystem UnixWare uses for its boot partition. It has extremely limited functionality, only supporting contiguous files and no subdirectories", escreveu Nelson-Moore no patch. O envio acrescenta que "bfs is highly unlikely to have any users, so remove it".

Esses dois limites merecem uma pausa. Um arquivo contíguo precisa caber em uma sequência ininterrupta de blocos no disco. Não ter subdiretórios significa que todo arquivo vive em uma única lista plana. Isso basta para guardar um kernel e um carregador de boot, e para pouco mais.

Parte de uma faxina maior

O BFS não é o primeiro a sair. EFS e FreeVxFS foram removidos no Linux 7.3, o ciclo imediatamente anterior. O Phoronix relata que as remoções seguem novas orientações do kernel, feitas para reduzir o peso de manter na árvore sistemas de arquivos raramente usados.

A revisão foi rápida. Brauner respondeu ao patch com "I agree" e o aplicou. Ele escreveu que foi para "the vfs-7.4.bfs branch of the vfs/vfs.git tree", e que "patches in the vfs-7.4.bfs branch should appear in linux-next soon". Lorenzo Stoakes, Jan Kara, Tigran Aivazian e Darrick J. Wong participaram do tópico, e nenhuma das respostas visíveis se opôs à remoção.

O que isso significa para desenvolvedores

Confira sua tabela de montagem se você mantém ferramentas de perícia ou de migração. Uma ferramenta que lê discos antigos do UnixWare montando-os vai parar de funcionar assim que sua distribuição entregar um kernel 7.4. Planeje um leitor em espaço de usuário, ou uma cópia do último kernel que ainda traz o driver.

Não leia o cabeçalho sobrevivente como um indulto. O bfs_fs.h fica porque interfaces para o espaço de usuário não são removidas de qualquer jeito, não porque o driver vá voltar. Se o seu código inclui esse cabeçalho e depois chama mount, só metade continuará funcionando.

Olhe qual sistema de arquivos vem a seguir, em vez de lamentar este. Três remoções em dois ciclos formam um padrão, e o critério anunciado é o custo de manutenção diante de usuários reais. Se você depende de algo obscuro na árvore, o movimento útil é dizer isso agora na lista de discussão. O tópico do BFS mostra como um desses vai rápido de patch a fila quando ninguém objeta.

Há aqui uma lição para quem leva um driver para o upstream. Um driver sem usuários visíveis é um custo de manutenção sem eleitorado, e o kernel começou a cobrar por isso. O jeito de manter vivo um driver de nicho é deixar provas de que ele é usado: relatos de bug, resultados de teste e um mantenedor que responde e-mail. O trabalho no kernel neste ciclo está cheio do caso oposto, como o Zen 6 da AMD tornando desnecessária uma mitigação existente, em que é o fabricante do hardware que carrega o código.