xfs_repairがスタックしています-それを殺しても安全ですか？
Centos 6.9
そのため、少なくとも名目上は、それらが含まれているレイドを再構成した後、2つの40TBボリュームに障害が発生しました。レイドボリュームは問題ありませんが、マウントすると、1つは「スーパーブロックを読み取れません」、もう1つは「間違ったfsタイプ、不正なオプション、不正なスーパーブロック」と報告しました。
次に、両方で同時にxfs_repairを実行する（同じファイルサーバー上にある）という間違いを犯しました。これは、メモリの問題を求めていることがわかりました。ファイルサーバーには64GBのRAMがあり、スワップ量は半分です。そのため、サーバーのメモリが不足し、xfs_repairプロセスの1つが強制終了されました。現在、2つ目はまだ実行中ですが、進行がなく、CPU使用率が0％で、長い間スタックしています。
スタックしたxfs_repairプロセスを強制終了する必要があると思いますが、それでは緊張します。私が試すかもしれない何か他のものはありますか？
修理中のプロセスが中断された他のボリュームについては、マウントしてみましたが、正常にマウントされています。
アドバイスありがとうございます。
一般に、低レベルの操作を行っているプロセスを強制終了することは安全ではありません。ただし、あなたの場合、他のドライブが機能しているため、セーフティネットがあります。
これらがRAID1としてセットアップされた2つのボリュームであると仮定すると、（安全性を高めるために）機能するボリュームをアンマウントし、xfs_repairプロセスを強制終了して、中断されたボリュームの状態を評価してから、正常なボリュームを復元できます（以前にアンマウントされました）。それが機能していない場合はそれに。
プロセスの使用率が0％であることを考えると、おそらくデッドロックが発生しています。つまり、プロセスは強制終了されます必須強制終了され、安全かどうかに関係なく当てはまります。シャットダウンまたは再起動すると、とにかく暗黙的にそれが強制終了されるため、先に進んで自分で実行することをお勧めします。そうすれば、何が起こっているかをより細かく制御できます。何か悪いことが起こった場合、それはおそらくすでに起こったか、避けられなかったでしょう。