volumeが読み書き不能になった。LVじゃないpartitionは大丈夫なのだが。いまどきdiskは安いのででっかくアロケートしてLVMでちまちま切り出して使うことは止めましょうかねぇ。LVM関係のDocumentを読み漁ることになって、いままで概念的にしか知っていなかったLVMの実装っぽいところまで見るハメに。概念的な話なら、@ITとかにいい記事があったと思うし、結局「もう一段レイヤーをはさむ」ありがちな話なので難解ではない。「ソフトウェアを分かるにはデータ構造を見よ」というありがたい教えにしたがい、メタデータの構造を調べた。metadataに関するドキュメント。」ということなので、ddした結果をhexdumpしgrepした。hexdumpは不要かもしれないが、それではまわりがどうなっているのか分からんので、富豪的なアプローチをとった。|t.E:ID_FS_LABEL_|ddして周辺のデータを生きているfs上のfileとして持ってくる。論理ボリュームの自由配列一覧、それぞれ以下を含む論理ボリュームセグメントの順番配列一覧。するマッピングを含んでいます。実際、dumpを順番に見ていくと、こんな感じで整理できる情報が手に入る。PVをどっからとっているのかとか、どのように使っているのか、とかねぇ。LVを追加すると、どんどん後ろにappendされていくようだ。たしかに、flushのタイミングがおかしくなったときに情報が失われてしまうからね。226806なので、総合すると、すべてのPEとLEを使っていて、226806で一致している、PV0を線形に使っているので、offsetを計算してあげれば、ddをつかってimageを作れるはず、というとことまできた。ext4が壊れているかもしくは存在しないことになってしまっている。LVMのmetadataを利用してdeviceを作ることができればもうちょっと作業が楽になるハズが・・・。ー、なんか手動で--maps相当をやっていたようだ。利用していると、ディスク不良が発生した時に不良箇所がファイルシステム上のどこに相当するかを調べるのが面倒になります。割り当て状況を確認し、物理ボリューム上のどの位置がどの論理ボリュームのどこに相当するのか確認しなければなりません。パーティションを作成する事をお勧めします。こんなような結果が得られる。scriptでsdaとsdbを比較した結果(sda2とsdb2じゃないのがイケてない。sda1/sdb1には500Mくらいの/bootのpartitionが存在する)では174815245KiBあたりから不一致だった。PE/LE換算42554あたりから42992あたりまでおかしいので、Rootの部分がなにやらおかしなことになっていると検討がつく。Panicがおこることが説明できる。今後の作業は無傷であると思われるDataとHomeの救済、backupRootの修復である。sda/sdbの間でRootの部分を上書きコピーしてやる荒技もアルが、そのときはsda/sdbで食い違う部分をddして保管したのちに試みるべきだね。投稿Atom投稿コメントAtomコメント。