フラッシュ ファイルシステムに関する優れた記事。
フラッシュ ファイル システムについて話すときの重要な質問は次のとおりです。ウェア レベリングとは何ですか。ウィキペディアの記事。基本的に、フラッシュ ディスクでは、ブロックが不良になるまで限られた回数だけ書き込むことができます。その後、ファイルシステム (ハードウェアに組み込みのウェア レベリング管理がない場合、SSD の場合は通常あります) は、そのブロックを無効としてマークし、それ以上使用しないようにする必要があります。
一般的なファイルシステム (ReiserFS、NTFS、ext3 など) は、ハードディスク用に設計されており、そのような制限はありません。
JFFS2
コンプレッションとエレガントな摩耗レベリング保護が含まれています。
YAFFS2
- 違いを生む 1 つの点:アンマウントが成功した後の短いマウント時間。
- ライト ワンス プロパティを実装:データが 1 つのブロックに書き込まれると、それを再書き込みする必要はありません。摩耗を減らすため、これは重要です。
LogFS
- あまり成熟していませんが、すでに Linux カーネル ツリーに含まれています。
- JFFS2/YAFFS2 より大きなファイルシステムを問題なくサポートします。
UBIF
- LogFS より成熟
- 書き込みキャッシュのサポート
- スケーラビリティについて:記事。大容量ディスクでは、JFFS2 よりも優れたパフォーマンス
ext4
ドライバまたはカード (たとえば、SSD ドライブには少なくとも通常は内部ウェア レベリングがある) がウェア レベリングを処理しない場合、ext4 は最適なアイデアではありません。
どれが一番いい?
もちろん、それは使用状況とサポートに依存します。インターネットで読んだことから、UBIFS をお勧めします。大規模なファイル システムの適切なサポート、成熟した開発フェーズ、適切なパフォーマンス、大きなマイナス面はありません。
私も同じ問題に直面していて、いくつかの調査も行いました。最終的に、ext2 を使用することにしました。
一部の SDHC カードは、ハードウェア層で独自のウェアレベリングを実装しているようです。ウェアレベリングが組み込まれた SDHC カードを手に入れることができれば。
ウェアレベリングを提供するファイルシステムは、フラッシュレベルのウェアレベリングに干渉する可能性があるため、フラッシュがそれらを使用するのは実際には悪いことです (上記の IBM の記事では、JFFS がどのようにそれを行うかについて述べているため、それが機能しないことは明らかですフラッシュレベル WL)。 ext3 には重要なデータを保存しておらず、通常は定期的にバックアップ (cron) を行っているため、ext3 のジャーナリングは必要ないと判断しました。
また、速度を上げるために、/tmp と /var を tmpfs としてマウントしました。十分な RAM がある場合は、それを行う必要があります (ただし、ログを定期的にローテーションまたは削除するようにしてください)
ヒント:「noatime」オプションを使用して外部 SD カードをマウントします