電力損失による破損からデータを保護するための最良の保護を提供するファイルシステムはどれですか。

Question

X86デバイスで小さなuClibcおよびbusyboxベースの組み込みシステムを実行しています。私はinitramfsを使用していますが、カスタムのext3ディレクトリをコンパクトフラッシュデバイスにIDEモードでマウントしています。これは、カスタムで記述されたc ++によって作成された永続的な測定ログデータを保存するために使用していますアプリケーション。私が読んだ数冊の本でCFドライブをIDEモードで使用する場合の電力損失に対する安全性のために推奨されているため、ext3ファイルシステムを選択しました（Building Embedded Linux Systemsby Karim Yaghmour andEmbedded Linux Primerby Christopher Hallinan）。これは特に重要であり、データは重要です。

ただし、前の質問のコメントの一部が原因でファイルの書き込み中に停電が発生した場合に、破損したext3ファイルを復元する方法との混乱実際には、このファイルシステムは、停電によるデータ破損に対する安全性。だから私は知りたいのですが

ext3は実際にこの設定に最適ですか？
ディスク書き込み操作中の停電は、定期的にファイルに追加しているデータの一部のみを破壊しますか、それとも全体ファイルを破壊しますか？
notであるデータは、電力損失の時点で完全に安全ですか？特に、私のinitramfs.cpioファイルも破損するリスクはありますか？
アプリケーションコードでデータを保護するために使用できる方法はありますか（つまり、追加のパーティションを作成し、データをミラーイメージに書き込んで常に2つのコピーが存在するようにします）-アプリケーションにとって速度は実際の問題ではないため、高価なコピー操作です許容されます。

私はこの関連する質問への回答を見て読みました：停電後の破損に対するジャーナリングファイルシステムは破損を保証しますか？しかし、それは私を混乱させるいくつかのことを完全にカバーしていません。

たくさんの質問をしていることに気づきましたが、たくさんの資料を読んだにもかかわらず、停電が発生した場合のデータのリスクを根本的に理解できなかったようです。

Alexios · Accepted Answer

セキュリティに関連するすべてのものと同様に、保証はありませんが、リスク（およびコスト）と確率のバランスをとる必要もあります。経験から（そして私は暗黒時代から何十もの* nix boxenを実行してきました）、私は実際に重大な電力によるファイルシステムの破損を経験したことはありません。

これらのマシンの一部は、ジャーナリングされていないファイルシステム（通常はufsとext2）でさえ実行されていました。それらのいくつかは組み込みであり、いくつかはNokia N900のような携帯電話でした—そのため、良好な電源はまったく保証されませんでした。

ファイルシステムの破損が発生する可能性があるわけではありません。発生する可能性が十分に低いため、心配する必要はありません。それでも、あなたの賭けをヘッジしない理由はありません。

あなたの文字通りの質問に答えて：

少なくともあなたが参照した最初の本は_ext4_の前に書かれました—著者が_ext3_の使用を提案するとき、彼らは本当に「_ext2_のような不安定なまたはジャーナル化されていないファイルシステムを使用しないでください」と言っています。）。 _ext4_を試してみてください。かなり成熟しており、フラッシュデバイスの寿命を延ばす可能性のある非回転ディスク用の適切なオプションがいくつかあります。
ファイル全体ではなく、最後の1〜2ブロックが失われる可能性があります。ジャーナル化されたファイルシステムでは、これが唯一の損失になります。ファイル全体にランダムなデータがスプレーされているのを見ることができる障害シナリオがありますが、それらは、組み込みデバイスを介して微小隕石が砕けるのとほぼ同じように見えます。
2を参照してください。100.00％安全なものはありません。
2番目のIDE=チャネルがある場合は、そこに2番目のCFカードを挿入し、定期的にファイルシステムのバックアップを取得します。これを行う方法はいくつかあります。rsync、cp dump、dd、 md(4)（ソフトウェアRAID）デバイスを使用する（2番目のドライブをときどき追加し、同期させてから削除します。両方のデバイスが常に稼働している場合、ファイルシステムが破損するリスクは同じです）。 LVMを使用すれば、スナップショットを取得することもできます。データ収集組み込みデバイスの場合は、2番目のファイルシステムをマウントし、データログをコピーして、すぐにマウント解除するアドホックソリューションを使用します。適切なブートイメージを持つデバイス、ブートマネージャーの2番目のコピー、およびすべての必要なブートイメージを2番目のデバイスに貼り付け、いずれかのCFカードからブートするようにコンピューターを構成します。

ストレージデバイスは安定したファイルシステムよりも頻繁に故障するため、同じデバイス上の2番目のコピーを信頼しません。 非常により頻繁に、これまでの私の経験では（仕事では、金曜日の午後にディスク障害が発生する可能性が非常に高い可能性について、厳しい冗談がありました。しばらくの間、ほぼ毎週のイベントでした）。ディスクが回転しているかどうかに関係なく、障害が発生する可能性があります。できれば卵を2つのバスケットに入れておけば、データをより安全に保護できます。

データが特に機密性が高い場合は、定期的にデバイスにアクセスし、バックアップCFを新しいCFと交換して再起動し、適切な測定のためにすべてのファイルシステムをfsckにします。

goldilocks · Answer

突然の電力損失の場合にファイルシステムの実装が達成できることは限られているように思えます-結局のところ、それは実際にはハードウェアとインターフェイスしているので、データ/命令をハードウェアに送信してからハードウェアに送信するまでの間に何が起こりますか？応答が制御不能であることを取得します。この問題を回避できるファイルシステムがあれば、聞いたことがあるでしょう。

そのため、重要なデータを保護するための戦略は、ハードウェアレベルで行われた決定から、たとえば無停電電源装置を使用することによって最も恩恵を受けます。おそらくこれはあなたの状況ではそれほど実行可能ではありません。

パフォーマンスはそれほど大きな問題ではないとおっしゃっていたので、 fsync() を慎重に使用してください。

ディスク書き込み操作中の電力損失は、ファイルに定期的に追加しているデータの一部のみを破損しますか、それともファイル全体を破損する可能性がありますか？

私はextNファイルシステムを個人的に使用しており、低トラフィックのインターネットサーバーで何年も使用しています。Alexiosのように、電源障害による破損はあまり見られません（ただし、サーバーはUPSを備えているので、思い出せません）それらの1つは実際にそのように下がっています）。さらに深刻な問題は、ハードウェア障害による破損です。これは、さまざまなファイルシステムが（繰り返して）問題に対処する能力をますます低下させる可能性がありますが、（繰り返します）これは根本的に制御不能であり、防止できません。

ファイルが失われたり、サイズがゼロに切り捨てられたりするのを時々見ました。これらが何らかの形で回復可能になる可能性は十分にあると思います。彼らはバックアップされていたので、これは私にとって必要ではありませんでした。ほとんどの場合、何か問題がある場合はfsckが対処しているようです。

停電時に書き込まれていないデータは完全に安全ですか？特に、initramfs.cpioファイルも破損するリスクはありますか？

停電に伴う電力サージによってフラッシュストレージが破損する可能性があることを除けば、停電だけではリスクは非常に低いと思います。これは私が経験したことはありませんが、考えていただければ幸いです。そしてこれを研究しました。

データを保護するためにアプリケーションコードで使用できる方法はありますか？

fsync（）についてのポイントを繰り返す価値があります。 C++/iostreamオブジェクトにはこのためのメソッドがありません（:: flushと:: syncはfsyncではありません）が、必要なのはファイル記述子だけです。

jlliagre · Answer

ZFSは間違いなく、設計による破損から保護されたファイルシステムであり、おそらく唯一のものです。ただし、uClinuxベースのプラットフォームでのZFS実装（Fuseベースまたはネイティブ）の可用性についてはよくわかりません。

QFang · Answer

停電によってファイルシステムがほとんど破損しないようにし、停電時に追加されていたデータだけが失われるリスクがあることを確認するために、途方もない仕事をする商用ファイルシステムが少なくとも1つあります。

欠点はそれが非常に高価であるということです、利点で彼らは素晴らしいサポートを提供します。費用がかかるため、これは実際には大量の製品や大量の製品に対する唯一の選択肢です。たとえば、重要な組み込み機器のように「不確実な」動作条件（頻繁な停電など）内でシステムの整合性を確保する必要がある石油およびガスの生産。

DataLight（company）および/または製品 " Reliance NITRO "を確認してください。（Relianceは彼らのレガシーで安全ですが、あまり効果的なソリューションではなく、 Reliance NITRO に取って代わられています）。このシステムを使用するお金がない場合でも、システムがどのように機能するのか、なぜそれがたとえばext3およびext4。

これが広告のように読めば、オプションを指摘したかっただけです。