Linuxで縮小した後もファイルシステムは古い値を表示していますが、LVMでは正しい値を表示しています
ファイルシステムのサイズを8TからLVMにある7Tに変更するタスクがあります。 resize2fsコマンドを実行しているときに、「書き込みに失敗しました：ピアによって接続がリセットされました」というエラーが表示されますが、再度ログインすると、resize2fsコマンドはまだプロセスリストを実行しています。プロセスが完了した後、「lvreduce」を使用してLVMを削減し、マウントし直しました。
現在、df -hではまだ8TBを示していますが、LVMでは7TBを示しています。問題を修正する方法は？
resize2fsはおそらくジョブを終了しませんでしたが、出力の終わりを逃したため、わかりません。
not先に進み、その時点でlvreduceを実行する必要があります。ファイルシステムのこの破損した部分が破損している可能性が非常に高くなります。 lvextendを実行し、失われたバイトが戻ってきてファイルシステムが回復できることを期待してこの操作を元に戻すことはできないことに注意してください。lvextendは別のバイトを返す可能性があるためです。
推測しなければならないのは、おそらく何が起こったのかというと、resize2fsが出力を出さずにしばらく動作していたときに接続がリセットされたということです。接続がリセットされた後、しばらくの間実行を続けました（SIGHUPを無視したか、受信しませんでしたか？）。しかし後で、おそらくそれがほぼ終了したとき、それはいくつかのステータス出力を発し、存在しない端末に書き込もうとしたときにエラーまたは信号を受け取ったためにすぐに強制終了されました。そして、それは決して完了しませんでした。
resize2fsがファイルシステムをどのような状態にしたかは未解決の質問ですが、ファイルシステムのサイズの縮小がコミットされていない状態で、かなり使用可能な状態のままになっていることを期待できます。
ストーリーのこの部分の教訓：接続が中断される可能性がある場合は、screenの下で（またはatジョブなどとして）resize2fsのような重要な操作を実行します。
この時点で試みる可能性のあるものはすべて危険であるため、何をする場合でも、適切なバックアップがあることを確認してください。適切なバックアップがない場合は、ファイルシステムを読み取り専用でマウントし（読み取りと書き込みでマウントしないでください。損傷が悪化する可能性があります）、今すぐ実行してください。
最も安全なのは、ファイルシステムを削除してバックアップから回復することです。ただし、ファイルシステムを適切に回復しようとする場合は、次の2つのタスクを組み合わせて実行することをお勧めします。
fsckファイルシステムはそのまま。これにより、ファイルシステムの終わりを超えて読み取ろうとした場合に通知され、データのどれだけがそれらの境界を超えているかがわかります。resize2fsがクラッシュする前にそのデータの移動に成功した可能性があるため、それほど多くないことを願っています。lvextendを使用してブロックデバイスを以前のサイズに再拡張し、ファイルシステムを満足させるために、次にfsckを使用して、正方形から操作全体を再試行します。これにより、ファイルシステムが有効なデータが存在する範囲を超えたバイト範囲にアクセスするため、サイレント破損が発生する可能性があります。
正確に何があなたに最適かわかりません。それは、ファイルシステム上で起こったレイアウトと、イベント以降に触れられた量によって異なります（少なくとも一度は、おそらく読み取り+書き込みでマウントしたと言っています...）