This Newly Proposed Linux Filesystem Can Fix Corrupted Data

The kernel's filesystem mailing list has received an 18-patch proposal this week from Aurelien Desbrieres, the creator of BeamFS. It takes the place of FTRFS, an earlier filesystem he had proposed back in April.

Aurelien says he used Anthropic's Claude to write the code, the tool that checks the patches, and the cover letter.

He also points out that every patch carries an Assisted-by tag. You might remember that is the disclosure the kernel's AI coding assistants policy asks for. The same policy keeps the human submitter responsible for the code.

How does it fix data?

Filesystems that can repair damage, like Btrfs and ZFS, usually do it by falling back on a spare copy of the data. BeamFS skips that and stores Reed-Solomon error-correcting codes inside every block.

Every read gets checked against those codes, and small amounts of damage are corrected before the data reaches the application. If the filesystem can tell the damage is beyond repair, the read fails with an error instead of returning the wrong bytes.

The idea started with satellite computers. They keep data on a single drive and cannot fit a second copy. The same case is made for radiotherapy rooms.

Neutrons from treatment machines can flip bits in the computers there, including the ones handling imaging and records. Aurelien argues a silently wrong byte does more damage in that setting than a failed read.

BeamFS has not been tested in a real radiation environment yet. The tests done so far simulated the damage by flipping single bits in data as it was read on virtual machines and USB flash drives.

In his technical report, ext4 and ext3 returned wrong data without any error, while Btrfs refused to read the file. BeamFS returned the correct file every time except once, when a flip hit a pointer to the file’s data and it refused the read.

Do keep in mind that the comparison is uneven. Each filesystem received a different number of flips, and the report makes it clear that it is not a ranking.

Is it close to landing?

Nope, this is a request for comments (RFC). Aurelien is asking for feedback, not calling for a merge, and he has two questions for the maintainers.

The first is whether it should be a separate filesystem or be proposed for an existing one.

The second is the journal, the log other filesystems use to recover from crashes. BeamFS lacks one and relies on its fsck tool after an unclean shutdown. Aurelien asks whether it has to come before further review or can be submitted afterward.

So far, the only reply in the thread is about where the MAINTAINERS entry sits alphabetically.

The project's README has a warning of its own. It lists bugs that can lose data, open security holes, and crash the kernel, advising against trusting the code with anything important.

from It's FOSS https://ift.tt/H3sqBYT
via IFTTT