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

[Gao Xiang <hsiangkao@linux.alibaba.com>]

On 2026/4/14 02:03, Andreas Dilger wrote:
> On Apr 13, 2026, at 09:04, Pedro Falcato <pfalcato@suse.de> wrote:
>>
>> 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.
>>>
>>>
>>> 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
> 
> 
> 
> 
>