6ヶ月に2回 - 3つのExt4ディスク（そのうちの1つは約1年前にSeagateディスク）に重大なファイルシステムの損傷を受けました。何が起こるかは、多くのディレクトリでディレクトリエントリのリストが切り捨てられ、「.」だけが残るようです。そして「..」で、多くのメタデータ構造が0xFFで直接上書きされます。つまり、ブロックは4096回繰り返されるバイト0xFFでのみ構成されます。私はUbuntu Mate、18.04.3 LTS、4.15.0-72-generic＃81-Ubuntu SMPを使用しています。
約6ヶ月前の最初のケースでは、停電が発生したマシンから2つのディスクを取り、fsckingなしで別のマシンにマウントしました。ディスクにデータを書き込んでいないが読み取り専用でマウントしていないため、メタデータが書き込まれている可能性があります。結局、私は両方でfsckを実行し、上記の破損が発生しました。具体的には、スーパーブロック、すべてのバックアップスーパーブロック、GDTのすべてのコピー、およびほとんどのinodeテーブルを0xFFバイトで上書きします。ディスク上の正しいテーブルの外側にあるinodeレコードとディレクトリファイルを取得するコードを書くことで、ほとんどのファイルシステムをもう一度まとめることができました。あるディスクではデータの約半分を回復し、別のディスクでは75％を回復したと推定されます。まあ、データの書き込みにさらされていないにもかかわらず、fsckを実行せずにRWドライブをマウントするのに不注意でした。私はこれをあまりにも不注意にしてはいけない骨の痛い教訓として受け入れました。奇妙なことに、ディスクの間違った場所にいくつかの欠落しているメタデータが見つかりました。これは私がスーパーブロックとかなり多くのinodeテーブルエントリを回復することができた方法です。システムがパニック状態でディスク上の複数のデータ領域にその内容を書き込んだようです。チェックサムでフィルタリングした結果、このスキャンで部分項目のコピー5〜10個が見つかりました。
ところで、ほんの数日前、似たような不正事件がまた発生しました（真剣でなければいいのですが）。私のデータディスクにExt4パーティションがありますが（デフォルトオプション）、コンピュータに電源の問題があります。機械は連続的にシャットダウンします。ディスクは1年しかない4TB Seagateディスクです。ついに電源を交換して取り付けて電源を入れてみると、データディスクが破損していることがわかりました。起動を何度も（5？）試みましたが、毎回緊急/安全モードに入りました。面倒なスタート画面は、起動しようとしている間に何が起こっているのか私に隠します。データディスクはfstabにリストされていますが、マウントできず、起動に失敗したことを最終的に実現しました。 fstabから削除すると、システムは正常に起動します。ディスクを調べてみると破損しています。正確に言うと、ブロック0のすべてのスーパーブロックは0xFFです。しかし、バックアップサブチャンクとGDTはどちらも大丈夫です。最初のinodeブロック（inode 1-11）を含む、使用されたinode項目の約0.5％も通常の0xFFで上書きされます（つまり、99.5％は問題ありません）。 0xFF カバレッジは常にブロック境界の整数ブロックです。ファイルシステムの詳細な調査を開始したところ、ディレクトリファイルのほぼすべてのinodeエントリが一度にブロック全体の0xFFで上書きされたことがわかりました。したがって、0.5％のinodeのみが使用されていますが、失われる最も不快な0.5％です。さらに、複数の高レベルのディレクトリファイルは、すべてのエントリ（「.」、「..」を除く）が削除されたように見えます。つまり、".."エントリのrec_lenフィールドはブロックの最後まで拡張され、ディレクトリファイルの後続のブロックは最初のエントリのinode番号が0に設定されます。
だから起動しようとすると、fsckが自動的に実行されるように見えます。理解できない理由で、複数のディレクトリ内のすべてのファイルを削除してから、重要なメタデータブロックをすぐに0xFFで上書きします。これは自動的に行われます。この「修正」について承認を求める必要はありません。
いくつかの質問があります。
ファイルシステムログの破損によりfsckが調整しようとしているからかもしれませんか？そうでなければ、何が原因である可能性がありますか？
ジャーナリング機能を持つExt4が実際に以前のext2またはext3ファイルシステムよりもこのエラーモードを介してデータ損失を受けやすい理由はありますか？
このようなことが再度発生しないようにできるだけ保証するために、次のデータディスクファイルシステムをどのように構成しますか？可能な限り最新のデータディスクを復元し、チェックサムが有効なExt4ファイルシステムを設定する予定です。また、ログのチェックサムを有効にするオプションがあると聞きました。これが望ましいですか？私にとっては、パフォーマンスよりも安定性が重要です。ただし、大規模なRAIDアレイを構築するための資金はありません。私の目的に合わせてExt4よりも優れたファイルシステムはありますか？
ブート時や他の方法でファイルシステムを自動的に「回復」するfsckの試行を制限するために、Ubuntu Mateでオプションを設定できますか？ジャーナリングを無効にする方が良いでしょうか？ fsckがファイルを自動的に削除したくありません！実際、私はfsckを削除して自分の修正コードを書くことを真剣に考えていますが、より簡単な方法が必要です。
他の人にもこれが起こったかどうかを調べるためにオンラインで検索しましたが、他のケースは見つかりませんでした。これらの一般的な失敗モードが6ヶ月間私に3回発生した場合、他の多くの人にも影響を与えることは確実です。ただし、オンラインでこの問題に関する他の説明が見つかりません。
答え1
残念ながら、私は "light geek"の使用を除いてext4の専門家ではありません。
このようなことが再発生しないようにするには、次のようないくつかの措置を講じることができます。
お金を節約するために、最も安価な電源（PSU）を購入しないでください。失敗したり、そうでない場合があります。言うことはない。
オプションで、利用可能な資金がある場合、壁のコンセントとコンピュータPSUの間に配置された無停電電源装置（UPS）を購入できます。停電時にバッテリバックアップを提供するだけでなく、グリッドで発生する可能性のあるサージ、スパイク、その他の異常に対する保護を提供します。私の経験では、これは良い投資であることを知っています。必要に応じて、コンピュータを見なくても正常にシャットダウンできるように、コンピュータを数分間実行し続けるには、400W（またはコンピュータや他のデバイスがより多くの電力を消費する場合は大きい）UPSが必要になることがあります。すべてがすぐに暗くなって静かになりました。 UPSはあなたのPSUをより満足させることもできます。
フィールド構造システムを構築します。 Knoppixはまさにこの理由に捧げられるディストリビューションです。私は最近、USBデバイス（16GBフラッシュドライブなど）でLive CD環境をカスタマイズして維持できるいくつかのMX Linuxを試しました。つまり、設定と変更が保存されます。これにより、不要なソフトウェアを大量に削除し、ある種の回復に役立つさまざまなツールを追加できます。ライブシステムをリマスターし、小規模なバックアップ（元に戻すファイルなど）用の追加スペースを提供するだけです。これが発生した場合は、ライブシステムを実行して内部ディスクなどのファイルシステムを自動的に確認しないでください。ライブシステムは、必要に応じてオンラインリソースにアクセスして情報やその他のサポートを見つけるのにも役立ちます。
- メニュー（GRUB2が一般的に良い選択）でブートローダーを使用すると、デフォルトのブートエントリを入力する前に数秒待ちます。あなたが説明するように、潜在的なオートメーション狂気に飛び込む前に他のことをすることができます。