既存のブロックデバイスのサイズを増やす場合（たとえば、vmwareは/ dev / sdcに20 GBを提供していますが、現在は40 GB）、そのスペースを使用するにはLVMに対していくつかの作業を行う必要があります。私が見たすべてのガイド（1、2、サム）では、既存のパーティションを削除して再作成し、最後に追加のスペースを追加してからpvresizeを実行することを提案します。
pvresize /dev/sdc1/dev/sdc1のサイズを変更して実行する代わりに、/dev/sdc2を作成して実行してpvcreate /dev/sdc2VGに追加することもできます。
新しいパーティションを追加するよりもサイズ変更が優れた技術的またはパフォーマンス上の理由はありますか？それとも、サイズ変更は常にやってきた方法で動作しますか？
ベストアンサー1
要約：純粋に技術的な観点から大きな違いはありませんが、サイズ変更がより良いです。実用的な側面が追加されたら、新しいパーティションを追加することは確かな勝者です。
厳密に技術的な観点から見ると、新しい太陽電池にはいくつかの欠点があります。
- 一部のディスク容量を消費するLVMメタデータの別のコピーが得られます。これはまた、LVM操作が頻繁な場合に書き込み増幅につながる可能性があります（メタデータがすべてのPVにミラーリングされるため）。
- ソートのための空きスペースが残っている可能性があります。
- 新しいPVに関する情報を保存するには、LVMメタデータ（レプリカ本当）の量を少し増やします。
- 2つのPVにまたがるLVを作成する場合、それは連続しません（追加のメタデータと整列のために残された穴のため）。たとえば、大規模な順次読み取り/書き込みに対応するLVを使用している場合は、そこで検索を実行します。
実用的な観点から見ると、これは合理的な量のPVにとって重要ではありません。メタデータの追加コピーが最初に重要ですが、少数のコピー（VG--metadatacopiesまたはPV --metadataignore）を保持するLVMオプションがあります。
さらに、実用的な観点から、パーティションを削除して再作成することは、新しいパーティションを作成するよりも管理エラー（誤字など）に苦しむ可能性が高くなります。なぜなら、後者のためのより良いツールがあるからです。発生した管理エラーは、サイズ変更にさらに損傷を与える可能性があります（データはサイズ変更されたパーティションにありますが、新しいパーティションにはデータがないため）。たとえば、mdraidがLVMより低い場合、状況はさらに悪化します。選択に応じて、-eスーパーブロックはアレイの終わりにある可能性があり、これはパーティションのサイズを変更するときに面白いことがあります。
1つの例外があります。何らかの理由で新しいパーティションを作成できない場合です。たとえば、DOSパーティションテーブルを使用していて、4つの基本パーティションをすべて使用しました（拡張パーティションは作成されません）。もしそうなら、選択の余地はありません。