Re: [RFC PATCH 0/10] ftrfs: Fault-Tolerant Radiation-Robust Filesystem
From: Gao Xiang
Date: Mon Apr 13 2026 - 22:56:48 EST
On 2026/4/14 02:03, Andreas Dilger wrote:
On Apr 13, 2026, at 09:04, Pedro Falcato <pfalcato@xxxxxxx> wrote:
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.
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.
This was my first question as well. If this was some existing filesystem
that was widely used in satellites or something, it might make sense to
add support for that format (though a FUSE plugin might be better if the
performance is not critical). But it doesn't necessarily make sense to
implement a greenfield filesystem that doesn't extend the boundaries over
existing filesystems very far.
Modern ext4 has metadata checksums for many years, and fsverity can be used
to add Merkle-tree checksums for file data. Data redundancy can be handled
by the block layer.
If code size/complexity is a significant issue for new embedded satellite
controllers, then implementing "read-only" support for ext4 could be fairly
straight forward development to put large chunks of the code under a CONFIG
option.
According to the patchset, they need read-write support, but
I think the ext2 codebase is more suitable for embedded use
(if they don't need journalling) and to isolate unneeded
features.
However, I don't think an RO Kconfig option is useful for
isolating filesystem complexity concerns, unless the ondisk
layout and related runtime codepath can be separated by
design rather than gathering random RO pieces together:
because in that way, the new RO Kconfig option can only
make the testing and new development worse.
You also have to consider that filesystems are critical components of any
computer, and having bugs in newly-developed filesystem code could be as
fatal to the satellite as the radiation. The general rule of thumb is that
filesystems take about 10 years to mature.
Just a wild guess, I'm not sure if it's part of the AI work
(because it seems even there is no page cache for mmap()):
with new AI tools like Claude, it's pretty easy for everyone
to "write" and publish something now and in the future.
Thanks,
Gao Xiang
Cheers, Andreas