FTRFS is a Linux kernel filesystem designed for dependable storage in radiation-intensive environments. It provides CRC32 integrity checks on metadata (superblock, inodes, Radiation Event Journal) and Reed-Solomon forward error correction on the on-disk allocation bitmap via the kernel's lib/reed_solomon library. The design targets embedded Linux systems on single-device storage (MRAM, NOR flash) where no external redundancy is available. The architectural target is universal RS FEC protection of all data blocks; the current implementation protects metadata and the on-disk allocation bitmap, with universal data block protection as the next major milestone (see Documentation/threat-model.md).

This implementation is an independent open-source realization of the design described in:

Fuchs, C.M., Langer, M., Trinitis, C. (2015). FTRFS: A Fault-Tolerant Radiation-Robust Filesystem for Space Use. ARCS 2015, Lecture Notes in Computer Science, vol 9017. Springer. DOI: https://doi.org/10.1007/978-3-319-16086-3_8 Full text: https://www.cfuchs.net/chris/publication-list/ARCS2015/FTRFS.pdf

The original design was developed at TU Munich (Institute for Astronautics) in the context of the MOVE-II CubeSat mission.

FTRFS does not compete with ext4 or btrfs for general-purpose use.

The problem it solves: on a single MRAM or NOR flash device in a radiation environment, a single-event upset (SEU) silently flips bits in data at rest. ext4 checksums detect this corruption but cannot correct it. There is no redundant copy to fall back to.

FTRFS integrates Reed-Solomon FEC at the filesystem block level. In the current implementation, RS FEC protects the on-disk allocation bitmap so that a corrupted bitmap is corrected in place at mount time without operator intervention. Extending the same mechanism to data blocks at writeback is the next step on the roadmap; today, data block corruption would be detected only when RS FEC writeback is enabled in a future release.

A secondary constraint is code auditability. Standards such as DO-178C (avionics), ECSS-E-ST-40C (space), and IEC 61508 (nuclear/industrial) require complete auditability of safety-critical software. ext4 (~100k lines) and btrfs (~200k lines) are not realistically certifiable under these frameworks. FTRFS is designed to stay under 5000 lines of auditable code.

FTRFS addresses two distinct families of failure that share a common technical signature — silent bit corruption in data at rest on a single read-write storage device — but differ in their causal origin and statistical distribution:

• Family A — benign single-event upsets (cosmic rays, MRAM/NOR retention loss, industrial radiation environments). Spatially uniform, Poisson-distributed.
• Family B — adversarial electromagnetic events (HPM, IEMI, EMP, RF weapons in conflict zones). Spatially correlated, burst distributed, may exceed per-block RS capacity without interleaving.

Both families require in-place correction on a read-write single device, fully in-kernel, without external redundancy — a combination not provided by any existing Linux or BSD storage component (ext4, btrfs, ZFS, dm-verity, dm-integrity, HAMMER2, UFS2).

The full failure model, gap analysis, deployment scenarios, and normative architectural constraints derived from this threat model are documented in Documentation/threat-model.md. That document is normative: subsequent design decisions are evaluated against the constraints it defines.

Out-of-tree module, actively maintained and validated on arm64 kernel 7.0. RFC v3 submitted to linux-fsdevel (April 2026), incorporating review feedback before v4 resubmission.

Block 0        superblock (magic 0x46545246, 4096 bytes, CRC32 verified)
Block 1..N     inode table (256 bytes/inode, configurable via mkfs -N)
Block N+1      bitmap block (RS FEC protected — 16 subblocks RS(255,239))
Block N+2      root directory data
Block N+3..end data blocks

Default: mkfs.ftrfs -N 256 → 16 inode table blocks, bitmap at block 17, data start at block 19.

File addressing:

• 12 direct blocks = 48 KiB
• 1 single indirect block = 512 × 4 KiB = 2 MiB
• Total per file: ~2 MiB (v1)

Zero BUG/WARN/Oops/inconsistency in dmesg across all tests.

Validated as a data partition in an arm64 Slurm 25.11.4 cluster built with Yocto Styhead (5.1), deployed on KVM/QEMU (cortex-a57, Linux 7.0.0). Cluster: 1 master + 3 compute nodes, each with FTRFS on /data.

End-to-end validation on a refactored deployment that closes the gap between the prior tmpfs-backed POC and a production-shaped configuration:

• Rootfs: read-only squashfs (hpc-arm64-research.bb, 52 MB) with overlayfs-etc for runtime config writes. Replaces the ext4 + dm-verity stack used in earlier runs.
• /data (FTRFS): real virtio block device /dev/vdb (64 MB), formatted with mkfs.ftrfs and mounted via mount -t ftrfs /dev/vdb /data. No more loopback file, no more losetup. The I/O path traversed by the bench is now the upstream-shape that the kernel.org submission will need to defend.
• Dirent fix: this is the first end-to-end run with the dirent slot reuse fix applied (see Documentation/testing.md section "Dirent Slot Reuse Bug"). M4 (stat bulk on 100 files) returns stable values for the first time, where pre-fix the directory scan terminated early on a zeroed dirent and stat could not reach all entries.

I/O metrics (3 compute nodes x 10 runs = 30 samples per metric):

Reference: yocto-hardened/Documentation/iobench-baseline-2026-04-26.md

The v3 superblock format with stage 3 item 2 (CRC32 + RS FEC superblock protection, kernel side) was validated end-to-end on the same cluster configuration. mkfs writes v3 with parity, kernel mounts v3 and exercises both the nominal CRC32 path and the RS recovery path under injected corruption.

Latency figures are below the 2026-04-21 reference run (0.26s / 0.35s / 5.41s) on single-node and 3-node metrics because those metrics are noise-dominated on this host (see context-tir-de-performance.md section 5). 9-job throughput is the statistically robust regression indicator on spartian-1; the 4.84s measurement is -16.1% relative to the loaded reference (5.77s, 2026-04-26 commit B), within the +/-20% regression band. The host workstation was concurrently running a syzkaller fuzzing campaign during the run.

Yocto layer: https://github.com/roastercode/yocto-hardened/tree/arm64-ftrfs

FTRFS uses the kernel's lib/reed_solomon library (encode_rs8, decode_rs8). No custom Galois Field arithmetic is implemented in the kernel module. The codec is initialized once at module load:

init_rs(8, 0x187, 0, 1, 16)
// GF(2^8), primitive polynomial 0x187
// fcr=0: roots alpha^0..alpha^15
// 16 parity bytes per 239-byte subblock
// Corrects up to 8 symbol errors per subblock

• Linux kernel 7.0 or later
• CONFIG_REED_SOLOMON=y (selected automatically by Kconfig)
• Tested: x86_64 (build), arm64/qemuarm64 (runtime)
• Yocto Styhead (5.1) for embedded integration

make KERNEL_SRC=/lib/modules/$(uname -r)/build
sudo insmod ftrfs.ko

source <yocto>/oe-init-build-env <build-dir>
bitbake ftrfs-module
bitbake mkfs-ftrfs

gcc -o mkfs.ftrfs mkfs.ftrfs.c
dd if=/dev/zero of=test.img bs=4096 count=16384
./mkfs.ftrfs -N 256 test.img
sudo insmod ftrfs.ko
sudo mount -t ftrfs test.img /mnt

Run tools/checkpatch-precommit.sh before committing — it runs checkpatch.pl --strict on staged C files and rejects the commit on any warning.

Submitted to linux-fsdevel@vger.kernel.org:

Reviewers who responded publicly: Matthew Wilcox, Pedro Falcato, Darrick J. Wong, Andreas Dilger, Eric Biggers, Gao Xiang.

Status: incorporating review feedback. Next submission (v4) planned after indirect block support (done), xfstests coverage, and Eric Biggers response.

Developed with Claude (Anthropic) as a coding assistant, per Documentation/process/coding-assistants.rst (Linux 7.0). The submitter takes full responsibility for all code and has reviewed, tested, and debugged every patch on real hardware.

Commit attribution: Assisted-by: Claude:claude-sonnet-4-6

FTRFS: Bringing Radiation-Robust Filesystem Principles to Contemporary Linux. A Reed--Solomon, MIL-STD-882E-Aligned Implementation (Technical Report -- Version 1)

• DOI (Zenodo): 10.5281/zenodo.19824442
• License: CC-BY 4.0
• Source: papers/2026-04-ftrfs-v1/ (LaTeX source, bibliography, dataset, build instructions)
• Anchor commit: 9a63468

This report is part of a versioned publication roadmap aligned with the project's engineering milestones. Subsequent versions (v2, v3, v4) will follow the tags v0.3.0-metadata-hardening, v0.4.0-universal-protection, and v0.5.0-security-reviewed respectively. Each new version is deposited under the same HAL idHAL (aurelien-desbrieres), preserving cumulative anteriority through HAL's native versioning. Each version will additionally be mirrored to Zenodo via a GitHub release tag, yielding a perennial DOI independent of the HAL platform.

See Documentation/roadmap.md (section "Publication roadmap") for the engineering-publication alignment table.

• Phoronix — FTRFS: New Fault-Tolerant File-System Proposed For Linux (2026-04-13): https://www.phoronix.com/news/FTRFS-Linux-File-System
• Phoronix — Linux 7.1 Staging (FTRFS mention): https://www.phoronix.com/news/Linux-7.1-Staging
• LWN.net — ftrfs: Fault-Tolerant Radiation-Robust Filesystem: https://lwn.net/Articles/1067452/
• daily.dev: https://app.daily.dev/posts/ftrfs-new-fault-tolerant-file-system-proposed-for-linux-m5rbha19y
• Reddit r/filesystems: https://www.reddit.com/r/filesystems/comments/1skjj18/
• Reddit r/phoronix_com: https://www.reddit.com/r/phoronix_com/comments/1skbg7q/
• X/Twitter @phoronix: https://x.com/phoronix/status/2043678672775754091
• X/Twitter @jreuben1: https://x.com/jreuben1/status/2043912800376889429
• Telegram Linuxgram (2026-04-13): https://t.me/s/linuxgram?before=18454
• YouTube — Genai Linux News: https://www.youtube.com/watch?v=EKA93IBcCvk

GNU General Public License v2.0 only.

Aurelien DESBRIERES <aurelien@hackers.camp>