


PCパーツ・ガジェット専門
自作PCパーツやガジェットの最新情報を発信中。実測データに基づいた公平なランキングをお届けします。
ディスクパーティションの基本概念からWindows/Linux両OSでの実践的な分割方法まで完全解説。GPT vs MBR比較、Windows推奨構成(EFI/OS/データ/回復)、Linux推奨構成(root/home/swap分離)、GParted活用法とデュアルブート設計手順。見逃せない最新トレンドも解説。
Btrfsファイルシステムのスナップショットを活用したバックアップ戦略ガイド。サブボリューム設計、自動スナップショット、増分送受信、Snapper設定を解説。
1台のPCで複数OSをマルチブート管理する方法。パーティション設計、ブートローダー設定、データ共有のコツを解説。
RAID 0/1/5/6/10の速度・冗長性・容量効率の違いを比較表で徹底解説。ハードウェアRAID vs ソフトウェアRAID(Windows記憶域/Linux mdadm/ZFS)の設定手順、NASでのRAID構成ガイド、SSD RAID構成の是非とリビルド時間のリスク分析。選び方のポイントを明確に整理。
LinuxのSwapパーティションとzRAM(圧縮RAM)の違いと最適な設定方法を解説。用途別の推奨設定、ハイバネーション対応、メモリ不足時のパフォーマンス改善策を紹介する。
現代の PC システムにおいて、ストレージデータの管理は単なる容量確保を超え、システム全体の信頼性とパフォーマンスに直結する重要な要素となっています。特に 2025 年以降、AI 処理や大規模データセットの保存ニーズが高まる中で、固定されたパーティション構成では迅速なリソース割り当てが困難になっています。Linux 環境における LVM(Logical Volume Manager)は、物理ディスクと論理ボリュームを抽象化し、柔軟かつ効率的なストレージ運用を実現する標準的なソリューションです。本ガイドでは、Ubuntu 24.04 LTS や Fedora 41、RHEL 9 など主要な Linux ディストリビューションに対応した LVM の実用的な管理術を、2026 年時点の最新ベストプラクティスに基づいて解説します。
LVM を適切に運用することは、システムメンテナンスの負担を軽減し、ディスク障害時のリスク管理にも寄与しますが、その反面、従来のパーティションテーブル(GPT や MBR)とは異なる仕組みのため、初学者には理解が難しい側面があります。本記事では、物理ボリューム(PV)、ボリュームグループ(VG)、論理ボリューム(LV)という 3 層構造の基礎概念から始まり、実際のセットアップ手順、オンラインでの容量拡張、安全性の高いスナップショット作成、さらには RAID 構成との連携までを網羅的に取り扱います。また、ext4 や XFS といったファイルシステムの違いによる挙動差、あるいは Btrfs のようなネイティブ機能を持つ代替案との比較も行うことで、読者が自身の環境に最適なストレージ設計を選択できるように支援します。
具体的な運用においては、コマンドの理解だけでなく、背後で動作するメタデータの管理や、データ整合性を保つためのロック機構についても深く掘り下げる必要があります。例えば、lvextend コマンドを実行した際にファイルシステムが即座に拡張されるかどうかも、使用するファイルシステムの種類(ext4 か XFS か)によって対応が異なるため、ここで誤るとデータ破損のリスクを招く可能性があります。また、物理ディスクを追加してストレージプールを拡張する際の手順や、スナップショット作成時に必要な容量計算など、実務で直面する具体的な数値シナリオを紹介していきます。
本記事を通じて、読者は LVM の複雑な仕組みを克服し、障害耐性のある柔軟なストレージアーキテクチャを構築できるようになることを目指します。2026 年現在では、NVMe SSD の普及により I/O パフォーマンスが向上していますが、LVM のオーバーヘッドは依然として無視できないため、性能と柔軟性のバランスを取りながらシステムを設計する知見が必要です。以下に示す各セクションにおいて、具体的なコマンドライン操作や設定値の指定方法を詳細に解説いたしますので、実際の Linux サーバーやワークステーションで即座に実践できる内容となっています。
LVM(Logical Volume Manager)は、Linux カーネル上のデバイスマップパー(dm)サブシステムを利用したストレージ管理手法であり、物理ディスクの断片化された領域を論理的なプールとして統合します。この仕組みにより、ディスクの物理的な接続順序や位置に関係なく、一貫してボリュームにアクセスすることが可能になります。従来のパーティション管理では、1 つのパーティションが特定の物理領域(セクタ範囲)に固定されるため、容量変更にはパーティション削除と再作成というリスクの高い作業が必要でしたが、LVM では論理レベルでのみ管理が行われるため、非破壊的に容量を調整できます。
この 3 層構造は、物理ボリューム(PV)、ボリュームグループ(VG)、論理ボリューム(LV)で構成されており、それぞれがデータの保持単位となっています。まず PV は、pvcreate コマンドによって LVM メタデータを含むディスクまたはパーティションを指します。これは LVM の管理下に置かれた「素材」となる領域です。次に VG は、複数の PV を結合して作成されたストレージプールであり、ここから LV へ容量が割り当てられます。最後は LV で、これがファイルシステムとしてマウントされ、ユーザーが直接データを保存する最終的なボリュームとなります。この抽象化レイヤーがあるおかげで、ディスクの物理的交換や増設をシステム停止なしで行うことが可能になります。
従来のパーティション管理と比較した場合、LVM の最大のメリットは柔軟性と拡張性ですが、いくつかのデメリットも認識しておく必要があります。以下に主な特徴を比較表としてまとめました。
| 項目 | 従来パーティション (GPT/MBR) | LVM (Logical Volume Manager) |
|---|---|---|
| 柔軟性 | 低(削除・再作成必須) | 高(オンライン拡張可能) |
| パフォーマンス | 若干高い(オーバーヘッドなし) | やや低い(メタデータ処理) |
| スナップショット | ネイティブ不支持(外部ツール依存) | ネイティブサポート(COW 方式) |
| 管理コスト | シンプルだが運用が硬直化 | 学習コストが必要だが柔軟 |
| 障害耐性 | 単一ディスク故障でデータ喪失リスク大 | RAID/ミラーリング連携で耐性が向上 |
LVM の構成要素であるメタデータは、通常ディスクの先頭と末尾に保存され、これにより特定のセクタに損傷があっても情報復元を試みることができます。ただし、この仕組みが LVM 特有の複雑性を生んでおり、初心者にとって「どこにメタデータがあるのか」を把握するのは容易ではありません。また、LVM を使用するとディスクのシーク動作パターンが変わるため、機械式 HDD の場合、従来のパーティション配置とは異なる I/O パフォーマンス特性を示すことがあります。特に 2026 年時点では NVMe SSD が主流となっていますが、大容量の SATA HDD をアーカイブ用に使用する場合でも LVM の管理機能は依然として有効です。
さらに、LVM のメタデータ構造にはバージョンがあり、LVM2 2.03.x 以降ではメタデータの冗長化やロック機構が強化されています。これにより、複数ノードで共有ストレージを利用するクラスタ環境における整合性維持が容易になっていますが、単一サーバーでの運用においても、vgcfgbackup コマンドによる定期的なバックアップが推奨されます。もし LVM メタデータが破損した場合、従来のパーティションテーブル修復ツールでは復旧できず、専用の LVM ツール(vgck, vgcfgrestore)を使用する必要があります。この点からも、LVM を導入する際にはメタデータの管理手順を事前に確立しておくことが必須となります。
Linux システムへの LVM 環境の構築は、インストール時の選択肢に任せることもできますが、カスタマイズした構成を行う場合は手動での設定が必要です。Ubuntu 24.04 LTS や Fedora 41 のインストーラーでは、ディスクレイアウトの設定画面で「LVM」というオプションが提供されており、これを選択すると自動的に PV と VG が作成されます。しかし、RHEL 9 や Arch Linux などの環境では、インストール後に lvm2 パッケージを明示的にインストールし、コマンドラインから構成するケースが多くなります。ここでは、 freshly installed なシステムに新規で LVM を構築する手順を、実用的なシナリオに基づいて解説します。
まず、LVM の前提となる物理ボリューム(PV)の作成を行います。これは /dev/sdb1 などの既存パーティションまたはディスク全体に対して実行します。pvcreate コマンドを使用し、対象デバイスに LVM メタデータを書き込みます。この際、オプションとして -ff (force)を指定することで、既に存在する不明なメタデータを上書きして作成できますが、誤って重要なデータを消去しないよう注意が必要です。また、-y オプションを付与すると確認プロンプトを自動で肯定し、バッチ処理をスムーズに進めることができます。2026 年現在、大型の NVMe SSD ではシークアンス速度が高いため、メタデータ書き込みによる I/O スターブはほとんど発生しません。
sudo pvcreate -ff /dev/sdb1 /dev/sdc1
次に、作成した PV を結合してボリュームグループ(VG)を作成します。vgcreate コマンドにより、PV の合計容量をプールとして利用可能にします。VG 名は任意の名前(例:data_vg)を指定しますが、システム内で一意である必要があります。この VG は、その後の論理ボリューム(LV)の母体となるため、名前には「用途」や「場所」を含めるなど、運用上のルールを設けるのがベストプラクティスです。VG 作成時に物理拡張(PE)サイズを指定することも可能ですが、デフォルト値(通常 4MB)が多くのケースで最適化されています。
sudo vgcreate data_vg /dev/sdb1 /dev/sdc1
最後に、VG から論理ボリューム(LV)を作成し、ファイルシステムを適用します。lvcreate コマンドを使用し、サイズ指定(-L オプション)と名前指定(-n オプション)を行います。例えば、100GB の論理ボリュームを root_lv として作成する場合の命令は以下のようになります。
sudo lvcreate -L 100G -n root_lv data_vg
この LV はまだファイルシステムを持っていないため、mkfs.ext4 または mkfs.xfs を使用してフォーマットする必要があります。ここで注意すべきは、使用するファイルシステムの選択です。ext4 は汎用性が高く、Linux 標準として広くサポートされていますが、XFS は大規模データや高速な I/O に特化しており、2026 年のサーバー環境では XFS がデフォルトとなるケースが増えています。以下に主要ディストリビューションにおける LVM デフォルト設定と推奨コマンドの差異をまとめました。
| ディストリビューション | 初期 PV/VG 作成方法 | 推奨ファイルシステム | デフォルト PE サイズ |
|---|---|---|---|
| Ubuntu 24.04 LTS | インストーラー選択で自動 | ext4 | 4MB |
| Fedora 41 | インストール時 LVM オプション | XFS | 4MB (xfs_growfs 推奨) |
| RHEL 9 | Anaconda デフォルト設定 | XFS | 16MB (XFS 最適化) |
| Arch Linux | 手動コマンド構成 | ext4 / Btrfs | ユーザー指定可能 |
ファイルシステム作成後は、/dev/mapper/data_vg-root_lv または /dev/data_vg/root_lv という経路でアクセスできるようになります。このパスを /etc/fstab に記述することで、システム起動時に自動マウントされます。ただし、LVM のパス名はデバイス名の論理名に依存するため、ハードウェアの物理名(sdb1 など)とは異なるため、システム再起動後も一貫性を保つことができます。
セットアップ完了後には、pvs, vgs, lvs コマンドを使用して状態を確認するのが習慣です。これらのコマンドは LVM のメタデータを読み取り、現在の構成を可視化します。特に pvs -o +pv_used,pv_free オプションを使用すると、各物理ボリュームの使用中容量と残量が即座に確認できます。2026 年時点では、lsblk --inverse コマンドも併用して階層構造を確認することが推奨されており、LVM の論理デバイスがどの物理ディスク上に存在するかを追跡しやすくしています。
LVM の最大の利点である「オンラインでの容量拡張」について解説します。システム稼働中にディスク容量不足が発生した場合、従来のパーティション方式ではファイルシステムを縮小・削除・再作成するリスクの高い作業が必要でしたが、LVM では停止時間を最小限に抑えながら対応可能です。ただし、拡張可能な範囲は論理ボリューム(LV)とファイルシステムの種類によって制約があり、これらを正しく理解しておく必要があります。
まず、既存の LV に対して容量を追加する場合の手順です。lvextend コマンドを使用し、-L オプションで新しいサイズを指定します。あるいは、+10G のように増加分だけを指定することも可能です。例えば、現在の 100GB の LV を 50GB 拡張したい場合は lvextend -L +50G /dev/data_vg/root_lv と入力します。ここで重要なのは、このコマンドだけではファイルシステム自体は拡張されない点です。LV は論理アドレス空間が増えただけで、マウント先のファイルシステムがその領域を認識しないため、データ書き込み時にエラーが発生します。
ファイルシステムの拡張には、ext4 用と XFS 用で異なるツールを使用する必要があります。ext4 を使用している場合は resize2fs コマンドを実行し、LV のデバイスパスを指定することで同期してサイズ拡大を行います。このコマンドはオンライン(マウント状態)でも実行可能ですが、安全性確保のためには余裕を持って行うことが推奨されます。
sudo resize2fs /dev/data_vg/root_lv
一方、XFS を使用している場合は xfs_growfs コマンドを使用します。XFS は ext4 と異なり、ファイルシステム拡張時に論理ボリュームのデバイスパスではなく、マウントポイント(ディレクトリ)を指定する必要があります。これは XFS の内部構造がブロックアロケーションに依存しており、マウント状態でのメタデータ更新を前提としているためです。
sudo xfs_growfs /mnt/data_mount_point
もし単一の LV 内の容量不足に対して、VG に未割り当ての容量がない場合は、VG 自体の拡張が必要です。これは物理ディスクを追加して PV を作成し、それを VG に追加することで実現します。vgextend data_vg /dev/sdd1 のように実行し、新しい PV をプールに統合すると、LV が使用する余地が生まれます。このプロセスにより、ストレージプールの総容量が増加し、既存の LV や新規作成する LV に対して利用可能になります。
2026 年現在では、NVMe SSD の高速性を利用してキャッシュボリュームを LVM キャッシュとして構成する手法も一般的です。LVM Cache を使用すると、頻繁にアクセスされるデータを HDD 上の LV と SSD 上のキャッシュ LV に分けて管理し、パフォーマンスを向上させることができます。この場合、拡張手順は通常の LV 拡張と異なり、キャッシュプールへの追加容量指定が必要になります。
以下は、ストレージプールの拡張プロセスにおける重要なチェックポイントのリストです。
vgs コマンドで VG の未割り当て容量(VFree)を確認する。vgcfgbackup を実行し、新しい構成をバックアップする。また、VG の容量が不足している場合でも、lvconvert --type raid1 のように RAID モードに切り替えることで、既存の PV をミラーリングとして再利用し耐性を高めることができます。ただし、この操作には元の LV のコピーに時間がかかるため、夜間などメンテナンスウィンドウで行うことが推奨されます。
LVM 環境で最も注意が必要な作業が「ボリュームの縮小」です。拡張はオンラインで安全に行えますが、縮小はデータの破損やメタデータの不整合を引き起こす可能性が高く、慎重な手順と事前バックアップが必須となります。特に XFS ファイルシステムは設計上、容量を小さくする機能を持っていないため、縮小を試みると即座にエラーが発生し、作業が中断されます。
ext4 ファイルシステムの場合、resize2fs コマンドを使用して縮小可能です。ただし、これはオンラインではリスクが高いため、原則としてアンマウント(オフライン)状態で行う必要があります。手順としては、まずファイルを退避させ、システムをリブートしてシングルユーザーモードまたはライブメディアから起動し、ファイルシステムを確認した上で縮小コマンドを実行します。
sudo umount /mnt/data_mount_point
sudo e2fsck -f /dev/data_vg/root_lv
sudo resize2fs /dev/data_vg/root_lv 50G
この際、resize2fs はファイルシステムのブロックサイズを確認し、指定したサイズがデータ保持に必要な最小容量より小さい場合は自動でエラーを返します。しかし、ファイルシステム内の断片化状況やメタデータの位置によっては、理論上の最小値より多くの領域が必要になるケースがあり、計算誤りによる破損リスクがあります。
XFS ファイルシステムの縮小は xfs_growfs の逆操作のように思われますが、実は xfs_admin -d などのコマンドで物理容量を調整することはできません。2026 年時点でも XFS の仕様上、サイズ縮小機能は実装されていません。これは、XFS がメタデータをファイルシステムの末尾に配置し、拡張時にのみデータを書き込む設計のためです。縮小を行うには、一旦データを別のストレージへ移動させ、LV を再作成する手間が必要です。
したがって、縮小を伴うリサイズ計画を立てる際は、以下のリスク管理手順を厳守してください。
dd コマンドまたは rsync でデータ全体のイメージを作成する。fsck や xfs_repair を事前実行して破損がないか確認する。データ移行による再構築の手順は以下の通りです。まず、容量の余裕がある別の LV または外部ストレージを用意します。その後、元 LV のファイルをすべてコピーし、元の LV を削除(lvremove)した後、新しいサイズで再度作成します。このプロセスは一見単純ですが、膨大なデータ量の場合には数時間かかる可能性があり、ネットワーク転送速度やディスク I/O パフォーマンスがボトルネックになることがあります。
また、LVM のメタデータ領域自体も縮小できるかどうか検討する必要があります。pvresize コマンドを使用することで、物理ボリュームのサイズを調整できますが、これも同様にバックアップと慎重な操作が必要です。2026 年時点では、Btrfs ファイルシステムのように、ネイティブでスナップショットとリサイズ機能を備えた選択肢も増えています。しかし、既存の LVM + ext4/XFS 環境を変更するコストを考慮すると、縮小は最後の手段として位置づけるのが無難です。
LVM のスナップショット機能は、システムアップデートや設定変更前のセーフティネットとして極めて有効なツールです。これは「コピーオンライト(COW: Copy-On-Write)」という仕組みを採用しており、元のデータの全コピーを行うのではなく、変更されたブロックのみを新しい領域に記録します。この方式により、数十 GB のデータでも数 MB の容量のスナップショットを作成することが可能で、ストレージ効率と回復速度の両面で優れています。
スナップショット作成は lvcreate コマンドに --snapshot オプションを追加することで実行できます。例えば、/dev/data_vg/root_lv に対して 10GB のスナップショットを作成する場合は以下のようになります。
sudo lvcreate -L 10G --name root_snap --snapshot /dev/data_vg/root_lv
作成されたスナップショットは /dev/data_vg/root_snap という経路でアクセス可能ですが、通常はマウントして直接読み書きを行うことはできません。これは COW 方式の特性上、元のボリューム(オリジナル)とスナップショットが同じデータブロックを参照しているためです。もしスナップショット上でデータを書き込むと、そのブロックは自動的に新しい領域にコピーされ、元データとの差分管理が行われます。
この機能を利用した典型的なユースケースは、システムアップデート前の状態保存です。例えば、パッケージ管理者(apt や dnf)による OS 更新を行う前に LVM スナップショットを作成しておけば、更新後にシステムが起動しなくなった場合でも、スナップショットに戻して復旧が可能です。2026 年現在では、自動バックアップツールとの連携も強化されており、lvm-snapshot ユーティリティが標準パッケージに含まれるケースもあります。
ただし、COW 方式には性能上の制約があります。スナップショット作成直後は元のデータへのアクセス効率は維持されますが、頻繁に書き込みが行われるとスナップショット領域(メタデータ)が飽和し、「スナップショットの完全な破損」を引き起こす可能性があります。これを防ぐため、スナップショット作成時に十分な容量を確保することが重要です。また、パフォーマンス低下を避けるため、スナップショットは読み取り専用として使用し、書き込みが必要な場合はマウント後にコピーを作成するか、別ボリュームへ移行するのがベストプラクティスです。
スナップショットの管理と削除には以下の手順が用いられます。
lvs -o +snap_used コマンドでスナップショット領域の使用率を確認する。lvremove /dev/data_vg/root_snap で即座に削除可能。以下は LVM スナップショットと Btrfs スナップショットの比較表です。両者ともスナップショット機能を提供しますが、実装方式に明確な違いがあります。
| 項目 | LVM スナップショット (COW) | Btrfs ネイティブ スナップショット |
|---|---|---|
| 作成時間 | 高速(メタデータのみ更新) | 高速(コピーオンライト共有) |
| 容量消費 | 変更量に応じて増加(上限あり) | 変更量に応じて増加(自動管理) |
| 読み取り性能 | オリジナルとの差分で若干低下 | オリジナルと同等(写し込み) |
| 整合性 | バックアップ時のスナップショットが独立 | サブボリュームとして永続的に保持可能 |
| 可用性 | 元ボリューム依存(削除不可) | 独立したサブボリュームとして管理可 |
LVM のスナップショットは、元ボリュームが破損すると参照先を失うため、重要なデータに対しては外部へのエクスポート(dd や rsync)も併用するのが安全です。また、2026 年時点では、クラウドストレージ連携による自動バックアップ戦略との組み合わせも推奨されており、オンプレミス LVM スナップショットを「ローカルフェイルオーバー」として位置づける運用が増えています。
LVM は単独でのボリューム管理だけでなく、RAID(Redundant Array of Independent Disks)機能とも親和性が高く、データ保護とパフォーマンス向上を両立させる構成が可能です。Linux における RAID 構成には、主に「mdadm」によるカーネルレベルのソフトウェア RAID と、「dm-raid」と呼ばれる LVM レベルでの RAID の 2 つのアプローチがあります。
mdadm を利用する場合、まず物理ディスクを md デバイス(例:/dev/md0)として RAID1 や RAID5 に構成し、その上に LVM の PV を作成します。この方式は OS 起動時にも RAID が認識されており、LVM メタデータ保護の観点からは極めて堅牢です。特に 2026 年時点では NVMe SSD の高速性を活かした RAID0(ストライピング)構成が、データベースや AI トレーニング用ストレージで広く採用されています。
sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1
sudo pvcreate /dev/md0
sudo vgextend data_vg /dev/md0
一方、LVM 自体の機能である dm-raid を利用する方法もあります。これは物理ディスクを直接使用し、LV の作成時に RAID モード(mirror, raid4, raid5, raid6)を指定して構築します。mdadm との違いは、RAID メタデータが LVM メタデータと統合される点です。これにより、管理コマンドの統一性が高まりますが、LVM の依存度が高まるため、LVM コンポーネントに障害が発生すると RAID 全体にも影響を及ぼす可能性があります。
以下は、RAID 構成における主要なモードとその用途を示した表です。
| RAID モード | 冗長性 | パフォーマンス | 推奨用途 | 最小ディスク数 |
|---|---|---|---|---|
| RAID0 (Striping) | なし | 高い(並列化) | キャッシュ、一時データ | 2 |
| RAID1 (Mirror) | あり(N-1) | 中(書き込み遅延) | OS ドライブ、重要データ | 2 |
| RAID5 | あり(N-1) | 中(読み出し高速) | ファイルサーバー、一般保存 | 3 |
| RAID6 | あり(N-2) | 低(計算オーバーヘッド) | アーカイブ、大容量 HDD | 4 |
LVM + RAID を組み合わせたハイブリッド構成では、パフォーマンスが必要な LV は RAID0 で高速化し、重要なデータは RAID1 に配置するなど、用途に応じた使い分けが可能です。また、2026 年現在では、ZFS や Btrfs のような次世代ファイルシステムが LVM の代わりに使用されるケースも増えていますが、既存の Linux サーバー資産を維持する場合、LVM と mdadm の組み合わせは依然として標準的な選択肢です。
さらに、LVM のキャッシュ機能(lvconvert --type cache-pool)を RAID 構成と併用することで、HDD 上の RAID5/RAID6 構成でも SSD キャッシュにより I/O レイテンシを改善できます。これは、コストパフォーマンスを重視する環境において非常に有効です。ただし、キャッシュ設定には SSD の寿命管理(TRIM 対応など)も考慮する必要があり、LVM2 2.03.x 以降ではキャッシュの自動最適化機能が提供されています。
Q1: LVM を使用していてもディスクが故障したらデータは守られますか?
A1: LVM 単体では RAID やミラーリング機能を備えていないため、物理ディスクの故障によりデータ喪失が発生するリスクがあります。データ保護には dm-raid モードの使用や mdadm との併用、あるいは定期的なバックアップが必須となります。LVM は「容量管理」のための技術であり、「冗長化」は別途実装する必要があります。
Q2: スナップショットを作成するとシステムに負荷がかかりますか? A2: 作成直後は COW メタデータの更新により若干の I/O オーバーヘッドが発生しますが、通常の使用では体感レベルで影響はありません。ただし、大量の書き込みが行われるとスナップショット領域が飽和し、元ボリュームへの書き込み阻止(full snapshot)が発生する可能性があるため、容量管理を徹底してください。
Q3: Ubuntu のインストーラーで LVM を選択しましたが、コマンドが使えません。
A3: インストール時に自動設定された場合は lvm2 パッケージがインストール済みです。もしコマンドが見つからない場合は sudo apt install lvm2 でパッケージを追加してください。また、Ubuntu 24.04 では Btrfs がデフォルトのファイルシステムとして選べるため、LVM の設定とは別に確認が必要です。
Q4: XFS ファイルシステムの縮小は絶対にできないのですか?
A4: 現状の仕様では xfs_growfs の逆操作(縮小)はサポートされていません。これはメタデータの配置構造上の問題によるもので、将来的なアップデートで追加される可能性は低いです。縮小が必要な場合は、データを移行して LV を再作成するしかありません。
Q5: LVM メタデータが破損した場合の復旧手順を教えてください。
A5: まず vgck コマンドでメタデータの整合性を確認します。問題がある場合、vgcfgrestore コマンドを使用して /etc/lvm/backup に保存されたバックアップファイルから復元を試みます。それでも復旧できない場合は vgreduce --removemeta を使用して強制リセットを行う必要がありますが、これはデータ消失のリスクを伴います。
Q6: LVM の物理拡張(PE)サイズを変更できますか?
A6: VG 作成時に -s オプションで指定可能です(例:-s 1M)。ただし、一度設定した PE サイズは後から変更できません。LVM2 2.03.x 以降ではデフォルトの 4MB が多くの環境で最適化されているため、特別な理由がない限り変更しないのが推奨されます。
Q7: LVM と ZFS を併用することは可能ですか? A7: 理論上は可能ですが、非推奨です。ZFS は独自のブロック管理を行うため、LVM の抽象化レイヤーを介するとパフォーマンス低下やデータ整合性の問題が発生する可能性があります。どちらか一方を採用し、ストレージ設計の基盤として統一するのが望ましいです。
Q8: LVM スナップショットと Btrfs サブボリュームの違いは? A8: LVM スナップショットは元ボリュームに依存し、削除不可です。Btrfs は独立したサブボリュームとして扱え、コピーやマウントが柔軟に行えます。LVM が OS レベルの管理に特化しているのに対し、Btrfs はファイルシステムレベルで高度な機能を提供します。
Q9: 仮想環境(KVM/QEMU)内でも LVM を使用できますか? A9: はい、可能です。ただし、ホスト側がブロックデバイスとして LVM LV を提供する場合、ゲスト OS 内部でのパーティション管理は必要なくなります。これはストレージの動的割り当てを可能にし、リソース効率を高めます。
Q10: LVM の設定変更後、再起動しても反映されますか?
A10: lvcreate や vgextend での変更は永続的ですが、ファイルシステムのマウント情報は /etc/fstab に記載する必要があります。LVM 自体の構成情報はメタデータとして保存されるため、再起動後も自動的に復元されますが、マウント設定忘れに注意してください。
本記事では、Linux LVM(Logical Volume Manager)を使った柔軟なパーティション管理について、2026 年時点の最新情報を反映して詳細に解説しました。LVM は従来の固定パーティション管理の欠点を補完し、ディスク容量の動的拡張やスナップショット機能により、システム運用の信頼性を大幅に向上させる技術です。
記事全体を総括する主なポイントは以下の通りです。
pvcreate, vgcreate, lvcreate の基本手順と、Ubuntu/Fedora/RHEL における設定の違いを把握する。LVM を適切に設計・運用することは、システム管理者としてのスキル向上だけでなく、2026 年以降の複雑化するストレージ環境においても安定したサービス提供を可能にする基盤となります。各セクションで解説した具体的なコマンドや設定値を実際の環境で試し、自分のワークフローに合った最適な構成を見つけてください。安全で柔軟なストレージ運用の実現に向けて、本ガイドが参考になれば幸いです。
この記事に関連するストレージの人気商品をランキング形式でご紹介。価格・評価・レビュー数を比較して、最適な製品を見つけましょう。
ストレージをAmazonでチェック。Prime会員なら送料無料&お急ぎ便対応!
※ 価格・在庫状況は変動する場合があります。最新情報はAmazonでご確認ください。
※ 当サイトはAmazonアソシエイト・プログラムの参加者です。
SSDケース 安定感◎
M.2 SSDを外付けケースに換装する際に使ってみた。USB3.2 Gen2接続で転送速度も十分だし、アルミ製でしっかりしてるから安定感がある。UASP対応でちょっと速くなったかも。2230/2242/2260/2280に対応してるのも便利。M key/B+M key SSDも使えるみたいだし、とり...
4K編集者、ついに手に入れた!SATECHI SSDケース、冷却性能に惚れた!
4K動画編集のためにPCを組んだばかりで、ストレージの選択に悩まされてたんだけど、セールでこのSATECHIのミニSSDエンクロージャーが安くなっていたから、ついつい衝動買い…いや、推せる!買っちまった!開封した瞬間から、パッケージングの質感に惹かれたんだよね。Satechiらしい、シンプルで洗練さ...
4K動画編集、ストレスフリーに!AGI外付けSSD、初の導入で大満足
初めて4K動画編集に挑戦しようと思い、外付けSSDを導入することにしました。予算を抑えつつ、速度も重視してAgiの1TB ED198に決めました。開封してみると、コンパクトでスタイリッシュなアルミケースが気に入りました。USB-C to Type-C/Aケーブルも付属しており、PS5との接続もスムー...
PS5/PS4 ゲーミング快適化!SSD
PS5のロードがマジで速い!PS4でも差がわかるから、ゲーム体験がグッと良くなった。容量も1TBあるから、好きなゲームをたくさん入れても余裕。USB3.2Gen1に対応してるのも嬉しいポイント。メーカー動作確認済みだから安心して使えるね
ゲームのロードが劇的に改善!自作PCの相棒に最適SSD
自作PCに挑戦して初めて外付けSSDを購入しました。きっかけは、以前使っていたHDDが容量不足で、ゲームのインストールやデータのバックアップに困っていたからです。特に最近プレイしているゲームはデータ量が大きく、ロード時間も気になっていたので、思い切ってSSDに換えてみることにしました。 パッケージ...
RAIDの沼にハマっちゃった!ORICOケース、神!
前々からRAIDってことで気になってたんだけど、なかなか良いケースに出会えなくてね。以前に使ってたケースは、安定性にちょっと不安があって、データのバックアップが心配だったんだよね。んで、今回ORICOのこのケースに乗り換えたんだけど…もう感動レベル! まずね、コンパクトさが最高。前のが大きくて邪魔...
PS5のゲーム体験が劇的に変わった!Hanye内蔵SSD、これは神商品です!
子供たちがPS5でゲームをするのが大好きで、私もたまに一緒にプレイするんですが、以前のSSDだとロード時間が長くて本当にストレスでした。「ママ、ロード長いよー!」って子供の声が耳に痛かったんです。そこで、思い切ってHanyeの内蔵SSD 2TBに買い替えを決意しました。 以前使っていたのは、某有名...
ゲーミングPCの速度が爆上がり!Acer M.2 SSDで作業効率がマジで変わる!
はい、皆さん、衝撃的な体験を報告します!以前使っていたSSDが、とうとう寿命を迎えてしまったので、買い替えを決意。予算は1TB程度で、とにかく高速なものが良いと判断して、Acer Predator M.2 SSD GM7000 1TBを購入しました。箱を開けて最初に感じたのは、しっかりとした重みと、...
快適なゲーミング体験を提供するWD Blue SN580 SSD
WD Blue SN580 SSDの導入は、私のコンピューターの高速化に大きな役割を果たしました。特にゲーミング中に起こる読み込み遅延が顕著に改善され、よりスムーズなプレイ体験を提供してくれました。具体的には、以前のHDDからSSDへの移行ではありませんでしたが、この製品の導入後、起動時間が大幅に短...
超薄型ヒートシンク、値段相応の冷却性能。期待はずれでも、価格を考えると…
散々迷った末に、M.2 SSDの冷却対策としてこのヒートシンクを購入しました。前にもSSDを自作PCに組み込んでいるので、温度管理は重要だと感じていたんです。候補としては、もう少し高価なアルミヒートシンクとか、水冷式も検討していたんですが、予算を考えるとここは妥協するか…という思いで、この製品に落ち...