ア | イ | ウ | エ | オ |
カ | キ | ク | ケ | コ |
サ | シ | ス | セ | ソ |
タ | チ | ツ | テ | ト |
ナ | ニ | ヌ | ネ | ノ |
ハ | ヒ | フ | ヘ | ホ |
マ | ミ | ム | メ | モ |
ヤ | ユ | ヨ | ||
ラ | リ | ル | レ | ロ |
ワ | ヰ | ヴ | ヱ | ヲ |
ン |
A | B | C | D | E |
F | G | H | I | J |
K | L | M | N | O |
P | Q | R | S | T |
U | V | W | X | Y |
Z | 数字 | 記号 |
かつて、フラッシュメモリー用としてLinuxで使われていたファイルシステム。
NOR型フラッシュメモリー用に設計されたファイルシステムである。
初期に登場したJFFSは、フラッシュメモリーにまつわる各種の問題(イレースの回数制限、リードの回数制限)への対応として、様々な特徴的な動作を試みている。
フラッシュメモリーは、従来の磁気ディスクなどと違い、様々な特徴がある。特にファイルシステムを載せる上で問題となる特徴として、次のようなものがあげられる。
ext2など従来のファイルシステムではウェアレベリングを考慮していないため、inodeやディレクトリの情報などを頻繁に更新する。このため、従来のファイルシステムはフラッシュメモリーに向いていない。
JFFSはウェアレベリングの問題に対応するために、デバイスをブロックの循環ログとして管理する方式を採用した。
ファイル等への更新は、末尾のブロックに書き込まれ、先頭のブロックは再利用される。先頭と末尾の間のフリースペースが少なくなると、ガベージコレクションが実行される。この時、有効なブロックのみがログ末尾へと移され、未使用のブロックは消去される。
このシステムの根本的な問題は、書き換えが頻繁に発生し、デバイスの劣化が早いという問題であった。
また、inodeチェーンの全てをマウント時にメモリー上に読み込んでおく必要があり、これがマウントの遅さという問題の他、メモリーの消費を招くという問題も招いた。
コメントなどを投稿するフォームは、日本語対応時のみ表示されます