LVM
関連記事
Wikipedia より:
- 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 │
└─────────────────────────┴─────────────────────────┴──────────────────────────┘
利点
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 によって提供される) lvm-monitoring.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 %
物理ボリュームのサイズを変更する
すべての空き物理セグメントを最後の物理エクステント上に移動したら、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
ボリュームグループをアクティブ化する
# 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 ではこれを簡単に行えます:
# 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
論理ボリューム
論理ボリュームを作成する
ボリュームグループ 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) をすべてアップデートすることを忘れないでください。
論理ボリュームとファイルシステムのサイズを一度に変更する
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
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) ポリシーを使うことによって効率化を実現しています。最初に作成したスナップショットには実際のデータの 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 サービスを有効化してください。
暗号化
LUKS と LVM の組み合わせの可能なスキームについては、dm-crypt/システム全体の暗号化#LUKS on LVM と dm-crypt/システム全体の暗号化#LVM on LUKS を参照してください。
キャッシュ
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 パラメータに指定する容量を変えてください。
削除
上記で作成したキャッシュを削除したい場合:
# lvconvert --uncache dataVG/dataLV
上記のコマンドでキャッシュに留まっている書き込みが LV に適用され、それからキャッシュが削除されます。他のオプションについては man ページを参照。
RAID
LVM may be used to create a software RAID. It is a good choice if the user does not have hardware RAID and was planning on using LVM anyway. From lvmraid(7):
- lvm(8) RAID is a way to create a Logical Volume (LV) that uses multiple physical devices to improve performance or tolerate device failures. In LVM, the physical devices are Physical Volumes (PVs) in a single Volume Group (VG).
LVM RAID supports RAID 0, RAID 1, RAID 4, RAID 5, RAID 6 and RAID 10. See Wikipedia:Standard RAID levels for details on each level.
RAID をセットアップする
Create physical volumes:
# pvcreate /dev/sda2 /dev/sdb2
Create volume group on the physical volumes:
# vgcreate MyVolGroup /dev/sda2 /dev/sdb2
Create logical volumes using lvcreate --type raidlevel, see lvmraid(7) and lvcreate(8) for more options.
# lvcreate --type RaidLevel [OPTIONS] -n Name -L Size VG [PVs]
For example:
# lvcreate --type raid1 --mirrors 1 -L 20G -n myraid1vol MyVolGroup /dev/sda2 /dev/sdb2
will create a 20 GiB mirrored logical volume named "myraid1vol" in VolGroup00 on /dev/sda2 and /dev/sdb2.
シンプロビジョニング
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 [2] 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.
トラブルシューティング
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
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) を使って論理ボリュームが作成されており、ボリュームの近隣に連続したエクステントが存在しないのが原因です (リファレンス を参照)。
この問題を修正するには、論理ボリュームを拡張する前に、lvchange --alloc inherit <logical_volume> で割り当てポリシーを変更してください。連続割り当てポリシーを使い続ける必要がある場合、空きエクステントが十分存在するディスク領域にボリュームを移動してください ([3] を参照)。
"grub-mkconfig" コマンドで "unknown filesystem" エラーが発生する
grub.cfg を生成する前にスナップショットボリュームは削除するようにしてください。
シンプロビジョニングボリュームに root を配置する場合にタイムアウトが発生する
大量のスナップショットを使用した場合、thin_check の実行時間が長くなるためルートデバイスがタイムアウトしてしまうことがあります。そのためブートローダーの設定に rootdelay=60 カーネルブートパラメータを追加してください。
シャットダウンが遅くなる
RAIDやスナップショット、シンプロビジョニングによってシャットダウンが遅くなる場合、lvm2-monitor.service を起動・有効化してください。FS#50420 を参照。