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

Pedro Falcato
2026-04-13T15:04:13Z

On Mon, Apr 13, 2026 at 04:23:46PM +0200, Aurelien DESBRIERES wrote:
> From: Aurélien DESBRIERES <aurelien@hackers.camp>
>
> This RFC introduces FTRFS, a new Linux filesystem designed for dependable
> storage in radiation-intensive environments, targeting embedded Linux systems
> operating in space or other harsh conditions.
>
> FTRFS was originally described in:
>
> Fuchs, C.M., Langer, M., Trinitis, C. (2015).
> FTRFS: A Fault-Tolerant Radiation-Robust Filesystem for Space Use.
> ARCS 2015, LNCS vol 9017, Springer.
> https://doi.org/10.1007/978-3-319-16086-3_8
>
> This implementation is an independent open-source realization of the
> concepts described in that paper, developed for the Linux kernel.

Well, here's the obvious question: do you have a usecase for this?

>
> == Design ==
>
> FTRFS provides three layers of data integrity:
>
> - CRC32 per block and per inode (hardware-accelerated via crc32_le)
> - Reed-Solomon FEC (encoder implemented, decoder planned)
> - EDAC-compatible error tracking
>
> On-disk layout:
>
> Block 0 : superblock (magic 0x46545246, CRC32-protected)
> Block 1..N : inode table (128 bytes/inode, CRC32 per inode)
> Block N+1..end : data blocks (CRC32 + RS FEC per block)
>
> Inodes use direct addressing (12 direct block pointers) plus single
> and double indirection. Directory entries are fixed-size (268 bytes)
> stored in direct blocks.
>
> == Current Status ==

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?

>
> - Superblock: mount/umount, CRC32 validation [done]
> - Inodes: read with CRC32 verification [done]
> - Directories: readdir, lookup [done]
> - Files: read via generic page cache helpers [done]
> - Allocator: in-memory bitmap for blocks and inodes [done]
> - Write path: create, mkdir, unlink, rmdir, link [done]
> - Reed-Solomon: encoder done, decoder planned [partial]
> - xattrs / SELinux [planned]
> - fsck.ftrfs [planned]
> - Indirect block support for large files [planned]
>
> == Validation ==
>
> FTRFS has been validated on arm64 (cortex-a57) running Linux 7.0-rc7,
> built with Yocto Styhead (5.1), deployed as a data partition in a
> 3-node Slurm HPC cluster on KVM/QEMU:
>
> insmod ftrfs.ko -> module loaded
> mount -t ftrfs /dev/vdb /mnt -> success
> ls /mnt -> returns empty directory correctly

https://github.com/kdave/xfstests

>
> Compile-tested on x86_64 with Linux 7.0 (this series).
> checkpatch.pl: 0 errors on all patches.
>
> == Feedback Requested ==
>
> This is an RFC. Feedback is welcome on:
>
> 1. On-disk format: is the superblock/inode layout reasonable?

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.

--
Pedro