Linux Kernel Receives Proposal for Error-Correcting Filesystem BeamFS

The Linux kernel's filesystem mailing list received a submission this week consisting of 18 patches from Aurelien Desbrieres, who created BeamFS. The proposal supersedes FTRFS, a filesystem Desbrieres had put forward in April. According to Desbrieres, Anthropic's Claude assisted in generating the code, the validation tool, and the accompanying cover letter. Each patch includes an Assisted-by tag, which aligns with the kernel's disclosure requirements for AI-assisted coding contributions while maintaining the human submitter's responsibility for the submitted work.

How does it fix data?

Traditional repair-capable filesystems like Btrfs and ZFS rely on maintaining duplicate copies of data to recover from corruption. BeamFS takes a different approach by embedding Reed-Solomon error-correcting codes within each data block. During file reads, the system validates data against these codes and automatically corrects minor corruption before passing information to applications. When damage exceeds what the codes can repair, the filesystem returns an error rather than delivering corrupted information.

The concept originated from satellite systems, which store data on single drives without space for redundant copies. Medical radiotherapy facilities present a similar use case. Neutron radiation from treatment equipment can cause bit flips in computer systems managing imaging and patient records. Desbrieres contends that silently corrupted data poses greater risk in medical settings than a failed read operation.

BeamFS has not undergone testing in an actual radiation environment. Current testing simulated bit corruption by deliberately flipping individual bits during reads on virtual machines and USB flash drives. In Desbrieres's technical report, ext4 and ext3 returned corrupted data without signaling errors, while Btrfs refused to read the affected file. BeamFS successfully returned correct data in all but one instance, when a bit flip affected a file pointer, causing the filesystem to reject the read. The comparison involves different numbers of bit flips per filesystem and does not constitute a formal ranking.

Is it close to landing?

The submission functions as a request for comments (RFC) rather than a merge request. Desbrieres is soliciting feedback from maintainers on two specific questions. First, whether BeamFS should exist as an independent filesystem or be integrated into an existing one. Second, regarding the journal mechanism that other filesystems employ to recover from crashes. BeamFS currently lacks a journal and instead depends on its fsck tool following unclean shutdowns. Desbrieres is asking whether implementing a journal must occur before further review or can be addressed in subsequent submissions.

Discussion on the mailing list has been minimal so far, with the only response addressing the alphabetical placement of a MAINTAINERS entry. The project's README file includes its own caution, documenting known bugs that could result in data loss, introduce security vulnerabilities, and trigger kernel crashes. The documentation recommends against using the code with data that requires protection.