Executive Summary

I read the 18-patch RFC from Aurelien Desbrieres, BeamFS's creator, which replaces his earlier filesystem proposal (FTRFS) that he submitted last April to the Linux kernel filesystem mailing list. What immediately caught my attention: he states outright that the code, patch-checking tool, and cover letter were written with help from Claude, and every patch carries an Assisted-by tag per the kernel's AI policy — even though responsibility for the code still rests with the human submitter.

The Problem It Solves

Self-healing filesystems like Btrfs and ZFS usually rely on a backup copy of the data to repair corruption. The problem, according to Aurelien, is that there are scenarios where keeping a second copy isn't an option — for example, a satellite computer that only has a single drive, or a computer in a radiotherapy room whose data (including imaging and medical records) can suffer bit-flips from the therapy machine's neutron radiation. In contexts like this, a byte that's wrong but "looks normal" is actually more dangerous than a read that fails outright, because bad data can slip through undetected.

Key Features and Code Example

Rather than full redundancy, BeamFS stores Reed-Solomon error-correction codes inside every data block. On every read, the data is re-checked against that code: minor damage gets corrected before it reaches the application, while damage too severe causes the read to fail with an error (instead of returning wrong data). In Aurelien's technical report, he simulated bit-flips on data read from a VM and a USB flash drive: ext4 and ext3 silently returned wrong data, Btrfs refused to read the file, while BeamFS managed to return the correct file in almost every case — except once, when the bit-flip hit a pointer to the file data, causing BeamFS to likewise refuse the read. He himself cautions this isn't a fair benchmark, since the number of flips per filesystem varied and it wasn't meant as a ranking.

Since this RFC doesn't yet have a documented public API or command, here's a rough illustration (not from the source) of what the workflow should look like once it's usable:

# Ilustrasi, bukan contoh resmi dari proyek
mkfs.beamfs /dev/sdb1
mount -t beamfs /dev/sdb1 /mnt/data

# BeamFS belum punya journal, jadi fsck wajib dijalankan
# setelah unclean shutdown sebelum filesystem dipakai lagi
fsck.beamfs /dev/sdb1

Impact and Upgrade Notes

This is still an RFC, not a merge request — Aurelien himself posed two questions to the maintainers: whether BeamFS should be its own standalone filesystem or whether this feature should be proposed for an existing filesystem, and about the journal. BeamFS doesn't have a journal yet (a log for recovery after a crash) and currently only relies on fsck after an unclean shutdown — he's asking whether the journal needs to exist before review can continue, or whether it can follow later. So far the thread has gotten only one reply, and even that was about the alphabetical ordering of the MAINTAINERS entry, not anything technical. The project's README itself already warns: there are bugs that can cause data loss, security holes, and even kernel crashes — so it's not yet fit for anything important. For me, this is worth keeping an eye on because its approach differs from existing self-healing filesystems, but there's nothing that needs upgrading or adopting right now.

---

First announced on It's FOSS News. Read the original source for full details.

Read also