組み込みファイルシステムの選定

ファイルシステムが必要になる場面

フラッシュの先頭から構造体をベタ書きする方式は、データが1〜2種類であれば問題なく動作します。しかし、保存したいデータが増える、サイズが可変になる、書き込み中の電源断で設定が消える、といった問題が出始めると、アドレス管理表がどんどん属人化していきます。ファイル名で読み書きでき、領域管理と不整合対策をライブラリに任せられるのがファイルシステムの価値です。

組み込み特有の4つの要件

PCのファイルシステムと違い、組み込みでは次の4点を必ず評価します。

• 電源断耐性：書き込みの途中で電源断（＝突然の電源OFF）が起きても、ファイルシステム全体が壊れないこと。電源断を前提に設計されているかどうかが最初の分かれ道。
• フラッシュの物理制約：消去はブロック単位でしかできず、書き換え回数には寿命がある。同じブロックばかり書き換えない工夫（ウェアレベリング）が要るかどうか。
• RAM/ROMフットプリント：マイコンの限られたメモリに収まるか。ファイル数や容量の増加でRAM使用量が増えないか。
• 互換性：メディアを抜いてPCで読む運用があるか（SDカードならほぼ必須の要件）。

FatFs：PC互換が必要なら第一候補

FatFsは、ChaN氏が開発・公開している小規模組み込み向けの汎用FATファイルシステムモジュールです。SDカードやUSBメモリの標準フォーマットであるFATを扱えるため、「カードを抜いてPCで開く」運用がそのまま成立します。移植に必要なのはセクタ単位の読み書きなど数個の関数（diskioインタフェース）の実装だけで、構成オプションによりRAM使用量や機能を細かく調整できます。国内の主要な半導体メーカのミドルウェアとして採用された実績もあります。

※exFATを使う構成では、出荷先や製品条件によって権利者ライセンスの要否が変わり得ます。2019年に仕様が公開され状況は変わりつつありますが、商用利用時はFatFs公式のアプリケーションノートと最新の特許状況をあわせて確認してください。

注意点は電源断時の整合性です。これはFatFs固有の欠陥ではなくFAT方式の構造上の性質で、同期のタイミング、書き込み単位、キャッシュ、メディア側コントローラ、取り外しの運用によってリスクは増減します。FATという仕組み自体が、管理領域（FAT・ディレクトリエントリ）とデータを別々に更新する構造のため、更新の途中で電源断や不正取り外し（＝アンマウントしないまま抜去すること）が起きると、ファイルシステムが破損する可能性があることが公式アプリケーションノートにも明記されています。ログ用途などで使う場合は、書き込みのためにファイルを開いている時間を短くすること、f_sync() によるこまめな確定、書き込み中の電源保持（コンデンサや電源監視）、起動時の破損検出と再フォーマット戦略をセットで設計します。

littlefs：電源断前提の内蔵・NORフラッシュ向け

littlefsは、組み込み向けに設計されたオープンソースのファイルシステムで、「fail-safe（障害発生時にも安全な状態を維持する設計。この記事では主に電源断を想定）」を看板に掲げて設計されています。公式リポジトリでは次の特徴が示されています。

• 電源断耐性：メタデータの更新をアトミック（atomic、原子的）におこない、電源断からの復旧を前提に設計されている（copy-on-write・ログ構造）。運用としては、失ってよいデータの範囲に応じて同期（sync）のタイミングを設計する。
• 動的ウェアレベリング：ブロックの消去回数を分散させ、フラッシュの寿命を延ばす。不良ブロックの検出・回避にも対応。
• RAM使用量を上限固定（bounded）に設計：ストレージ容量や保存ファイル数に比例してRAM消費が増えにくい（※read/progキャッシュなどの設定値には依存する）。

RAM使用量はキャッシュなどの設定値で決まり、ストレージ容量や保存ファイル数に単純比例しにくい設計です。ただし、同時にオープンするファイル数に応じたRAMは必要です。内蔵フラッシュや基板直付けのSPI NORフラッシュに、設定値やログを安全に置く用途に最適です。オープンソースの組み込みPython実装（MicroPython）など、主要な組み込みプラットフォームでも採用されています。一方で、littlefsでフォーマットした領域はPCの標準機能では直接マウントして読めないため（※FUSEドライバなどの追加手段を使えばPC側から参照できる場合もあります）、データの取り出しにはイメージの吸い出しと専用ツール、または通信経由での取得が一般的です。

FatFsとlittlefsの比較表

選定フロー：迷ったらこう決める

• メディアを抜いてPCで読む？　SDカード／USBメモリを使う？　→　FatFsが有力（第一候補）。
• 内蔵フラッシュやSPI NORに設定・ログを置きたい、電源断がいつ起きるかわからない　→　littlefs。
• 両方の要件がある　→　併用する（例：SDカードはFatFs、内蔵フラッシュはlittlefs）。MicroPythonのドキュメントでも、PCから見せる領域はFAT、電源断に耐えたいデータはlittlefs、という同様の使い分けが示されています。

なお、NORフラッシュ向けの先行例としてSPIFFSというファイルシステムもあり、ファイルサイズや書き込みパターン（小さいファイルが多い、連続書き込みが中心、メタデータの更新頻度が高いなど）によってはlittlefsより高速な場合があるとlittlefs公式も言及していますが、新規設計ではエコシステムの広がりからlittlefsを軸に検討するのが現在の主流です。

導入後の運用設計で決めておくこと

• マウント失敗時の方針：自動で再フォーマットするか、エラー停止して保全するか。ログ用途なら自動再フォーマット、設定保存なら二重化＋手動復旧、のように用途で分ける。
• 書き込み頻度と寿命の見積もり：次の式でおおよその寿命（日数）を概算し、ウェアレベリングの有無を踏まえて余裕を確認する。

寿命（日数）＝（書き換え寿命（回数／ブロック）× ブロック数）÷ 1日あたりのブロック消去回数

• sync/closeのタイミング：電源断で失ってよいデータの範囲を決め、それに合わせて確定処理を入れる。
• 容量監視とローテーション：ログは上限サイズと世代数を決めて自動削除する。

まとめ

「PCで読むならFatFs、電源断に耐えるならlittlefs」が選定の軸です。どちらを選んでも、電源断・寿命・容量の3点は運用設計で必ず手当てしておく必要があります。ファイルシステムは導入して終わりではなく、壊れ方と直し方まで決めて初めて製品品質を担保できます。