This is v3 of the FTRFS patch series. FTRFS is a Linux kernel filesystem
designed for dependable storage in radiation-intensive environments,
implementing Reed-Solomon FEC at the filesystem block level for in-place
correction of silent bit flips on single-device embedded systems (MRAM,
NOR flash) without external redundancy.

Based on: Fuchs, Langer, Trinitis - ARCS 2015, TU Munich / MOVE-II CubeSat.
Full text: https://www.cfuchs.net/chris/publication-list/ARCS2015/FTRFS.pdf

Changes since v2 (<20260413230601.525400-1-aurelien@hackers.camp>):

  - iomap IO path: replace buffer_head based read/write with iomap API
    as requested by Matthew Wilcox. Implements ftrfs_iomap_begin/end,
    iomap_writeback_ops (writeback_range/writeback_submit), and uses
    iomap_bio_read_ops for the read path. buffer_head is retained for
    metadata IO (inode table, directory blocks) as discussed.

  - rename: implement ftrfs_rename in namei.c. Handles same-dir and
    cross-dir rename for files and directories, updates '..' entries
    and nlink counts. RENAME_EXCHANGE and RENAME_WHITEOUT return
    -EINVAL (not supported in v3).

  - RS FEC decoder: implement full RS(255,239) decoder in edac.c using
    Berlekamp-Massey error locator polynomial, Chien search, and Forney
    algorithm for in-place correction. Corrects up to 8 symbol errors
    per 255-byte subblock. Returns -EBADMSG if uncorrectable.

  - Radiation Event Journal: persistent ring buffer of 64 x 24 bytes
    in the superblock reserved area. Records block number, timestamp
    (ns), symbols corrected, and per-entry CRC32 for each RS correction
    event. Written under spinlock via ftrfs_log_rs_event(). No existing
    Linux filesystem provides this filesystem-level radiation event
    history - VxWorks HRFS, btrfs scrub, and NVMe SMART all operate
    at different layers.

AI tooling disclosure (Documentation/process/coding-assistants.rst):
  Assisted-by: Claude:claude-sonnet-4-6
  The submitter takes full responsibility for all code, has reviewed,
  tested, and debugged every patch.

Testing:
  - qemuarm64, kernel 7.0 final (Yocto Styhead 5.1, cortex-a57 TCG)
  - mount, write, read, rename, umount: 0 BUG/WARN/Oops
  - xfstests generic/001, 002, 010 equivalent: all pass
  - Slurm 25.11.4 HPC cluster validation (3-node parallel jobs)
  - checkpatch.pl: 0 errors, 0 warnings on all modified files

HPC/space use case:
  FTRFS is validated in an arm64 Slurm cluster built with Yocto
  (github.com/roastercode/yocto-hardened, branch arm64-ftrfs).
  This demonstrates the filesystem operating in a real HPC embedded
  context, not just a test image - the target environment for
  space-grade embedded Linux systems.

Remaining work (v4):
  - kthread scrubber with RT priority and sysfs interface
  - Full xfstests Yocto recipe
  - iomap for metadata IO path (currently buffer_head)

Aurelien DESBRIERES (12):
  ftrfs: add on-disk format and in-memory data structures
  ftrfs: add superblock operations
  ftrfs: add inode operations
  ftrfs: add directory operations
  ftrfs: add file operations
  ftrfs: add block and inode allocator
  ftrfs: add filename and directory entry operations
  ftrfs: add CRC32 checksumming and Reed-Solomon FEC skeleton
  ftrfs: add Kconfig, Makefile and fs/ tree integration
  MAINTAINERS: add entry for FTRFS filesystem
  ftrfs: v2 fixes - write path, inode lifecycle, on-disk format
  ftrfs: v3 - iomap IO path, rename, RS decoder, Radiation Event Journal

 MAINTAINERS       |   6 +
 fs/ftrfs/Kconfig  |  49 +++++
 fs/ftrfs/Makefile |  46 ++++
 fs/ftrfs/alloc.c  | 251 +++++++++++++++++++++
 fs/ftrfs/dir.c    | 126 +++++++++++
 fs/ftrfs/edac.c   | 277 +++++++++++++++++++++++
 fs/ftrfs/file.c   | 197 +++++++++++++++++
 fs/ftrfs/ftrfs.h  | 201 +++++++++++++++++
 fs/ftrfs/inode.c  | 104 +++++++++
 fs/ftrfs/namei.c  | 548 ++++++++++++++++++++++++++++++++++++++++++++++
 fs/ftrfs/super.c  | 317 +++++++++++++++++++++++++++
 11 files changed, 2122 insertions(+)
 create mode 100644 fs/ftrfs/Kconfig
 create mode 100644 fs/ftrfs/Makefile
 create mode 100644 fs/ftrfs/alloc.c
 create mode 100644 fs/ftrfs/dir.c
 create mode 100644 fs/ftrfs/edac.c
 create mode 100644 fs/ftrfs/file.c
 create mode 100644 fs/ftrfs/ftrfs.h
 create mode 100644 fs/ftrfs/inode.c
 create mode 100644 fs/ftrfs/namei.c
 create mode 100644 fs/ftrfs/super.c

-- 
2.52.0

On Tue, Apr 14, 2026 at 02:07:13PM +0200, Aurelien DESBRIERES wrote:
> This is v3 of the FTRFS patch series. FTRFS is a Linux kernel filesystem
> designed for dependable storage in radiation-intensive environments,
> implementing Reed-Solomon FEC at the filesystem block level for in-place
> correction of silent bit flips on single-device embedded systems (MRAM,
> NOR flash) without external redundancy.
> 
> Based on: Fuchs, Langer, Trinitis - ARCS 2015, TU Munich / MOVE-II CubeSat.
> Full text: https://www.cfuchs.net/chris/publication-list/ARCS2015/FTRFS.pdf
> 
> Changes since v2 (<20260413230601.525400-1-aurelien@hackers.camp>):
> 
>   - iomap IO path: replace buffer_head based read/write with iomap API
>     as requested by Matthew Wilcox. Implements ftrfs_iomap_begin/end,
>     iomap_writeback_ops (writeback_range/writeback_submit), and uses
>     iomap_bio_read_ops for the read path. buffer_head is retained for
>     metadata IO (inode table, directory blocks) as discussed.
> 
>   - rename: implement ftrfs_rename in namei.c. Handles same-dir and
>     cross-dir rename for files and directories, updates '..' entries
>     and nlink counts. RENAME_EXCHANGE and RENAME_WHITEOUT return
>     -EINVAL (not supported in v3).
> 
>   - RS FEC decoder: implement full RS(255,239) decoder in edac.c using
>     Berlekamp-Massey error locator polynomial, Chien search, and Forney
>     algorithm for in-place correction. Corrects up to 8 symbol errors
>     per 255-byte subblock. Returns -EBADMSG if uncorrectable.
> 
>   - Radiation Event Journal: persistent ring buffer of 64 x 24 bytes
>     in the superblock reserved area. Records block number, timestamp
>     (ns), symbols corrected, and per-entry CRC32 for each RS correction
>     event. Written under spinlock via ftrfs_log_rs_event(). No existing
>     Linux filesystem provides this filesystem-level radiation event
>     history - VxWorks HRFS, btrfs scrub, and NVMe SMART all operate
>     at different layers.
> 
> AI tooling disclosure (Documentation/process/coding-assistants.rst):
>   Assisted-by: Claude:claude-sonnet-4-6
>   The submitter takes full responsibility for all code, has reviewed,
>   tested, and debugged every patch.

I was going to ask if you were on the world's strongest stimulant but, yeah,
this also makes sense.

3 versions in a day and no reply to review comments, no usecase, just vibes,
AI ones at that. This latest batch even got the LLM to hallucinate my old
email address.

Naturally,
Nacked-by: Pedro Falcato <pfalcato@suse.de>

Please pick this up to every patch if you get to send more slop versions.

-- 
Pedro

On Tue Apr 14, 2026 at 6:22 AM EDT, Pedro Falcato wrote:
> On Tue, Apr 14, 2026 at 02:07:13PM +0200, Aurelien DESBRIERES wrote:
>> 
>> Based on: Fuchs, Langer, Trinitis - ARCS 2015, TU Munich / MOVE-II CubeSat.
>> Full text: https://www.cfuchs.net/chris/publication-list/ARCS2015/FTRFS.pdf
>> 

>> AI tooling disclosure (Documentation/process/coding-assistants.rst):
>>   Assisted-by: Claude:claude-sonnet-4-6
>>   The submitter takes full responsibility for all code, has reviewed,
>>   tested, and debugged every patch.
>
> I was going to ask if you were on the world's strongest stimulant but, yeah,
> this also makes sense.
>
> 3 versions in a day and no reply to review comments, no usecase, just vibes,
> AI ones at that. This latest batch even got the LLM to hallucinate my old
> email address.
>
> Naturally,
> Nacked-by: Pedro Falcato <pfalcato@suse.de>
>
> Please pick this up to every patch if you get to send more slop versions.

I'm not enthusiastic about vibe coding either, so I understand why you
wanted to NACK the series. But I feel obligated to say that you
can't claim there is "no usecase" when in the cover letter, a paper was
provided, and you even quoted it in the reply.

-Josh

On Tue, Apr 14, 2026 at 07:05:30AM -0400, Joshua Peisach wrote:
> On Tue Apr 14, 2026 at 6:22 AM EDT, Pedro Falcato wrote:
> > On Tue, Apr 14, 2026 at 02:07:13PM +0200, Aurelien DESBRIERES wrote:
> > > 
> > > Based on: Fuchs, Langer, Trinitis - ARCS 2015, TU Munich / MOVE-II CubeSat.
> > > Full text: https://www.cfuchs.net/chris/publication-list/ARCS2015/FTRFS.pdf
> > > 
> 
> > > AI tooling disclosure (Documentation/process/coding-assistants.rst):
> > >   Assisted-by: Claude:claude-sonnet-4-6
> > >   The submitter takes full responsibility for all code, has reviewed,
> > >   tested, and debugged every patch.
> > 
> > I was going to ask if you were on the world's strongest stimulant but, yeah,
> > this also makes sense.
> > 
> > 3 versions in a day and no reply to review comments, no usecase, just vibes,
> > AI ones at that. This latest batch even got the LLM to hallucinate my old
> > email address.
> > 
> > Naturally,
> > Nacked-by: Pedro Falcato <pfalcato@suse.de>
> > 
> > Please pick this up to every patch if you get to send more slop versions.
> 
> I'm not enthusiastic about vibe coding either, so I understand why you
> wanted to NACK the series. But I feel obligated to say that you
> can't claim there is "no usecase" when in the cover letter, a paper was
> provided, and you even quoted it in the reply.

Yes, a paper is provided. However, when I asked for a usecase I really did mean:
"is anyone going to actually use this?". Which is a very non-trivial question to
answer, particularly when it comes to "space stuff" (how commonly is linux even
used for those?).

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, known to work
well for a variety of users"
- "Yes, we are using it"

IMO it's not sufficient to say this _could_ be used in space, or was used
by the paper authors. And instead of a straight up answer, there was radio
silence.

-- 
Pedro

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@hackers.camp>