linux - 組み込みシステムで ext3 を fsck する必要がありますか?

Question

ブロックデバイスエミュレーションを備えたフラッシュストレージに存在するファイルシステムへの読み取り/書き込みアクセスを必要とする組み込みシステムが多数あります。当社の最も古いプラットフォームはコンパクト フラッシュで動作し、これらのシステムは 3 年以上使用されていますが、起動時に fsck が実行されることはありません。これまでのところ、ファイル システムまたは CF に起因する障害は発生していません。

最新のプラットフォームでは、最初の生産に USB フラッシュを使用しましたが、現在は読み取り/書き込みストレージ用にディスク オン モジュールに移行しています。しばらく前に、USB ストレージで実行されている多くのデバイスのファイルシステムに問題があったため、e2fsck を有効にして、それが役立つかどうかを確認しました。不良品のフラッシュ メモリを受け取ったことが判明したため、それらを交換すると問題は解消されました。それ以来、システムの信頼性が向上したという兆候はなく、歴史的にはそれがなくても問題がなかったので、e2fsck を無効にしました。

Disk-on-Module ユニットの導入を開始したので、ファイルシステム エラーが再び発生するようになりました。突然、システムが特定のファイルを読み書きできなくなり、緊急コンソールからファイルにアクセスしようとすると、「入出力エラー」が発生します。e2fsck を再度有効にすると、すべてのファイルが修正されました。

O'Reilly の「Building Embedded Linux Systems」では、ext2 ファイルシステムで e2fsck を実行することを推奨していますが、ext3 に関しては言及していないため、有効にするかどうかについて少し混乱しています。

組み込みシステムで fsck を実行することについてどう思いますか? fsckが重要なシステムバイナリを誤って削除しないように、バイナリをar/oパーティションに配置し、ar/wパーティションで変更する必要があるファイルのみを同じフラッシュデバイスに配置することを検討しています。そのようなセットアップの経験がある人はいますか? （良し悪し）？

Answer 1

あなたの質問への答えは、アプリケーションがそのデータに対してどのような種類の一貫性要件を持っているかに関連していると思います。つまり、システムを正式にシャットダウンせずに電源が失われた場合、何を保証する必要があるのでしょうか? 一般に、デスクトップ オペレーティング システム タイプのファイル システムはどれも、アプリケーションの重要なトランザクション ポイントで特定のアプリケーションを閉じたりファイルを同期したり、ディスク キャッシュをフラッシュしたりせずに、これをうまく処理することはできません。マスコミに公言した事実。

fsck を実行するとファイルシステムが修正されますが、上記の注意を払わないと、行った変更が実際に保持されるという保証はありません。つまり、停電の結果として何が失われるかは正確には決定論的ではありません。

バイナリやその他の重要な読み取り専用データを別の読み取り専用パーティションに置くことで、ファイル システム構造に対する fsck 修正が原因でそれらが誤って破棄されないようにすることができることに同意します。少なくとも、R/W データが保持されている場所とは異なるルートから離れたサブディレクトリにそれらを配置すると役立ちます。ただし、どちらの場合も、ソフトウェアの更新をサポートしている場合は、「読み取り専用」領域の書き込みを処理するためのスキームが必要です。

私たちのアプリケーションでは、実際にはバイナリなどのディレクトリのペアを維持しており、システムは 2 つの領域のいずれかから起動するようにセットアップされています。ソフトウェアの更新中に、最初のディレクトリを更新し、すべてをメディアに同期し、ディスク上の MD5 チェックサムを確認してから、2 番目のコピーの更新に進みます。ブート中は、MD5 チェックサムが良好な場合にのみ使用されます。これにより、一貫したイメージを常に起動することが保証されます。