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

[Pedro Falcato]

On Mon, Apr 13, 2026 at 04:23:46PM +0200, Aurelien DESBRIERES wrote:
> From: Aurélien DESBRIERES <aurelien@xxxxxxxxxxxx>
> 
> 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