「LVM」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
 
(→‎LVM の構成要素: 訳を修正)
 
(4人の利用者による、間の50版が非表示)
1行目: 1行目:
[[Category:Arch の入手とインストー]]
+
[[Category:ストジ仮想化]]
[[Category:ファイルシステム]]
 
[[cs:LVM]]
 
 
[[de:LVM]]
 
[[de:LVM]]
 
[[en:LVM]]
 
[[en:LVM]]
 
[[es:LVM]]
 
[[es:LVM]]
[[fr:LVM]]
+
[[pt:LVM]]
[[it:LVM]]
+
[[zh-hans:LVM]]
[[ru:LVM]]
 
[[tr:LVM]]
 
[[zh-CN:LVM]]
 
 
{{Related articles start}}
 
{{Related articles start}}
  +
{{Related|LVM に Arch Linux をインストールする}}
 
{{Related|ソフトウェア RAID と LVM}}
 
{{Related|ソフトウェア RAID と LVM}}
{{Related|LUKS によるシステム暗号化}}
 
 
{{Related|dm-crypt/システム全体の暗号化#LVM on LUKS}}
 
{{Related|dm-crypt/システム全体の暗号化#LVM on LUKS}}
 
{{Related|dm-crypt/システム全体の暗号化#LUKS on LVM}}
 
{{Related|dm-crypt/システム全体の暗号化#LUKS on LVM}}
  +
{{Related|:en:Resizing LVM-on-LUKS}}
  +
{{Related|:en:Create root filesystem snapshots with LVM}}
 
{{Related articles end}}
 
{{Related articles end}}
 
[[Wikipedia:ja:論理ボリュームマネージャ|Wikipedia]] より:
 
[[Wikipedia:ja:論理ボリュームマネージャ|Wikipedia]] より:
  +
:LVM は [[Wikipedia:ja:Linuxカーネル|Linux カーネル]]の[[Wikipedia:logical volume management|論理ボリュームマネージャ]]です。ディスクドライブと大容量記憶装置を管理します。
 
  +
:論理ボリュームマネージャ (Logical Volume Manager, LVM) とは、[[Wikipedia:ja:Linuxカーネル|Linux カーネル]]に[[Wikipedia:ja:論理ボリュームマネージャ|論理ボリューム管理]]を提供する[[Wikipedia:device mapper|デバイスマッパー]]フレームワークです。
  +
  +
== 背景 ==
   
 
=== LVM の構成要素 ===
 
=== LVM の構成要素 ===
   
Logical Volume Management は Linux カーネルの [http://sources.redhat.com/dm/ device-mapper] 機能を利用して基になっているディスクレイアウトから独立したパーティションのシステムを提供します。LVM を使うことで記憶領域を抽象化することで、(使っているファイルシステムで可能限り)簡単にパーティションを拡大・縮小たりディク上十分な連続した領域があるかどうか心配することなく、た、fdisk したいディスクが使用中だったり (そしてカーネが新旧どちらのパーティョンーブルを使っているかわからなかったり) 他のパーティションなくてはならないという問題に煩わされことなく、パーティションを追加・削除することが可能になります。これは厳密に言えば管理のしやすさの問題です: LVM はセキュリティを追加することはありません。しかしながら、私達の使っている他の2つの技術と上手く収まりがつきます。
+
Logical Volume Management は Linux カーネルの [http://sources.redhat.com/dm/ device-mapper] 機能を利用して底のディスクレイアウトから独立した[[パーティション]]のシステムを提供します。LVM を使うことでストレージを抽象化し「仮想的なパーティション作成[[#論ボリュームとファイルシテムのサイズを別々変更する|拡張/縮小]]を容易にし (ファイルシ制限ける可能はあります)
   
  +
仮想パーティションにより、パーティションディスク上に十分な連続領域が存在するかどうかを心配したり、使用中のディスクに fdisk してしまったり (そして、カーネルが古いパーティションテーブルと新しいほうのどちらを使っているか悩んだり)、他のパーティションを移動してスペースを作らないといけなかったりすることなく、追加と削除ができるようになります。
LVM の基本的な構成要素は以下の通りです:
 
   
  +
LVM の基本的構成要素:
* '''物理ボリューム (PV, Physical volume)''': ハードディスク上のパーティション (もしくはハードディスクそれ自体、ループバックファイル) です。これをまとめてボリュームグループを作ることができます。特別なヘッダーがあり物理エクステントに分割されます。物理ボリュームについてはハードドライブを構成するための大きなブロックとして考えて下さい。
 
  +
* '''ボリュームグループ (VG, Volume group)''': ストレージボリューム(つまり一つのディスク)として使われる物理ボリュームの集まりです。ボリュームグループには論理ボリュームが含められます。ボリュームグループはハードドライブとして考えて下さい。
 
  +
; 物理ボリューム (Physical Volume, PV): LVM によって利用可能な Unix ブロックデバイスノード。例: ハードディスク、[[MBR]] か [[GPT]] のパーティション、ループバックファイル、デバイスマッパーデバイス (例: [[dm-crypt]])。PV は LVM のヘッダをホストします。
* '''論理ボリューム (LV, Logical volume)''': ボリュームグループの中にある"仮想/論理パーティション"であり、物理エクステントで構成されます。論理ボリュームのことは通常のパーティションみたいなものと考えて下さい。
 
  +
; ボリュームグループ (Volume Group, VG): LV のコンテナとして機能する、PV の集まり。VG から PE を割り当てて LV を構成します。
* '''物理エクステント (PE, Physical extent)''': 論理ボリュームに割り当てるごとができるディスクの欠片 (通常 4MiB) です。物理エクステントはどのパーティションにも割り当てることが出来るディスクのパーツと考えて下さい。
 
  +
; 論理ボリューム (Logical Volume, LV): VG 内に存在する「仮想/論理パーティション」であり、PE で構成されます。LV は、物理パーティションに似た Unix ブロックデバイスです。例えば、LV は[[ファイルシステム]]で直接フォーマットできます。
  +
; 物理エクステント (Physical Extent, PE): LV に割り当てることのできる、PV 内の最小の連続するエクステント (範囲) です。PE は、任意の LV に割り当てることのできる、PV のパーツだと考えてください。
   
 
例:
 
例:
'''Physical disks'''
 
 
Disk1 (/dev/sda):
 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 
|Partition1 50GB (Physical volume) |Partition2 80GB (Physical volume) |
 
|/dev/sda1 |/dev/sda2 |
 
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
 
 
Disk2 (/dev/sdb):
 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 
|Partition1 120GB (Physical volume) |
 
|/dev/sdb1 |
 
| _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _|
 
   
  +
{{Text art|<nowiki>
'''LVM logical volumes'''
 
  +
物理ディスク
 
  +
Volume Group1 (/dev/MyStorage/ = /dev/sda1 + /dev/sda2 + /dev/sdb1):
 
  +
ディスク1 (/dev/sda):
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 
  +
┌──────────────────────────────────────────┬─────────────────────────────────────────┐
|Logical volume1 15GB |Logical volume2 35GB |Logical volume3 200GB |
 
  +
│ パーティション1 50 GiB (物理ボリューム) │ パーティション2 80 GiB (物理ボリューム) │
|/dev/MyStorage/rootvol|/dev/MyStorage/homevol |/dev/MyStorage/mediavol |
 
|_ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
+
/dev/sda1 /dev/sda2
  +
└──────────────────────────────────────────┴─────────────────────────────────────────┘
  +
  +
ディスク2 (/dev/sdb):
  +
┌──────────────────────────────────────────┐
  +
│ パーティション1 120 GiB (物理ボリューム) │
  +
│ /dev/sdb1 │
  +
└──────────────────────────────────────────┘
  +
</nowiki>}}
  +
  +
{{Text art|<nowiki>
  +
LVM 論理ボリューム
  +
  +
ボリュームグループ1 (/dev/MyVolGroup/ = /dev/sda1 + /dev/sda2 + /dev/sdb1):
  +
┌─────────────────────────┬─────────────────────────┬──────────────────────────┐
  +
│ 論理ボリューム1 15 GiB │ 論理ボリューム2 35 GiB │ 論理ボリューム3 200 GiB │
  +
│ /dev/MyVolGroup/rootvol │ /dev/MyVolGroup/homevol │ /dev/MyVolGroup/mediavol │
  +
└─────────────────────────┴─────────────────────────┴──────────────────────────┘
  +
</nowiki>}}
  +
  +
{{Note|論理ボリュームは {{ic|/dev/''ボリュームグループ名''/''論理ボリューム名''}} と {{ic|/dev/mapper/''ボリュームグループ名-論理ボリューム名''}} の両方からアクセス可能です。しかし、{{man|8|lvm|VALID NAMES}} は「ソフトウェアとスクリプト」においては前者の形式を推奨しています。後者は「内部での使用」を意図しており、「リリースやディストリビューション間で変わる」可能性があるからです。}}
   
 
=== 利点 ===
 
=== 利点 ===
   
LVM には通常のハードドライブのパーティションを使うよりも幅広い柔軟性があります:
+
LVM には通常のハードドライブのパーティションをただ使うよりも幅広い柔軟性があります:
  +
 
* 多数のディスクを一つの大きなディスクとして使えます。
 
* 多数のディスクを一つの大きなディスクとして使えます。
 
* 複数のディスクにまたがる論理ボリュームを作れます。
 
* 複数のディスクにまたがる論理ボリュームを作れます。
 
* 小さな論理ボリュームを作成し、満杯になったら"動的に"リサイズできます。
 
* 小さな論理ボリュームを作成し、満杯になったら"動的に"リサイズできます。
 
* ディスクの順番と関係なく論理ボリュームをリサイズできます。VG における LV の位置に依存しないので、周辺に空き容量を取る必要がありません。
 
* ディスクの順番と関係なく論理ボリュームをリサイズできます。VG における LV の位置に依存しないので、周辺に空き容量を取る必要がありません。
* オンラインで論理・物理ボリュームをリサイズ・作成・削除できます。ボリューム上のファイルシステムもリサイズする必要がありますが、オンラインリサイズをサポートしているファイルシステムもあります。
+
* オンラインで論理・物理ボリュームをリサイズ・作成・削除できます。ボリューム上のファイルシステムもリサイズする必要がありますが、オンラインリサイズをサポートしているファイルシステムもあります (ext4 など)
 
* サービスによって使われている LV を、サービスを再起動する必要なく他のディスクへオンラインで移行することができます。
 
* サービスによって使われている LV を、サービスを再起動する必要なく他のディスクへオンラインで移行することができます。
 
* スナップショットを使うことでファイルシステムのフローズンコピーをバックアップすることができます。サービスを落とす時間を最小限にできます。
 
* スナップショットを使うことでファイルシステムのフローズンコピーをバックアップすることができます。サービスを落とす時間を最小限にできます。
  +
* 起動時にキーを複数回入力することなく、個別のボリュームをアンロック ([[dm-crypt/システム全体の暗号化#LVM on LUKS|LUKS 上に LVM を作成]])。
 
  +
* 頻繁に使用されるデータをキャッシュする組み込みサポート ({{man|7|lvmcache}})。
以上のことはサーバー環境でとても役に立ちます。デスクトップでは利点が薄れるかもしれませんが、これらの機能を使う価値があるかどうか決めるのはあなたです。
 
   
 
=== 欠点 ===
 
=== 欠点 ===
   
  +
* システムのセットアップに追加の手順が必要で、やや複雑。(複数の) デーモンを継続的に実行する必要あり。
* (ほとんど) Linux でしか使えない。他の OS (FreeBSD, Windows..) には公式なサポートがない。
 
  +
* デュアルブートする場合、Windows は LVM をサポートしていないことに注意してください。Windows からは LVM パーティションにアクセスできません。サードパーティのソフトウェアによって、特定の種類の LVM セットアップをマウントできる場合があります。[https://www.paragon-software.com/home/linuxfs-windows/]
* システムのセットアップに追加の手順が必要で、やや複雑。
 
  +
* 物理ボリュームが RAID-1、RAID-5、RAID-6 のどれにもない場合、論理ボリュームが複数の非冗長ディスクにまたがっている (あるいは、拡張されている) と、1つ以上のディスクが失われると1つまたは複数の論理ボリュームが失われる可能性があります。
* [[Btrfs|btrfs]] ファイルシステムを使用する場合、サブボリューム機能があるので柔軟性のあるレイアウトを作ることができる。そのため、LVM の抽象レイヤーを使う必要性が少なくなる。
 
  +
* 論理ボリュームマネージャによって使用されている領域 (つまり、論理ボリュームのために使用されている物理ボリューム) は (簡単には) 縮小できません。物理エクステントが物理ボリューム上に末尾まで散らばっている場合、Arch Wiki 上で提供されているスクリプトでは物理ボリュームを縮小することはできません。他のオペレーティングシステム (例: Microsoft Windows) とデュアルブートしたい場合、Microsoft Windows のために残される唯一のスペースは、LVM によって使用されない、あるいは物理ボリュームとして使用されない領域となります。
   
== Arch Linux を LVM にインストールする ==
+
== インストール ==
   
  +
{{pkg|lvm2}} パッケージが[[インストール]]されていることを確認してください。
インストール作業の[[Partitioning|パーティション分割]]と[[File Systems#デバイスのフォーマット|フォーマット]]の手順の間に LVM ボリュームを作成する必要があります。root ファイルシステムにするパーティションを直接フォーマットする代わりに、論理ボリューム (LV) の中に作成します。
 
   
  +
LVM ボリュームを [[initramfs]] によってアクティブ化しない場合、({{pkg|lvm2}} によって提供される) {{ic|lvm2-monitor.service}} を[[有効化]]してください。
{{pkg|lvm2}} パッケージを[[pacman|インストール]]してください。
 
   
  +
== ボリューム操作 ==
概略:
 
* PV を入れるパーティションを作成します。パーティションのタイプは 'Linux LVM' に設定してください、MBR を使っている場合は 8e、GPT の場合は 8e00 です。
 
* 物理ボリューム (PV) を作成します。ディスクが一つしかない場合は一つの大きなパーティションに一つの PV を作成するのが良いでしょう。ディスクが複数ある場合はそれぞれにパーティションを作成してパーティション毎に PV を作ることができます。
 
* ボリュームグループ (VG) を作成して全ての PV を追加します。
 
* VG の中に論理ボリューム (LV) を作成します。
 
* [[ビギナーズガイド]]の "パーティションのフォーマット" の手順に進んで下さい。
 
* ビギナーズガイドの “Initial ramdisk 環境の作成” まで行ったら、{{ic|mkinitcpio.conf}} に lvm フックを追加してください (詳細は下を見て下さい)。
 
   
  +
=== 物理ボリューム ===
{{Warning|[[GRUB Legacy]] は LVM をサポートしていないため、LVM の中に {{ic|/boot}} を置くことはできません。[[GRUB|GRUB]] を使っている場合はこの制限はありません。GRUB Legacy を使う必要があるときは、{{ic|/boot}} パーティションを分割して作成し直接フォーマットするようにしてください。}}
 
   
=== 物理ボリュームの作成 ===
+
==== 作成 ====
   
  +
{{ic|/dev/sda1}} 上に PV (物理ボリューム) を作成するには:
適切なパーティションを指定するようにしてください。'Linux LVM' タイプのパーティションを見つけるには:
 
* MBR システム: {{Ic|fdisk -l}}
 
* GPT システム: {{Ic|lsblk}} からの {{Ic|gdisk -l ''disk-device''}}
 
   
  +
# pvcreate /dev/sda1
パーティションに物理ボリュームを作成してください:
 
# pvcreate ''disk-device''
 
''disk-device'' は {{ic|/dev/sda2}} などに置き換えてください。このコマンドはパーティションにヘッダーを作成し LVM に使えるようにします。次のコマンドで作成した物理ボリュームを確認できます:
 
# pvdisplay
 
   
  +
PV が作成されたかどうかは、以下のコマンドを使って確認できます:
{{Note|SSD を使っているなら {{ic|pvcreate --dataalignment 1m /dev/sda2}} を使用してください (1MiB 境界で整列させる)、[http://serverfault.com/questions/356534/ssd-erase-block-size-lvm-pv-on-raw-device-alignment ここ] を参照。}}
 
   
  +
# pvs
=== ボリュームグループの作成 ===
 
   
  +
==== 拡張 ====
次は物理ボリュームの上にボリュームグループを作成します。まず新しいパーティションの一つにボリュームグループを作成してから、そこに入れたい他の全ての物理ボリュームを追加します:
 
# vgcreate VolGroup00 /dev/sda2
 
# vgextend VolGroup00 /dev/sdb1
 
また、ボリュームグループを作成する際に、VolGroup00 以外の好きな名前を付けることもできます。ボリュームグループがどうなっているか確認するには次のコマンドを使います:
 
# vgdisplay
 
   
  +
物理ボリュームのあるデバイスのサイズを増やした後、または減らす前に、{{man|8|pvresize}} を使って PV を拡大/縮小する必要があります。
{{Note|必要ならば複数のボリュームグループを作成することもできますが、それだと全てのストレージを一つのディスクにまとめることはできなくなります。}}
 
   
  +
[[パーティション]]を大きくした後に {{ic|/dev/sda1}} 上の PV を拡張するには、以下を実行します:
=== 論理ボリュームの作成 ===
 
   
  +
# pvresize /dev/sda1
そしてボリュームグループには論理ボリュームを作る必要があります。論理ボリュームを作成するには次のコマンドを使います。新しい論理ボリュームの名前、サイズ、そしてどのボリュームグループに作るかを指定してください:
 
# lvcreate -L 10G VolGroup00 -n lvolhome
 
これで論理ボリュームが作成され {{ic|/dev/mapper/Volgroup00-lvolhome}} や {{ic|/dev/VolGroup00/lvolhome}} でアクセスできるようになります。ボリュームグループと同じく、論理ボリュームには好きな名前を命名できます。
 
   
  +
これは、自動的にデバイスのサイズを検出し、最大まで PV を拡張します。
論理ボリュームにスワップを作成するには、引数を追加する必要があります:
 
# lvcreate -C y -L 10G VolGroup00 -n lvolswap
 
{{Ic|-C y}} を使うことで連続するパーティションが作られます。スワップ領域を複数のディスクや飛び飛びの物理エクステントにまたがってパーティション分けすることはできません。
 
   
  +
{{Note|このコマンドは、ボリュームがオンラインの間も実行することができます。}}
ボリュームグループに残っている空き容量全てを使う論理ボリュームを作成するには、次のコマンドを使って下さい:
 
# lvcreate -l +100%FREE VolGroup00 -n lvolmedia
 
   
  +
==== 縮小 ====
作成した論理ボリュームは次のコマンドで確認できます:
 
# lvdisplay
 
   
  +
基底となるデバイスを縮小する前に物理ボリュームを縮小するには、パラメータ {{ic|--setphysicalvolumesize ''サイズ''}} を先のコマンドに追加してください。''例えば'':
{{Note|上のコマンドを実行するために ''device-mapper'' カーネルモジュールをロード ({{ic|modprobe dm-mod}}) しなくてはならない場合があります。}}
 
   
  +
# pvresize --setphysicalvolumesize 40G /dev/sda1
{{Tip|比較的小さな論理ボリュームを作ってから、後で必要になったときに拡大することも可能です。シンプリシティを尊ぶのなら、ボリュームグループに拡大のための空き容量をいくらか残しておきましょう。}}
 
   
  +
上記のコマンドは以下のエラーを出力する場合があります:
=== ファイルシステムの作成と論理ボリュームのマウント ===
 
   
  +
/dev/sda1: cannot resize to 25599 extents as later ones are allocated.
論理ボリュームは {{ic|/dev/mapper/}} や {{ic|/dev/''YourVolumeGroupName''}} に配置されているはずです。論理ボリュームを見つけられないときは、以下のコマンドを使ってデバイスノードを作成するためのモジュールをロードしてボリュームグループが使えるようにしてください:
 
  +
0 physical volume(s) resized / 1 physical volume(s) not resized
# modprobe dm-mod
 
# vgscan
 
# vgchange -ay
 
さて論理ボリュームにファイルシステムを作成して通常のパーティションとしてマウントすることが可能になりました (Arch linux のインストールをしているのならば、詳しくは[[Beginners' Guide#パーティションのマウント|パーティションのマウント]]を参照してください):
 
# mkfs.ext4 /dev/mapper/VolGroup00-lvolhome
 
# mount /dev/mapper/VolGroup00-lvolhome /home
 
   
  +
実際 ''pvresize'' は、新しい終了位置よりも後にエクステントが割り当てられている場合、PV の縮小を拒否します。十分な空き領域があるならば、前もって [[#物理エクステントを移動させる|pvmove]] を実行して、そのようなエクステントをボリュームグループ内の別の場所に移動させる必要があります。
{{Warning|マウントポイントを選択する時は、新しく作成した論理ボリュームを選択してください (次を使って下さい: {{ic|/dev/mapper/Volgroup00-lvolhome}})。論理ボリュームが作られている実際のパーティションを'''選択してはいけません''' (次は使わないで下さい: {{ic|/dev/sda2}})。}}
 
   
=== lvm フックを mkinitcpio.conf に追加する ===
+
===== 物理エステント移動させ=====
   
  +
空きエクステントをボリュームの末尾に移動させる前に、{{ic|pvdisplay -v -m}} を実行して物理セグメントを確認しなければなりません。以下の例では、1つの物理ボリュームが {{ic|/dev/sdd1}} 上に存在し、1つのボリュームグループ {{ic|vg1}} と1つの論理ボリューム {{ic|backup}} が存在しています。
{{Ic|udev}} と {{Ic|lvm2}} の [[mkinitcpio|mkinitcpio]] フックを有効にする必要があります。
 
   
  +
{{hc|# pvdisplay -v -m|
{{Ic|udev}} はデフォルトで有効になっています。以下のようにファイルを編集して {{Ic|block}} と {{Ic|filesystem}} の間に {{Ic|lvm2}} を入れて下さい:
 
  +
Finding all volume groups.
  +
Using physical volume(s) on command line.
  +
--- Physical volume ---
  +
PV Name /dev/sdd1
  +
VG Name vg1
  +
PV Size 1.52 TiB / not usable 1.97 MiB
  +
Allocatable yes
  +
PE Size 4.00 MiB
  +
Total PE 399669
  +
Free PE 153600
  +
Allocated PE 246069
  +
PV UUID MR9J0X-zQB4-wi3k-EnaV-5ksf-hN1P-Jkm5mW
  +
  +
--- Physical Segments ---
  +
Physical extent 0 to 153600:
  +
FREE
  +
Physical extent 153601 to 307199:
  +
Logical volume /dev/vg1/backup
  +
Logical extents 1 to 153599
  +
Physical extent 307200 to 307200:
  +
FREE
  +
Physical extent 307201 to 399668:
  +
Logical volume /dev/vg1/backup
  +
Logical extents 153601 to 246068
  +
}}
   
  +
{{ic|FREE}} な領域がボリュームを跨いで分かれて存在していることがわかります。物理ボリュームを縮小させるには、まず、すべての使用中セグメントを先頭に移動させなければなりません。
{{hc|/etc/mkinitcpio.conf:|<nowiki>HOOKS="base udev ... block lvm2 filesystems"</nowiki>}}
 
   
  +
ここで、最初の空きセグメントは 0 から 153600 にあり、153601 の空きエクステントが存在しています。この状態では、このセグメント番号を最後の物理エクステントから最初のエクステントに移動させることができます。なので、コマンドは以下のようになります:
その後、[[Mkinitcpio#イメージ作成とアクティベーション|initial ramdisk の作成]]を行なってから通常のインストールの手順に戻ることができます。
 
   
  +
{{hc|# pvmove --alloc anywhere /dev/sdd1:307201-399668 /dev/sdd1:0-92467|
== 設定 ==
 
  +
/dev/sdd1: Moved: 0.1 %
  +
/dev/sdd1: Moved: 0.2 %
  +
...
  +
/dev/sdd1: Moved: 99.9 %
  +
/dev/sdd1: Moved: 100.0 %
  +
}}
   
  +
{{Note|1=<nowiki/>
=== 高度なオプション ===
 
  +
* このコマンドは、399668 - 307201 + 1 = 92468 個の PE (物理エクステント) を最後のセグメント '''から''' 最初のセグメント '''へ''' 移動させます。これは、最初のセグメントが 153600 個の空き PE を囲っており、92467 - 0 + 1 = 92468 個の移動された PE を含むことができるため、可能なのです。
  +
* {{ic|--alloc anywhere}} オプションは、同じパーティション内で PE を移動させるので、使用されています。異なるパーティションの場合、先のコマンドは以下のようなものになるでしょう: {{bc|# pvmove /dev/sdb1:1000-1999 /dev/sdc1:0-999}}
  +
* このコマンドは、ボリュームが大きい場合、長い時間 (1~2時間) が掛かるかもしれません。このコマンドを [[tmux]] や [[GNU Screen]] のセッション内で実行するのが良いアイディアかもしれません。プロセスを望まない形で停止させてしまうと、致命的になる可能性があります。
  +
* 操作が完了したら、[[fsck]] を実行して、ファイルシステムが有効であることを確認してください。
  +
}}
   
  +
===== 物理ボリュームのサイズを変更する =====
(スナップショットに必要な)モニタリングが必要な場合は lvmetad を有効にしてください。{{ic|/etc/lvm/lvm.conf}} の {{ic|1=use_lvmetad = 1}} を設定することで有効にできます。現在はデフォルトで有効になっています。
 
   
  +
すべての空き物理セグメントを最後の物理エクステント上に移動したら、{{ic|vgdisplay}} を root 権限で実行して空き PE を確認してください。
自動的に有効になるボリュームを制限するには {{Ic|/etc/lvm/lvm.conf}} の {{Ic|auto_activation_volume_list}} を設定します。よくわからないときは、このオプションはコメントアウトしたままにしてください。
 
   
  +
そうしたら、先のあのコマンドを再び実行できます:
=== 論理ボリュームを拡大する ===
 
   
  +
# pvresize --setphysicalvolumesize ''サイズ'' ''物理ボリューム''
論理ボリュームを拡大するには、まず論理ボリュームを拡大させてから次に新しく作られた空き容量を使うようにファイルシステムを拡大させる必要があります。例えば ext3 が載った 15GB の論理ボリュームがあり 20G まで拡大したいとします。そうすると以下のコマンドを実行しなくてはなりません:
 
# lvextend -L 20G VolGroup00/lvolhome (or lvresize -L +5G VolGroup00/lvolhome)
 
# resize2fs /dev/VolGroup00/lvolhome
 
{{Ic|lvextend}} の代わりに {{Ic|lvresize}} を使うことも可能です。
 
   
  +
結果を確認しましょう:
ボリュームグループにある全ての空き容量を使うようにしたい場合は、次のコマンドを使って下さい:
 
# lvextend -l +100%FREE VolGroup00/lvolhome
 
   
  +
{{hc|# pvs|
{{Warning|ファイルシステムによっては拡大するとデータが消失したり、オンラインでの拡大をサポートしていません。}}
 
  +
PV VG Fmt Attr PSize PFree
  +
/dev/sdd1 vg1 lvm2 a-- 1t 500g
  +
}}
   
  +
===== パーティションのサイズを変更する =====
{{Note|ファイルシステムのリサイズを行わないと、以前のボリュームと同じサイズしか使えません (ボリュームは大きくなっていますが部分的にしか使えません)。}}
 
   
  +
最後に、お気に入りの[[パーティショニング#パーティショニングツール|パーティショニングツール]]を使ってパーティションを縮小させる必要があります。
=== 論理ボリュームを縮小する ===
 
   
  +
=== ボリュームグループ ===
基本的にファイルシステムは論理ボリュームと同じ大きさになっているので、まずファイルシステムを縮小してから次に論理ボリュームを縮小する必要があります。ファイルシステムによっては、先にファイルシステムをアンマウントする必要があるかもしれません。例えば ext3 が載った 15GB の論理ボリュームがあり 10G まで縮小したいとします。そうすると以下のコマンドを実行することになります:
 
# resize2fs /dev/VolGroup00/lvolhome 9G
 
# lvreduce -L 10G VolGroup00/lvolhome
 
   
  +
==== ボリュームグループを作成する ====
ここでファイルシステムを必要以上に縮小しているのは論理ボリュームを縮小するときにファイルシステムの末尾を偶発的に切り落とすことがないようにするためです。論理ボリュームを縮小した後に、論理ボリュームに残っている空き容量を満たすようにファイルシステムを拡大してください。{{Ic|lvreduce}} の代わりに {{Ic|lvresize}} を使うことも可能です。
 
# lvresize -L -5G VolGroup00/lvolhome
 
# resize2fs /dev/VolGroup00/lvolhome
 
   
  +
PV {{ic|/dev/sdb1}} を持つ VG (ボリュームグループ) {{ic|MyVolGroup}} を作成するには、以下を実行してください:
{{Warning|
 
* ファイルシステムのサイズをデータによって占められている容量よりも削減してはいけません、データを消失する可能性があります。
 
* ファイルシステムによっては縮小するとデータが消失したり、オンラインでの縮小をサポートしていません。
 
}}
 
   
  +
# vgcreate MyVolGroup /dev/sdb1
=== 論理ボリュームを削除する ===
 
   
  +
以下のコマンドを使うことで VG {{ic|MyVolGroup}} が作成されたことを確認できます:
{{Warning|論理ボリュームを削除する前に、データは全て他の場所に退避させてください、残っているデータは消去されます!}}
 
   
  +
# vgs
まず、削除したい論理ボリュームの名前を確認してください。システムにインストールされている全ての論理ボリュームのリストを表示するには次のコマンドを使います:
 
   
  +
VG の作成時に以下のようにすることで複数の PV をバインドすることができます:
# lvs
 
   
  +
# vgcreate MyVolGroup /dev/sdb1 /dev/sdb2
次に、削除する論理ボリュームのマウントポイントを確認して:
 
   
  +
==== ボリュームグループをアクティブ化する ====
$ df -h
 
   
  +
{{Note|{{ic|/etc/lvm/lvm.conf}} 内の {{ic|auto_activation_volume_list}} を設定することで、自動的にアクティブ化されるボリュームを制限することができます。疑っているならば、このオプションをコメントアウトしてみてください。}}
アンマウントしてください:
 
   
  +
# vgchange -a y MyVolGroup
# umount /your_mountpoint
 
   
  +
デフォルトでは、これにより該当するボリュームグループが再アクティブ化されます。例えば、仮にミラーでドライブ障害が発生し、そのドライブを交換したとすると、(1) {{ic|pvcreate}}、(2) {{ic|vgextend}}、(3) {{ic|vgreduce --removemissing --force}} を実行するでしょう。
最後に、論理ボリュームを削除してください:
 
   
  +
==== ボリュームグループを修復する ====
# lvremove /dev/yourVG/yourLV
 
   
  +
この例での破損したミラーアレイの再ビルドプロセスを開始するには、以下を実行します:
{{ic|y}} を入力することで実際に削除が実行されます。
 
   
  +
# lvconvert --repair /dev/MyVolGroup/mirror
{{ic|/etc/fstab}} を更新することを忘れないようにしましょう。
 
   
  +
以下で再ビルドプロセスをモニタリングできます (Cpy%Sync 列の出力):
論理ボリュームの削除を確認するには root で {{ic|lvs}} を実行します (このセクションの一番最初を参照)。
 
   
  +
# lvs -a -o +devices
=== ボリュームグループに物理ボリュームを追加する ===
 
   
  +
==== ボリュームグループを非アクティブ化する ====
まず使いたいブロックデバイスに新しい物理ボリュームを作成して、それからボリュームグループに追加してください:
 
   
  +
以下を実行してください:
{{bc|1=
 
# pvcreate /dev/sdb1
 
# vgextend VolGroup00 /dev/sdb1
 
}}
 
   
  +
# vgchange -a n MyVolGroup
これでボリュームグループの物理エクステントの総量が増えて、自由に論理ボリュームに割り当てることができるようになります。
 
   
  +
これは、ボリュームグループを非アクティブ化し、その VG を格納しているコンテナをアンマウントできるようにします。
{{Note|ストレージメディアの[[Partitioning|パーティションテーブル]]は LVM の下に置くのが良いと考えられています。適切なタイプコードを使って下さい: MBR なら {{ic|8e}}、GPT なら {{ic|8e00}}。}}
 
   
=== ボリュームグループからパーティション削除する ===
+
==== ボリュームグループの名前変更する ====
  +
  +
既存のボリュームグループの名前を変更するには {{man|8|vgrename}} コマンドを使用してください。
  +
  +
次のいずれかのコマンドにより、既存のボリュームグループ {{ic|MyVolGroup}} を {{ic|my_volume_group}} に名称変更します:
  +
  +
# vgrename /dev/MyVolGroup /dev/my_volume_group
  +
  +
# vgrename MyVolGroup my_volume_group
  +
  +
名前を変更したボリュームグループを参照している設定ファイル (例: {{ic|/etc/fstab}}、{{ic|/etc/crypttab}}) をすべてアップデートすることを忘れないでください。
  +
  +
==== ボリュームグループに物理ボリュームを追加する ====
  +
  +
まず、使用したいブロックデバイス上に新しい物理ボリュームを作成し、ボリュームグループを拡張します:
  +
  +
# pvcreate /dev/sdb1
  +
# vgextend MyVolGroup /dev/sdb1
  +
  +
これにより、ボリュームグループ上の物理エクステントの合計数が増加し、論理ボリュームによって割り当てられることが可能です。
  +
  +
{{Note|LVM 下にあるストレージメディア上に[[パーティションテーブル]]を作成することは、良い形式であると考えられています。適切なパーティションタイプを使用してください: MBR の場合は {{ic|8e}}、GPT パーティションの場合は {{ic|E6D6D379-F507-44C2-A23C-238F2A3DF928}}。}}
  +
  +
==== ボリュームグループからパーティションを削除する ====
  +
  +
論理ボリュームがパーティション上に存在している場合、まずその論理ボリュームを[[#論理ボリュームを削除する|削除]]してください。
  +
  +
そのパーティション上にあるすべてのデータを他のパーティションに移動する必要があります。幸い、LVM ではこれを簡単に行えます:
   
パーティションにあるデータを全て他のパーティションに移動する必要があります。ありがたいことに、LVM では簡単にできます:
 
 
# pvmove /dev/sdb1
 
# pvmove /dev/sdb1
  +
データを特定の物理ボリュームに移したい場合は、{{Ic|pvmove}} の二番目の引数に物理ボリュームを指定してください:
 
  +
特定の物理ボリューム上にデータを移したい場合は、{{ic|pvmove}} の第2引数でそれを指定してください:
  +
 
# pvmove /dev/sdb1 /dev/sdf1
 
# pvmove /dev/sdb1 /dev/sdf1
次に物理ボリュームをボリュームグループから削除する必要があります:
 
# vgreduce myVg /dev/sdb1
 
もしくは、空の物理ボリュームを全て削除してください:
 
# vgreduce --all vg0
 
   
  +
次に、物理ボリュームをボリュームグループから削除する必要があります:
そして最後に、パーティションを他のことに使うために、LVM にパーティションを物理ボリュームとして扱わせないようにするには:
 
  +
  +
# vgreduce MyVolGroup /dev/sdb1
  +
  +
または、空の物理ボリュームをすべて削除します:
  +
  +
# vgreduce --all MyVolGroup
  +
  +
例: 削除されたか障害が発生しているため見つけることのできない、グループ内の不良ディスクがある場合:
  +
  +
# vgreduce --removemissing --force MyVolGroup
  +
  +
最後に、そのパーティションを他の目的のために使用したい場合で、かつ LVM がそのパーティションを物理ボリュームであると認識させたくない場合:
  +
 
# pvremove /dev/sdb1
 
# pvremove /dev/sdb1
   
=== ボリュームグループを無効化する ===
+
=== 論理ボリューム ===
   
  +
{{Note|{{man|8|lvresize}} は、特殊化された {{man|8|lvextend}} や {{man|8|lvreduce}} コマンドとほぼ同じオプションを提供しますが、両方の種類の操作を実行できます。にも関わらず、これらのユーティリティはすべて、{{man|8|fsadm}} (''ext2''、[[ext3]]、[[ext4]]、''ReiserFS''、[[XFS]] をサポート) を使用して LV と一緒にファイルシステムもリサイズできる {{ic|-r}}/{{ic|--resizefs}} オプション を提供しています。なので、特定のニーズがある場合やプロセスを完全に制御したい場合を覗いて、両方の操作に対して {{ic|lvresize}} を使用し {{ic|--resizefs}} を使用して作業を少しばかり単純化するほうが簡単である場合があります。}}
次を実行してください:
 
# vgchange -a n my_volume_group
 
   
  +
{{Warning|多くの場合、ファイルシステムの拡張はオンライン (つまり、ファイルシステムがマウントされている) で行うことができます (ルートパーティションも例外ではありません)。しかし、縮小においては、ほとんどの場合、データの損失を防ぐためにファイルシステムをまずアンマウントする必要があります。対象のファイルシステムが、あなたが行おうとしていることをサポートしていることを確認してください。}}
これでボリュームグループが無効になりボリュームグループが入っていたコンテナをアンマウントできるようになります。
 
   
  +
{{Tip|論理ボリュームを [[ext4]] でフォーマットする場合、{{man|8|e2scrub}} を使えるようにするために 256 MiB 以上の空きスペースをボリュームグループに残しておいてください。最後のボリュームを {{ic|-l 100%FREE}} で作成した後に {{ic|lvreduce -L -256M ''volume_group''/''logical_volume''}} を実行してボリュームサイズを縮小することで行うことができます。}}
=== スナップショット ===
 
   
==== 説明 ====
+
==== 論理ボリュームを作成する ====
   
  +
ボリュームグループ {{ic|MyVolGroup}} に容量 300 GiB の論理ボリューム {{ic|homevol}} を作成するには、以下を実行してください:
LVM を使うことで伝統的なバックアップよりも効率的なシステムのスナップショットを作ることができます。COW (copy-on-write) ポリシーを使うことによって効率化を実現しています。最初に作成したスナップショットには実際のデータの inode のハードリンクだけが含まれます。データに変更が加えられない間は、スナップショットには inode ポインターしかなくデータ自体は入りません。スナップショット先のファイルやディレクトリに変更が入ると、スナップショットによって古いコピーが参照され、新しいコピーは実行中のシステムによって参照されます。このため、35GB のデータがあるシステムでも 2GB 以下しか (オリジナルとスナップショット両方に) 変更を加えない限り、スナップショットに消費する空き容量は 2GB だけです。
 
   
  +
# lvcreate -L 300G MyVolGroup -n homevol
==== 設定 ====
 
   
  +
あるいは、ボリュームグループ {{ic|MyVolGroup}} に論理ボリューム {{ic|homevol}} を、容量の残りすべてを使って作成するには、次を実行してください:
スナップショットの論理ボリュームは通常の論理ボリュームと同じように作れます:
 
   
# lvcreate --size 100M --snapshot --name snap01 /dev/mapper/vg0-pv
+
# lvcreate -l 100%FREE MyVolGroup -n homevol
上記のボリュームでは、スナップショットボリュームが一杯になるまで、データの 100M まで変更を加えることができます。
 
   
  +
新しい LV が {{ic|/dev/MyVolGroup/homevol}} として現れます。これで、LV を適切なファイルシステムで[[フォーマット]]できます。
次のコマンドを使うことによって変更が入った後の 'pv' 論理ボリュームを 'snap01' スナップショットが作られた状態まで戻すことが可能です:
 
   
  +
以下のコマンドで、LV が作成されたことを確認できます:
# lvconvert --merge /dev/vg0/snap01
 
   
  +
# lvs
オリジナルの論理ボリュームが使用中の場合は、次のブート時にマージされます (LiveCD からマージすることもできます)。
 
   
  +
==== 論理ボリュームの名前を変更する ====
マージが行われるとスナップショットはもう存在しなくなります。
 
  +
  +
既存の論理ボリュームの名前を変更するには、{{man|8|lvrename}} コマンドを使用してください。
  +
  +
次のいずれかのコマンドにより、ボリュームグループ {{ic|MyVolGroup}} 内の論理ボリューム {{ic|old_vol}} を {{ic|new_vol}} に名称変更します:
  +
  +
# lvrename /dev/MyVolGroup/old_vol /dev/MyVolGroup/new_vol
  +
  +
# lvrename MyVolGroup old_vol new_vol
  +
  +
名前を変更した論理ボリュームを参照している設定ファイル (例: /etc/fstab、/etc/crypttab) をすべてアップデートすることを忘れないでください。
  +
  +
==== 論理ボリュームとファイルシステムのサイズを一度に変更する ====
  +
  +
{{Note|''ext2''、[[ext3]]、[[ext4]]、''ReiserFS''、[[XFS]] ファイルシステムはサポートされています。違うタイプのファイルシステムについては、[[#論理ボリュームとファイルシステムのサイズを別々に変更する]] を見てください。}}
  +
  +
{{ic|MyVolGroup}} 内の論理ボリューム {{ic|mediavol}} を 10 GiB だけ増やし、ファイルシステムも ''同時に'' リサイズします:
  +
  +
# lvresize -L +10G --resizefs MyVolGroup/mediavol
  +
  +
{{ic|MyVolGroup}} 内の論理ボリューム {{ic|mediavol}} のサイズを 15 GiB に設定し、ファイルシステムも ''同時に'' リサイズします:
  +
  +
# lvresize -L 15G --resizefs MyVolGroup/mediavol
  +
  +
ボリュームグループ上の空き領域をすべて埋めたい場合、次のコマンドを使用してください:
  +
  +
# lvresize -l +100%FREE --resizefs MyVolGroup/mediavol
  +
  +
更に詳細なオプションは {{man|8|lvresize}} を参照してください。
  +
  +
==== 論理ボリュームとファイルシステムのサイズを別々に変更する ====
  +
  +
{{man|8|fsadm}} によってサポートされていないファイルシステムの場合、論理ボリュームを縮小する前、または拡張した後に、[[ファイルシステム#ファイルシステムのタイプ|適切なユーティリティ]]を使ってそのファイルシステムをリサイズする必要があります。
  +
  +
ファイルシステムに''触れずに''、ボリュームグループ {{ic|MyVolGroup}} 内の論理ボリューム {{ic|mediavol}} を 2 GiB だけ増やすには:
  +
  +
# lvresize -L +2G MyVolGroup/mediavol
  +
  +
そして、ファイルシステム (この例では [[ext4]]) を論理ボリュームの最大サイズまで拡張してください:
  +
  +
# resize2fs /dev/MyVolGroup/mediavol
  +
  +
{{ic|MyVolGroup}} 内の論理ボリューム {{ic|mediavol}} のサイズを 500 MiB だけ減らすには、まず最終的なファイルシステムサイズを計算し、ファイルシステム (この例では [[ext4]]) をその新しいサイズに縮小します:。
  +
  +
# resize2fs /dev/MyVolGroup/mediavol ''NewSize''
  +
  +
ファイルシステムが縮小したら、論理ボリュームのサイズも縮小してください:
  +
  +
# lvresize -L -500M MyVolGroup/mediavol
  +
  +
''ext2''、[[ext3]]、[[ext4]] ファイルシステムの場合の正確な論理ボリュームサイズを計算するには、このシンプルな計算式をしようしてください: {{ic|1=LVM_EXTENTS = FS_BLOCKS × FS_BLOCKSIZE ÷ LVM_EXTENTSIZE}}。
  +
  +
{{hc|# tune2fs -l /dev/MyVolGroup/mediavol {{!}} grep Block|
  +
Block count: 102400000
  +
Block size: 4096
  +
Blocks per group: 32768
  +
}}
  +
  +
{{hc|# vgdisplay MyVolGroup {{!}} grep "PE Size"|
  +
PE Size 4.00 MiB
  +
}}
  +
  +
{{Note|このファイルシステムブロックサイズ ({{ic|FS_BLOCKSIZE}}) はバイト単位です。ブロックサイズとエクステントサイズには同じ単位を使用することに気をつけてください。}}
  +
  +
102400000 blocks × 4096 bytes/block ÷ 4 MiB/extent = 100000 extents
  +
  +
{{ic|--resizefs}} を渡せば、正しいことを確認できます。
  +
  +
{{hc|# lvreduce -l 100000 --resizefs /dev/MyVolGroup/mediavol|
  +
...
  +
The filesystem is already 102400000 (4k) blocks long. Nothing to do!
  +
...
  +
Logical volume sysvg/root successfully resized.
  +
}}
  +
  +
更に詳細なオプションは {{man|8|lvresize}} を参照してください。
  +
  +
==== 論理ボリュームを削除する ====
  +
  +
{{Warning|論理ボリュームを削除する前に、キープしておきたいデータを他の場所にすべて移動することを忘れないでください。さもないと、消えてしまいますよ!}}
  +
  +
まず、削除したい論理ボリュームの名前を調べてください。以下のコマンドですべての論理ボリュームのリストを得られます:
  +
  +
# lvs
  +
  +
次に、選択した論理ボリュームのマウントポイントを探してください:
  +
  +
$ lsblk
  +
  +
そうしたら、論理ボリューム上のファイルシステムをアンマウントしてください:
  +
  +
# umount /''マウントポイント''
  +
  +
最後に、論理ボリュームを削除してください:
  +
  +
# lvremove ''ボリュームグループ''/''論理ボリューム''
  +
  +
例えば:
  +
  +
# lvremove MyVolGroup/homevol
  +
  +
{{ic|y}} を押して、確定してください。
  +
  +
削除した論理ボリュームを参照しているすべての設定ファイル (例: {{ic|/etc/fstab}}、{{ic|/etc/crypttab}}) を更新することを忘れないでください。
  +
  +
{{ic|lvs}} を root として実行することで、論理ボリュームが削除されたことを確認できます (このセクションの最初のステップを参照)。
  +
  +
== スナップショット ==
  +
  +
LVM は CoW (コピーオンライト, Copy-on-Write) スナップショットをサポートしています。CoW スナップショットは初めはオリジナルデータを参照します。データブロックが上書きされた時、オリジナルコピーはそのまま残り、新しいブロックはディスク上の別の場所に書き込まれます。これには、いくつかの望ましい特性があります:
  +
* データをコピーしない (ディスク上の場所を指すポインタのより小さいリストだけです) ため、スナップショットの作成が高速です。
  +
* スナップショットは、新しいデータブロック (加えて、新しいブロックを指すポインタのための無視できるほど小さい領域) を保持するのに十分な空き領域しか必要としません。例えば、(オリジナルとスナップショットの両方に) 2 GiB だけ書き込んだ 35 GiB のデータのスナップショットは 2 GiB の空き領域しか必要としません。
  +
  +
LVM スナップショットはブロックレベルです。LVM スナップショットは、LVM ツールを扱う場合を除いて、オリジナルと明らかな関連を持たない、新しいブロックデバイスを作成します。なので、オリジナルコピー内でファイルを削除しても、スナップショット内の領域は開放されません。ファイルシステムレベルのスナップショットが必要である場合は、btrfs や ZFS、bcache が必要です。
  +
  +
{{Warning|
  +
* CoW スナップショットは '''バックアップではありません'''。スナップショットはオリジナルデータの第2のコピーを作成するわけではないからです。例えば、オリジナルデータに影響するディスクセクタに損傷が発生すると、スナップショットにも影響が及びます。とはいえ、[[#バックアップ|以下]]で概要を説明しているように、バックアップを作成するために他のツールを使用するときに、スナップショットは便利かもしれません。
  +
* btrfs は、異なるファイルシステムが異なる UUID を持つことを期待します。btrfs ファイルシステムを含む LVM ボリュームのスナップショットを作成する場合、オリジナルまたはコピーの UUID を、それらをマウントする前 (及び、無関係のデーモンが ''btrfs デバイススキャン''をトリガーする場合など、カーネルから見えるようにする前) に変更するようにしてください。詳細は、[https://btrfs.wiki.kernel.org/index.php/Gotchas#Block-level_copies_of_devices btrfs wiki Gotcha's] を参照してください。
  +
}}
  +
  +
=== 設定 ===
  +
  +
スナップショットの論理ボリュームは通常の論理ボリュームと同じように作成します。
  +
  +
# lvcreate --size 100M --snapshot --name snap01vol /dev/MyVolGroup/lvol
  +
  +
上記のボリュームでは、スナップショットボリュームが一杯になるまで 100 MiB のデータを変更を加えることができます。
  +
  +
次のコマンドを使うことで、変更が加えられた {{ic|lvol}} 論理ボリュームを、{{ic|snap01vol}} スナップショットが作成された時の状態まで戻すことができます:
  +
  +
# lvconvert --merge /dev/MyVolGroup/snap01vol
  +
  +
オリジナルの論理ボリュームが使用中の場合は、次回のブート時にマージサれます (LiveCD からマージすることもできます)。
  +
  +
{{Note|マージが行われると、そのスナップショットはもはや存在しなくなります。}}
   
 
また、複数のスナップショットを作成して、それぞれを自由にオリジナルの論理ボリュームにマージすることも可能です。
 
また、複数のスナップショットを作成して、それぞれを自由にオリジナルの論理ボリュームにマージすることも可能です。
   
  +
=== バックアップ ===
スナップショットはマウントして ''dd'' や ''tar'' を使うことでバックアップできます。''dd'' で作られるバックアップファイルのサイズはスナップショットボリュームに入っているファイルのサイズになります。
 
復元は、スナップショットを作成してマウントして、バックアップをそこに書き込むか展開するだけです。そしてオリジナルのボリュームにマージしてください。
 
   
  +
スナップショットは、バックアップの作成のためにファイルシステムの凍結されたコピーを提供します。例えば、2時間かかったバックアップは、パーティションを直接バックアップするよりも、ファイルシステムのより一貫性のあるイメージを提供します。
{{ic|/etc/mkinitcpio.conf}} の MODULES 変数に ''dm_snapshot'' モジュールを入れることが必要で、これがないとシステムが起動しなくなります。インストールしたシステムに既に記述してある場合は、次のコマンドでイメージを再生成してください:
 
# mkinitcpio -g /boot/initramfs-linux.img
 
   
スナップショットは主にバックアップめのファイルシステムフローンコピを作るのに使われます; 2時間かかるバックアップはパーティショ直接バックアップするよりも一貫性あるファイルシステムイメージを提供ます
+
[[dd]] や [[tar]] でスナップショットをマウントしたりバックアップりできます。''dd'' によって作成されたバックアップファイルのサイは、対象のスナップショットボリュム上に存在すファイル総サイズとなります。(バックアップから) 復元するに、スナップショット作成し、それをマウントし、そこへバックアップを書き込むか展開してください。そ後、そスナップショットを origin にマージしてください
   
バックアップロールバックのためシステム起動時に root ファイルシステムのスナップショットを自動的に作成する方法は [[Create root filesystem snapshots with LVM]] をさい。
+
バックアップロールバックのために、システム起動時にルートファイルシステムのクリーンなスナップショットを自動的に作成する方法について[[LVM によるルートファイルシステムのスナップショット]] を参照しください。
   
  +
== 暗号化 ==
[[Mkinitcpio|initramfs]] によって有効にならない LVM ボリュームがある場合は、{{pkg|lvm2}} パッケージに入っている ''lvm-monitoring'' サービスを[[systemd#ユニットを使う|有効化]]してください。
 
   
  +
LUKS と LVM の組み合わせの可能なスキームについては、[[dm-crypt/システム全体の暗号化#LUKS on LVM]] と [[dm-crypt/システム全体の暗号化#LVM on LUKS]] を参照してください。
== トラブルシューティング ==
 
   
  +
== キャッシュ ==
=== Arch-Linux のデフォルトの変更のためにする必要がある変更 ===
 
   
  +
{{man|7|lvmcache}} より:
{{ic|/etc/lvm/lvm.conf}} には {{ic|1=use_lvmetad = 1}} を設定する必要があります。現在はデフォルトで設定されています。{{ic|lvm.conf.pacnew}} ファイルがある場合は、この変更を適用してください。
 
  +
  +
: キャッシュ論理ボリュームタイプは小さくて高速な LV を使うことで巨大で鈍重な LV のパフォーマンスを改善します。頻繁に使用されるブロックを高速な LV に保存することで高速化します。LVM は小さくて高速な LV のことをキャッシュプール LV と呼び、巨大で鈍重な LV のことをオリジン LV と呼びます。dm-cache (カーネルドライバー) の要件を満たすため、LVM はキャッシュプール LV をさらに2つのデバイスに分割します。キャッシュデータ LV とキャッシュメタデータ LV です。キャッシュデータ LV にはオリジン LV のデータブロックのコピーが保存されます。キャッシュメタデータ LV にはどこにデータブロックが保存されるかを示す情報が格納されます (例: オリジン LV にあるのかあるいはキャッシュデータ LV にあるのか)。最速かつ最強のキャッシュ論理ボリュームを作成しようと考えている場合はこれらの LV をよく知る必要があります。これらの LV は全て同一の VG に入っていなければなりません。
  +
  +
=== キャッシュを作成する ===
  +
  +
高速なディスク ({{ic|/dev/''fastdisk''}}) を PV に変換し、既存の VG ({{ic|MyVolGroup}}) に追加します:
  +
  +
# vgextend MyVolGroup /dev/''fastdisk''
  +
  +
{{ic|/dev/''fastdisk''}} 上に自動メタデータのあるキャッシュプールを作成し、既存の LV {{ic|MyVolGroup/rootvol}} をキャッシュボリュームに変換します、1ステップですべてできます:
  +
  +
# lvcreate --type cache --cachemode writethrough -l 100%FREE -n root_cachepool MyVolGroup/rootvol /dev/''fastdisk''
  +
  +
{{Tip|{{ic|-l 100%FREE}} を使って PV {{ic|/dev/''fastdisk''}} の利用可能な空き領域 100% を割り当てるのではなく、{{ic|-L 20G}} を使うことでキャッシュプールに 20 GiB だけを割り当てることができます。}}
  +
  +
キャッシュモードには2つのオプションが利用できます:
  +
  +
* {{ic|writethrough}} は書き込まれたデータがキャッシュプール LV とオリジナルの LV の両方に保存されることが保証されます。キャッシュプール LV が保存されているデバイスが故障してもデータが消失することはありません。
  +
* {{ic|writeback}} は高い性能を発揮しますが、キャッシュに使っているドライブが故障したときにデータを喪失する危険性があります。
  +
  +
{{ic|--cachemode}} を指定しなかった場合、デフォルトで {{ic|writethrough}} が使われます。
  +
  +
=== キャッシュを削除する ===
  +
  +
上記で作成したキャッシュを削除したい場合:
  +
  +
# lvconvert --uncache MyVolGroup/rootvol
  +
  +
上記のコマンドでキャッシュに留まっている書き込みが origin LV に適用され、それからキャッシュが削除されます。他のオプションについては {{man|7|lvmcache}} で説明されています。
  +
  +
== RAID ==
  +
  +
LVM は、[[RAID#実装|ソフトウェア RAID]] を作成するために使用できます。ハードウェア RAID を持っておらず、いずれにせよ LVM を使用するつもりであるならば、これは良い選択肢です。{{man|7|lvmraid}} によると:
  +
: {{man|8|lvm}} RAID は、複数の物理デバイスを使用する論理ボリューム (LV) を作成して、パフォーマンスを向上させたり、デバイス障害に対する耐性を持たせたりするための1つの方法です。LVM では、それらの物理デバイスは単一のボリュームグループ (VG) 内の物理ボリューム (PV) です。
  +
  +
LVM RAID は RAID 0、RAID 1、RAID 4、RAID 5、RAID 6、RAID 10 をサポートします。それぞれのレベルに関する詳細は [[Wikipedia:Standard RAID levels]] を参照してください。
  +
  +
{{Warning|{{ic|lvm2}} [[mkinitcpio]] フックを使用している場合、忘れずに [[LVM に Arch Linux をインストールする#mkinitcpio を RAID 用に設定する|initramfs 内に RAID カーネルモジュールを含めてください]]。これは、ルートボリュームが LVM RAID 上にあるか無いかに関わらず、行わなくてはなりません。ブート後、''pvscan'' が、initramfs の段階でアクティブ化できなかったデバイスのアクティブ化を再試行しないためです。{{Bug|71385}} を参照してください。}}
  +
  +
{{Tip|[[mdadm]] も、ソフトウェア RAID を作成するために使用できます。こちらの方が、間違いなくよりシンプルで、人気で、セットアップが簡単です。}}
  +
  +
=== RAID をセットアップする ===
  +
  +
物理ボリュームを作成してください:
  +
  +
# pvcreate /dev/sda2 /dev/sdb2
  +
  +
物理ボリューム上にボリュームグループを作成してください:
  +
  +
# vgcreate MyVolGroup /dev/sda2 /dev/sdb2
  +
  +
{{ic|lvcreate --type ''RAIDレベル''}} を使用して論理ボリュームを作成してください。その他のオプションについては {{man|7|lvmraid}} と {{man|8|lvcreate}} を参照してください。
  +
  +
# lvcreate --type RaidLevel [OPTIONS] -n Name -L Size VG [PVs]
  +
  +
例:
  +
  +
# lvcreate --type raid1 --mirrors 1 -L 20G -n myraid1vol MyVolGroup /dev/sda2 /dev/sdb2
  +
  +
これは、20 GiB のミラー化された、"myraid1vol" という名前の論理ボリュームを、{{ic|/dev/sda2}} と {{ic|/dev/sdb2}} の上にある VolGroup00 内に作成します。
  +
  +
== シンプロビジョニング ==
  +
  +
{{Note|シン (thin) LV のファイルシステムをマウントする際、{{ic|discard}} オプションを使うか [[fstrim]] を定期的に使用するようにしてください。ファイルが削除されたときにシン LV が縮小できるようにするためです。}}
  +
  +
{{man|7|lvmthin}} によると:
  +
  +
:標準的な {{man|8|lvm}} 論理ボリューム (LV) 内のブロックは、LV が作成されたときに割り当てられます。しかし、シンプロビジョニング LV 内のブロックは、それらのブロックが書き込まれたときに割り当てられます。そのため、シンプロビジョニング LV には仮想的なサイズが設定され、物理的に利用可能なストレージよりもさらに大きくすることができます。シンプロビジョニング LV のために提供される物理ストレージの容量は、ニーズに応じて後に拡大させることができます。
  +
  +
=== 例: 仮想専用サーバを立てる ===
  +
  +
古典的なユースケースを挙げましょう。あなたは独自の VPS サービスを開始したいと考え、初めは約100個の VPS を 930 GiB ハードドライブ搭載の1台の PC 上でホストしているとしましょう。割り当てられたストレージのすべてを実際に使用する VPS はほとんど存在しないため、各 VPS に 9 GiB を割り当てるのではなく、各 VPS に最大 30 GiB を使用できるようにし、シンプロビジョニングを使うことで各 VPS に実際に使用している量のハードドライブ領域を割り当てるようにします。930 GiB のハードドライブは {{ic|/dev/sdb}} であるとします。以下がそのセットアップです。
  +
  +
ボリュームグループ {{ic|MyVolGroup}} を準備します。
  +
  +
# vgcreate MyVolGroup /dev/sdb
  +
  +
シンプール LV {{ic|MyThinPool}} を作成します。この LV はストレージ用のブロックを提供します。
  +
  +
# lvcreate --type thin-pool -n MyThinPool -l 95%FREE MyVolGroup
  +
  +
シンプールは2つのサブボリュームから成ります: データ LV とメタデータ LV です。このコマンドは両方を自動的に作成します。しかし、いずれかが完全に一杯になると、シンプールは動作を停止してしまいます。さらに、LVM は現在、それらのボリュームの縮小をサポートしていません。これが、上記のコマンドで 5% の追加領域を用意している理由です。シンプールのデータサブボリュームかメタデータサブボリュームを拡張する必要が発生する場合に備えているのです。
  +
  +
各 VPS に対してシン LV を作成します。これは、ユーザに対してルートパーティションとして公開されるブロックデバイスです。
  +
  +
# lvcreate -n SomeClientsRoot -V 30G --thinpool MyThinPool MyVolGroup
  +
  +
そのブロックデバイス {{ic|/dev/MyVolGroup/SomeClientsRoot}} は、ルートパーティションとして [[VirtualBox]] が使用することができます。
  +
  +
==== シンスナップショットを使用してスペースを節約する ====
  +
  +
シンスナップショットは、それ自体がシン LV なので、通常のスナップショットよりも遥かに強力です。シンスナップショットが持つ長所の完全なリストは Red Hat のガイド [https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/configuring_and_managing_logical_volumes/index#creating-and-managing-thinly-provisioned-volumes_configuring-and-managing-logical-volumes] を参照してください。
  +
  +
VPS が作成されるたびに Linux をゼロからインストールするのではなく、基本的な Linux 環境が含まれるただ1つのシン LV から始める方が容量を効率的に使用できます:
  +
  +
# lvcreate -n GenericRoot -V 30G --thinpool MyThinPool MyVolGroup
  +
*** /dev/MyVolGroup/GenericRoot に Linux をインストール ***
  +
  +
そして、各 VPS に対してその LV のスナップショットを作成します:
  +
  +
# lvcreate -s MyVolGroup/GenericRoot -n SomeClientsRoot
  +
  +
このように、シンプールには (少なくとも最初は) 全 VPS に対して共通のデータのコピーがただ1つだけ存在します。追加の利点として、新しい VPS の作成が瞬時に行われます。
  +
  +
これらはシンスナップショットであるため、{{ic|GenericRoot}} への1回の書き込み操作において COW 操作は、スナップショット毎に1回ではなく、合計で1回しか行われません。これにより、{{ic|GenericRoot}} の更新は、各 VPS が通常のスナップショットである場合よりも効率的なります。
  +
  +
=== 例: ゼロダウンタイムでストレージをアップグレードする ===
  +
  +
VPS のホスティング以外にもシンプロビジョニングの活用法は存在します。シンプロビジョニングを使用して、すでにマウントされているファイルシステムをアンマウントすることなく、その実効容量を増やす方法を紹介しましょう。ここでは (再び)、サーバに1台の 930 GiB ハードドライブが搭載されていると仮定します。環境は VPS ホスティングのときと同じですが、シン LV が1つしかなく、LV のサイズはシンプールのサイズよりも遥かに大きいとします。
  +
  +
# lvcreate -n MyThinLV -V 16T --thinpool MyThinPool MyVolGroup
  +
  +
この追加の仮想領域は、シンプールを拡張することで後に実際のストレージで埋めることができます。
  +
  +
しばらくして、ストレージのアップグレードが必要になり、新しいハードドライブ {{ic|/dev/sdc}} がサーバに接続されたとします。シンプールの容量をアップグレードするには、新しいハードドライブを VG に追加します:
  +
  +
# vgextend MyVolGroup /dev/sdc
  +
  +
次に、シンプールを拡張します:
  +
  +
# lvextend -l +95%FREE MyVolGroup/MyThinPool
  +
  +
このシン LV のサイズは 16 TiB なので、最終的にファイルシステムをアンマウントしてサイズ変更するはめになるまでに、さらに 15.09 TiB のハードドライブ領域を追加できます。
  +
  +
{{Note|アプリケーションが実際に存在する以上の物理ストレージを使用しないようにするために、[[Ext4#予約ブロック|予約ブロック]]や[[ディスククォータ]]を使うべきかもしれません。}}
  +
  +
== トラブルシューティング ==
   
 
=== LVM コマンドが機能しない ===
 
=== LVM コマンドが機能しない ===
   
 
* 適切なモジュールをロードしてください:
 
* 適切なモジュールをロードしてください:
# modprobe dm_mod
 
   
  +
# modprobe dm_mod
{{ic|dm_mod}} モジュールは自動的にロードされるはずです。そうならない場合は、次を試してみて下さい:
 
   
  +
{{ic|dm_mod}} モジュールは自動的にロードされるはずです。そうならない場合は、明示的に[[カーネルモジュール#モジュールの自動ロード|モジュールを起動時にロードするようにしてください]]。
{{hc|/etc/mkinitcpio.conf:|<nowiki>MODULES="dm_mod ..."</nowiki>}}
 
   
  +
* ''lvm'' コマンドを次のように試してみてください:
変更を適用するには initramfs を[[Mkinitcpio#イメージ作成とアクティベーション|再生成]]する必要があります。
 
   
* ''lvm'' コマンドを次のように試してみて下さい:
 
 
# lvm pvdisplay
 
# lvm pvdisplay
   
312行目: 614行目:
 
# vgchange -ay
 
# vgchange -ay
   
=== リムーバルメディア上の LVM ===
+
=== リムーバルメディア上の LVM ===
   
 
症状:
 
症状:
  +
# vgscan
 
  +
{{hc|# vgscan|
 
Reading all physical volumes. This may take a while...
 
Reading all physical volumes. This may take a while...
 
/dev/backupdrive1/backup: read failed after 0 of 4096 at 319836585984: Input/output error
 
/dev/backupdrive1/backup: read failed after 0 of 4096 at 319836585984: Input/output error
323行目: 626行目:
 
Found volume group "backupdrive1" using metadata type lvm2
 
Found volume group "backupdrive1" using metadata type lvm2
 
Found volume group "networkdrive" using metadata type lvm2
 
Found volume group "networkdrive" using metadata type lvm2
  +
}}
   
  +
病因: 最初にボリュームグループを無効にしないで外付けの LVM ドライブを取り外したこと。切断する前に、次を実行するようにしましょう:
病因:
 
  +
:最初にボリュームグループを無効にしないで外付けの LVM ドライブを取り外したこと。切断する前に、次を実行するようにしましょう:
 
# vgchange -an ''volume group name''
+
# vgchange -an ''ボリュームグループ名''
  +
  +
修復: あなたがすでに {{ic|vgchange -ay ''vg''}} でそのボリュームグループのアクティブ化を試み、先の Input/output エラーを見たと仮定します:
  +
  +
# vgchange -an ''ボリュームグループ名''
  +
  +
外部ドライブを取り外し、数分待ってください。
   
治療:
 
:外部ドライブのプラグを抜いて数分待って下さい:
 
 
# vgscan
 
# vgscan
# vgchange -ay ''volume group name''
+
# vgchange -ay ''ボリュームグループ名''
   
=== オプション ===
+
==== LVM とリムバブメディアでサスペド/復帰 ====
   
  +
{{Accuracy|提供されている解決策は、LUKS on LVM などの複雑なセットアップでは機能しません。}}
カーネルオプションに、{{ic|dolvm}} が必要かもしれません。{{ic|<nowiki>root=</nowiki>}} は論理ボリュームに設定してください (例: {{ic|/dev/mapper/''vg-name''-''lv-name''}})。
 
  +
  +
LVM をリムーバブルメディア (外部 USB ドライブなど) で正常に動作させるには、外部ドライブのボリュームグループをサスペンド前に非アクティブ化させる必要があります。これが行われないと、(復帰後に) dm デバイスでバッファ I/O エラーが発生する場合があります。この理由により、外部ドライブと内部ドライブを同じボリュームグループ内に混在させることは推奨されません。
  +
  +
外部 USB ドライブのあるボリュームグループを自動的に非アクティブ化するには、以下の方法でそれぞれのボリュームグループに {{ic|sleep_umount}} タグを付けてください:
  +
  +
# vgchange --addtag sleep_umount ''外部ボリュームグループ''
  +
  +
このタグを設定したら、systemd の以下のユニットファイルを使用して、サスペンド前にボリュームを適切に非アクティブ化します。復帰時には、それらのボリュームは LVM によって自動的にアクティブ化されます。
  +
  +
{{hc|/etc/systemd/system/ext_usb_vg_deactivate.service|2=
  +
[Unit]
  +
Description=Deactivate external USB volume groups on suspend
  +
Before=sleep.target
  +
  +
[Service]
  +
Type=oneshot
  +
ExecStart=-/etc/systemd/system/deactivate_sleep_vgs.sh
  +
  +
[Install]
  +
WantedBy=sleep.target
  +
}}
  +
  +
あと以下のスクリプトです:
  +
  +
{{hc|/etc/systemd/system/deactivate_sleep_vgs.sh|2=
  +
#!/bin/sh
  +
  +
TAG=@sleep_umount
  +
vgs=$(vgs --noheadings -o vg_name $TAG)
  +
  +
echo "Deactivating volume groups with $TAG tag: $vgs"
  +
  +
# $TAG タグのあるボリュームグループに属する論理ボリュームをアンマウントします
  +
for vg in $vgs; do
  +
for lv_dev_path in $(lvs --noheadings -o lv_path -S lv_active=active,vg_name=$vg); do
  +
echo "Unmounting logical volume $lv_dev_path"
  +
umount $lv_dev_path
  +
done
  +
done
  +
  +
# sleep_umount でタグ付けされたボリュームグループを非アクティブ化します
  +
for vg in $vgs; do
  +
echo "Deactivating volume group $vg"
  +
vgchange -an $vg
  +
done
  +
}}
  +
  +
最後に、そのユニットを[[有効化]]してください。
  +
  +
=== 連続している論理ボリュームのサイズ変更に失敗する ===
  +
  +
論理ボリュームを拡張しようとすると以下のエラーが表示される場合:
  +
  +
" Insufficient suitable contiguous allocatable extents for logical volume "
  +
  +
明示的に連続するように割り当てるポリシー (オプション {{ic|-C y}} または {{ic|--alloc contiguous}}) を使って論理ボリュームが作成されており、ボリュームの近隣に連続したエクステントが存在しないのが原因です。[https://hostatic.ro/lvm-inherit-and-contiguous-policies/]
  +
  +
この問題を修正するには、論理ボリュームを拡張する前に、{{ic|lvchange --alloc inherit ''論理ボリューム''}} で割り当てポリシーを変更してください。連続割り当てポリシーを使い続ける必要がある場合、空きエクステントが十分存在するディスク領域にボリュームを移動してください。[https://superuser.com/questions/435075/how-to-align-logical-volumes-on-contiguous-physical-extents] を参照。
  +
  +
=== "grub-mkconfig" コマンドで "unknown filesystem" エラーが発生する ===
  +
  +
[[GRUB#メイン設定ファイルの生成|grub.cfg を生成する]]前にスナップショットボリュームは削除するようにしてください。
  +
  +
=== シンプロビジョニングボリュームに root を配置する場合にタイムアウトが発生する ===
  +
  +
大量のスナップショットを使用した場合、{{ic|thin_check}} の実行時間が長くなるためルートデバイスがタイムアウトしてしまうことがあります。そのためブートローダーの設定に {{ic|1=rootdelay=60}} カーネルブートパラメータを追加してください。あるいは、{{ic|thin_check}} によるブロックマップのチェックをスキップし ([https://www.redhat.com/archives/linux-lvm/2016-January/msg00010.html] を参照) [[Initramfs を再生成する|Initramfs を再生成してください]]:
  +
  +
{{hc|/etc/lvm/lvm.conf|
  +
2=thin_check_options = [ "-q", "--clear-needs-check-flag", "--skip-mappings" ]
  +
}}
  +
  +
=== シャットダウンが遅くなる ===
  +
  +
RAIDやスナップショット、シンプロビジョニングを使用していてシャットダウンが遅くなる場合、{{ic|lvm2-monitor.service}} が[[起動]]していることを確認してください。{{Bug|50420}} を参照。
  +
  +
=== シンプロビジョニングされたスワップボリューム上にハイバネートする ===
  +
  +
[[サスペンドとハイバネート#thinly-provisioned LVM ボリュームへのハイバネーション]] を参照してください。
   
 
== 参照 ==
 
== 参照 ==
   
* [http://sourceware.org/lvm2/ LVM2 Resource Page] on SourceWare.org
+
* SourceWare.org の [https://sourceware.org/lvm2/ LVM2 Resource Page]
  +
* [[Gentoo:LVM]]
* [http://tldp.org/HOWTO/LVM-HOWTO/ LVM HOWTO] article at The Linux Documentation project
 
  +
* [https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/9/html-single/configuring_and_managing_logical_volumes/index Red Hat Enterprise 9: 論理ボリュームの設定および管理]
* [http://wiki.gentoo.org/wiki/LVM/ja LVM] article at Gentoo wiki
 
  +
* [https://www.tutonics.com/2012/11/ubuntu-lvm-guide-part-1.html Ubuntu LVM Guide Part 1][https://www.tutonics.com/2012/12/lvm-guide-part-2-snapshots.html Part 2 details snapshots]
* [http://www.joshbryan.com/blog/2008/01/02/lvm2-mirrors-vs-md-raid-1/ LVM2 Mirrors vs. MD Raid 1] post by Josh Bryan
 
  +
* [http://www.tutonics.com/2012/11/ubuntu-lvm-guide-part-1.html Ubuntu LVM Guide Part 1][http://www.tutonics.com/2012/12/lvm-guide-part-2-snapshots.html Part 2 detals snapshots]
 
  +
{{TranslationStatus|LVM|2023-04-29|776399}}

2024年7月26日 (金) 15:28時点における最新版

関連記事

Wikipedia より:

論理ボリュームマネージャ (Logical Volume Manager, LVM) とは、Linux カーネル論理ボリューム管理を提供するデバイスマッパーフレームワークです。

目次

背景

LVM の構成要素

Logical Volume Management は Linux カーネルの device-mapper 機能を利用して、基底のディスクレイアウトから独立したパーティションのシステムを提供します。LVM を使うことでストレージを抽象化し「仮想的なパーティション」を作成して、拡張/縮小を容易にします (ファイルシステムの制限を受ける可能性はあります)。

仮想パーティションにより、パーティションディスク上に十分な連続領域が存在するかどうかを心配したり、使用中のディスクに fdisk してしまったり (そして、カーネルが古いパーティションテーブルと新しいほうのどちらを使っているか悩んだり)、他のパーティションを移動してスペースを作らないといけなかったりすることなく、追加と削除ができるようになります。

LVM の基本的構成要素:

物理ボリューム (Physical Volume, PV)
LVM によって利用可能な Unix ブロックデバイスノード。例: ハードディスク、MBRGPT のパーティション、ループバックファイル、デバイスマッパーデバイス (例: dm-crypt)。PV は LVM のヘッダをホストします。
ボリュームグループ (Volume Group, VG)
LV のコンテナとして機能する、PV の集まり。VG から PE を割り当てて LV を構成します。
論理ボリューム (Logical Volume, LV)
VG 内に存在する「仮想/論理パーティション」であり、PE で構成されます。LV は、物理パーティションに似た Unix ブロックデバイスです。例えば、LV はファイルシステムで直接フォーマットできます。
物理エクステント (Physical Extent, PE)
LV に割り当てることのできる、PV 内の最小の連続するエクステント (範囲) です。PE は、任意の LV に割り当てることのできる、PV のパーツだと考えてください。

例:

物理ディスク

  ディスク1 (/dev/sda):
    ┌──────────────────────────────────────────┬─────────────────────────────────────────┐
    │ パーティション1  50 GiB (物理ボリューム) │ パーティション2 80 GiB (物理ボリューム) │
    │ /dev/sda1                                │ /dev/sda2                               │
    └──────────────────────────────────────────┴─────────────────────────────────────────┘

  ディスク2 (/dev/sdb):
    ┌──────────────────────────────────────────┐
    │ パーティション1 120 GiB (物理ボリューム) │
    │ /dev/sdb1                                │
    └──────────────────────────────────────────┘
LVM 論理ボリューム

  ボリュームグループ1 (/dev/MyVolGroup/ = /dev/sda1 + /dev/sda2 + /dev/sdb1):
    ┌─────────────────────────┬─────────────────────────┬──────────────────────────┐
    │ 論理ボリューム1 15 GiB  │ 論理ボリューム2 35 GiB  │ 論理ボリューム3 200 GiB  │
    │ /dev/MyVolGroup/rootvol │ /dev/MyVolGroup/homevol │ /dev/MyVolGroup/mediavol │
    └─────────────────────────┴─────────────────────────┴──────────────────────────┘
ノート: 論理ボリュームは /dev/ボリュームグループ名/論理ボリューム名/dev/mapper/ボリュームグループ名-論理ボリューム名 の両方からアクセス可能です。しかし、lvm(8) § VALID NAMES は「ソフトウェアとスクリプト」においては前者の形式を推奨しています。後者は「内部での使用」を意図しており、「リリースやディストリビューション間で変わる」可能性があるからです。

利点

LVM には、通常のハードドライブのパーティションをただ使うよりも幅広い柔軟性があります:

  • 多数のディスクを一つの大きなディスクとして使えます。
  • 複数のディスクにまたがる論理ボリュームを作れます。
  • 小さな論理ボリュームを作成し、満杯になったら"動的に"リサイズできます。
  • ディスクの順番と関係なく論理ボリュームをリサイズできます。VG における LV の位置に依存しないので、周辺に空き容量を取る必要がありません。
  • オンラインで論理・物理ボリュームをリサイズ・作成・削除できます。ボリューム上のファイルシステムもリサイズする必要がありますが、オンラインリサイズをサポートしているファイルシステムもあります (ext4 など)。
  • サービスによって使われている LV を、サービスを再起動する必要なく他のディスクへオンラインで移行することができます。
  • スナップショットを使うことでファイルシステムのフローズンコピーをバックアップすることができます。サービスを落とす時間を最小限にできます。
  • 起動時にキーを複数回入力することなく、個別のボリュームをアンロック (LUKS 上に LVM を作成)。
  • 頻繁に使用されるデータをキャッシュする組み込みサポート (lvmcache(7))。

欠点

  • システムのセットアップに追加の手順が必要で、やや複雑。(複数の) デーモンを継続的に実行する必要あり。
  • デュアルブートする場合、Windows は LVM をサポートしていないことに注意してください。Windows からは LVM パーティションにアクセスできません。サードパーティのソフトウェアによって、特定の種類の LVM セットアップをマウントできる場合があります。[1]
  • 物理ボリュームが RAID-1、RAID-5、RAID-6 のどれにもない場合、論理ボリュームが複数の非冗長ディスクにまたがっている (あるいは、拡張されている) と、1つ以上のディスクが失われると1つまたは複数の論理ボリュームが失われる可能性があります。
  • 論理ボリュームマネージャによって使用されている領域 (つまり、論理ボリュームのために使用されている物理ボリューム) は (簡単には) 縮小できません。物理エクステントが物理ボリューム上に末尾まで散らばっている場合、Arch Wiki 上で提供されているスクリプトでは物理ボリュームを縮小することはできません。他のオペレーティングシステム (例: Microsoft Windows) とデュアルブートしたい場合、Microsoft Windows のために残される唯一のスペースは、LVM によって使用されない、あるいは物理ボリュームとして使用されない領域となります。

インストール

lvm2 パッケージがインストールされていることを確認してください。

LVM ボリュームを initramfs によってアクティブ化しない場合、(lvm2 によって提供される) lvm2-monitor.service有効化してください。

ボリューム操作

物理ボリューム

作成

/dev/sda1 上に PV (物理ボリューム) を作成するには:

# pvcreate /dev/sda1

PV が作成されたかどうかは、以下のコマンドを使って確認できます:

# pvs

拡張

物理ボリュームのあるデバイスのサイズを増やした後、または減らす前に、pvresize(8) を使って PV を拡大/縮小する必要があります。

パーティションを大きくした後に /dev/sda1 上の PV を拡張するには、以下を実行します:

# pvresize /dev/sda1

これは、自動的にデバイスのサイズを検出し、最大まで PV を拡張します。

ノート: このコマンドは、ボリュームがオンラインの間も実行することができます。

縮小

基底となるデバイスを縮小する前に物理ボリュームを縮小するには、パラメータ --setphysicalvolumesize サイズ を先のコマンドに追加してください。例えば:

# pvresize --setphysicalvolumesize 40G /dev/sda1

上記のコマンドは以下のエラーを出力する場合があります:

/dev/sda1: cannot resize to 25599 extents as later ones are allocated.
0 physical volume(s) resized / 1 physical volume(s) not resized

実際 pvresize は、新しい終了位置よりも後にエクステントが割り当てられている場合、PV の縮小を拒否します。十分な空き領域があるならば、前もって pvmove を実行して、そのようなエクステントをボリュームグループ内の別の場所に移動させる必要があります。

物理エクステントを移動させる

空きエクステントをボリュームの末尾に移動させる前に、pvdisplay -v -m を実行して物理セグメントを確認しなければなりません。以下の例では、1つの物理ボリュームが /dev/sdd1 上に存在し、1つのボリュームグループ vg1 と1つの論理ボリューム backup が存在しています。

# pvdisplay -v -m
    Finding all volume groups.
    Using physical volume(s) on command line.
  --- Physical volume ---
  PV Name               /dev/sdd1
  VG Name               vg1
  PV Size               1.52 TiB / not usable 1.97 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              399669
  Free PE               153600
  Allocated PE          246069
  PV UUID               MR9J0X-zQB4-wi3k-EnaV-5ksf-hN1P-Jkm5mW
   
  --- Physical Segments ---
  Physical extent 0 to 153600:
    FREE
  Physical extent 153601 to 307199:
    Logical volume	/dev/vg1/backup
    Logical extents	1 to 153599
  Physical extent 307200 to 307200:
    FREE
  Physical extent 307201 to 399668:
    Logical volume	/dev/vg1/backup
    Logical extents	153601 to 246068

FREE な領域がボリュームを跨いで分かれて存在していることがわかります。物理ボリュームを縮小させるには、まず、すべての使用中セグメントを先頭に移動させなければなりません。

ここで、最初の空きセグメントは 0 から 153600 にあり、153601 の空きエクステントが存在しています。この状態では、このセグメント番号を最後の物理エクステントから最初のエクステントに移動させることができます。なので、コマンドは以下のようになります:

# pvmove --alloc anywhere /dev/sdd1:307201-399668 /dev/sdd1:0-92467
/dev/sdd1: Moved: 0.1 %
/dev/sdd1: Moved: 0.2 %
...
/dev/sdd1: Moved: 99.9 %
/dev/sdd1: Moved: 100.0 %
ノート:
  • このコマンドは、399668 - 307201 + 1 = 92468 個の PE (物理エクステント) を最後のセグメント から 最初のセグメント 移動させます。これは、最初のセグメントが 153600 個の空き PE を囲っており、92467 - 0 + 1 = 92468 個の移動された PE を含むことができるため、可能なのです。
  • --alloc anywhere オプションは、同じパーティション内で PE を移動させるので、使用されています。異なるパーティションの場合、先のコマンドは以下のようなものになるでしょう:
    # pvmove /dev/sdb1:1000-1999 /dev/sdc1:0-999
  • このコマンドは、ボリュームが大きい場合、長い時間 (1~2時間) が掛かるかもしれません。このコマンドを tmuxGNU Screen のセッション内で実行するのが良いアイディアかもしれません。プロセスを望まない形で停止させてしまうと、致命的になる可能性があります。
  • 操作が完了したら、fsck を実行して、ファイルシステムが有効であることを確認してください。
物理ボリュームのサイズを変更する

すべての空き物理セグメントを最後の物理エクステント上に移動したら、vgdisplay を root 権限で実行して空き PE を確認してください。

そうしたら、先のあのコマンドを再び実行できます:

# pvresize --setphysicalvolumesize サイズ 物理ボリューム

結果を確認しましょう:

# pvs
  PV         VG   Fmt  Attr PSize    PFree 
  /dev/sdd1  vg1  lvm2 a--     1t     500g
パーティションのサイズを変更する

最後に、お気に入りのパーティショニングツールを使ってパーティションを縮小させる必要があります。

ボリュームグループ

ボリュームグループを作成する

PV /dev/sdb1 を持つ VG (ボリュームグループ) MyVolGroup を作成するには、以下を実行してください:

# vgcreate MyVolGroup /dev/sdb1

以下のコマンドを使うことで VG MyVolGroup が作成されたことを確認できます:

# vgs

VG の作成時に以下のようにすることで複数の PV をバインドすることができます:

# vgcreate MyVolGroup /dev/sdb1 /dev/sdb2

ボリュームグループをアクティブ化する

ノート: /etc/lvm/lvm.conf 内の auto_activation_volume_list を設定することで、自動的にアクティブ化されるボリュームを制限することができます。疑っているならば、このオプションをコメントアウトしてみてください。
# vgchange -a y MyVolGroup

デフォルトでは、これにより該当するボリュームグループが再アクティブ化されます。例えば、仮にミラーでドライブ障害が発生し、そのドライブを交換したとすると、(1) pvcreate、(2) vgextend、(3) vgreduce --removemissing --force を実行するでしょう。

ボリュームグループを修復する

この例での破損したミラーアレイの再ビルドプロセスを開始するには、以下を実行します:

# lvconvert --repair /dev/MyVolGroup/mirror

以下で再ビルドプロセスをモニタリングできます (Cpy%Sync 列の出力):

# lvs -a -o +devices

ボリュームグループを非アクティブ化する

以下を実行してください:

# vgchange -a n MyVolGroup

これは、ボリュームグループを非アクティブ化し、その VG を格納しているコンテナをアンマウントできるようにします。

ボリュームグループの名前を変更する

既存のボリュームグループの名前を変更するには vgrename(8) コマンドを使用してください。

次のいずれかのコマンドにより、既存のボリュームグループ MyVolGroupmy_volume_group に名称変更します:

# vgrename /dev/MyVolGroup /dev/my_volume_group
# vgrename MyVolGroup my_volume_group

名前を変更したボリュームグループを参照している設定ファイル (例: /etc/fstab/etc/crypttab) をすべてアップデートすることを忘れないでください。

ボリュームグループに物理ボリュームを追加する

まず、使用したいブロックデバイス上に新しい物理ボリュームを作成し、ボリュームグループを拡張します:

# pvcreate /dev/sdb1
# vgextend MyVolGroup /dev/sdb1

これにより、ボリュームグループ上の物理エクステントの合計数が増加し、論理ボリュームによって割り当てられることが可能です。

ノート: LVM 下にあるストレージメディア上にパーティションテーブルを作成することは、良い形式であると考えられています。適切なパーティションタイプを使用してください: MBR の場合は 8e、GPT パーティションの場合は E6D6D379-F507-44C2-A23C-238F2A3DF928

ボリュームグループからパーティションを削除する

論理ボリュームがパーティション上に存在している場合、まずその論理ボリュームを削除してください。

そのパーティション上にあるすべてのデータを他のパーティションに移動する必要があります。幸い、LVM ではこれを簡単に行えます:

# pvmove /dev/sdb1

特定の物理ボリューム上にデータを移したい場合は、pvmove の第2引数でそれを指定してください:

# pvmove /dev/sdb1 /dev/sdf1

次に、物理ボリュームをボリュームグループから削除する必要があります:

# vgreduce MyVolGroup /dev/sdb1

または、空の物理ボリュームをすべて削除します:

# vgreduce --all MyVolGroup

例: 削除されたか障害が発生しているため見つけることのできない、グループ内の不良ディスクがある場合:

# vgreduce --removemissing --force MyVolGroup

最後に、そのパーティションを他の目的のために使用したい場合で、かつ LVM がそのパーティションを物理ボリュームであると認識させたくない場合:

# pvremove /dev/sdb1

論理ボリューム

ノート: lvresize(8) は、特殊化された lvextend(8)lvreduce(8) コマンドとほぼ同じオプションを提供しますが、両方の種類の操作を実行できます。にも関わらず、これらのユーティリティはすべて、fsadm(8) (ext2ext3ext4ReiserFSXFS をサポート) を使用して LV と一緒にファイルシステムもリサイズできる -r/--resizefs オプション を提供しています。なので、特定のニーズがある場合やプロセスを完全に制御したい場合を覗いて、両方の操作に対して lvresize を使用し --resizefs を使用して作業を少しばかり単純化するほうが簡単である場合があります。
警告: 多くの場合、ファイルシステムの拡張はオンライン (つまり、ファイルシステムがマウントされている) で行うことができます (ルートパーティションも例外ではありません)。しかし、縮小においては、ほとんどの場合、データの損失を防ぐためにファイルシステムをまずアンマウントする必要があります。対象のファイルシステムが、あなたが行おうとしていることをサポートしていることを確認してください。
ヒント: 論理ボリュームを ext4 でフォーマットする場合、e2scrub(8) を使えるようにするために 256 MiB 以上の空きスペースをボリュームグループに残しておいてください。最後のボリュームを -l 100%FREE で作成した後に lvreduce -L -256M volume_group/logical_volume を実行してボリュームサイズを縮小することで行うことができます。

論理ボリュームを作成する

ボリュームグループ MyVolGroup に容量 300 GiB の論理ボリューム homevol を作成するには、以下を実行してください:

# lvcreate -L 300G MyVolGroup -n homevol

あるいは、ボリュームグループ MyVolGroup に論理ボリューム homevol を、容量の残りすべてを使って作成するには、次を実行してください:

# lvcreate -l 100%FREE MyVolGroup -n homevol

新しい LV が /dev/MyVolGroup/homevol として現れます。これで、LV を適切なファイルシステムでフォーマットできます。

以下のコマンドで、LV が作成されたことを確認できます:

# lvs

論理ボリュームの名前を変更する

既存の論理ボリュームの名前を変更するには、lvrename(8) コマンドを使用してください。

次のいずれかのコマンドにより、ボリュームグループ MyVolGroup 内の論理ボリューム old_volnew_vol に名称変更します:

# lvrename /dev/MyVolGroup/old_vol /dev/MyVolGroup/new_vol
# lvrename MyVolGroup old_vol new_vol

名前を変更した論理ボリュームを参照している設定ファイル (例: /etc/fstab、/etc/crypttab) をすべてアップデートすることを忘れないでください。

論理ボリュームとファイルシステムのサイズを一度に変更する

ノート: ext2ext3ext4ReiserFSXFS ファイルシステムはサポートされています。違うタイプのファイルシステムについては、#論理ボリュームとファイルシステムのサイズを別々に変更する を見てください。

MyVolGroup 内の論理ボリューム mediavol を 10 GiB だけ増やし、ファイルシステムも 同時に リサイズします:

# lvresize -L +10G --resizefs MyVolGroup/mediavol

MyVolGroup 内の論理ボリューム mediavol のサイズを 15 GiB に設定し、ファイルシステムも 同時に リサイズします:

# lvresize -L 15G --resizefs MyVolGroup/mediavol

ボリュームグループ上の空き領域をすべて埋めたい場合、次のコマンドを使用してください:

# lvresize -l +100%FREE --resizefs MyVolGroup/mediavol

更に詳細なオプションは lvresize(8) を参照してください。

論理ボリュームとファイルシステムのサイズを別々に変更する

fsadm(8) によってサポートされていないファイルシステムの場合、論理ボリュームを縮小する前、または拡張した後に、適切なユーティリティを使ってそのファイルシステムをリサイズする必要があります。

ファイルシステムに触れずに、ボリュームグループ MyVolGroup 内の論理ボリューム mediavol を 2 GiB だけ増やすには:

# lvresize -L +2G MyVolGroup/mediavol

そして、ファイルシステム (この例では ext4) を論理ボリュームの最大サイズまで拡張してください:

# resize2fs /dev/MyVolGroup/mediavol

MyVolGroup 内の論理ボリューム mediavol のサイズを 500 MiB だけ減らすには、まず最終的なファイルシステムサイズを計算し、ファイルシステム (この例では ext4) をその新しいサイズに縮小します:。

# resize2fs /dev/MyVolGroup/mediavol NewSize

ファイルシステムが縮小したら、論理ボリュームのサイズも縮小してください:

# lvresize -L -500M MyVolGroup/mediavol

ext2ext3ext4 ファイルシステムの場合の正確な論理ボリュームサイズを計算するには、このシンプルな計算式をしようしてください: LVM_EXTENTS = FS_BLOCKS × FS_BLOCKSIZE ÷ LVM_EXTENTSIZE

# tune2fs -l /dev/MyVolGroup/mediavol | grep Block
Block count:              102400000
Block size:               4096
Blocks per group:         32768
# vgdisplay MyVolGroup | grep "PE Size"
PE Size               4.00 MiB
ノート: このファイルシステムブロックサイズ (FS_BLOCKSIZE) はバイト単位です。ブロックサイズとエクステントサイズには同じ単位を使用することに気をつけてください。
102400000 blocks × 4096 bytes/block ÷ 4 MiB/extent = 100000 extents

--resizefs を渡せば、正しいことを確認できます。

# lvreduce -l 100000 --resizefs /dev/MyVolGroup/mediavol
...
The filesystem is already 102400000 (4k) blocks long.  Nothing to do!
...
Logical volume sysvg/root successfully resized.

更に詳細なオプションは lvresize(8) を参照してください。

論理ボリュームを削除する

警告: 論理ボリュームを削除する前に、キープしておきたいデータを他の場所にすべて移動することを忘れないでください。さもないと、消えてしまいますよ!

まず、削除したい論理ボリュームの名前を調べてください。以下のコマンドですべての論理ボリュームのリストを得られます:

# lvs

次に、選択した論理ボリュームのマウントポイントを探してください:

$ lsblk

そうしたら、論理ボリューム上のファイルシステムをアンマウントしてください:

# umount /マウントポイント

最後に、論理ボリュームを削除してください:

# lvremove ボリュームグループ/論理ボリューム

例えば:

# lvremove MyVolGroup/homevol

y を押して、確定してください。

削除した論理ボリュームを参照しているすべての設定ファイル (例: /etc/fstab/etc/crypttab) を更新することを忘れないでください。

lvs を root として実行することで、論理ボリュームが削除されたことを確認できます (このセクションの最初のステップを参照)。

スナップショット

LVM は CoW (コピーオンライト, Copy-on-Write) スナップショットをサポートしています。CoW スナップショットは初めはオリジナルデータを参照します。データブロックが上書きされた時、オリジナルコピーはそのまま残り、新しいブロックはディスク上の別の場所に書き込まれます。これには、いくつかの望ましい特性があります:

  • データをコピーしない (ディスク上の場所を指すポインタのより小さいリストだけです) ため、スナップショットの作成が高速です。
  • スナップショットは、新しいデータブロック (加えて、新しいブロックを指すポインタのための無視できるほど小さい領域) を保持するのに十分な空き領域しか必要としません。例えば、(オリジナルとスナップショットの両方に) 2 GiB だけ書き込んだ 35 GiB のデータのスナップショットは 2 GiB の空き領域しか必要としません。

LVM スナップショットはブロックレベルです。LVM スナップショットは、LVM ツールを扱う場合を除いて、オリジナルと明らかな関連を持たない、新しいブロックデバイスを作成します。なので、オリジナルコピー内でファイルを削除しても、スナップショット内の領域は開放されません。ファイルシステムレベルのスナップショットが必要である場合は、btrfs や ZFS、bcache が必要です。

警告:
  • CoW スナップショットは バックアップではありません。スナップショットはオリジナルデータの第2のコピーを作成するわけではないからです。例えば、オリジナルデータに影響するディスクセクタに損傷が発生すると、スナップショットにも影響が及びます。とはいえ、以下で概要を説明しているように、バックアップを作成するために他のツールを使用するときに、スナップショットは便利かもしれません。
  • btrfs は、異なるファイルシステムが異なる UUID を持つことを期待します。btrfs ファイルシステムを含む LVM ボリュームのスナップショットを作成する場合、オリジナルまたはコピーの UUID を、それらをマウントする前 (及び、無関係のデーモンが btrfs デバイススキャンをトリガーする場合など、カーネルから見えるようにする前) に変更するようにしてください。詳細は、btrfs wiki Gotcha's を参照してください。

設定

スナップショットの論理ボリュームは通常の論理ボリュームと同じように作成します。

# lvcreate --size 100M --snapshot --name snap01vol /dev/MyVolGroup/lvol

上記のボリュームでは、スナップショットボリュームが一杯になるまで 100 MiB のデータを変更を加えることができます。

次のコマンドを使うことで、変更が加えられた lvol 論理ボリュームを、snap01vol スナップショットが作成された時の状態まで戻すことができます:

# lvconvert --merge /dev/MyVolGroup/snap01vol

オリジナルの論理ボリュームが使用中の場合は、次回のブート時にマージサれます (LiveCD からマージすることもできます)。

ノート: マージが行われると、そのスナップショットはもはや存在しなくなります。

また、複数のスナップショットを作成して、それぞれを自由にオリジナルの論理ボリュームにマージすることも可能です。

バックアップ

スナップショットは、バックアップの作成のためにファイルシステムの凍結されたコピーを提供します。例えば、2時間かかったバックアップは、パーティションを直接バックアップするよりも、ファイルシステムのより一貫性のあるイメージを提供します。

ddtar でスナップショットをマウントしたりバックアップしたりできます。dd によって作成されたバックアップファイルのサイズは、対象のスナップショットボリューム上に存在するファイルの総サイズとなります。(バックアップから) 復元するには、スナップショットを作成し、それをマウントし、そこへバックアップを書き込むか展開してください。その後、そのスナップショットを origin にマージしてください。

バックアップとロールバックのために、システム起動時にルートファイルシステムのクリーンなスナップショットを自動的に作成する方法については、LVM によるルートファイルシステムのスナップショット を参照してください。

暗号化

LUKS と LVM の組み合わせの可能なスキームについては、dm-crypt/システム全体の暗号化#LUKS on LVMdm-crypt/システム全体の暗号化#LVM on LUKS を参照してください。

キャッシュ

lvmcache(7) より:

キャッシュ論理ボリュームタイプは小さくて高速な LV を使うことで巨大で鈍重な LV のパフォーマンスを改善します。頻繁に使用されるブロックを高速な LV に保存することで高速化します。LVM は小さくて高速な LV のことをキャッシュプール LV と呼び、巨大で鈍重な LV のことをオリジン LV と呼びます。dm-cache (カーネルドライバー) の要件を満たすため、LVM はキャッシュプール LV をさらに2つのデバイスに分割します。キャッシュデータ LV とキャッシュメタデータ LV です。キャッシュデータ LV にはオリジン LV のデータブロックのコピーが保存されます。キャッシュメタデータ LV にはどこにデータブロックが保存されるかを示す情報が格納されます (例: オリジン LV にあるのかあるいはキャッシュデータ LV にあるのか)。最速かつ最強のキャッシュ論理ボリュームを作成しようと考えている場合はこれらの LV をよく知る必要があります。これらの LV は全て同一の VG に入っていなければなりません。

キャッシュを作成する

高速なディスク (/dev/fastdisk) を PV に変換し、既存の VG (MyVolGroup) に追加します:

# vgextend MyVolGroup /dev/fastdisk

/dev/fastdisk 上に自動メタデータのあるキャッシュプールを作成し、既存の LV MyVolGroup/rootvol をキャッシュボリュームに変換します、1ステップですべてできます:

# lvcreate --type cache --cachemode writethrough -l 100%FREE -n root_cachepool MyVolGroup/rootvol /dev/fastdisk
ヒント: -l 100%FREE を使って PV /dev/fastdisk の利用可能な空き領域 100% を割り当てるのではなく、-L 20G を使うことでキャッシュプールに 20 GiB だけを割り当てることができます。

キャッシュモードには2つのオプションが利用できます:

  • writethrough は書き込まれたデータがキャッシュプール LV とオリジナルの LV の両方に保存されることが保証されます。キャッシュプール LV が保存されているデバイスが故障してもデータが消失することはありません。
  • writeback は高い性能を発揮しますが、キャッシュに使っているドライブが故障したときにデータを喪失する危険性があります。

--cachemode を指定しなかった場合、デフォルトで writethrough が使われます。

キャッシュを削除する

上記で作成したキャッシュを削除したい場合:

# lvconvert --uncache MyVolGroup/rootvol

上記のコマンドでキャッシュに留まっている書き込みが origin LV に適用され、それからキャッシュが削除されます。他のオプションについては lvmcache(7) で説明されています。

RAID

LVM は、ソフトウェア RAID を作成するために使用できます。ハードウェア RAID を持っておらず、いずれにせよ LVM を使用するつもりであるならば、これは良い選択肢です。lvmraid(7) によると:

lvm(8) RAID は、複数の物理デバイスを使用する論理ボリューム (LV) を作成して、パフォーマンスを向上させたり、デバイス障害に対する耐性を持たせたりするための1つの方法です。LVM では、それらの物理デバイスは単一のボリュームグループ (VG) 内の物理ボリューム (PV) です。

LVM RAID は RAID 0、RAID 1、RAID 4、RAID 5、RAID 6、RAID 10 をサポートします。それぞれのレベルに関する詳細は Wikipedia:Standard RAID levels を参照してください。

警告: lvm2 mkinitcpio フックを使用している場合、忘れずに initramfs 内に RAID カーネルモジュールを含めてください。これは、ルートボリュームが LVM RAID 上にあるか無いかに関わらず、行わなくてはなりません。ブート後、pvscan が、initramfs の段階でアクティブ化できなかったデバイスのアクティブ化を再試行しないためです。FS#71385 を参照してください。
ヒント: mdadm も、ソフトウェア RAID を作成するために使用できます。こちらの方が、間違いなくよりシンプルで、人気で、セットアップが簡単です。

RAID をセットアップする

物理ボリュームを作成してください:

# pvcreate /dev/sda2 /dev/sdb2

物理ボリューム上にボリュームグループを作成してください:

# vgcreate MyVolGroup /dev/sda2 /dev/sdb2

lvcreate --type RAIDレベル を使用して論理ボリュームを作成してください。その他のオプションについては lvmraid(7)lvcreate(8) を参照してください。

# lvcreate --type RaidLevel [OPTIONS] -n Name -L Size VG [PVs]

例:

# lvcreate --type raid1 --mirrors 1 -L 20G -n myraid1vol MyVolGroup /dev/sda2 /dev/sdb2

これは、20 GiB のミラー化された、"myraid1vol" という名前の論理ボリュームを、/dev/sda2/dev/sdb2 の上にある VolGroup00 内に作成します。

シンプロビジョニング

ノート: シン (thin) LV のファイルシステムをマウントする際、discard オプションを使うか fstrim を定期的に使用するようにしてください。ファイルが削除されたときにシン LV が縮小できるようにするためです。

lvmthin(7) によると:

標準的な lvm(8) 論理ボリューム (LV) 内のブロックは、LV が作成されたときに割り当てられます。しかし、シンプロビジョニング LV 内のブロックは、それらのブロックが書き込まれたときに割り当てられます。そのため、シンプロビジョニング LV には仮想的なサイズが設定され、物理的に利用可能なストレージよりもさらに大きくすることができます。シンプロビジョニング LV のために提供される物理ストレージの容量は、ニーズに応じて後に拡大させることができます。

例: 仮想専用サーバを立てる

古典的なユースケースを挙げましょう。あなたは独自の VPS サービスを開始したいと考え、初めは約100個の VPS を 930 GiB ハードドライブ搭載の1台の PC 上でホストしているとしましょう。割り当てられたストレージのすべてを実際に使用する VPS はほとんど存在しないため、各 VPS に 9 GiB を割り当てるのではなく、各 VPS に最大 30 GiB を使用できるようにし、シンプロビジョニングを使うことで各 VPS に実際に使用している量のハードドライブ領域を割り当てるようにします。930 GiB のハードドライブは /dev/sdb であるとします。以下がそのセットアップです。

ボリュームグループ MyVolGroup を準備します。

# vgcreate MyVolGroup /dev/sdb

シンプール LV MyThinPool を作成します。この LV はストレージ用のブロックを提供します。

# lvcreate --type thin-pool -n MyThinPool -l 95%FREE MyVolGroup

シンプールは2つのサブボリュームから成ります: データ LV とメタデータ LV です。このコマンドは両方を自動的に作成します。しかし、いずれかが完全に一杯になると、シンプールは動作を停止してしまいます。さらに、LVM は現在、それらのボリュームの縮小をサポートしていません。これが、上記のコマンドで 5% の追加領域を用意している理由です。シンプールのデータサブボリュームかメタデータサブボリュームを拡張する必要が発生する場合に備えているのです。

各 VPS に対してシン LV を作成します。これは、ユーザに対してルートパーティションとして公開されるブロックデバイスです。

# lvcreate -n SomeClientsRoot -V 30G --thinpool MyThinPool MyVolGroup

そのブロックデバイス /dev/MyVolGroup/SomeClientsRoot は、ルートパーティションとして VirtualBox が使用することができます。

シンスナップショットを使用してスペースを節約する

シンスナップショットは、それ自体がシン LV なので、通常のスナップショットよりも遥かに強力です。シンスナップショットが持つ長所の完全なリストは Red Hat のガイド [2] を参照してください。

VPS が作成されるたびに Linux をゼロからインストールするのではなく、基本的な Linux 環境が含まれるただ1つのシン LV から始める方が容量を効率的に使用できます:

# lvcreate -n GenericRoot -V 30G --thinpool MyThinPool MyVolGroup
*** /dev/MyVolGroup/GenericRoot に Linux をインストール ***

そして、各 VPS に対してその LV のスナップショットを作成します:

# lvcreate -s MyVolGroup/GenericRoot -n SomeClientsRoot

このように、シンプールには (少なくとも最初は) 全 VPS に対して共通のデータのコピーがただ1つだけ存在します。追加の利点として、新しい VPS の作成が瞬時に行われます。

これらはシンスナップショットであるため、GenericRoot への1回の書き込み操作において COW 操作は、スナップショット毎に1回ではなく、合計で1回しか行われません。これにより、GenericRoot の更新は、各 VPS が通常のスナップショットである場合よりも効率的なります。

例: ゼロダウンタイムでストレージをアップグレードする

VPS のホスティング以外にもシンプロビジョニングの活用法は存在します。シンプロビジョニングを使用して、すでにマウントされているファイルシステムをアンマウントすることなく、その実効容量を増やす方法を紹介しましょう。ここでは (再び)、サーバに1台の 930 GiB ハードドライブが搭載されていると仮定します。環境は VPS ホスティングのときと同じですが、シン LV が1つしかなく、LV のサイズはシンプールのサイズよりも遥かに大きいとします。

# lvcreate -n MyThinLV -V 16T --thinpool MyThinPool MyVolGroup

この追加の仮想領域は、シンプールを拡張することで後に実際のストレージで埋めることができます。

しばらくして、ストレージのアップグレードが必要になり、新しいハードドライブ /dev/sdc がサーバに接続されたとします。シンプールの容量をアップグレードするには、新しいハードドライブを VG に追加します:

# vgextend MyVolGroup /dev/sdc

次に、シンプールを拡張します:

# lvextend -l +95%FREE MyVolGroup/MyThinPool

このシン LV のサイズは 16 TiB なので、最終的にファイルシステムをアンマウントしてサイズ変更するはめになるまでに、さらに 15.09 TiB のハードドライブ領域を追加できます。

ノート: アプリケーションが実際に存在する以上の物理ストレージを使用しないようにするために、予約ブロックディスククォータを使うべきかもしれません。

トラブルシューティング

LVM コマンドが機能しない

  • 適切なモジュールをロードしてください:
# modprobe dm_mod

dm_mod モジュールは自動的にロードされるはずです。そうならない場合は、明示的にモジュールを起動時にロードするようにしてください

  • lvm コマンドを次のように試してみてください:
# lvm pvdisplay

論理ボリュームが表示されない

既存の論理ボリュームをマウントしようとしても、lvscan に表示されない場合、以下のコマンドによってボリュームを有効にすることができます:

# vgscan
# vgchange -ay

リムーバブルメディア上の LVM

症状:

# vgscan
  Reading all physical volumes.  This may take a while...
  /dev/backupdrive1/backup: read failed after 0 of 4096 at 319836585984: Input/output error
  /dev/backupdrive1/backup: read failed after 0 of 4096 at 319836643328: Input/output error
  /dev/backupdrive1/backup: read failed after 0 of 4096 at 0: Input/output error
  /dev/backupdrive1/backup: read failed after 0 of 4096 at 4096: Input/output error
  Found volume group "backupdrive1" using metadata type lvm2
  Found volume group "networkdrive" using metadata type lvm2

病因: 最初にボリュームグループを無効にしないで外付けの LVM ドライブを取り外したこと。切断する前に、次を実行するようにしましょう:

# vgchange -an ボリュームグループ名

修復: あなたがすでに vgchange -ay vg でそのボリュームグループのアクティブ化を試み、先の Input/output エラーを見たと仮定します:

# vgchange -an ボリュームグループ名

外部ドライブを取り外し、数分待ってください。

# vgscan
# vgchange -ay ボリュームグループ名

LVM とリムーバブルメディアでサスペンド/復帰

この記事またはセクションの正確性には問題があります。
理由: 提供されている解決策は、LUKS on LVM などの複雑なセットアップでは機能しません。 (議論: トーク:LVM#)

LVM をリムーバブルメディア (外部 USB ドライブなど) で正常に動作させるには、外部ドライブのボリュームグループをサスペンド前に非アクティブ化させる必要があります。これが行われないと、(復帰後に) dm デバイスでバッファ I/O エラーが発生する場合があります。この理由により、外部ドライブと内部ドライブを同じボリュームグループ内に混在させることは推奨されません。

外部 USB ドライブのあるボリュームグループを自動的に非アクティブ化するには、以下の方法でそれぞれのボリュームグループに sleep_umount タグを付けてください:

# vgchange --addtag sleep_umount 外部ボリュームグループ

このタグを設定したら、systemd の以下のユニットファイルを使用して、サスペンド前にボリュームを適切に非アクティブ化します。復帰時には、それらのボリュームは LVM によって自動的にアクティブ化されます。

/etc/systemd/system/ext_usb_vg_deactivate.service
[Unit]
Description=Deactivate external USB volume groups on suspend
Before=sleep.target

[Service]
Type=oneshot
ExecStart=-/etc/systemd/system/deactivate_sleep_vgs.sh

[Install]
WantedBy=sleep.target

あと以下のスクリプトです:

/etc/systemd/system/deactivate_sleep_vgs.sh
#!/bin/sh

TAG=@sleep_umount
vgs=$(vgs --noheadings -o vg_name $TAG)

echo "Deactivating volume groups with $TAG tag: $vgs"

# $TAG タグのあるボリュームグループに属する論理ボリュームをアンマウントします
for vg in $vgs; do
    for lv_dev_path in $(lvs --noheadings  -o lv_path -S lv_active=active,vg_name=$vg); do
        echo "Unmounting logical volume $lv_dev_path"
        umount $lv_dev_path
    done
done

# sleep_umount でタグ付けされたボリュームグループを非アクティブ化します
for vg in $vgs; do
    echo "Deactivating volume group $vg"
    vgchange -an $vg
done

最後に、そのユニットを有効化してください。

連続している論理ボリュームのサイズ変更に失敗する

論理ボリュームを拡張しようとすると以下のエラーが表示される場合:

" Insufficient suitable contiguous allocatable extents for logical volume "

明示的に連続するように割り当てるポリシー (オプション -C y または --alloc contiguous) を使って論理ボリュームが作成されており、ボリュームの近隣に連続したエクステントが存在しないのが原因です。[3]

この問題を修正するには、論理ボリュームを拡張する前に、lvchange --alloc inherit 論理ボリューム で割り当てポリシーを変更してください。連続割り当てポリシーを使い続ける必要がある場合、空きエクステントが十分存在するディスク領域にボリュームを移動してください。[4] を参照。

"grub-mkconfig" コマンドで "unknown filesystem" エラーが発生する

grub.cfg を生成する前にスナップショットボリュームは削除するようにしてください。

シンプロビジョニングボリュームに root を配置する場合にタイムアウトが発生する

大量のスナップショットを使用した場合、thin_check の実行時間が長くなるためルートデバイスがタイムアウトしてしまうことがあります。そのためブートローダーの設定に rootdelay=60 カーネルブートパラメータを追加してください。あるいは、thin_check によるブロックマップのチェックをスキップし ([5] を参照) Initramfs を再生成してください:

/etc/lvm/lvm.conf
thin_check_options = [ "-q", "--clear-needs-check-flag", "--skip-mappings" ]

シャットダウンが遅くなる

RAIDやスナップショット、シンプロビジョニングを使用していてシャットダウンが遅くなる場合、lvm2-monitor.service起動していることを確認してください。FS#50420 を参照。

シンプロビジョニングされたスワップボリューム上にハイバネートする

サスペンドとハイバネート#thinly-provisioned LVM ボリュームへのハイバネーション を参照してください。

参照

翻訳ステータス: このページは en:LVM の翻訳バージョンです。最後の翻訳日は 2023-04-29 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。