O BeamFS é um sistema de arquivos Linux protegido por Reed-Solomon que corrige bytes corrompidos no local, em um único dispositivo, sem cópia secundária para reparo.
Uma nova proposta de sistema de arquivos para o kernel Linux busca resolver um problema que afeta satélites, salas de radioterapia e qualquer hardware exposto a partículas energéticas: a corrupção silenciosa de dados.
O BeamFS chega como uma evolução do FTRFS e aposta em correção Reed-Solomon diretamente nos blocos, sem depender de cópias redundantes.
O que é o BeamFS e por que ele importa
O BeamFS é um sistema de arquivos de dispositivo de bloco que corrige bytes corrompidos no local, em um único dispositivo de armazenamento, sem uma segunda cópia para reparo.
Cada bloco de dados é uma cápsula de dezesseis codewords RS(255,239) intercalados, construída sobre a biblioteca lib/reed_solomon do próprio kernel Linux.
Toda leitura decodifica o bloco; se o decodificador não puder atestá-lo, a leitura falha com -EIO em vez de retornar bytes errados.
Além dos blocos de dados, os blocos de diretório, inodes, o bitmap de alocação e o superbloco também carregam paridade Reed-Solomon, e os blocos indiretos têm uma região de paridade própria. No layout padrão, 288 bytes de cada 4096 (7%) são de overhead.
O BeamFS descende do FTRFS (Fault-Tolerant Radiation-Robust Filesystem), proposto como o RFC em abril de 2026. As limitações do FTRFS estavam no design — modelo de ameaça, local da correção, escala e integração com o kernel —, por isso o BeamFS é um sistema de arquivos novo, com formato on-disk próprio e uma nova thread de discussão.
Para quem o BeamFS foi projetado
O alvo são sistemas que mantêm seus dados em um único dispositivo de armazenamento em ambiente de radiação, onde não há espaço para uma segunda cópia.
A física por trás disso é medida, não suposta: erros suaves em silício comercial são um fato documentado; o mecanismo — uma partícula depositando carga em um nó de circuito — é modelado; nêutrons atmosféricos sozinhos perturbam aviônicos em altitude; e o próprio meio não está isento, com o flash NAND tendo modos e taxas de erro próprios.
Entre o meio físico e o page cache, uma leitura atravessa um controlador, um barramento, buffers de DMA e caches — qualquer um deles pode inverter um bit. O espaço foi onde tudo começou: o FTRFS foi projetado para computadores de bordo de satélites.
A medicina tem o mesmo problema no solo: uma sala de radioterapia é um campo de nêutrons, e feixes de fótons acima de 10 MV liberam nêutrons do cabeçote do acelerador, enquanto feixes de prótons ou íons produzem nêutrons secundários.
A evolução em relação ao FTRFS
O FTRFS introduziu três camadas de integridade de dados: CRC32 por bloco e por inode, Reed-Solomon FEC e o Rastreamento de Erros Compatível com o EDAC. No entanto, a implementação inicial tinha o decodificador Reed-Solomon apenas planejado, e não concluído.
O BeamFS incorpora o feedback recebido na proposta original e delega a decodificação RS em nível de kernel à lib/reed_solomon já existente na árvore do kernel — o BeamFS não traz seu próprio decodificador.
Além disso, o BeamFS segue as diretrizes de revisão do kernel Linux que emergiram da thread do FTRFS na lista linux-fsdevel. Essas diretrizes foram formalizadas em 2026, após propostas como FTRFS e VMUFAT, para estabelecer critérios mais claros para a aceitação de novos sistemas de arquivos no kernel.
Como o BeamFS se posiciona no ecossistema Linux
O kernel Linux já conta com a infraestrutura lib/reed_solomon, que implementa a decodificação em dois estágios: primeiro calcula a síndrome sobre os dados recebidos e, em seguida, realiza a correção de erros propriamente dita. O BeamFS se apoia nessa base madura em vez de reinventar a roda.
A proposta do BeamFS é interessante porque a correção acontece na camada de bloco, não na camada de consistência de metadados via journaling ou COW.
O modelo de ameaça é o single-event upset (SEU) induzido por radiação — uma inversão de bit causada pela incidência de partículas —, e a correção Reed-Solomon atua diretamente sobre os bytes corrompidos.
Para quem acompanha o desenvolvimento do kernel, o BeamFS representa um esforço de integrar a tolerância a falhas físicas diretamente no sistema de arquivos, algo particularmente relevante diante do crescente interesse em data centers em órbita baixa e computação espacial.
FAQ
1. Qual é a principal diferença entre o BeamFS e o FTRFS?
2. O que acontece quando o decodificador Reed-Solomon não consegue atestar um bloco no BeamFS?
A leitura falha com -EIO em vez de retornar bytes errados, garantindo que dados corrompidos não sejam entregues ao usuário.
3. Qual é o overhead de armazenamento do BeamFS no layout padrão?
288 bytes de cada 4096 bytes (7%) são de overhead de paridade Reed-Solomon.
Checklist
Checklist para acompanhar a proposta do BeamFS.
□ Ler a série RFC completa na lista linux-fsdevel ou no LWN.
□ Verificar a documentação em Documentation/filesystems/beamfs.rst
□ Acompanhar as discussões sobre o formato on-disk e a integração com o VFS.
□ Comparar o design do BeamFS com o do FTRFS original.
□ Monitorar as diretrizes de novos sistemas de arquivos do kernel.
□ Testar a série de patches em ambiente controlado, se possível.
Conclusão
O BeamFS é um sistema de arquivos Linux protegido por Reed-Solomon que corrige bytes corrompidos no local, em um único dispositivo, sem cópia secundária de reparo.
Projetado para ambientes de radiação, como satélites e salas de radioterapia, ele usa cápsulas de 16 codewords RS(255,239) por bloco de dados e falha leituras irrecuperáveis com -EIO em vez de entregar dados errados.
Nenhum comentário:
Postar um comentário