MAINTAINERS | 6 + fs/Kconfig | 1 + fs/Makefile | 1 + fs/ftrfs/Kconfig | 49 +++ fs/ftrfs/Makefile | 16 + fs/ftrfs/alloc.c | 251 +++++++++++++++ fs/ftrfs/dir.c | 132 ++++++++ fs/ftrfs/edac.c | 84 +++++ fs/ftrfs/file.c | 25 ++ fs/ftrfs/ftrfs.h | 168 ++++++++++ fs/ftrfs/inode.c | 103 +++++++ fs/ftrfs/namei.c | 428 +++++++++++++++++++++++++++ fs/ftrfs/super.c | 274 ++++++++++++++++ 13 files changed, 1538 insertions(+)
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. == 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 == - 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 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? 2. Directory entry design: fixed 268-byte entries vs. variable length 3. Reed-Solomon: use lib/reed_solomon or keep custom GF(2^8) tables? 4. Allocator: in-memory bitmap vs. dedicated on-disk bitmap block 5. Any VFS API misuse or missing locking The code is also available at: https://github.com/roastercode/FTRFS Aurélien DESBRIERES (10): ftrfs: add on-disk format and in-memory data structures ftrfs: add superblock operations ftrfs: add inode operations ftrfs: add directory operations ftrfs: add file operations ftrfs: add block and inode allocator ftrfs: add filename and directory entry operations ftrfs: add CRC32 checksumming and Reed-Solomon FEC skeleton ftrfs: add Kconfig, Makefile and fs/ tree integration MAINTAINERS: add entry for FTRFS filesystem MAINTAINERS | 6 + fs/Kconfig | 1 + fs/Makefile | 1 + fs/ftrfs/Kconfig | 49 +++ fs/ftrfs/Makefile | 16 + fs/ftrfs/alloc.c | 251 +++++++++++++++ fs/ftrfs/dir.c | 132 ++++++++ fs/ftrfs/edac.c | 84 +++++ fs/ftrfs/file.c | 25 ++ fs/ftrfs/ftrfs.h | 168 ++++++++++ fs/ftrfs/inode.c | 103 +++++++ fs/ftrfs/namei.c | 428 +++++++++++++++++++++++++++ fs/ftrfs/super.c | 274 ++++++++++++++++ 13 files changed, 1538 insertions(+) Signed-off-by: Aurélien DESBRIERES <aurelien@hackers.camp>
On Mon, Apr 13, 2026 at 04:23:46PM +0200, Aurelien DESBRIERES wrote: > 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 Might be nice to link to a non-paywalled copy of that paper, eg: https://www.cfuchs.net/chris/publication-list/ARCS2015/FTRFS.pdf > This implementation is an independent open-source realization of the > concepts described in that paper, developed for the Linux kernel. Can I ask why? Is the original code not available or too ugly? > 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. This is very old-school. That may be appropriate for the intended use-case, but it ignores about five decades of filesystem research.
On Mon, Apr 13, 2026 at 04:06:07PM +0100, Matthew Wilcox wrote: > Might be nice to link to a non-paywalled copy of that paper, eg: > https://www.cfuchs.net/chris/publication-list/ARCS2015/FTRFS.pdf Done in v2 and v3 cover letters. > Can I ask why? Is the original code not available or too ugly? The original FTRFS from the ARCS 2015 paper was a research prototype targeting a custom RTOS (not Linux). There is no upstream Linux implementation. This series is an independent open-source realization of the published design for the mainline Linux kernel. > This is very old-school. That may be appropriate for the intended > use-case, but it ignores about five decades of filesystem research. Intentional. The design constraints are auditability (DO-178C, ECSS-E-ST-40C, IEC 61508) and minimal code size (target < 5000 lines). Five decades of filesystem research produced ext4 (~100k lines) and btrfs (~200k lines), neither of which is certifiable under these frameworks. The old-school approach is a feature, not a limitation. The iomap IO path was adopted in v3 as you requested, replacing the buffer_head based read/write. buffer_head is retained for metadata IO (inode table, directory blocks) pending further review. Aurelien DESBRIERES <aurelien@hackers.camp>
On Mon, Apr 13, 2026 at 04:06:07PM +0100, Matthew Wilcox wrote: > On Mon, Apr 13, 2026 at 04:23:46PM +0200, Aurelien DESBRIERES wrote: > > 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 > > Might be nice to link to a non-paywalled copy of that paper, eg: > > https://www.cfuchs.net/chris/publication-list/ARCS2015/FTRFS.pdf > > > This implementation is an independent open-source realization of the > > concepts described in that paper, developed for the Linux kernel. > > Can I ask why? Is the original code not available or too ugly? > > > 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. > > This is very old-school. That may be appropriate for the intended > use-case, but it ignores about five decades of filesystem research. Why not add FEC to btrfs instead? Then you can concentrate on getting the IO paths correct, instead of burning time on ensuring that you've implemented all the other posix filesystemisms correctly. --D
On Mon, Apr 13, 2026 at 11:11:56AM -0700, Darrick J. Wong wrote: > Why not add FEC to btrfs instead? Then you can concentrate on getting > the IO paths correct, instead of burning time on ensuring that you've > implemented all the other posix filesystemisms correctly. Adding FEC to btrfs would produce a filesystem that cannot be certified under DO-178C, ECSS-E-ST-40C, or IEC 61508. btrfs at ~200k lines is not auditable under these frameworks regardless of what features are added or removed. The certification constraint is a hard requirement for the target environment (space, avionics, nuclear/industrial). It is not a preference. A smaller, purpose-built filesystem with RS FEC as a first-class design constraint is the only viable path to certification. btrfs also carries significant complexity in its COW B-tree allocator, extent maps, and RAID layer that would need to be analyzed and certified alongside the FEC addition. The audit surface would be orders of magnitude larger than a dedicated implementation. That said, the IO path concern is valid. v3 addresses this by migrating the data IO path to iomap as you and Matthew Wilcox requested. buffer_head is retained only for metadata IO (inode table, directory blocks) pending further review. Aurelien DESBRIERES <aurelien@hackers.camp>
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
On Mon, Apr 13, 2026 at 03:04:11PM +0000, Pedro Falcato wrote: > Well, here's the obvious question: do you have a usecase for this? The target is embedded Linux systems in radiation-intensive environments where single-event upsets (SEU) cause silent bit flips in data at rest. Specifically: nanosatellites using MRAM or NOR flash as primary storage, with no block layer redundancy (no RAID, no mirroring, single device). The concrete use case is derived from the MOVE-II CubeSat mission at TU Munich (Fuchs, Langer, Trinitis — ARCS 2015). The paper documents measured SEU rates on commercial MRAM in LEO and shows that RS FEC at the filesystem level is the only mechanism that can recover corrupted data in place on a single-device system without external redundancy. The implementation is validated in a real arm64 HPC cluster (Slurm 25.11.4, Yocto Styhead 5.1, kernel 7.0) as a proof of concept for space-grade embedded Linux deployments: https://github.com/roastercode/yocto-hardened/tree/arm64-ftrfs > 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? v1 was an RFC skeleton. These were addressed in subsequent versions: - v2: address_space_operations, write path, inode lifecycle fixes - v3: iomap IO path (replacing buffer_head, per Matthew Wilcox), rename, RS FEC decoder, Radiation Event Journal - v3: xfstests generic/001, 002, 010 equivalent validated on qemuarm64 kernel 7.0 > 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. ext4 checksums detect corruption but do not correct it. fsverity detects tampering on read-only data but does not correct it. Neither provides in-place RS FEC correction on a single-device system. The certification constraint is also a hard requirement for the target environment: DO-178C (avionics), ECSS-E-ST-40C (space), and IEC 61508 (nuclear/industrial) require complete code auditability. ext4 at ~100k lines cannot realistically be certified under these frameworks. FTRFS targets under 5000 lines of auditable code. Aurelien DESBRIERES <aurelien@hackers.camp>
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. 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
On Mon, Apr 13, 2026 at 12:03:10PM -0600, Andreas Dilger wrote: > 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. ext4 checksums and fsverity both detect corruption. Neither corrects it. On a single MRAM or NOR flash device in a nanosatellite, there is no block layer redundancy available. Detection without correction means data loss. RS FEC integrated at the filesystem block level corrects up to 8 symbol errors per 255-byte subblock in place, on a single device, without external redundancy. That is the specific gap that FTRFS addresses and that no existing Linux filesystem provides. > 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. Read-only ext4 does not solve the write path requirement. The target systems require read-write access to MRAM during mission operations (telemetry, payload data). A read-only filesystem is not sufficient. > 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. Acknowledged. This is precisely why the design targets under 5000 lines of auditable code, why the on-disk format is deliberately simple (ext2-reminiscent), and why DO-178C / ECSS-E-ST-40C certification is an explicit design constraint. A smaller, auditable codebase reduces the bug surface. The maturity concern is real and will be addressed through progressive validation - the Yocto arm64 HPC cluster (Slurm 25.11.4, kernel 7.0) is the first step. Aurelien DESBRIERES <aurelien@hackers.camp>
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 > > > > >
© 2016 - 2026 Red Hat, Inc.