Re: [PATCH v3 00/12] ftrfs: Fault-Tolerant Radiation-Robust Filesystem

[Aurelien DESBRIERES]

On Tue, Apr 14, 2026 at 12:28:33PM +0100, Pedro Falcato wrote:
> Yes, a paper is provided. However, when I asked for a usecase I
> really did mean: "is anyone going to actually use this?".
>
> Good answers (IMHO):
> - "Yes, we have a couple of planned users for this"
> - "Yes, this has been maintained out-of-tree for X months/years"
> - "Yes, we are using it"

Fair. Let me give a more concrete answer.

The implementation is currently maintained out-of-tree and validated
in an arm64 HPC cluster running Slurm 25.11.4 on Yocto Styhead 5.1,
kernel 7.0. This is an active, working deployment, not a paper
prototype:
https://github.com/roastercode/yocto-hardened/tree/arm64-ftrfs

For planned users, the target environments where Linux is actively
used and where radiation-induced SEU is a documented operational
concern include:

- Embedded Linux on nanosatellites and CubeSats. The MOVE-II mission
  at TU Munich is the direct origin of the FTRFS design. Commercial
  CubeSat operators increasingly use Linux-capable SoCs (i.MX, Zynq)
  precisely because of the ecosystem, and SEU rates on MRAM in LEO
  are well-documented.

- Robotics in high-radiation environments. Industrial robots deployed
  in nuclear facilities (decommissioning, inspection) and planetary
  rovers operate in radiation environments where silent bit flips are
  a real operational risk. Linux is the dominant OS in these systems.

- Space HPC. There is growing interest in deploying HPC workloads
  in orbit for Earth observation and AI inference at the edge.
  European space industry players (including Thales Alenia Space,
  a known Linux embedded user) are actively exploring this. A
  radiation-tolerant filesystem is a missing piece of that stack.

None of these are signed contracts I can point to today. This is an
RFC, not a production submission. The question for the community is
whether the technical problem is real and the approach sound — both
of which are independent of whether I have a purchase order in hand.

The radio silence you mention was a process failure on my part.
Replies to v1 review comments should have come before v2, not after
v3. That is corrected now.

Aurelien DESBRIERES <aurelien@xxxxxxxxxxxx>