オンボードファイルシステム設計 — フラッシュメモリの上に「壊れないファイル」を実現する

この回で学ぶこと

マスメモリの回では、探査機が観測データを一時的に溜め込む記憶装置——フラッシュメモリを中心としたマスメモリ——を扱いました。そこで学んだのは、生成レートとダウンリンクレートのミスマッチをバッファ占有量の積分式で見積もる方法、放射線環境でビットが反転する中EDACとスクラビングでどう保護するか、そして容量が逼迫したときに科学的価値の高いデータをどう優先して残すか、という3つの視点でした。しかしそこでの議論は一貫して「ビット列」や「バイト列」というフラットな量を対象にしており、そのビット列が探査機の中でどう「ファイル」という単位に整理されているかには踏み込みませんでした。

一方、CFDPの回では、探査機と地上局の間で「ファイル」を1バイトも欠けることなく転送する仕組みを学びました。CFDPはファイルという単位を転送する側のプロトコルですが、そもそも探査機の中で「このファイルは何というファイルで、いつ作られ、どれくらい優先度が高いか」を管理し、CFDPに「これを送ってほしい」と渡す側の仕組みについては触れていませんでした。

この回で扱うのは、マスメモリという物理的な記憶媒体の上に構築される、オンボードファイルシステムという論理的な抽象化層です。地上のパソコンやサーバーで動いているファイルシステム(ext4やNTFSのようなジャーナリングファイルシステム)は、電源が安定して供給され続けるという前提のもとで設計されています。しかし探査機は、単一イベントラッチアップやウォッチドッグタイマーの発火、予期しないソフトウェア異常によって、書き込み処理の真っ最中に電源が落ちたりリセットがかかったりする環境で動作しなければなりません。この回では、(1) なぜ地上前提のファイルシステム設計がそのままでは通用しないのか、(2) フラッシュメモリの書き込み回数制限を前提にファイルをどう配置すべきか、(3) ファイル名・時刻・優先度といったメタデータをどう効率的かつ頑健に管理するか、という3つの問いを数式とともに整理し、最後にMars Exploration Roverの実際の異常事例や、CFDPが実はファイル管理操作の機能も持っていることを見ていきます。

直感的導入: 「ファイル」という抽象はどこから生まれるか

マスメモリの回でのフラッシュメモリは、あくまで「アドレスを指定すればビットが読み書きできる箱」でした。しかし実際の運用では、地上のオペレーターやフライトソフトウェアの各コンポーネントは「アドレス0x00A31F00から1024バイト読め」ではなく、「昨日撮影したナビゲーションカメラの画像ファイルを読め」と考えたいはずです。この「アドレスの集合」から「意味のあるひとまとまりの名前付きデータ」への変換を担うのが、ファイルシステムです。

地上のOSでファイルシステムを学んだことがある人は、ディレクトリ構造・inode・FAT(File Allocation Table)といった概念を思い浮かべるでしょう。これらの設計は基本的に共通した発想——「データの実体(ファイルの中身)」と「そのデータがどこにあるかを指し示す管理情報(メタデータ)」を分離して持つ——に基づいています。オンボードファイルシステムもこの基本構造自体は踏襲しますが、決定的に異なる制約が2つあります。

制約1: 電源はいつでも落ちうる。 地上のサーバーはUPS(無停電電源装置)に守られ、シャットダウンは通常「正常な手順」を踏んで行われます。ジャーナリングファイルシステムが前提とする「クラッシュからの復旧」は、多くの場合、シャットダウン処理自体は正常に完了していて、あとはログを再生するだけ、という比較的穏やかな状況を指します。ところが探査機では、放射線起因のラッチアップやプロセッサリセットが書き込み処理の途中の任意の瞬間に起こり得ます。したがって「復旧」の前提そのものが、地上のシステムより遥かに厳しいものになります。

制約2: 記憶媒体そのものに書き込み回数の上限がある。 マスメモリの回で見たように、NAND型フラッシュメモリは典型的に $10^4$〜$10^5$ 回程度の書き込み・消去でセルが劣化します。ファイルシステムの管理構造(ディレクトリエントリやFATに相当する部分)は、ファイルが作成・削除されるたびに更新される、いわば「最も書き込み頻度の高い場所」になりがちです。もしこの管理構造を毎回同じ物理アドレスに上書きしていたら、そこだけが真っ先に寿命を迎えてしまいます。

この2つの制約を同時に満たす設計思想として、宇宙機の組み込みソフトウェアでは**ログ構造化ファイルシステム(log-structured file system)**という考え方が広く採用されています。以下、まず制約1(電源断への頑健性)を定式化し、その解決策として自然に導かれる形でログ構造化の考え方を導入し、最後に制約2(書き込み回数)との相性を見ていきます。

電源断とファイルシステム整合性: 「いつ止まっても壊れない」という要件

原子性(atomicity)という不変条件

ファイルシステムに対する1回の論理的な操作——たとえば「新しいファイルを作成する」「既存ファイルの一部を書き換える」「ファイルを削除する」——は、実際には複数の物理的な書き込み操作の列として実行されます。ファイルの実データを書き込む操作に加え、そのファイルがどこにあるかを示すディレクトリエントリの更新、空き領域管理テーブルの更新など、1つの論理操作が複数バイト・複数ページにまたがる物理的な書き込みを要求することが普通です。

ここで求められる性質を**原子性(atomicity)**と呼びます。論理的な状態が $S_{old}$ から $S_{new}$ へ遷移する操作を考えるとき、その内部で行われる物理書き込みの列を $W_1, W_2, \dots, W_k$ とすると、原子性とは次の不変条件のことです。

$$\text{電源断が } W_i \text{ と } W_{i+1} \text{ の間のどの時点で起きても、再起動後にファイルシステムが復元する状態は } S_{old} \text{ か } S_{new} \text{ のいずれかでなければならない}$$

言い換えれば、$S_{old}$ と $S_{new}$ のどちらでもない中間的な、破損した状態($W_1$ から $W_j$ ($j<k$)までだけが反映された状態)が観測されることは、いかなる電源断のタイミングであっても許されません。地上のジャーナリングファイルシステムがこの性質を保証できるのは、「書き込みが中断されたら、次に正常起動したときにジャーナル(操作ログ)を読み直して未完了の操作をやり直すか巻き戻す」という復旧手続きが必ず最後まで実行されることを前提にできるからです。しかし探査機では、復旧処理の途中でさらにリセットがかかる可能性すら排除できません。したがって、オンボードファイルシステムは「復旧手続きに頼らずとも、フラッシュ上の物理状態そのものが常に解釈可能である」という、より強い性質を目指す必要があります。

インプレース更新がなぜ危険か

なぜインプレース(その場書き換え)更新がこの不変条件を破りやすいのかは、NAND型フラッシュメモリの物理的な性質からも説明できます。フラッシュメモリのプログラム(書き込み)操作は、ビットを $1 \to 0$ にすることしかできず、$0 \to 1$ に戻すには、ページよりずっと大きな消去ブロック単位でまとめて消去する必要があります(マスメモリの回のウェアレベリングの議論の前提です)。したがって、たとえばディレクトリエントリのような小さな管理構造を「更新」しようとすると、多くの実装では次のいずれかの手順を踏むことになります。

• 該当ページの一部ビットだけを $1\to0$ 方向に書き換える(元の値によっては不可能な変更もある)
• 該当ブロック全体を一度消去し、旧データと新データを合成したうえで書き戻す

後者の場合、消去によって旧データはすでに失われているのに、新データの書き込みがまだ完了していないという時間帯が必ず生じます。この時間帯に電源が落ちれば、$S_{old}$ でも $S_{new}$ でもない、文字通り「何も書かれていない、あるいは破損した」状態が残ってしまいます。ディレクトリエントリやFATのような管理構造がこの状態に陥ると、そのエントリが指していたファイルだけでなく、同じ管理テーブルを共有する他の多くのファイルの所在まで分からなくなりかねません。これが、地上のFATファイルシステムのような単純な設計を、そのまま探査機のフラッシュメモリに持ち込めない理由です。

ログ構造化ファイルシステム: 追記とガベージコレクション

「上書きしない」という設計原理

前節の問題を解決する自然な発想は、既存のデータを一切上書きせず、更新は常に新しい場所への追記(append)として行うことです。これがログ構造化ファイルシステムの基本原理です。ファイルの新しいバージョンを書き込むときも、ディレクトリエントリを更新するときも、フラッシュメモリ上のまだ使われていない領域に新しいレコードを追記し、そのレコードにはシーケンス番号とチェックサムを付与します。旧いバージョンのレコードは、上書きされるのではなく「無効(stale)」という論理的な状態になるだけで、物理的にはそのまま残り続けます。

この設計のもとでは、前節で定式化した原子性の不変条件が構造的に保証されます。新しいレコードの書き込みが完了する前に電源が落ちても、そのレコードはチェックサム検証で不合格となり、再起動時のスキャンで単純に無視されます。このとき読み出されるのは旧いレコード、すなわち $S_{old}$ です。書き込みが最後まで(チェックサムを含めて)完了していれば、そのレコードは正当な最新版として認識され、$S_{new}$ が復元されます。中間状態が観測されることは原理的にありません——なぜなら「新データの一部だけが反映された $S_{old}$」という状態自体が、旧データを一切破壊しない追記という操作の性質上、存在しえないからです。この意味で、ログ構造化アプローチは電源断安全性の要件を、複雑な復旧アルゴリズムに頼らず、書き込みモデルそのものの性質として満たします。

ガベージコレクションと書き込み増幅

しかし「上書きしない」という方針には代償があります。無効になった旧レコードが領域を占有し続けるため、有効な空き領域はいずれ枯渇します。そこで定期的に、無効なレコードが多く溜まった消去ブロックを選び、その中にまだ残っている有効なレコードだけを新しい場所に退避させたうえで、ブロック全体を消去して空き領域として再利用する処理——ガベージコレクション(garbage collection, GC)——が必要になります。

ここで生じるコストを定量化しましょう。GCの対象として選ばれる消去ブロックの有効データ利用率(まだ有効なレコードが占める割合)を $u$ とします。つまりそのブロックの $(1-u)$ の割合が、すでに無効化されたレコードで占められているということです。このブロックを再利用可能にするには、まず残っている有効データ($u$ の割合)を他の場所へコピーしなければなりません。この「$1$ 単位のブロックを解放するために $u$ 単位の追加書き込みが必要になる」という関係から、ホスト(上位のファイルシステム利用者)が実際に書き込みたい1単位のデータに対して、GCによる再配置分を含めた実際の物理書き込み量は

$$W_{phys} = \underbrace{1}_{\text{ホストの新規書き込み}} + \underbrace{\frac{u}{1-u}}_{\text{GCによる退避コピー}}$$

となります。この $W_{phys}$ を**書き込み増幅率(Write Amplification, WA)**と呼び、整理すると

$$WA = 1 + \frac{u}{1-u} = \frac{1}{1-u}$$

という簡潔な式で表せます。$u \to 0$(ブロックがほとんど無効データで占められてからGCする)であれば $WA \to 1$ に近づき理想的ですが、空き領域に余裕がないシステムでは頻繁に、利用率 $u$ が高いブロックからもGCを行わざるを得ず、$WA$ は大きくなります。

この $WA$ は、マスメモリの回で見たフラッシュセルの書き込み・消去回数上限 $N_{endurance}$(典型的に $10^4$〜$10^5$ 回)と直結します。ホストが書き込みたい論理データ量の総和を $D_{host}$ とすると、フラッシュチップが実際に消化する物理書き込み量は $WA \times D_{host}$ であり、ウェアレベリングによって全セルに均等に分散されると仮定すれば、寿命に到達するまでにホストが書き込める総データ量の目安は

$$D_{host,\,max} \;\approx\; \frac{C_{mem}\, N_{endurance}}{WA}$$

で与えられます($C_{mem}$ は総容量)。つまりGCの利用率しきい値 $u$ をどこに設定するかという設計判断が、そのままフラッシュメモリの実効寿命を左右します。これはマスメモリの回で導入したウェアレベリングの基本概念(特定セルへの書き込みの偏りを避ける)を前提としつつ、それとは別の軸——「そもそも同じ論理データを何回物理的に書き直すことになるか」——を定量化するものであり、ログ構造化設計を採用する上で避けて通れないトレードオフです。

メタデータ設計: ファイル名・時刻・優先度をどう管理するか

自己記述型ログレコード

ログ構造化ファイルシステムでは、フラッシュ上のあらゆるレコード(ファイルデータの断片、ディレクトリエントリの更新など)が、それ自身の意味を説明するヘッダを持つ「自己記述型」の形で書き込まれるのが一般的です。典型的なヘッダには次のような項目が含まれます。

• ファイル識別子: 可変長のファイル名そのものを毎レコードに含めるとオーバーヘッドが大きいため、多くの実装ではファイル作成時に固定長の内部ID(inode番号に相当)を割り当て、人間可読なファイル名との対応表は別途1か所にまとめて持ちます。
• 作成・更新時刻: CCSDS時刻コードの回で学んだCUC(CCSDS Unsegmented Time Code)形式のタイムスタンプを、固定長のフィールドとしてヘッダに埋め込みます。搭載クロックが素朴に吐き出すカウンタ値に近いCUCは、ヘッダに追加するオーバーヘッドが小さく、この用途に適しています。
• 優先度クラス: マスメモリの回で見たデータ優先順位付け(価値密度 $v_i/s_i$ による貪欲法や、循環バッファのクラス分け)と同じ優先度タグを、ファイル単位のメタデータとしても保持します。これにより、バッファ容量が逼迫した際に「どのファイルから削除・上書きしてよいか」をファイルシステム層だけで判断でき、上位のミッション運用ソフトウェアが個々のバイト列の中身まで立ち入る必要がなくなります。
• シーケンス番号とチェックサム: 前節で述べた通り、そのレコードが最新版かどうかの判定と、書き込み途中の破損検出に使われます。

メタデータの冗長化

ファイルの実データの一部が破損しても、失われるのはそのファイル1つの一部分に留まります。しかしディレクトリ構造やファイル識別子とファイル名の対応表のようなメタデータが破損すると、それが指し示していたすべてのファイルが行方不明になるという、被害が非対称に大きい障害につながります。このため実務のオンボードファイルシステムでは、マスメモリの回で扱ったEDAC(誤り訂正符号)による保護に加えて、メタデータ領域に限っては複数の消去ブロックにまたがる冗長コピーを持たせたり、より頻繁にスクラビングの対象としたりするなど、実データ領域よりも一段厚い保護をかけるのが一般的です。「ファイルという抽象を成立させている土台こそ、最も壊れてはならない部分である」という優先順位づけは、この回の設計思想全体を貫く考え方だと言えます。

起動時のリカバリ: チェックポイントとログスキャンのトレードオフ

前述の通り、ログ構造化ファイルシステムは原理的に「ログを先頭からスキャンし、各論理オブジェクトについて最も新しい有効なシーケンス番号を持つレコードを採用する」ことで、フラッシュ上の物理状態からいつでも論理的なファイル一覧(ディレクトリ構造)を再構築できます。しかし、ミッション期間全体にわたるログをリセットのたびに毎回先頭から全スキャンしていては、復旧に膨大な時間がかかってしまいます。

そこで実務では、定期的にその時点でのディレクトリ構造の全体像を1つのスナップショットとしてフラッシュに書き出すチェックポイントを導入します。再起動時の復旧は、直近のチェックポイントを読み込んだうえで、そのチェックポイント以降に追記されたログレコードだけを順にスキャンして反映する「ロールフォワード」で済むようになります。

チェックポイント間隔を $T_{ckpt}$、その間に平均的に追記される物理ログ量を $R_{log}$(バイト/秒)、ログのスキャン(読み出しと検証)速度を $R_{scan}$、チェックポイント自体の読み込みに要する固定時間を $T_{load}$ とすると、復旧に要する時間はおおよそ

$$T_{recover} \;\approx\; T_{load} \;+\; \frac{R_{log}\, T_{ckpt}}{R_{scan}}$$

と見積もれます。この式が示すのは明快なトレードオフです。$T_{ckpt}$ を短くすれば復旧時間 $T_{recover}$ は短縮されますが、チェックポイント自体の書き込み頻度が上がるため、そのぶんフラッシュへの書き込み量が増え、前節で見た書き込み増幅・寿命消費が悪化します。逆に $T_{ckpt}$ を長く取れば書き込み負荷は減りますが、万一の異常発生時に長い復旧時間を要するリスクを抱えます。

ミッション運用上、異常発生後の復旧時間には多くの場合上限 $T_{max}$(たとえば「次の通信パスまでに必ず復旧していること」といった運用要求)が課されます。この制約から、許容されるチェックポイント間隔の上限は

$$T_{ckpt} \;\leq\; \frac{(T_{max} - T_{load})\, R_{scan}}{R_{log}}$$

と求まります。設計者は、この上限ぎりぎりまで $T_{ckpt}$ を伸ばすことで、復旧時間の要求を満たしつつチェックポイント由来の書き込み負荷を最小化する、という最適化を行います。これはマスメモリの回で見たスクラビング間隔の設計(訂正不能確率と検査頻度のトレードオフ)と発想の骨格は似ていますが、対象としている量(復旧時間 vs. 訂正不能確率)も導かれる関係式もまったく別物であることに注意してください。

実務での使われ方

Mars Exploration Rover Spiritのフラッシュ異常(2004年)

オンボードファイルシステムの設計がなぜこれほど重要視されるのかを物語る実例が、2004年1月にNASA/JPLの火星探査車Spirit(Mars Exploration Rover)で発生した通信異常です。着陸後まもなく、Spiritは地上との正常なテレメトリ通信ができなくなり、繰り返しリセットを起こす状態に陥りました。原因を調査したJPLのチームは、巡航フェーズ中に生成・蓄積されたまま削除されずに残っていた大量の小さなファイルが、フライトソフトウェアがファイルシステムの管理構造をメモリ上に保持するための領域を圧迫し、システムが正常に起動処理を完了できなくなっていたことを突き止めました。地上のチームは、探査機を最小限の機能で起動するセーフモードを使って通信を回復させ、不要なファイルの削除とファイルシステムの再編成を行うことで運用を正常化させています。この事例は、ファイルシステムの管理構造(この回で扱ったメタデータやディレクトリ相当の情報)が、実データそのものと同じか、それ以上にミッションの成否を左右しうることを示す教訓として、その後の宇宙機フライトソフトウェア設計に大きな影響を与えました。

core Flight System (cFS) におけるファイル管理

CFDPの回で触れたNASA/JPLのフライトソフトウェア基盤core Flight System (cFS)には、CFDPを実装するCF (CFDP) アプリケーションに加えて、探査機上のファイルをコピー・移動・削除したりディレクトリを一覧したりするFM (File Manager) アプリケーションが標準コンポーネントとして用意されています。CF appが担うのは「ファイルを地上と探査機の間でどう転送するか」であり、FM appが担うのは「探査機上のファイルシステムをどう操作するか」という、まさにこの回で扱った論理層そのものの実務的な実装です。両者が組み合わさることで、地上のオペレーターはCFDPで新しいファイルをアップリンクし、続けてFM appへのコマンドで不要になった旧ファイルを削除する、といった一連の遠隔ファイル管理作業を行えます。

CFDPのFilestore Request: ファイル転送と一体化したファイル管理操作

CFDPの回ではファイルの転送そのものに焦点を当てましたが、CCSDS 727.0-Bで規定されるCFDPには、実はファイル転送に付随してリモートのファイルシステムに対する操作を指示する機能も含まれています。これがFilestore Requestです。Metadata PDUやEOF PDUのオプションフィールド(TLV: Type-Length-Value)として、CREATE FILE(ファイル作成)、DELETE FILE(削除)、RENAME FILE(改名)、REPLACE FILE(既存ファイルを新しいファイルで置き換え)、APPEND FILE(追記結合)、CREATE DIRECTORY / REMOVE DIRECTORY(ディレクトリ操作)といった操作要求を埋め込むことができ、受信側のCFDPエンティティはファイル転送が完了した段階でこれらの操作をローカルのファイルシステムに対して実行します。

これにより、たとえば「新しいフライトソフトウェアのバイナリファイルを転送し、転送完了後に自動的に旧バージョンのファイルを削除して新ファイルにリネームする」といった一連の手順を、1回のCFDPトランザクションの中で完結させられます。ここで重要なのは、この回で見たログ構造化・原子的コミットの設計があってはじめて、こうした「転送直後の自動的なファイル置き換え」を安全に行えるという点です。もしオンボードファイルシステムがインプレース更新しか提供できなければ、Filestore Requestによる置き換え処理の途中でリセットが起きた場合に、旧ファイルも新ファイルも失われた不整合な状態が残りかねません。CFDPが提供する高水準の遠隔ファイル管理機能は、その足元にあるオンボードファイルシステムの電源断安全性に、暗黙のうちに支えられているのです。

組み込み業界のログ構造化ファイルシステム

宇宙機に限らず、NAND型フラッシュを搭載する組み込み機器全般で、この回と同じ設計思想を持つファイルシステムが実用化されています。Linux組み込み環境で広く使われるJFFS2 (Journalling Flash File System 2)やYAFFS2 (Yet Another Flash File System 2)は、いずれもログ構造化の考え方に基づいてNANDフラッシュ向けに設計されています。またマイクロコントローラ向けには、ARM社が開発したlittlefsが、まさに「電源がいつ落ちても壊れない(power-loss resilient)」ことを設計目標に掲げ、コピーオンライトとチェックサム付きメタデータブロックによって本文と同様の原子性を実現しています。これらは民生・産業機器向けの実装ですが、根底にある問題意識と解法は、この回で見た探査機のオンボードファイルシステム設計と共通しています。

演習問題

1. あるオンボードファイルシステムが、ディレクトリエントリを16バイトの固定長構造体として管理しており、これが2つのフラッシュページ境界をまたいで配置されているとする。(a) このエントリをインプレース更新する設計で、最初の8バイトの書き込みが完了した直後に電源が落ちた場合、再起動後にこのエントリを読み出すとどのような問題が起こりうるか説明せよ。(b) 同じ更新を、シーケンス番号とチェックサム付きの新規レコードとして別の空き領域に追記するログ構造化設計で行った場合、同じタイミングで電源が落ちたら再起動後にどう振る舞うべきか、この回で述べた不変条件をもとに説明せよ。

2. あるフラッシュメモリの総容量が $C_{mem} = 16$ GB、セルの書き込み・消去回数上限が $N_{endurance} = 10^5$ 回であるとする。ガベージコレクションが消去ブロックの有効データ利用率 $u=0.75$ に達した時点で発動する設計の場合、書き込み増幅率 $WA$ を求めよ。また、ウェアレベリングによって全セルに均等に摩耗が分散されると仮定したとき、寿命に達するまでにホストが書き込める総データ量の目安 $D_{host,max}$ を求めよ。さらに、$u$ を $0.5$ まで下げた場合に $D_{host,max}$ がどう変化するか、GC発動の頻度とのトレードオフに触れながら論じよ。

3. あるオンボードファイルシステムの平均物理ログ書き込みレートが $R_{log} = 20$ kbps、ログのスキャン速度が $R_{scan} = 4$ Mbps、チェックポイントの読み込みに要する固定時間が $T_{load} = 1$ 秒であるとする。ミッション運用要求として、異常発生から次の通信パスまでに復旧を完了させる必要があり、その猶予時間が $T_{max} = 30$ 秒であるとき、許容されるチェックポイント間隔 $T_{ckpt}$ の上限を求めよ。

4. CFDPのFilestore Requestを使って、探査機上の旧フライトソフトウェアファイルを新バージョンで置き換える(REPLACE FILE)運用を考える。この置き換え処理が、この回で学んだログ構造化・原子的コミットの設計の上でどのように安全に実現されるか、電源断が転送完了直後・置き換え処理の途中のそれぞれのタイミングで起きた場合を想定して説明せよ。また、この処理を仮にインプレース更新のファイルシステムの上で行った場合にどのようなリスクが生じるか、Mars Exploration Rover Spiritの事例も踏まえて論じよ。

まとめと次回予告

この回では、マスメモリの回で学んだフラッシュメモリという物理的な記憶媒体の上に、実際に「ファイル」という論理的な単位を構築するオンボードファイルシステムの設計を扱いました。地上のファイルシステムが前提とする安定電源とは異なり、探査機は書き込みの途中でリセットが起こりうる環境にあるため、既存データを上書きせず常に新しい領域へ追記するログ構造化という設計原理が、電源断安全性(原子性)とフラッシュの書き込み回数制約(ウェアレベリングとの親和性)の両方を同時に満たす自然な解になることを見ました。また、ファイル名・時刻・優先度といったメタデータをどう自己記述的なレコードとして管理し、チェックポイントとログスキャンのトレードオフの中で起動時の復旧をどう設計するかも定式化しました。そしてCFDPの回で学んだファイル転送プロトコルが、実はこの回で見たオンボードファイルシステムの操作(作成・削除・置き換え)まで一体化させたFilestore Requestという機能を持っていることも確認しました。「送る」プロトコルと「保つ」ファイルシステムは、決して独立した層ではなく、互いの前提の上に成り立っていたのです。

次回は視点を変え、こうして積み上げてきた通信系全体——変調方式からプロトコル、そしてこの回のファイルシステムまで——を、実機を飛ばす前にどう検証するかという運用工学の話題に踏み込みます。実際のハードウェアの挙動をソフトウェア上に精密に再現する通信系デジタルツインを使った試験手法に軽く触れ、設計した仕組みが本当に狙い通り動くことを、どう地上で確かめるのかを見ていきます。

参考文献

• CCSDS 727.0-B, CCSDS File Delivery Protocol (CFDP)(Filestore Requestの規定を含む)
• M. Rosenblum, J. K. Ousterhout, “The Design and Implementation of a Log-Structured File System,” ACM Transactions on Computer Systems, 1992
• G. Reeves, T. Neilson, “The Mars Rover Spirit Flash Anomaly,” Proceedings of the IEEE Aerospace Conference, 2005
• NASA/JPL, core Flight System (cFS) File Manager (FM) and CFDP (CF) Application Documentation
• ARM Limited, littlefs: A Little Fail-Safe Filesystem Designed for Microcontrollers(設計ドキュメント)
• CCSDS 301.0-B, Time Code Formats
• J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76