障害のあるLVMボリュームからreiserfsのサイズを変更できますか？
しばらく前に、backuppcのテストをセットアップするためにスペアパーツをいくつか引き出しました。 2台の大型ハードドライブがLVMを使用して1つのボリュームに統合されました。数か月後、2台目のドライブが故障しているようです。最後に確認したところ、ファイルシステムのサイズを変更するように説得できれば、私が持っているデータは最初のドライブにちょうど収まるでしょう。
バックアップPCでうまく機能したといういくつかの報告に従って、ファイルシステムをreiserfsとしてセットアップしました。私はresierfsckを使用して、（badblocksプログラムからの）badblockリストで--rebuild-treeを試すなど、被害がどれほど広範囲に及ぶかを確認し始めました。しかし、実行するたびに、新しい不良ブロックが検出されて停止するため、ディスクが失われた原因のように見えます。
resize_resierfsは、reiserfsck --checkを使用しても、最初に-fを実行する必要があることを示しています。これは、--rebuild-treeが不完全なために実行できないことを示しています。
少なくともデータはバックアップのみであるため、最初からやり直すことで重要なものが失われることはなく、最初のバックアップをダウンロードするのに多くの時間がかかります。
あなたが本当にやろうとしているのは、そのドライブから論理ボリュームを取り除くことです。そのための最善の策は、物理エクステントを別のディスクに移行することです。ファイルシステムのサイズを変更するだけでは、空き領域がどこから来るかを予測する方法はありません。
障害が発生したドライブが/dev/sdbで、新しいドライブが/dev/sdcであるとすると、手順は次のとおりです。
新しいディスクを準備します
pvcreate /dev/sdc
ボリュームグループに追加します
vgextend myvolumegroup /dev/sdc
データを新しいディスクに移動します
pvmove /dev/sdb /dev/sdc
注：pvmoveは遅いなので、実行することをお勧めします
pvmove -v /dev/sdb /dev/sdc
代わりに。
pvmove を使用して、そのLVのすべてのエクステントをVG内の他のPVに移動します。
私は、ディスクが失われた原因のように見えることに同意します。あなたのアプローチ（ファイルシステムの縮小、LVの縮小、不良ディスクからの移動）も問題ないようです。
これは機能する可能性があります（つまり、ディスクに障害が発生すると、すべての賭けが無効になります）。
- 少なくとも障害のあるディスクと同じ大きさの別のディスクを入手します。
- ボリュームグループ（pvcreate、vgextend）に追加します。
- 障害のあるディスク（pvmove）からLVを移動します。
これは、ファイルシステムをバイパスして、PE /ブロックレベルで機能します。しかし、読み取りエラーが発生しているので、それが機能するか失敗するかはわかりません。
正常なディスクの場合、VGからディスクを削除するドリルは次のようになります（両方のディスクにまたがる単一のLVがあると思います）
- ファイルシステムのサイズ変更
- lVのサイズを変更
- pvmove
- vgreduce
しかし、あなたの主な問題は、ステップ1と3が実際にはディスクエラーを好まないということのようです。
これまで、不良セクタのあるreiserfsボリュームからデータを回復する唯一の方法はddrescueでした。すべての「危険な」reiserfsツールは安全側でエラーが発生します。最初のディスクエラーで、操作全体がキャンセルされます。 ddrescueを使えば、良いデバイスにコピーしてreiserfsckを続けることができます。
私が今まで使用したすべてのパーティションサイズ変更プログラム（gparted、Partition Magicなど）は、変更をコミットする前にファイルシステムのヘルスチェックを実行します。 reiserfsをサポートしておらず、まだサポートしているアプリを誰かが知らない限り、最善の策は最初から始めることです。私が考えることができる他の方法は、はるかに多くの作業とはるかに長い時間がかかります。
それ以外の場合は、ファイルシステムツールを使用してすべての不良ブロックを再マッピングしてみることができますが、ドライブが実際に高速になっている場合は、再マッピングするよりも速く表示される可能性があります。