ＪＦＦＳ２

ジャーナリングフラッシュファイルシステムバージョン2またはJFFS2は、フラッシュメモリデバイスで使用するためのログ構造化ファイルシステムです。 ^[1]これはJFFSの後継です。JFFS2は、2001年9月23日にカーネルバージョン2.4.10リリースの一部としてLinuxカーネルメインラインに統合されて以来、Linuxカーネルに組み込まれています。JFFS2は、 Das U-Boot、Open Firmware、eCos RTOS、RTEMS RTOS、RedBootなどのいくつかのブートローダでも利用できます。JFFS2の最も顕著な使用法は、 OpenWrtです。^[2]

JFFS2 の代替として、少なくとも 3 つのファイル システムが開発されています: LogFS、UBIFS、YAFFS。

JFFS2 が導入されました:

• NAND フラッシュデバイスのサポート。NAND デバイスにはシーケンシャル I/O インターフェイスがあり、読み取り用にメモリ マップできないため、これにはかなりの作業が必要でした。
• ハード リンク。これは、ディスク上の形式の制限により、JFFS では不可能でした。
• 圧縮。zlib、rubin、lzma、rtime、lzoの 5 つのアルゴリズムが利用可能です。
• パフォーマンスが向上しました。JFFS はディスクを純粋な循環ログとして扱いました。これにより、大量の不要な I/O が発生しました。JFFS2のガベージ コレクション アルゴリズムにより、これがほとんど不要になりました。

JFFS と同様に、ファイルとディレクトリへの変更はノードのフラッシュに「記録」されます。ノードには次の 2 つのタイプがあります。

• inodes : ファイル メタデータを含むヘッダーと、それに続くファイル データのペイロード (存在する場合)。圧縮されたペイロードは 1 ページに制限されます。
• direntノード: それぞれ名前と inode 番号を保持するディレクトリ エントリ。ハード リンクは、同じ inode 番号を持つ異なる名前として表されます。特別な inode 番号 0 は、リンク解除を表します。

JFFS と同様に、ノードは作成された時点では有効な状態となり、他の場所で新しいバージョンが作成されると 廃止されます。

ただし、JFFSとは異なり、循環ログはありません。代わりに、JFFS2は、フラッシュメディアの消去セグメントと同じサイズの単位であるブロックを扱います。ブロックは、下から上に向かってノードで1つずつ埋められます。クリーンブロックは、有効なノードのみを含むブロックです。ダーティブロックには、少なくとも1つの古いノードが含まれます。フリーブロックにはノードが含まれません。^[3]

ガベージコレクターはバックグラウンドで実行され、ダーティブロックをフリーブロックに変換します。これは、有効なノードを新しいブロックにコピーし、古いノードをスキップすることで行われます。それが完了すると、ダーティブロックが消去され、フリーブロックであることを示す特別なマーカーでタグ付けされます（消去操作中に電源が失われた場合の混乱を防ぐため）。^[3]

ウェアレベリングをより均等にし、消去が主に静的なファイルシステムに集中するのを防ぐために、ガベージコレクターは時々クリーンなブロックも消費します。^[3]

JFFS2はログ構造設計のため、次のような欠点がある。^[3]

• マウント時にすべてのノードをスキャンする必要があります。これは時間がかかり、フラッシュ デバイスがテラバイトの範囲に拡大するにつれて、ますます深刻な問題になりつつあります。この問題を克服するために、 Linux カーネルのバージョン 2.6.15 でErase Block Summary (EBS) が導入されました。EBS は各ブロックの最後に配置され、ブロックへの書き込みごとに更新され、ブロックの内容を要約します。マウント中は、ブロック全体をスキャンするのではなく、EBS が読み取られます。
• 多数の小さなデータ ブロックを書き込むと、圧縮率が低下する可能性もあるため、アプリケーションでは大きな書き込みバッファーを使用することが不可欠です。
• デバイスにどれだけの使用可能な空き領域が残っているかを知る実用的な方法はありません。これは、追加データをどれだけ圧縮できるかと書き込みシーケンスの両方に依存するためです。

• JFFS2ウェブサイト
• JFFS: ジャーナリング フラッシュ ファイル システム (David Woodhouse 著) (PDF)
• JFFS2 公式メーリングリスト
• JFFS2 よくある質問