
パーティション テーブルを作成する手順を踏むことなく、raw ブロック デバイス上で pvcreate を正常に実行できるようです。その後、ボリューム グループ、論理ボリューム、最後にファイル システムを作成し、マウントして、dd 経由でテストできます。
動作しているように見えますが、健全性チェックが必要です。これは悪い考えでしょうか?
生のブロック デバイス上に GPT または MBR パーティション テーブルを作成するにはどうすればよいですか?
parted を使用して、使用されているパーティション テーブルの種類を表示するにはどうすればよいでしょうか? 次の操作を試しました:
parted、/dev/sdb を選択して印刷すると、次のようになります:
エラー: /dev/sdb: 認識されないディスクラベル
しかし、ドライブは現在使用中であり、読み取りと書き込みが可能です。これは、パーティション テーブルのない生のブロック デバイス上で LVM を実行した場合に予想される出力ですか? 何かご意見はありますか?
ありがとう!
答え1
LVM 自体は実際のパーティションの有無を気にしないとしても、とにかくパーティションを作成する理由の 1 つは、パーティション プログラムに「そこに何かがある」ことを知らせることです。悪夢のようなシナリオは、新しいシステム管理者がサーバーのブート問題を診断し、パーティション プログラムを起動し、パーティション化されていないディスクを見て、ドライブが壊れていると結論付けることです。
LVM パーティションを作成することに欠点はないと思います。あなたはどう思いますか?
答え2
生のブロック デバイスから pv を作成することもできますが、ブロック デバイスが何に使用されているかがわかりにくくなる可能性があるため、通常はこれを避けるようにしています。また、構成ファイルが見つからない場合、LVM が使用できる自動検出ルーチンの一部が機能しなくなる可能性もあります。
これは、parted を使用して、ドライブ全体である 1 つのパーティションを持つ GPT を作成し、パーティション フラグを lvm に設定する例です。mkpart ではファイル システムを指定する必要がありますが、ファイル システムが作成されません。これは、parted の長年のバグのようです。また、開始オフセットを 1M にすることで、適切なアラインメントが確保されます。
parted /dev/sdb
mklabel GPT
mkpart primary ext2 1M 100%
set 1 lvm on
答え3
過去には PV に MS-DOS ディスクラベルまたは GPT ディスクラベルを使用していましたが、現在はメイン ブロック デバイスで直接 LVM を使用することを好みます。非常に特殊なユース ケース (ブート セクタとブート パーティションを持つディスクなど) がない限り、2 つのディスクラベルを使用する理由はありません。
LVM を直接使用する利点は次のとおりです。
- シンプルさ - 2セットのツールを使用する必要はありません
- 柔軟性 - pvmoveを使用して、ダウンタイムなしでデータをあるディスクボリュームから別のディスクボリュームに移動できます。スナップショットとシンプロビジョニングを使用できます。
- ボリュームを作成/サイズ変更/削除したことをカーネルに伝えるためにpartprobeやkpartxを実行する必要はありません。そしてpartprobe/kpartx が失敗する可能性があるパーティションが使用中の場合は再起動が必要になる場合があります
- MS-DOS または GPT ディスクラベル上で LVM を使用する場合と比較して、パフォーマンスが向上する可能性があります。
- fdisk で作成されたパーティションが基礎となるボリューム (RAID アレイなど) のエクステントと一致していない場合に、潜在的なミスアライメントを回避します。
答え4
RedHatのLVMガイドのセクション4.2.1によると https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/論理ボリュームマネージャ管理/物理ボリューム管理
彼らは、パーティション テーブルは必要ないと言いました。ディスク全体を VG (ボリューム グループ) に使用する場合は、その一部 (パーティション) のみを含めるつもりがない限り、パーティション テーブルを破棄することを提案しています。