Re: [RFC PATCH 0/10] ftrfs: Fault-Tolerant Radiation-Robust Filesystem

[Aurelien DESBRIERES]

On Mon, Apr 13, 2026 at 12:03:10PM -0600, Andreas Dilger wrote:
> Modern ext4 has metadata checksums for many years, and fsverity can
> be used to add Merkle-tree checksums for file data. Data redundancy
> can be handled by the block layer.

ext4 checksums and fsverity both detect corruption. Neither corrects
it. On a single MRAM or NOR flash device in a nanosatellite, there is
no block layer redundancy available. Detection without correction means
data loss.

RS FEC integrated at the filesystem block level corrects up to 8 symbol
errors per 255-byte subblock in place, on a single device, without
external redundancy. That is the specific gap that FTRFS addresses and
that no existing Linux filesystem provides.

> If code size/complexity is a significant issue for new embedded
> satellite controllers, then implementing "read-only" support for ext4
> could be fairly straight forward development.

Read-only ext4 does not solve the write path requirement. The target
systems require read-write access to MRAM during mission operations
(telemetry, payload data). A read-only filesystem is not sufficient.

> You also have to consider that filesystems are critical components of
> any computer, and having bugs in newly-developed filesystem code could
> be as fatal to the satellite as the radiation. The general rule of
> thumb is that filesystems take about 10 years to mature.

Acknowledged. This is precisely why the design targets under 5000
lines of auditable code, why the on-disk format is deliberately
simple (ext2-reminiscent), and why DO-178C / ECSS-E-ST-40C
certification is an explicit design constraint. A smaller, auditable
codebase reduces the bug surface. The maturity concern is real and
will be addressed through progressive validation - the Yocto arm64
HPC cluster (Slurm 25.11.4, kernel 7.0) is the first step.

Aurelien DESBRIERES <aurelien@xxxxxxxxxxxx>