私はuClibcx86デバイスで小さな組み込みシステムを実行しています。busybox私はinitramfsを使用していますが、カスタム作成されたext3C ++アプリケーションによって生成された永続測定ロギングデータを保存するために使用するIDEモードのコンパクトフラッシュデバイスにカスタムディレクトリもインストールしました。ファイルシステムを選択したext3理由は、IDEモードでCFドライブを使用するときの電力損失を防ぐために読んだいくつかの本で推奨されているからです（組み込みLinuxシステムの構築著者：カリム・ヤグモール（Karim Yagmol）組み込みLinuxの起動著者：クリストファー・ハリナン）。これは特に重要であり、データが重要です。
しかし、以前の質問に対するいくつかの意見のためファイルの書き込み中に停電が発生した場合に破損したext3ファイルを修復する方法が混乱する実際、ファイルシステムは、停電によるデータ破損に対するセキュリティを提供していないようです。だから私は知りたいです。
ext3実際にこの設定に最適な選択ですか？- ディスクへの書き込み中に停電が発生した場合、ファイルに定期的に追加するデータ部分のみが破損しますか？みんな文書？
- データはいいえ電源を切った状態で文章を書くのは完全に安全ですか？特に私の
initramfs.cpioファイルが破損する危険がありますか？ - データを保護するために私のアプリケーションコードで使用する方法はありますか（例：追加のパーティションを作成し、私のデータをミラーに書き込んで常に2つのコピーを作成する）たくさんのコピー操作が許可されます。
私はこの関連質問に対する答えを見て読んだ。停電後もログファイルシステムが破損しないことを保証できますか？しかし、それは私を混乱させるいくつかの点を扱いません。
多くの質問をしていることは分かりますが、多くの資料を読んでいるにもかかわらず、停電が発生した場合、私のデータのリスクを根本的に理解していないようです。
答え1
セキュリティに関するすべてのものと同様に、保証はありませんが、リスク（およびコスト）と確率のバランスをとる必要があります。経験に照らして（私は暗闇の時代から数十の* nix boxenを実行してきました）、電源によるファイルシステムの破損を実際に経験したことはありません。
これらのシステムの一部は、ジャーナリングではなくファイルシステム（通常はufsとext2）でも実行されます。一部は内蔵されており、一部はNokia N900のような携帯電話なので、良い電源は保証されません。
これは、ファイルシステムの破損が発生しないという意味ではなく、発生する可能性が十分に低く、心配する必要がないという意味です。それにもかかわらず、賭けをヘッジしない理由はありません。
文字通りの質問に答えるには：
- 少なくともあなたが引用した最初の本は以前に書かれたものです
ext4。著者が使用を提案したとき、実際には「不安定なファイルやジャーナリング以外のファイルシステムを使用しないでください」とext3言っていました。ext2一度試してみてくださいext4。非常に完成度が高く、フラッシュデバイスの寿命を延ばすことができる非回転ディスクにはいくつかの良いオプションがあります。 - 完全なファイルではなく、最後の1〜2ブロックが失われる可能性があります。ジャーナリングファイルシステムの場合、これは唯一の損失です。いくつかのエラーシナリオでは、ファイル全体にランダムなデータが散在していることがわかりますが、これはマイクロ隕石が組み込まれたデバイスを直接強打するようです。
- 2を参照してください。 100.00% 安全なものはありません。
2番目のIDEチャネルがある場合は、ここに2番目のCFカードを挿入してファイルシステムを定期的にバックアップしてください。これを行うにはいくつかの方法があります
rsync。cpdumpファイルシステムの破損などの危険があります。 LVMでは、スナップショットを撮ることもできます。データ収集組み込みデバイスの場合は、2番目のファイルシステムをマウントし、データログをコピーしてすぐにマウント解除する一時的なソリューションのみを使用します。デバイスに良いブートイメージがあるかどうかが心配な場合は、ブートマネージャの2番目のコピーと必要なすべてのブートイメージを2番目のデバイスに貼り付けて、2つのCFカードのいずれかから起動するようにコンピュータを設定します。ddmd(4)私は2番目のコピーを信じていません同じストレージデバイスは、安定したファイルシステムよりもエラーが発生する可能性が高いためです。たくさんこれまでの経験によると（職場で金曜日の午後にディスク故障の可能性が驚くほど高いというのは冗談です。しばらくはほぼ毎週行事でした）。ディスクが回転しているかどうかに関係なく、失敗する可能性があります。したがって、可能であれば、卵を2つのバスケットに入れて、データをよりよく保護できます。
データが特に機密性の高い場合は、定期的にデバイスにアクセスし、バックアップCFを新しいものと交換してから再起動して、
fsckすべてのファイルシステムを完全に活用しました。
答え2
ファイルシステムの実装は、突然の停電時に実行できる作業が制限されているようです。結局のところ、ファイルシステムは実際にハードウェアと対話するので、データ/コマンドをハードウェアに送信する時間と時間の間にデータ/コマンドが送信される間に何が起こりますか？答えを得ることは制御できないことです。この問題を解決できるファイルシステムがあれば、聞いたことがあります。
したがって、重要なデータを保護するための戦略は、以下に基づく決定によって最大の利点を得ることができます。ハードウェアたとえば、無停電電源装置を使用してレベルを維持します。あなたの場合、これは可能ではないかもしれません。
パフォーマンスは大きな問題ではないと言ったので、賢く使用してくださいfsync()。
ディスク書き込み操作中に停電が発生した場合、ファイルに定期的に追加するデータの一部だけが破損するのですか、それともファイル全体が破損していますか？
私は、長年にわたり個人用のインターネットサーバーとトラフィックが途中以下のインターネットサーバーでextNファイルシステムを使用してきましたが、Alexiosのように停電による被害を多く見たことがありません。そのうちの1つは実際には次のようになります）。より深刻な問題は、ハードウェア障害による損傷です。他のファイルシステムではこれをある程度処理することができますが、これは基本的に制御範囲外であり、これを防止するための方法はありません。
場合によっては、ファイルが失われたり、サイズがゼロに切り捨てられることがあります。私はこれが何とか復元される可能性が高いと思います。バックアップされたので、私には必要ありません。ほとんどの場合、問題が発生するとfsck解決されるようです。
停電中に記録されていないデータは完全に安全ですか？特に、私のinitramfs.cpioファイルも破損する危険がありますか？
停電によって引き起こされる可能性がある電源サージによるフラッシュストレージの損傷を除いて、停電によるリスクは実際には非常に低いと思います。私はこれについて経験したことがありませんが、これについて考えて、知っていることを願っています。これについて研究しました。
データを保護するためにアプリケーションコードで使用できる方法はありますか？
それを繰り返す価値があるfsync()。 C++/iostream オブジェクトにはこのメソッドはありませんが (::flush および ::sync は fsync ではありません)、必要なのはファイル記述子だけです。
答え3
ZFSは確かにファイルシステムであり、おそらく設計上の損傷から保護される唯一のシステムです。ただし、uClinuxベースのプラットフォームに対するZFS実装（ヒューズベースまたは基本）の有用性は不明です。
答え4
停電によってファイルシステムがほとんど破損しないようにするのに役立つ商用ファイルシステムが1つ以上あり、失われる可能性がある唯一のデータは停電時に追加されたデータです。
欠点は、価格が非常に高価であるということですが、利点は優れたサポートを提供することです。費用のため、実際には高リスクおよび/または一括製品のオプションです。たとえば、石油やガスの生産に使用される重要な内蔵機器は、頻繁な停電などの「不確実な」動作条件でシステムの整合性を確保する必要があります。
確認するデータライト（会社）および/または製品"リライアンスニトロ（Relianceは彼らの遺産であり、安全ですがそれほど効果的ではないソリューションです。リライアンスニトロ）。このシステムを使用するお金がなくても、システムの動作方法とシステムがext3やext4などに比べてより安定している理由を説明する本当に良い記事があります。
広告のように聞こえたらすみません。いくつかのオプションをお知らせしたかったです。