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 より:

LVM は Linux カーネルの論理ボリュームマネージャです。ディスクドライブと大容量記憶装置を管理します。

背景

LVM の構成要素

Logical Volume Management は Linux カーネルの device-mapper 機能を利用して基になっているディスクレイアウトから独立したパーティションのシステムを提供します。LVM を使うことで記憶領域を抽象化することで、（使っているファイルシステムで可能な限り）簡単にパーティションを拡大・縮小したり、物理ディスク上に十分な連続した領域があるかどうか心配することなく、また、fdisk したいディスクが使用中だったり (そしてカーネルが新旧どちらのパーティションテーブルを使っているのかわからなかったり) 他のパーティションをどけなくてはならないという問題に煩わされることなく、パーティションを追加・削除することが可能になります。これは厳密に言えば管理のしやすさの問題です: LVM はセキュリティを追加することはありません。しかしながら、私達の使っている他の2つの技術と上手く収まりがつきます。

LVM の基本的な構成要素は以下の通りです:

• 物理ボリューム (PV, Physical volume): ハードディスク上のパーティション (もしくはハードディスクそれ自体、ループバックファイル) です。これをまとめてボリュームグループを作ることができます。特別なヘッダーがあり物理エクステントに分割されます。物理ボリュームについてはハードドライブを構成するための大きなブロックとして考えて下さい。
• ボリュームグループ (VG, Volume group): ストレージボリューム（つまり一つのディスク）として使われる物理ボリュームの集まりです。ボリュームグループには論理ボリュームが含められます。ボリュームグループはハードドライブとして考えて下さい。
• 論理ボリューム (LV, Logical volume): ボリュームグループの中にある"仮想/論理パーティション"であり、物理エクステントで構成されます。論理ボリュームのことは通常のパーティションみたいなものと考えて下さい。
• 物理エクステント (PE, Physical extent): 論理ボリュームに割り当てるごとができるディスクの欠片 (通常 4MiB) です。物理エクステントはどのパーティションにも割り当てることが出来るディスクのパーツと考えて下さい。

例:

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                                          |
    | _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _|

LVM logical volumes

  Volume Group1 (/dev/MyStorage/ = /dev/sda1 + /dev/sda2 + /dev/sdb1):
     _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
    |Logical volume1 15GB  |Logical volume2 35GB      |Logical volume3 200GB               |
    |/dev/MyStorage/rootvol|/dev/MyStorage/homevol    |/dev/MyStorage/mediavol             |
    |_ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |

利点

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

• 多数のディスクを一つの大きなディスクとして使えます。
• 複数のディスクにまたがる論理ボリュームを作れます。
• 小さな論理ボリュームを作成し、満杯になったら"動的に"リサイズできます。
• ディスクの順番と関係なく論理ボリュームをリサイズできます。VG における LV の位置に依存しないので、周辺に空き容量を取る必要がありません。
• オンラインで論理・物理ボリュームをリサイズ・作成・削除できます。ボリューム上のファイルシステムもリサイズする必要がありますが、オンラインリサイズをサポートしているファイルシステムもあります (ext4 など)。
• サービスによって使われている LV を、サービスを再起動する必要なく他のディスクへオンラインで移行することができます。
• スナップショットを使うことでファイルシステムのフローズンコピーをバックアップすることができます。サービスを落とす時間を最小限にできます。
• 透過的なファイルシステム暗号化や頻繁に使用されるデータのキャッシュなど、様々な device-mapper ターゲットをサポート。(LUKS によって暗号化された) 物理ディスクと LVM からなる環境を構築することで /, /home,/backup などの容量を簡単に変更したりできるようになります。起動時に何度もキーを入力する必要はありません。

欠点

• システムのセットアップに追加の手順が必要で、やや複雑。
• デュアルブートする場合、Windows は LVM をサポートしていません。Windows から LVM のパーティションにアクセスすることは不可能です。

始める

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

ボリューム操作

物理ボリューム

作成

/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) provides more or less the same options as the specialized lvextend(8) and lvreduce(8) commands, while allowing to do both types of operation. Notwithstanding this, all those utilities offer a -r/--resizefs option which allows to resize the file system together with the LV using fsadm(8) (ext2, ext3, ext4, ReiserFS and XFS supported). Therefore it may be easier to simply use lvresize for both operations and use --resizefs to simplify things a bit, except if you have specific needs or want full control over the process.

警告: While enlarging a file system can often be done on-line (i.e. while it is mounted), even for the root partition, shrinking will nearly always require to first unmount the file system so as to prevent data loss. Make sure your file system supports what you are trying to do.

ヒント: If a logical volume will be formatted with ext4, leave at least 256 MiB free space in the volume group to allow using e2scrub(8).

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

To create a LV homevol in a VG MyVolGroup with 300 GiB of capacity, run:

# lvcreate -L 300G MyVolGroup -n homevol

or, to create a LV homevol in a VG MyVolGroup with the rest of capacity, run:

# lvcreate -l 100%FREE MyVolGroup -n homevol

The new LV will appear as /dev/MyVolGroup/homevol. Now you can format the LV with an appropriate file system.

You can check the LV is created using the following command:

# lvs

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

To rename an existing logical volume, use the lvrename(8) command.

Either of the following commands renames logical volume old_vol in volume group MyVolGroup to new_vol.

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

# lvrename MyVolGroup old_vol new_vol

Make sure to update all configuration files (e.g. /etc/fstab or /etc/crypttab) that reference the renamed logical volume.

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

ノート: Only ext2, ext3, ext4, ReiserFS and XFS file systems are supported. For a different type of file system see #Resizing the logical volume and file system separately.

Extend the logical volume mediavol in MyVolGroup by 10 GiB and resize its file system all at once:

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

Set the size of logical volume mediavol in MyVolGroup to 15 GiB and resize its file system all at once:

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

If you want to fill all the free space on a volume group, use the following command:

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

See lvresize(8) for more detailed options.

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

For file systems not supported by fsadm(8) will need to use the appropriate utility to resize the file system before shrinking the logical volume or after expanding it.

To extend logical volume mediavol within volume group MyVolGroup by 2 GiB without touching its file system:

# lvresize -L +2G MyVolGroup/mediavol

Now expand the file system (ext4 in this example) to the maximum size of the underlying logical volume:

# resize2fs /dev/MyVolGroup/mediavol

To reduce the size of logical volume mediavol in MyVolGroup by 500 MiB, first calculate the resulting file system size and shrink the file system (ext4 in this example) to the new size:

# resize2fs /dev/MyVolGroup/mediavol NewSize

When the file system is shrunk, reduce the size of logical volume:

# lvresize -L -500M MyVolGroup/mediavol

To calculate the exact logical volume size for ext2, ext3, ext4 file systems, use a simple formula: 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

ノート: The file system block size is in bytes. Make sure to use the same units for both block and extent size.

102400000 blocks × 4096 bytes/block ÷ 4 MiB/extent = 100000 extents

Passing --resizefs will confirm that the correctness.

# lvreduce -l 100000 --resizefs /dev/MyVolGroup/mediavol

...
The filesystem is already 102400000 (4k) blocks long.  Nothing to do!
...
Logical volume sysvg/root successfully resized.

See lvresize(8) for more detailed options.

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

警告: Before you remove a logical volume, make sure to move all data that you want to keep somewhere else; otherwise, it will be lost!

First, find out the name of the logical volume you want to remove. You can get a list of all logical volumes with:

# lvs

Next, look up the mountpoint of the chosen logical volume:

$ lsblk

Then unmount the filesystem on the logical volume:

# umount /mountpoint

Finally, remove the logical volume:

# lvremove volume_group/logical_volume

For example:

# lvremove MyVolGroup/homevol

Confirm by typing in y.

Make sure to update all configuration files (e.g. /etc/fstab or /etc/crypttab) that reference the removed logical volume.

You can verify the removal of the logical volume by typing lvs as root again (see first step of this section).

スナップショット

説明

LVM を使うことで伝統的なバックアップよりも効率的なシステムのスナップショットを作ることができます。COW (copy-on-write) ポリシーを使うことによって効率化を実現しています。最初に作成したスナップショットには実際のデータの inode のハードリンクだけが含まれます。データに変更が加えられない間は、スナップショットには inode ポインターしかなくデータ自体は入りません。スナップショット先のファイルやディレクトリに変更が入ると、スナップショットによって古いコピーが参照され、新しいコピーは実行中のシステムによって参照されます。このため、35GB のデータがあるシステムでも 2GB 以下しか (オリジナルとスナップショット両方に) 変更を加えない限り、スナップショットに消費する空き容量は 2GB だけです。

設定

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

# lvcreate --size 100M --snapshot --name snap01 /dev/mapper/vg0-pv

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

次のコマンドを使うことによって変更が入った後の 'pv' 論理ボリュームを 'snap01' スナップショットが作られた状態まで戻すことが可能です:

# lvconvert --merge /dev/vg0/snap01

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

マージが行われるとスナップショットはもう存在しなくなります。

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

スナップショットはマウントして dd や tar を使うことでバックアップできます。dd で作られるバックアップファイルのサイズはスナップショットボリュームに入っているファイルのサイズになります。 復元は、スナップショットを作成してマウントして、バックアップをそこに書き込むか展開するだけです。そしてオリジナルのボリュームにマージしてください。

/etc/mkinitcpio.conf の MODULES 変数に dm_snapshot モジュールを入れることが必要で、これがないとシステムが起動しなくなります。インストールしたシステムに既に記述してある場合は、次のコマンドでイメージを再生成してください:

# mkinitcpio -p linux

スナップショットは主にバックアップのためのファイルシステムのフローズンコピーを作るのに使われます; 2時間かかるバックアップはパーティションを直接バックアップするよりも一貫性のあるファイルシステムのイメージを提供します。

バックアップやロールバックのためシステム起動時に root ファイルシステムのスナップショットを自動的に作成する方法は LVM で root ファイルシステムのスナップショットを作成を見て下さい。

initramfs によって有効にならない LVM ボリュームがある場合は、lvm2 パッケージに入っている lvm-monitoring サービスを有効化してください。

キャッシュ

man より:

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

作成

高速なディスクに PV を作成して既存のボリュームグループに追加:

# vgextend dataVG /dev/sdx

自動メタデータを保存するキャッシュプールを sdb に作成して、既存の論理ボリューム (dataLV) をキャッシュボリュームに変換:

# lvcreate --type cache --cachemode writethrough -L 20G -n dataLV_cachepool dataVG/dataLV /dev/sdx

キャッシュを大きくしたい場合、-L パラメータに指定する容量を変えてください。

ノート: キャッシュモードには2つのオプションが存在します:

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

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

削除

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

# lvconvert --uncache dataVG/dataLV

上記のコマンドでキャッシュに留まっている書き込みが LV に適用され、それからキャッシュが削除されます。他のオプションについては man ページを参照。

シンプロビジョニング

ノート: When mounting a thin LV file system, always remember to use the discard option or to use fstrim regularly, to allow the thin LV to shrink as files are deleted.

From lvmthin(7):

Blocks in a standard lvm(8) Logical Volume (LV) are allocated when the LV is created, but blocks in a thin provisioned LV are allocated as they are written. Because of this, a thin provisioned LV is given a virtual size, and can then be much larger than physically available storage. The amount of physical storage provided for thin provisioned LVs can be increased later as the need arises.

例: 仮想プライベートサーバを立てる

Here is the classic use case. Suppose you want to start your own VPS service, initially hosting about 100 VPSes on a single PC with a 930 GiB hard drive. Hardly any of the VPSes will actually use all of the storage they are allotted, so rather than allocate 9 GiB to each VPS, you could allow each VPS a maximum of 30 GiB and use thin provisioning to only allocate as much hard drive space to each VPS as they are actually using. Suppose the 930 GiB hard drive is /dev/sdb. Here is the setup.

Prepare the volume group, MyVolGroup.

# vgcreate MyVolGroup /dev/sdb

Create the thin pool LV, MyThinPool. This LV provides the blocks for storage.

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

The thin pool is composed of two sub-volumes, the data LV and the metadata LV. This command creates both automatically. But the thin pool stops working if either fills completely, and LVM currently does not support the shrinking of either of these volumes. This is why the above command allows for 5% of extra space, in case you ever need to expand the data or metadata sub-volumes of the thin pool.

For each VPS, create a thin LV. This is the block device exposed to the user for their root partition.

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

The block device /dev/MyVolGroup/SomeClientsRoot may then be used by a VirtualBox instance as the root partition.

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

Thin snapshots are much more powerful than regular snapshots, because they are themselves thin LVs. See Red Hat's guide [1] for a complete list of advantages thin snapshots have.

Instead of installing Linux from scratch every time a VPS is created, it is more space-efficient to start with just one thin LV containing a basic installation of Linux:

# lvcreate -n GenericRoot -V 30G --thinpool MyThinPool MyVolGroup
*** install Linux at /dev/MyVolGroup/GenericRoot ***

Then create snapshots of it for each VPS:

# lvcreate -s MyVolGroup/GenericRoot -n SomeClientsRoot

This way, in the thin pool there is only one copy the data common to all VPSes, at least initially. As an added bonus, the creation of a new VPS is instantaneous.

Since these are thin snapshots, a write operation to GenericRoot only causes one COW operation in total, instead of one COW operation per snapshot. This allows you to update GenericRoot more efficiently than if each VPS were a regular snapshot.

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

There are applications of thin provisioning outside of VPS hosting. Here is how you may use it to grow the effective capacity of an already-mounted file system without having to unmount it. Suppose, again, that the server has a single 930 GiB hard drive. The setup is the same as for VPS hosting, only there is only one thin LV and the LV's size is far larger than the thin pool's size.

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

This extra virtual space can be filled in with actual storage at a later time by extending the thin pool.

Suppose some time later, a storage upgrade is needed, and a new hard drive, /dev/sdc, is plugged into the server. To upgrade the thin pool's capacity, add the new hard drive to the VG:

# vgextend MyVolGroup /dev/sdc

Now, extend the thin pool:

# lvextend -l +95%FREE MyVolGroup/MyThinPool

Since this thin LV's size is 16 TiB, you could add another 15.09 TiB of hard drive space before finally having to unmount and resize the file system.

ノート: You will probably want to use reserved blocks or a disk quota to prevent applications from attempting to use more physical storage than there actually is.

トラブルシューティング

Arch-Linux のデフォルトの変更のためにする必要がある変更

/etc/lvm/lvm.conf には use_lvmetad = 1 を設定する必要があります。現在はデフォルトで設定されています。lvm.conf.pacnew ファイルがある場合は、この変更を適用してください。

LVM コマンドが機能しない

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

# modprobe dm_mod

dm_mod モジュールは自動的にロードされるはずです。そうならない場合は、次を試してみて下さい:

/etc/mkinitcpio.conf:

MODULES="dm_mod ..."

変更を適用するには initramfs を再生成する必要があります。

• 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 volume group name

治療:

外部ドライブのプラグを抜いて数分待って下さい:

# vgscan
# vgchange -ay volume group name

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

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

" Insufficient suitable contiguous allocatable extents for logical volume "

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

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

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

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

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

大量のスナップショットを使用した場合、thin_check の実行時間が長くなるためルートデバイスがタイムアウトしてしまうことがあります。そのためブートローダーの設定に rootdelay=60 カーネルブートパラメータを追加してください。

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

RAIDやスナップショット、シンプロビジョニングによってシャットダウンが遅くなる場合、lvm2-monitor.service を起動・有効化してください。FS#50420 を参照。

参照

• SourceWare.org の LVM2 資料ページ
• Gentoo wiki の LVM 記事
• Ubuntu LVM ガイドパート 1 スナップショットに関するパート 2
• Red Hat: 論理ボリュームマネージャーの管理