「LVM」の版間の差分

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

2023年1月19日 (木) 18:50時点における版

関連記事

Wikipedia より:

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 によって提供される) 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 %
ノート:
  • このコマンドは、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 以上の空きスペースをボリュームグループに残しておいてください。

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

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

設定

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

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

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

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

# lvconvert --merge /dev/vg0/snap01

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

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

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

スナップショットはマウントして ddtar を使うことでバックアップできます。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 LVMdm-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 パラメータに指定する容量を変えてください。

ノート: キャッシュモードには2つのオプションが存在します:
  • writethrough は書き込まれたデータがキャッシュプール LV とオリジナルの LV の両方に保存されることが保証されます。キャッシュプール LV が保存されているデバイスが故障してもデータが消失することはありません。
  • writeback は高い性能を発揮しますが、キャッシュに使っているドライブが故障したときにデータを喪失する危険性があります。
--cachemode を指定しなかった場合、デフォルトでは writetrough が使われます。

削除

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

# 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.

警告: When using the lvm2 mkinitcpio hook, make sure to include the RAID kernel modules in the initramfs. This must be done regardless whether the root volume is on LVM RAID or not, as after boot pvscan will not retry activating devices it could not activate in the initramfs phase. See FS#71385.
ヒント: mdadm may also be used to create a software RAID. It is arguably simpler, more popular, and easier to setup.

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.

シンプロビジョニング

ノート: 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 [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.

ノート: 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> で割り当てポリシーを変更してください。連続割り当てポリシーを使い続ける必要がある場合、空きエクステントが十分存在するディスク領域にボリュームを移動してください ([3] を参照)。

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

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

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

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

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

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

参照