新しいPVを追加する代わりにPVのサイズを変更するのはなぜですか？
既存のブロックデバイスのサイズを増やす場合（たとえば、/ dev/sdcにvmwareから20ギガが与えられたが、現在は40ギガに増えている）、LVMがスペースを使用するためにいくつかの作業を行う必要があります。私が見たすべてのガイド（ 1 、 2 、）は、既存のパーティションを削除し、追加のスペースを追加して再作成することを提案しています最後に、pvresizeを実行します。
/ dev/sdc1のサイズを変更してからpvresize /dev/sdc1を実行する代わりに、/ dev/sdc2を作成してpvcreate /dev/sdc2を実行し、それをVGに追加することもできます。
新しいパーティションを追加するよりもサイズ変更の方が優れている、またはいつものようにサイズ変更しているという技術的またはパフォーマンス上の理由はありますか？
要約：純粋に技術的な観点からは、それほど大きな違いはありませんが、サイズ変更の方が優れています。実用的な側面を追加したら、新しいパーティションを追加することが明らかに勝者です。
厳密に技術的な観点から、新しいPVにはいくつかの欠点があります。
- LVMメタデータの別のコピーを取得します。これにはディスクスペースが必要です。 LVM操作を頻繁に行う場合、これにより書き込み増幅も発生します（メタデータがすべてのPVにミラーリングされるため）
- 位置合わせのために空きスペースが残っている可能性があります
- 新しいPVに関する情報を保存するために、LVMメタデータの量（コピーあたり）をわずかに増やします。
- 両方のPVにまたがるLVを作成する場合、それは連続していません（追加のメタデータと位置合わせのために残された穴のため）。したがって、たとえば、そのLVを大きなシーケンシャル読み取り/書き込みに使用していた場合、そこにシークがあります。
実用的な観点からは、これらのいずれも妥当な数のPVには関係ありません。メタデータの余分なコピーが最初に重要ですが、より少ないコピーを保持するためのLVMオプションがあります（VG --metadatacopiesまたはPV--metadataignore）。
さらに、実用的な観点から続けると、パーティションを削除して再作成すると、新しいパーティションを作成するよりも管理エラー（タイプミスなど）が発生する可能性が高くなります。また、発生する管理エラーは、サイズ変更の際にはるかに破壊的である可能性があります（データはサイズ変更されたパーティションにありますが、新しいパーティションにはデータがないため）。複数のレイヤーがある場合、これはさらに悪化します。例：LVMの下のmdraid。あなたに応じて -eオプションを選択すると、スーパーブロックを配列の最後に配置できます。パーティションのサイズを変更するときに便利です。
頭に浮かぶ例外が1つあります。それは、何らかの理由で新しいパーティションを作成できない場合です。たとえば、DOSパーティションテーブルを使用していて、4つのプライマリパーティションすべてを（拡張パーティションを作成せずに）すでに使用している場合があります。その後、あなたは選択の余地がありません。
同じVGにPVを追加し続けて、VMのストレージを増やすことで、提案どおりにストレージを横方向にスケーリングすると、見苦しくなります。
VM 10倍-新しいPVをVGに10倍追加する予定ですか？VMには、膨大な数の仮想ディスクとPVが接続されていることになります。それら。
そして、余分なスペースを使用するためにVGにPVを追加するたびにlvextendとresize2fsを実行するとどうなりますか？ LVとそこに存在するファイルシステムは複数のPV にまたがります。 pvdisplay -mを実行すると、さまざまなPVのエクステントを使用したLVが表示されます。
システムが過度に複雑になるほど、失敗する可能性が高くなります。これは、奇妙で予期しない方法です。
つまり、 not " VMごとに1つのPV（仮想ディスク）のみ "！ 1つのPVを使用する各VG に対して、つまり、vg_systemとvg_dataは、データをOS。 VMの [〜＃〜]同じ[〜＃〜] VGに複数のPVを使用しないことをお勧めします。
