JFFS2

JFFS2
開発者	David Woodhouse
正式名	Journalling Flash File System version 2
導入	2001年9月23日 (2001-09-23) (Linux 2.4.10)
構造
限度
特徴
透過的圧縮	zlib, rubin and rtime
対応OS	Linux

Journaling Flash File System, version 2（または JFFS2）は、Linux向けNAND型フラッシュメモリ用ログ構造ファイルシステムの1つ^[1]。スウェーデンのAxis Communicationsが開発したJFFSを、Red HatのDavid Woodhouseが改良したもの。

JFFSの後継でJFFS2は、カーネルバージョン2.4.10リリースの一部としてLinuxカーネルメインラインにマージされた2001年9月23日以降、Linuxカーネルに含まれています。 JFFS2は、Das U-Boot、Open Firmware、eCos、RTEMS 、RedBootなどのいくつかのブートローダーでも利用できます。 JFFS2の最も顕著な使用法は、OpenWrtから来ています^[2]。

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

概要

JFFSのウェアレベリングアルゴリズムは、NOR型フラッシュメモリの寿命を短くしがちであったため、JFFS2ではアルゴリズムの再設計が行われ、循環ログが廃止された。また、NAND型フラッシュメモリ用に設計され、圧縮によってパフォーマンスも改善されている。

特徴

JFFS2で導入された新機能：

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

設計

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

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

JFFSと同様に、ノードは作成時に有効なものとして開始され、新しいバージョンが別の場所に作成されると廃止されます。

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

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

ウェアレベリングをより均一にし、消去がほとんど静的なファイルシステムに集中しすぎないようにするために、ガベージコレクタはクリーンなブロックを消費することもあります^[5]。

短所

構造化ログの設計により、JFFS2の欠点は次のとおりです^[5]：

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

関連項目

• フラッシュファイルシステム
  • JFFS
  • YAFFS
• Memory Technology Device

外部リンク

• レッドハットのJFFS2サイト(英語)
  • デビッドウッドハウスによるレジュメ(HTML版, PDF版)(英語)
• 公式メーリングリスト(英語)
• FAQ(英語)

脚注

1. “Memory Technology Device (MTD) Subsystem for Linux.”. www.linux-mtd.infradead.org. 2021年5月15日閲覧。
2. “The OpenWrt Flash Layout - OpenWrt Wiki”. Wiki.openwrt.org. 2014年3月4日閲覧。
3. “Software Profile: Journaling Flash File System, Version 2 (JFFS2)” (PDF). micron.com (2011年). 2014年3月7日時点のオリジナルよりアーカイブ。2014年3月4日閲覧。
4. “Software Profile: Journaling Flash File System, Version 2 (JFFS2)” (PDF). micron.com (2011年). 2014年3月7日時点のオリジナルよりアーカイブ。2014年3月4日閲覧。
5. ^ “Software Profile: Journaling Flash File System, Version 2 (JFFS2)” (PDF). micron.com (2011年). 2014年3月7日時点のオリジナルよりアーカイブ。2014年3月4日閲覧。