e2fsckで修復されたファイルシステムのファイルを信頼できますか?

e2fsckで修復されたファイルシステムのファイルを信頼できますか?

トピック

ファイルシステムがe2fsckによって正常に回復すると、一貫した(クリーン)状態が保証されます。しかし、回復後にファイル自体の信頼性を評価することは容易ではありません。

この質問は、特定のエラー状態で破損した後に修復されたext2およびext4ファイルシステムに格納されているデータの整合性を判断する基準をカバーしています。


背景

複数のLinuxシステムをバックアップするには、外部USBハードドライブ(プラッタベース、フラッシュなし)のext2ファイルシステムを使用します。これを行うには、rw, relatimeオプション(すべて)を使用してドライブを手動でマウントしたため、syncオプションは使用しませんでした。

最近、openSUSE 13.1システム(Linuxカーネル3.11.6-4)で大規模バックアップ(数100 GB)を実行し、USB HDDへのすべての書き込みアクティビティが完了した後にドライブをマウント解除できませんでした。umountコマンドがブロックされました。戻らないでください。中断のない省電力モード(状態D)syncに入る後続のコマンドにも同じことが当てはまります。ps

USB HDDを取り外すとブロックは解放されません。

この後も標準手段(pm-utils)でシステムの電源を切ろうとすると停止しました。マシンを終了するためにSysRq salute 、、、、、をr使用eしました。しかし、そこでもリクエスト(同期化)と(読み取り専用の再マウント)は成功しませんでした。isubsusysrq.c のカーネル文書(sysrq.txt)これらの要求は明示的に発表されるまで完了しませんが、この場合は完了しません。したがって、SysRq b(再起動)が発生すると、マウントされたファイルシステムが完全にアンマウントされたことは確認されず、完全な再起動が開始されます。

関連するすべてのファイルシステムの確認(ルートパーティションのext4とUSB HDDのext2)を使用して、e2fsck幸いにも、ルートファイルシステムがきれいで、USB HDDのファイルシステムに無効な利用可能なブロックと利用可能なinodeの数だけが表示されることがわかりました。 e2fsckで修正できます。

ここで使用されているシステムのSystemdログには、マウント解除と同期のブロックに関するエントリは表示されません。特にIOの問題に関連する項目はありません。 USB 分離イベントと SysRqs 以外の残りの測定値は正しく記録されます。

事件後のSMARTとUSB HDDテストの結果、badblocks異常な点は見つかりませんでした。ドライブは約5ヶ月間使用され、現在は正常に動作しているようです。


多様性

私は過去数年間、他のUSB HDD(16ヶ月より古いものはありません)と異なるカーネルバージョンを実行している他のLinuxシステムで同じ状況を何度も経験しました。処理の唯一の違いは、SysRqの代わりに電源ボタンを使用してシステムをシャットダウンすることです。

e2fsck各インシデントについて、以下を使用して潜在的に影響を受ける可能性があるすべてのファイルシステム(すべてのext2とext4)を特定しました。

  1. ファイルシステムをクリーンアップします。

  2. e2fsckはログ(ext4)を再生してダーティファイルシステムを回復できます。

  3. ファイルシステムに誤った空きブロックと空きinodeの数が表示されます。これはe2fsckで変更できます。

  4. e2fsck が Lost+found に接続された別々の inode を含むファイルシステムです。

  5. e2fsckによって複製された複数の要求inode(複数のファイルによって要求された)を含むファイルシステム。


実際の問題

上記の状況の影響を受けてe2fsckによって正常に回復されたext2またはext4ファイルシステムは、確実に一貫した(クリーン)状態です。

しかし、そのファイルシステム内のファイルの内容とメタデータはどうですか?

e2fsckで見つかったファイルシステムの破損とデータ破損の間に固有の相関関係はありますか?たとえば、

ファイルシステムで誤った数に加えて他の破損が見つからない場合、実際のファイルデータには問題はありません。

または:

ファイルシステムに複数宣言されたinodeが含まれていると、1つ以上のファイルの内容が破損します。

それともその逆ですか?ファイルシステムとファイルデータは独立しています。これは、少なくともデバイスの通信レベルで損傷を引き起こす原因が何であるかを正確に知らずに、一方の損傷が他方が損傷したと結論付けることができないためです。

後者の場合、後でファイルシステムがクリーンであると確認されても、説明された状況によってファイルの内容が破損する可能性があります。正しいですか?

e2fsckで見つかったファイルシステムエラーに基づいてファイルの整合性を評価するために使用できる経験値または合理的な基準はありますか?

この文脈では、回答膣到着「fsckで行われたファイルシステムの変更をテストする方法」良い本です。

ファイルシステムとデータの整合性の違いは次のとおりです。ext4 ファイルシステムのカーネルドキュメント。後者の場合、私は素晴らしいものに感銘を受けました。回答ミケル到着「停電後もジャーナルファイルシステムが破損しないことを保証できますか?」、これはこのトピックにも非常に関連しています。


自分の推測と影響

Systemdはサービスユニット(テンプレート)を提供します。[Eメール保護]passnoデフォルトでは、起動時に/etc/fstabで選択したファイルシステムを「グルーミング」します。-pマニュアルページのオプションの説明によるとe2fsck(8)、「手動介入なしに安全に回復できるすべてのファイルシステムの問題を自動的に回復する」ように構成されています。残念ながら、説明では、「セキュリティ」がファイルシステムの一貫性のみを指すのか、ファイルの内容とメタデータも含めるのかを指定しません。

ただし、Systemd サービスはユーザーに完全に透明な方法でデフラグを開始するため、少なくとも一部の専門家はそのファイルシステムの回復結果について完全な信頼を持っています。

したがって、曖昧な感じ(!)に基づいて、きれいなファイルシステム(上記のエラー状態1)とログを再生して修正できる(エラー状態2)を使用すると、ファイル自体が次のようになると仮定するのが安全であると思います。そのような事件の後も損なわれなかった。

一方、エラー状態5のファイルシステムについてはバックアップを参照してください。

それでは、なぜこんなに騒がしいのでしょうか?同意する:標準のプライマリまたはルートファイルシステムの場合は、その内容を最新のバックアップと比較します。ただし、この場合、これらのバックアップは影響を受けるUSB HDD自体にあります。整合性が疑われる場合は、すぐに複数のコンピュータを再バックアップする必要があります。これにより、そのドライブの循環バックアップ戦略中に蓄積された古いバックアップが作成されます。そうしないと、そのデータのスナップショットとして無意味に使用できます。

したがって、説明されたシナリオの影響を受けた後に修正されたext2またはext4ファイルシステムのデータをどれだけ信頼できるかについて合理的で信頼できる標準を持つことが有用です。


さらなる発見

自分で見つけようとして、これは素晴らしいことを知っていました。fsckの詳細については、『Sun用Oracleシステム管理ガイド』を参照してください。 fsckのUSFバージョンを説明しますが、一般的なアイデアはe2fsckにも当てはまります。しかし、この非常に詳細な文書は、fsckのペイロードを考慮するのではなく、fsckの使用とファイルシステム自体に焦点を当てています。

存在するこの回答到着「ext4でfsck -p(preen)は何をしますか?」、Noahは、fsckがext4ファイルシステムの最適化を実行して自動的に処理できるファイルシステムエラーのリストと、自動的に処理できないエラーのリストを公開しました。もちろん、相関関係が存在すると仮定すると、どのエラーがファイルデータの破損を意味するのか、どのエラーがそうでないかを示すファイルシステムエラーのリストがあればよいでしょう。

これは彼のものです回答、Michael Prokopecは、この問題に対する書き込みキャッシュの重要性について述べました。これに関して調べると回答背の高いジェフが到着します。「SATAディスクは書き込みキャッシュを正しく処理しますか?」少なくともほとんどのSATAドライブでは、デフォルトで書き込みキャッシュが有効になっています。しかし、同じ記事によると、ドライブはこれらのキャッシュをできるだけ早くフラッシュしようとします。もちろん保証はありませんが…

ベストアンサー1

  • 問題が発生したときにシステムがディスク集約的なタスクを実行しない限り。
  • ドライブ設定が書き込み前にデータをキャッシュするように意図的に設定されていない場合。

すべての検査に合格すると、データが信頼できることを合理的に保証できます。ただし、ドライブの寿命と使用状況に応じて、ドライブを最新のドライブに複製し、新しいドライブを使用します。

おすすめ記事