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

[Andreas Dilger]

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.

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.

Cheers, Andreas