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

[Aurelien DESBRIERES]

On Mon, Apr 13, 2026 at 03:04:11PM +0000, Pedro Falcato wrote:
> Well, here's the obvious question: do you have a usecase for this?

The target is embedded Linux systems in radiation-intensive environments
where single-event upsets (SEU) cause silent bit flips in data at rest.
Specifically: nanosatellites using MRAM or NOR flash as primary storage,
with no block layer redundancy (no RAID, no mirroring, single device).

The concrete use case is derived from the MOVE-II CubeSat mission at
TU Munich (Fuchs, Langer, Trinitis — ARCS 2015). The paper documents
measured SEU rates on commercial MRAM in LEO and shows that RS FEC at
the filesystem level is the only mechanism that can recover corrupted
data in place on a single-device system without external redundancy.

The implementation is validated in a real arm64 HPC cluster (Slurm
25.11.4, Yocto Styhead 5.1, kernel 7.0) as a proof of concept for
space-grade embedded Linux deployments:
https://github.com/roastercode/yocto-hardened/tree/arm64-ftrfs

> Well, as far as I can see, there's no write path, no read path (no
> address_space_operations as far as I can see), no rename. Did you
> test this?

v1 was an RFC skeleton. These were addressed in subsequent versions:
- v2: address_space_operations, write path, inode lifecycle fixes
- v3: iomap IO path (replacing buffer_head, per Matthew Wilcox),
  rename, RS FEC decoder, Radiation Event Journal
- v3: xfstests generic/001, 002, 010 equivalent validated on
  qemuarm64 kernel 7.0

> The layout itself is super unix-filesystem/ext2 reminiscent, so if
> something like this is really needed, I would strongly recommend you
> perhaps add this there. One feature (crc32c checksums over several
> metadata structures) already exists on ext4.

ext4 checksums detect corruption but do not correct it. fsverity
detects tampering on read-only data but does not correct it. Neither
provides in-place RS FEC correction on a single-device system.

The certification constraint is also a hard requirement for the target
environment: DO-178C (avionics), ECSS-E-ST-40C (space), and IEC 61508
(nuclear/industrial) require complete code auditability. ext4 at ~100k
lines cannot realistically be certified under these frameworks.
FTRFS targets under 5000 lines of auditable code.

Aurelien DESBRIERES <aurelien@xxxxxxxxxxxx>