恐ろしい状況-複数の独立したOSインスタンスによって同時にマウントされたファイルシステム
この状況から安全に抜け出すにはどうすればよいですか？ 詳細は次のとおりです。 xenサーバーには、VMにブロックデバイスが割り当てられています。ただし、これらのデバイスはXen内にもマウントされています。 実際、これらのブロックデバイスのうち44個がこのようにマウントされています。さらに悪いことに、各物理デバイスは4つのパス上にあり、それぞれが個別のマウントポイントにマウントされています。つまり、デバイスは実際に各5回マウントされます。 VMゲストOSは、PowerPath擬似デバイスを介してパスを認識します（phy：ブロックデバイスとしてdomUに割り当てられます） 一部のデバイスは、ext2およびreiserfsとしてフォーマットされています。 ここで関係するファイルシステム破損のリスクについて説明する必要はありません。 ファイルシステムをアンマウントするだけでも破損が発生する可能性があることを恐れており、この時点でホストから電源を引き出すことが最も安全なオプションであると感じています。 すべてのVMのアプリケーション（ほとんどの場合Oracleデータベース）は、まだ実行中で使用中であることに注意してください。 これは、dom0での高いCPU使用率を調査したときに発見されました。/ dev / emcpowerrに属する/ dev / sdf1からマウントされたcwd-> / media / disk-12を使用した、強制終了できない「検索」プロセスがあります。 誰かが尋ねる前に、一度プロセスを殺すことができず、CPUとRAMを使用し続けることができません（無効/ゾンビプロセスとは異なります）。 。より一般的には、テープI / Oで発生します。 提案！？ PSこの種のことを防ぐために、デバイスがマウントされると「予約」されると予想していましたか？それともLinuxでは不可能ですか？ 編集：まず、ハイパーバイザー内のKDEが原因だと確信しています。KDEは、ログに記録できるデバイスをマウントしてデスクトップアイコンを作成しているようです。ただし、他のXenサーバーでは同じことは起きていませんが、他のすべてのサーバーははるかに古いバージョンのSLESおよびKDEを実行しています... さらに、2つの重要ではないVMがハングしました。それらをシャットダウンした後、ファイルシステムの破損のために再起動しませんでした。メイン/実稼働VMはまだ実行中で、その上のデータベースはまだ動作していますが、明らかにこれは時限爆弾です。お客様は、別のサーバー上の別のVMで環境を再構築しようとしていますが、一部のコンポーネントの構成に関する問題に固執しているため、お待ちしています... いずれにせよ、これまでのところ「ベストプラクティスは常に適切にシャットダウンされる」以上の答えはなかったと感じています。考え。シャットダウンすると、未処理のIO、特にハイパーバイザーからのファイルシステムメタデータの更新が同期され、ファイルシステムが破損する可能性がありますか？