私は、ファイルシステムの使用を必要とするOSのない組み込みアプリケーションに取り組んでいます。私はプロジェクトの人々と何度もこれを経験してきましたが、停電が発生した場合はシステムがシステムを適切にシャットダウンする必要があることに同意する人もいます。そうしないと、ファイルシステムが機能しなくなる可能性があります。
単にシステムの電源を切り、自然にそのコースを実行させるかどうかは問題ではないと言う人もいますが、特にこれが問題を引き起こし、おそらく製品の寿命を縮めることがわかっている場合は、それは最悪のことの1つだと思います寿命。
最後の段落では、それが問題であると思いましたが、私の質問は残っています。
電源を切るとファイルシステムに影響はありますか？
これは、組み込みシステムが電源障害に耐えるのに役立つさまざまな手法のリストです。これらは、特定のアプリケーションには実用的でない場合があります。
ジャーナリングファイルシステムを使用する-電源障害やOSのクラッシュなどによる不完全な書き込みを許容できます。最新のファイルシステムのほとんどはジャーナリングされていますが、宿題をして確認してください。
アプリケーションで書き込みパフォーマンスが必要な場合を除いて、すべての書き込みキャッシュを無効にします。 キャッシュオプションについては、ディスクドライバを確認してください。Linux / Unixでは、ファイルシステムを同期モードでマウントすることを検討してください。
書き込み可能でなければならない場合を除いて、読み取り専用にします。 アプリケーションの実行可能ファイルとオペレーティングシステムファイルを独自のパーティションに保持し、書き込み保護を設定してください（たとえば、Linuxでのマウント読み取り専用）。読み取り/書き込みデータは、独自のパーティションにある必要があります。アプリケーションデータが破損した場合でも、システムは起動できるはずです（フェイルセーフのデフォルト構成ではありますが）。
3a。一度だけ書き込まれるデータ（構成設定など）の場合は、ほとんどの場合、読み取り専用としてマウントされたままにしてください。設定変更がある場合は、一時的にR / Wとしてマウントし、データを更新してから、読み取り専用としてアンマウント/再マウントします。
3b。3aと同様の手法を使用して、フィールドでアプリケーション/OSの更新を処理します。
3c。FSを読み取り専用としてマウントすることが現実的でない場合は、少なくとも個々のファイルを読み取り専用として開くことを検討してください（たとえば、fp = fopen（ "configuration.ini"、 "r"））。
可能であれば、ストレージに別のデバイスを使用してください。 物事を別々のパーティションに保持することである程度の保護が提供されますが、パーティションテーブルが破損し、ドライブ全体が読み取れなくなる可能性があるエッジケースがまだあります。物理的に分離されたデバイスを使用すると、1つの破損したデバイスからさらに隔離され、システム全体がダウンします。完璧な世界では、少なくとも4つの別々のデバイスがあります。
4a。ブートローダー
4b。オペレーティングシステムとアプリケーションコード
4c。構成設定
4e。アプリケーションデータ
ストレージデバイスの特性を把握し、使用するデバイスのブランド/モデル/リビジョンを管理します。 一部のハードディスクは、OSからのキャッシュフラッシュコマンドを無視します。コンパクトフラッシュカードの一部のモデルが停電時に破損する場合がありましたが、「産業用」モデルにはこの問題はありませんでした。もちろん、この情報はどのデータシートにも公開されておらず、実験的なテストによって収集する必要がありました。承認されたCFカードのリストを作成し、それらのカードの在庫を保管しました。古いカードが廃止されたため、定期的にこのリストを更新する必要がありました。そうしないと、メーカーが改訂を行うことになります。
一時ファイルをRAMディスクに入れます。これらの書き込みをディスク外に保持すると、破損の潜在的な原因としてそれらを排除できます。また、フラッシュの摩耗を減らします。
自動化された破損の検出と回復の方法を開発します。-設定ファイルがないためにアプリケーションが単にハングした場合、上記のすべての手法は役に立ちません。可能な限り優雅に回復できる必要があります。
7a。システムは、構成設定の少なくとも2つのコピー、「プライマリ」と「バックアップ」を維持する必要があります。何らかの理由でプライマリに障害が発生した場合は、バックアップに切り替えてください。また、構成が変更されたとき、または構成がユーザーによって「正常」であると宣言された後（テストモードと本番モード）にバックアップを作成するメカニズムも検討する必要があります。
7b。アプリケーションデータパーティションのマウントに失敗しましたか？chkdsk/fsckを自動的に実行します。
7c。chkdsk / fsckは問題の修正に失敗しましたか？パーティションを自動的に再フォーマットして、既知の状態に戻します。
7d。障害後にOSとアプリケーションを復元するためのブートローダーまたは他の方法はありますか？
7e。システムがビープ音を鳴らしたり、LEDを点滅させたり、何が起こったかをユーザーに示すものであることを確認してください。
電源障害は、システム認定テストの一部である必要があります。 堅牢なシステムがあることを確認する唯一の方法は、それをテストすることです。システムから電源コードをヤンクし、何が起こるかを文書化します。システム操作の複数のポイント（実行時、起動中、構成の途中など）で電源をヤンクしてみてください。各テストを複数回繰り返します。
すべての電源障害の問題を軽減できない場合は、システムにバッテリーまたはスーパーキャパシターを組み込んでください-電力が低下したときに正常なシャットダウンを開始するには、OSにバックグラウンドプロセスが必要になることに注意してください。また、バッテリーは定期的なテストと経年による交換が必要になります。
msemackの回答に加えて、残念ながら私の評価は低すぎて、彼の回答と別の回答にコメントを投稿することはできません。
電源を切るとファイルシステムに影響はありますか？
はい、腐敗を防ぐための適切な対策が講じられていない場合は可能です。軽減に役立つファイルシステムオプションについては、以前の回答を参照してください。ただし、ATAフラッシュ/スリープがデバイスに適切に実装されていない場合は、私たちが行ったシナリオに遭遇する可能性があります。このシナリオでは、デバイスがファイルシステムを超えて破損しており、fdisk/formatはデバイスを回復しませんでした。
代わりに、破損が発生した後、デバイスを回復するためにATAセキュリティ消去が必要でした。これを回避するために、電力損失の前にATAスリープコマンドを実装しました。これには、ATAスリープにかかった160msをサポートするために400msのホールドアップが必要であり、製品の寿命全体にわたってキャップが劣化する余地があります。
シナリオからのメモ：
非ジャーナルファイルシステムの場合、予期しないターンオフは、ディレクトリ構造を含む特定のデータの破損を意味する可能性があります。これは、キャッシュに未保存のデータがある場合、またはFSがマルチブロック更新を書き込んでいる途中であり、一部のブロックのみが書き込まれたときに中断が発生した場合に発生します。
Journallingは、この問題に主に対処します。途中で中断が発生した場合、FSによって実行されるリカバリルーチンまたはチェックアンドリペア操作（通常は暗黙的に）により、ファイルシステムは一貫した状態になります。ただし、この状態は常に最新であるとは限りません。つまり、メモリキャッシュにデータがあった場合、ジャーナル処理を行ってもデータが失われる可能性があります。これは、ジャーナル処理によってファイルシステムの破損を防ぐことができますが、魔法のようなことはしないためです。
ライトスルーモード（書き込みキャッシュなし）は、データ損失の可能性を減らしますが、ジャーナル処理はキャッシュとして機能するため（非常に短時間）、問題を完全に解決するわけではありません。
したがって、残念ながら、バックアップまたはデータの重複は、データの損失を防ぐための主な方法です。
これは、使用しているファイルシステムと、プロジェクトの要件に基づいて電源オフ時に一部のデータを失うことが許容されるかどうかに完全に依存します。
無人の電源オフから保護され、部分的な書き込みシーケンスから回復できるファイルシステムを使用することを想像できます。したがって、アプリケーション側では、シャットダウンする前に絶対に書き込む必要のある批評家データがない場合は、特定の電源オフ検出手順は必要ありません。
プロジェクトについてより具体的な回答が必要な場合は、使用しているファイルシステムとプロジェクトの要件に関する詳細情報を提供する必要があります。
編集：電源を切る前に保存する重要なアプリケーションデータがあるので、あなたは自分で質問に答えたと思います。無人電源オフを確保する唯一の方法は、シャットダウン手順を実行するのに十分な電力をデバイスに供給し続けることを可能にするいくつかのハードウェア回路と組み合わせて、組み込みデバイスに警告する電圧低下検出を行うことです。
FATファイルシステムは、書き込みが進行中の場合、またはシャットダウン時にファイルが開いている場合、特にフラッシュされていないバッファリングされた操作の場合に、特に破損する傾向があります。あるプロジェクトで私が解決策に取り組んだのは、起動時にファイルシステムの整合性チェックと修復（基本的にはchkdsk / scandsk）を実行することでした。この戦略はデータの損失を防ぎませんでしたが、ファイルシステムが使用できなくなるのを防ぎました。
多くのベンダーが、この問題に正確に対処するためにFAT用のジャーナルアドオンコンポーネントを提供しています。これらには、たとえばSegger、Quadros、Micriumが含まれます。
いずれにせよ、システムは通常、ファイルアクセスにopen-write-closeアプローチを採用するか、ファイルを開いたままにする必要があると感じた場合はopen-write-flushを採用する必要があります。