☰

停電後にI / Oエラーが発生し、ファイルシステムが読み取り専用で再マウントされます。 [閉じる]

tag-icon • tag-icon ubuntu filesystems virtual-machine ext4 fsck
停電後にI / Oエラーが発生し、ファイルシステムが読み取り専用で再マウントされます。 [閉じる]

私は多数の仮想マシンを備えた本番ESXIサーバーを持っています。数時間前に停電が発生し、UPSバッテリーが放電しました。何らかの理由で自動シャットダウンメカニズムが機能しなかったため、システム全体の電源が切断されました。

中断後、mysqlサーバー仮想マシンを除くすべてが正常に戻りました。これで、I / Oエラーでコンソールにスパムを送信しています。

end_request：重要なメディアエラー、dev sda、セクタX
end_request: I/O エラー、dev sda、セクタ X
....
EXT4-fsエラー（デバイスdm-1）：ext4_wait_block_bitmap：476通信バウンス：ブロックビットマップを読み取れません。 - block_group=X, block_bitmap=X
デバイスdm-1-8でロギングを中断しています
EXT4-fs(dm-1): ファイルシステムを読み取り専用で再マウントします。

快適

VMは暗号化されたLVM設定を使用します。

これらのエラーはどういう意味ですか？ハードウェアですか？どうですか？私は何時間もインターネット検索をしてきましたが、何をすべきかわかりません。ライブCDから起動し、アンマウントされたルートパーティションでfsckを実行した後、問題を解決して再起動しましたが、問題は同じです。

編集＃1これを試しましたが、何も起こりませんでした。

root@ubuntu:~# sudo cryptsetup --key-file=/media/ubuntu/7b225e2d-9c0f-4bd4-a4de-1d2f7a0b4c58/keyfile luksOpen /dev/sda5 myvolume

root@ubuntu:~# vgscan
  すべての物理学の本を読んでください。少し時間がかかるかもしれません...
  メタデータタイプlvm2を使用して、ボリュームグループ「mysql-server-vg」を見つけます。

root@ubuntu:~#tune2fs -O ^has_journal /dev/mysql-server-vg/root
une2fs 1.42.13(2015年5月17日)
need_recoveryフラグが設定されました。削除する前にe2fsckを実行してください。
has_journal フラグです。

root@ubuntu:~# e2fsck -f /dev/mysql-server-vg/root
\e2fsck 1.42.13(2015年5月17日)
/dev/mysql-server-vg/root: 回復ログ
パス1：inode、ブロック、サイズチェック
削除されたinode 391687のdtimeは0です。修正しますか？はい
破損した孤立接続リストの一部である索引ノードが見つかりました。修正しますか？はい
Inode 391697は、分離されたinodeリストの一部です。安定した。
Inode 391699は、分離されたinodeリストの一部です。安定した。
Inode 391700は、分離されたinodeリストの一部です。安定した。
ステップ2：ディレクトリ構造を確認する
ステップ3：ディレクトリ接続を確認する
ステップ4：参照数を確認する
パス5：グループサマリー情報の確認
使用可能なブロック数エラー（5462594、カウント= 5462792）。
修正しますか？はい
インデックスノードビットマップの違い: -391687 -391697 -(391699--391700)
修正しますか？はい
グループ＃48の利用可能なinodeの数が無効です（7946、Count = 7950）。
修正しますか？はい
使用可能な inode 数エラー (1854371、カウント = 1854370)。
修正しますか？はい

/dev/mysql-server-vg/root: ***** ファイルシステムが修正されました*****
/dev/mysql-server-vg/root: 95870/1950240ファイル(0.8%非連続)、2337016/7799808ブロック

root@ubuntu:~#tune2fs -O ^has_journal /dev/mysql-server-vg/root
une2fs 1.42.13(2015年5月17日)

root@ubuntu:~# e2fsck -f /dev/mysql-server-vg/root
e2fsck 1.42.13(2015年5月17日)
パス1：inode、ブロック、サイズチェック
ステップ2：ディレクトリ構造を確認する
ステップ3：ディレクトリ接続を確認する
ステップ4：参照数を確認する
パス5：グループサマリー情報の確認
/dev/mysql-server-vg/root: 95870/1950240ファイル(0.8%非連続)、2304248/7799808ブロック

root@ubuntu:~#tune2fs -j /dev/mysql-server-vg/root
une2fs 1.42.13(2015年5月17日)
ログinode生成：完了

答え1

わかりました、見つけ、正常に修正しました。二日かかりました。

まず、ストレージコントローラ、データストレージハードウェア（機械ドライブ）、ケーブルに異常がないことを確認しました。ファイルシステムがvmdkファイルに正しくアクセスできないことに注意してください。 scpとvSphere Clientを使用してローカルにコピーしようとしましたが、しばらくすると両方とも入力/出力エラーが発生しました。

仮想ディスクを別のデータストアに複製してみました。

CD /vmfs/ボリューム/
vmkfstools -i datastore1/vm/vm.vmdk datastore2/vm/vm.vmdk -d Thin -a lsilogic

16％後、入力/出力エラーが発生しました。

停電により、vmfsファイルシステム（データストア）、古いロックなどが一部破損していると思います。 VOMA（vSphere Disk Metadata Analyser）を使用して、VMFSメタデータの一貫性を確認しました。このコマンドを実行する前に、データストアをアンマウントする必要があります。

voma -m vmfs -f 確認 /vmfs/devices/disks/disk_name:1

34個のエラーが見つかりました。 vSphere Hypervisor バージョン 5.5 にバンドルされている voma は、確認するファイルシステムリカバリモードでは、clonezillaを使用してデータストアを新しいハードドライブに複製しています（不良セクタを含むディスクの複製）。その後、最新バージョンのvomaコマンドがあるので、VMware ESXiバージョン6.5にアップグレードしました。エラーが修正されたので、次のコマンドを実行しました。

voma -m vmfs -f 修理 /vmfs/devices/disks/disk_name:1

それは何かをします。仮想マシンを起動しましたが、次の理由でコンソールに接続できませんでした。新しい vCenter vSphere WebClient ナンセンスと vSphere Client が廃止されましただから、もともとVMware ESXi 5.5のインストールに戻りました。上記のvmdkファイルを正常に複製しました。複製されたディスクを使用してVMを起動し、fsckを一度実行して再起動しました。期待どおりに動作します。サーバーは私のすべてのデータでオンラインになりました。

多くの操作が必要でしたが、他のものを見つけることができませんでした。もしもっと簡単な方法ご存知の方お気軽にコメントありがとうございます。

事故発生の12時間前にデータベースバックアップを実行しましたが、可能であればライブデータを復元したいと思います。

関連情報