LVM

関連記事

• LVM に Arch Linux をインストールする
• ソフトウェア RAID と LVM
• dm-crypt/システム全体の暗号化#LVM on LUKS
• dm-crypt/システム全体の暗号化#LUKS on LVM
• en:Resizing LVM-on-LUKS
• en:Create root filesystem snapshots with LVM

Wikipedia より:

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

背景

LVM の構成要素

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

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

LVM の基本的構成要素:

物理ボリューム (Physical Volume, PV)

LVM によって利用可能な Unix ブロックデバイスノード。例: ハードディスク、MBR か GPT のパーティション、ループバックファイル、デバイスマッパーデバイス (例: 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時間) が掛かるかもしれません。このコマンドを tmux や GNU 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) コマンドを使用してください。

次のいずれかのコマンドにより、既存のボリュームグループ MyVolGroup を my_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) (ext2、ext3、ext4、ReiserFS、XFS をサポート) を使用して 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_vol を new_vol に名称変更します:

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

# lvrename MyVolGroup old_vol new_vol

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

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

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

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

ext2、ext3、ext4 ファイルシステムの場合の正確な論理ボリュームサイズを計算するには、このシンプルな計算式をしようしてください: 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時間かかったバックアップは、パーティションを直接バックアップするよりも、ファイルシステムのより一貫性のあるイメージを提供します。

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

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

暗号化

LUKS と LVM の組み合わせの可能なスキームについては、dm-crypt/システム全体の暗号化#LUKS on LVM と dm-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 とリムーバブルメディアでサスペンド/復帰

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 ボリュームへのハイバネーション を参照してください。

参照

• SourceWare.org の LVM2 Resource Page
• Gentoo:LVM
• Red Hat Enterprise 9: 論理ボリュームの設定および管理
• Ubuntu LVM Guide Part 1Part 2 details snapshots

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