Linux

宇宙向けFS「FTRFS」10年越しにLinuxへ提案

2015年の学術論文で構想された耐放射線ファイルシステムが、10年の時を経てLinuxカーネル本家に投下された。しかも書いたのは論文の著者ではない。まったくの別人だ。

情報の灯台

2026年4月14日

10年前の論文が、今ごろカーネルに届いた

Linuxカーネルメーリングリスト（LKML）に2026年4月13日、FTRFSという聞き慣れない名前のファイルシステムのRFCパッチが投下された。Fault-Tolerant Radiation-Robust Filesystem、日本語にすれば「耐障害性・耐放射線ファイルシステム」。投稿者はAurélien DESBRIERESという開発者で、所属はkernel.orgのアーカイブを見る限り個人ドメインのhackers.campだ。

紛らわしいので最初に書いておくと、名前はBtrfsに似ているが両者は無関係だ。Btrfsは汎用の高機能ファイルシステムで、FTRFSは極めてニッチな「壊れにくさ」専用の設計である。Phoronixも記事冒頭でわざわざ混同しないよう注意を促している。

ここで面白いのは、この名前がまったくの新作ではないという点だ。FTRFSはもともとChristian M. Fuchs、Martin Langer、Carsten Trinitisの3名が、ポルトガルのポルトで開催された2015年のARCSカンファレンスで発表した論文で提案された設計である。ARCSはコンピュータアーキテクチャ分野の国際会議で、毎年欧州を中心に開かれている。宇宙空間、とくにナノサテライトのような小型衛星のオンボードコンピュータ向けに、放射線によるビット反転からシステムソフトウェアを守る仕組みとして構想された。

今回の提案はその論文の概念を第三者が独立実装したものであり、それをカーネル本家に送りつけてきた、という構図になる。パッチ本文にも「この実装は、当該論文に記述された概念の独立したオープンソース実装である」と明記されている。論文から10年。普通なら誰も覚えていない話だ。

なぜ「耐放射線」ファイルシステムが必要なのか

宇宙空間では、地上で無視できるほど稀な現象が日常的に起きる。そのひとつがSEU（Single Event Upset）と呼ばれる一時的ビット反転で、高エネルギー粒子が半導体のメモリセルに飛び込むと、0が1に、1が0に化ける。地上のサーバーでECCメモリが稀に拾っているのと同じ現象だが、軌道上では頻度が桁違いに上がる。とくに南大西洋異常帯を通過する低軌道衛星は、浴びる放射線量が跳ね上がることで知られている。

ここで問題になるのが、OSのコアファイルや設定ファイルが置かれるストレージだ。ビットが反転すればカーネルイメージが壊れ、次の再起動で立ち上がらなくなる。衛星には修理に行けない。

FTRFSの設計思想は、ハードウェアに頼らず、ファイルシステム層そのものでデータの整合性を守ることにある。高価な放射線耐性チップを使わずとも、民生品のフラッシュや不揮発メモリで衛星を組めるようにする。それが2015年論文の狙いだった。

この思想を引き継ぐ形で、今回の実装もデータとメタデータの両方に保護をかける設計になっている。

3層の「守り」で壊れたビットを拾う

パッチシリーズの説明によれば、FTRFSは3段階のデータ整合性保護を提供する。第一層はブロック単位およびinode単位のCRC32チェックサムで、x86系プロセッサのcrc32_le命令によるハードウェアアクセラレーションを利用する。第二層はリード・ソロモン符号によるFEC（前方誤り訂正）で、エンコーダはすでに実装済み、デコーダは設計中だ。第三層はEDAC互換のエラー追跡機能となる。

オンディスクレイアウトも独特で、スーパーブロックにはマジックナンバー0x46545246が埋め込まれ、それ自体がCRC32で保護される。inodeテーブルは1エントリ128バイト固定でCRCが付き、データブロックにはブロックごとのCRC32に加えて末尾にリード・ソロモン符号が格納される。

小さなファイルと大きなファイルの両方に対応するため、inodeは直接アドレッシング（12個の直接ブロックポインタ）と二重間接参照を選択的に使う。ディレクトリエントリは268バイトの固定長で、直接ブロック内にまとめて格納される。可変長を避けた判断は、破損時の復旧しやすさを優先した結果だと読める。

現状動くのは、スーパーブロックのマウント・アンマウントとCRC32検証、ディレクトリ読み出し、ファイル読み出し、inode作成・削除、書き込み、そしてリード・ソロモンのエンコーダまで。まだ手が付いていないのがデコーダ、fsck.ftrfs、xattr／SELinux、大容量ファイル向けの間接ブロック対応だ。

RFC段階として見れば、読める・書ける・CRCで検証できるところまでは動くが、肝心の「壊れたデータを実際に復元する」部分はこれから、という状態だ。

HPCクラスタで動かしてみた、という不思議な検証環境

パッチ本文に書かれた検証環境も目を引く。開発者はLinux 7.0-rc7上で、arm64のCortex-A57を使い、Yocto Styhead 5.1でビルドした環境で動作確認をしたという。しかもその環境は3ノードのSlurm HPCクラスタのデータパーティションだと明記されている。

衛星のオンボードコンピュータ向けの設計が、地上のHPCクラスタで試されている。宇宙と高性能計算という、本来は交わらない2つの世界が1つのファイルシステムの上で交差している。放射線環境を模擬したわけでもなく、おそらく「たまたま手元にあった環境で回した」のだろうと思う。

x86_64上でもLinux 7.0でコンパイルテストは通っており、checkpatch.plもエラーなし。RFC投稿としては行儀の良いパッチに仕上がっている。コードはGitHubのroastercode/FTRFSでも公開されている。

カーネルに入るのか、という現実的な問い

ここからが本当の問題だ。FTRFSのような特殊用途ファイルシステムが、本家Linuxツリーに取り込まれる見込みはどれほどあるのか。

Linuxカーネルには、すでに一般用途向けだけで相当数のファイルシステムが同居している。Btrfs、XFS、ext4、F2FS、Bcachefs。いずれも「できるだけ多くのユーザーに使ってもらう」ことを前提にメンテナンス体制が組まれている。一方でFTRFSのターゲットは、小型衛星のルートファイルシステムや放射線環境下の産業機器といった極めて限定的な領域だ。メンテナが継続的に現れる保証はない。

ただしPhoronixは記事で、低軌道上のスーパーコンピュートやデータセンターへの関心が高まっている点に触れ、FTRFSには面白い出番があるかもしれないと書いている。これまでニッチだったものが、気づけばニッチでなくなる——宇宙空間を舞台にした計算資源の競争は、そういう変化を起こす力を持っている。

スレッド一覧を見ると、すでにファイルシステム界隈の重鎮Darrick J. Wong、Matthew Wilcox、Pedro Falcatoといった名前が反応している。中身までは踏み込めないが、RFC段階でこの顔ぶれがスレッドに入ること自体は悪い兆候ではない。もっとも、受け入れの可否と技術的な面白さはまったく別の話だ。

確かなのは、10年前の論文を拾い上げ、独立実装を仕上げ、本家への提案まで持ち込んだ人間がいるという事実のほうだ。取り込まれるかどうかは、これから議論されていく。

宇宙向けの設計が、地上のカーネルツリーにどこまで食い込めるか。答えはまだ誰も持っていない。

参照元