ジャーナリングファイルシステムは、停電後の破損を保証しますか?


28

Ubuntuチャットルームで問題を提起した別のユーザーに代わってこの質問をしています。

ジャーナリングファイルシステムは、電源障害が発生した場合に破損が発生しないことを保証していますか?

この回答がファイルシステムに依存する場合、どのシステムが破損を防止し、どのシステムが保護しないかを示してください。

回答:


21

保証はありません。ジャーナリングファイルシステムは回復力があり、破損の可能性は低くなりますが、耐性はありません。

ジャーナルとは、ファイルシステムに対して最近行われた操作のリストです。重要な部分は、操作が行われる前に仕訳入力が行われることです。ほとんどの操作には複数のステップがあります。たとえば、ファイルを削除するには、ファイルシステムの目次でファイルのエントリを削除してから、ドライブ上のセクターを空きとしてマークする必要があります。2つのステップの間に何かが発生した場合、ジャーナリングされたファイルシステムはすぐに通知し、すべての整合性を保つために必要なクリーンアップを実行できます。これは、エラーを見つけるためにボリュームの内容全体を調べる必要がある非ジャーナリングファイルシステムの場合ではありません。

このジャーナリングは、ジャーナリングを行わない場合よりも破損しにくい傾向がありますが、破損は依然として発生する可能性があります。たとえば、ハードドライブが機械的に誤動作している場合、またはジャーナル自体への書き込みが失敗または中断している場合。

ジャーナリングの基本的な前提は、通常、ジャーナルエントリの記述が、記述されている実際のトランザクションよりもはるかに高速であることです。そのため、OSが(ジャーナル)書き込みを注文してからそれを実行するハードドライブまでの期間は、通常の書き込みよりもはるかに短くなります。

参考文献


これが本当である理由について少し詳しく説明していただけますか?おそらく、特定のシナリオで破損がどのように発生するかの例を示すことができます。
ネイサンオスマン

1
@George Edison私の詳細な回答をご覧ください。
アンドリューランバート

2
その最後のビットは間違っています。物事がうまくいかない窓はありません。実行を開始する前に実行しようとしていることを記録しているため、操作中のどの時点で発生しても、停電後に操作を再開できます。タイミングではなく、順序の問題です。
-psusi

@psusiには、ジャーナルへの書き込みを中断するためのウィンドウがまだあります。ジャーナルの書き込みはOSにとってアトミックに見える場合がありますが、ディスクへの書き込みのままです。
アンドリューランバート

5
@Amazedは、シーケンス番号やチェックサムがあるためアトミックであるため、ジャーナルエントリは完全に書き込まれるか、書き込まれないかのどちらかです。完全に書き込まれていない場合は、システムの再起動後に無視され、fsに変更が加えられないため、一貫性が維持されます。
-psusi

18

いや

メタデータジャーナリングと呼ばれる最も一般的なタイプのジャーナリングは、データではなくファイルシステムの整合性のみを保護します。これにはxfs、デフォルトモードの、およびext3/ ext4が含まれdata=orderedます。

非ジャーナリングファイルシステムがクラッシュしfsckた場合、次回の起動時にチェックされます。 ファイルシステム上のfsckすべてのiノードをスキャンし、使用済みとしてマークされているが到達できない(ファイル名がない)ブロックを探し、それらのブロックを未使用としてマークします。これを行うには長い時間がかかります。

メタデータジャーナリングファイルシステムでは、を実行する代わりにfsck、変更中のブロックを認識しているため、パーティション全体を検索せずに空きブロックとしてマークできます。

データジャーナリングと呼ばれる、あまり一般的ではないタイプのジャーナリングext3がありdata=journalます。これは、オプションでマウントすると実行されます。

論理演算のリストだけでなく、ジャーナルへの各書き込みの内容全体を書き込むことにより、すべてのデータを保護しようとします。ただし、データを2回書き込むため、はるかに遅くなる可能性があります。

他の人が指摘しているように、ハードドライブがまだハードドライブのキャッシュにあるにもかかわらず、ハードドライブがデータを保存したことをオペレーティングシステムに伝えた可能性があるため、これでも保証ではありません。

詳細については、Wikipedia Journaling File Systemの記事ext4ドキュメントの Data Modeセクションをご覧ください。


1
ファイルシステムの破損とデータの破損を区別するために+1。その小さな違いは、実際には非常にすごいことです。
SplinterReality

私の完全な無知をすみませんdata=journalが、機能としてはまったく意味がありませんか?
boehj

繰り返しになりますが、OSは、ドライブがデータをキャッシュするタイミングを認識し、一貫性のあるfsを維持するために必要なときにデータをフラッシュします。もちろん、電源障害時に書き込みを行っていたアプリケーションが慎重に行っていなかった場合、データファイルは失われたり破損したりする可能性があり、data = journalを使用するかどうかに関係なく適用されます。
-psusi

@psusiは、プログラムがデータを書き込むことでいかに慎重ではありません、静かに壊れたハードドライブのたくさん読みのデータstackoverflow.com/q/34141117/3338098
user3338098

@ user3338098、静かにデータを破壊するドライブは恐ろしく壊れており、決して使用すべきではなく、ソフトウェアが間違ったことをすることによって引き起こされる破壊とはまったく異なる会話です。
-psusi

8

ファイルシステムは、電源障害が発生した場合、ハードウェアが何をするのかわからないため、ファイルシステムの一貫性を保証できません。

ハードドライブが書き込み用にデータをバッファリングするが、データを書き込み済みで適切な書き込みバリアをサポートしていないことをOSに伝えると、前の書き込みがプラッターにヒットせず、後の書き込みが順不同の書き込みが発生する可能性があります持っています。詳細については、このserverfaultの回答をご覧ください。

また、磁気HDDのヘッドの位置は電磁石で制御されます。書き込みの途中で電源が落ちた場合、ヘッドの移動中に一部のデータが引き続き書き込まれ、ファイルシステムが書き込みを意図していないブロックのデータが破損する可能性があります。


ドライブのファームウェアは、頭を引っ込めるときに書き込みを一時停止するほどスマートではありませんか?
ネイサンオスマン

@ジョージ:それはドライブに依存するでしょう。そこにはたくさんのものがあり、あなたの(安い)ドライブがどれだけうまくやっているかわからない。
カム

1
ハードドライブは、ライトビハインドキャッシュを使用するかどうかをOSに通知します。OSは、正しい順序でフラッシュされるように対策を講じます。また、ドライブは電源が落ちたときに書き込みを停止するように設計されています。私は、ECCの更新を完了していないために電力損失時に書き込まれているセクターが破損している(ただし、簡単に正しく再書き込みすることができます)が、電力損失時にランダムなセクターが破損していることを聞いたことがないケースを見てきました。
-psusi

3

ZFSは、ジャーナリングファイルシステムに近いものの、厳密にはジャーナリングファイルシステムではありませんが、電源障害後の破損に対する設計により保証されています。

そのような場合のように、進行中の書き込みが途中で中断されるかどうかは関係ありません。そのチェックサムは確かに正しくないため、ブロックは無視されます。ファイルシステムは書き込み時にコピーされるため、以前の正しいデータ(またはメタデータ)はまだディスク上にあり、代わりに使用されます。


2

ほとんどの場合、答えは「いいえ」です。

  • すでにmikelが言ったように、ほとんどのジャーナリングファイルシステムは、ファイルメタデータ(ファイルの名前、サイズ、権限などの情報)のみを保護でき、ファイルデータ(ファイルの内容)は保護できません。これは、ファイルデータを保護すると非常に遅い(実際には役に立たない)ファイルシステムになるためです。
  • ジャーナルはハードディスクに保存される特殊なファイルでもあるため、停電後に破損する可能性があります。したがって、ジャーナルが破損した場合、ファイルシステムは、電源障害が発生したときに行われていた不完全なトランザクションを完了できません。

どのようなイベントがジャーナルの破損につながる可能性がありますか?私が考えることができた唯一のものは不良セクターでした-他に何かがありますか?
ネイサンオスマン

そうです、ハードウェア障害は通常のケースです。
サキスク
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.