JFFS2とは - わかりやすく解説 Weblio辞書 (original) (raw)

	この記事は別の言語から大ざっぱに翻訳されたものであり、場合によっては不慣れな翻訳者や機械翻訳によって翻訳されたものかもしれません。翻訳を改善してくださる方を募集しています。

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. ^ a b “Software Profile: Journaling Flash File System, Version 2 (JFFS2)” (PDF). micron.com (2011年). 2014年3月7日時点のオリジナルよりアーカイブ。2014年3月4日閲覧。

表話編歴ファイルシステム
ディスク	Advanced Disc Filing System（英語版） AdvFS（英語版） APFS Be File System（英語版） Btrfs CrossDOS（英語版） Disc Filing System（英語版） Episode（英語版） EFS HPFS ext ext2 ext3 ext3cow ext4 FAT FAT12 FAT16 FAT32 exFAT Files-11 HAMMER HFS HFS Plus IBM General Parallel File System JFS Macintosh File System（英語版） MINIX NetWare File System（英語版） NILFS Novell Storage Service NTFS QFS QNX4FS ReFS ReiserFS Reiser4 SpadFS（英語版） UBIFS UFS VERITAS File System Write Anywhere File Layout（英語版） XFS Xsan ZFS 光ディスク / 磁気テープ HSF ISO 9660 ISO 13490 UDF LTFS Flashメモリ / SSD APFS FAT exFAT CHFS TFAT EROFS FFS2 F2FS JFFS JFFS2 LogFS NILFS NVFS YAFFS UBIFS 分散ファイルシステム Coda CXFS（英語版） GFS2 GlusterFS Google File System OCFS2 QFS Xsan
ネットワーク型	AFS OpenAFS AFP DFS GPFS GlusterFS Google File System Lustre NCP NFS POHMELFS Hadoop Plan 9 FS SMB (CIFS) SSHFS
特殊用途	cramfs Dokan EROFS FUSE SquashFS UMSDOS UnionFS aufs initrd 疑似・仮想 configfs devfs procfs specfs sysfs tmpfs WinFS 暗号化 EncFS EFS ZFS UFS2
その他	ファイルシステムの比較（英語版）
カテゴリ

	この項目は、コンピュータに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。