の続きです。
レスキューディスクからLVMをマウントできない状況になっていました。
１０年前の私なら、fdiskですべてを無に返したでしょうが、今回はあきらめません。以下の記事を知っているからです。
pvdisplayなどでながめて、lvmの設定ファイルをでっちあげて、復活させます。
とりあえずこれで中のデータにはアクセスできるようになったので、レスキューモードのままで重要ファイル(4.6TB)だけバックアップを取ることにしました。
え？Windows2012サーバには数百しか空きがないのに？
そうなのです。ここでシステムを再起動する勇気が私にはなかったのです。LVMを認識できないと/がマウントできません。設定ファイルやら何やらがfsckで失われる可能性だってあったからです。
そもそもの失敗は、まだ元のpvがまともなうちに、8TBを単一のドライブとしてマウントし、4.6TBのファイルだけ移せばよかったのです。
そうしてからLVMのvgから壊れかけのpvを取り外すだけでよかった。ただ、そうした場合の面倒は、2-2-4+8が2-4+8になってしまうことです。3リットルと５リットルの入れ物で、4リットルの水を汲むのと同じ面倒さがあるわけです。
その面倒さを避けるために、さらなる面倒に巻き込まれたわけです。
いまだによくわからないのが、pvmoveの失敗の原因です。当初はpvcreateせずにvgextendしてしまったのが原因のように思い込んでいましたが、結局は8TBの正常にvgを構成するpvとして動作しています。
やはりpvmoveのエラー処理が貧弱なだけではないかという気がしてきました。
設定ファイルを見る限り、pvmove対象のsegmentはミラー対象としてマークされ、コピーが終わってからコピー元のエクステントを削除する動作のように見えました。しかしそこでエラーが発生すると、lv全体がマウントできないというのは、イマイチな気がします。move中のミラーの健常性はmoveの失敗を示すだけで会って、lvの健常性とあまり関係ない気がするからです。
pvmoveはディスクが壊れかかってから使うものではないということなのかもしれませんが、いざというときに動かないツールは困ります。
このあと、HDDをかき集めて平成最期の冬休みに片助君をやることになったのです。
（つづく）
