Logical Volume Manager HOWTO bert hubert <ahu@ds9a.nl>&nl; Richard Allen <ra@ra.is> Version 0.0.2 $Date: 2000/11/01 13:42:21 $ 高橋 聡 hisai@din.or.jp 22 Oct 2000 とても実践的な Linux LVM HOWTO はじめに

親愛なる読者の皆さんへ。 このドキュメントでは、LVM が何者で、どのように働き、これを利用することで いかに楽ができるのかについて、皆さんの理解の一助になるように書きました。 LVM FAQ やドイツ語で書かれた HOWTO もありますが、このドキュメントとは系統 が違っています。 このドキュメントはまさに「HOWTO」そのもので、とても実践的であるだけでなく、 LVM の理解をも深めます(うまくいけば)。 はっきりさせておきますが、私は Linux の Logical Volume Manager の開発者では ありません。開発者の方々には敬意を表していますし、協力し合って行きたいと 思っています。 ただおかしな話なのですが、いまだに LVM の開発者がどなたなのかを知りません。 すぐにでも改めたいと思っています。「なんだ」と思われる前にあらかじめお詫びして おきます。 おことわりと著作権

これが役に立つドキュメントになることを望んで配布していますが、「保証は一切 ありません」し、「商業向け」や「特定の目的への適用」に対する保証もありません。 ディスクが融けて、会社をクビになっても - それは私のせいではありません。 申し訳ありませんが。 いつもバックアップを取って、ミッション・クリティカルなシステムでは試さない でください。 ましてや Richard Allen(著者)は、雇用主を代表しているわけでもありません。 Linux は Linus Torvalds 氏の登録商標です。 前提となる知識

たいしたことはありません。Linux をインストールして、ファイルシステム(fdisk や mkfs を使って)を作成したことがあれば、それで十分です。毎度のことですが、 root で作業する場合は注意してください。デバイス・ファイルへの間違った命令や 操作は、既存のデータを壊す恐れがあります。 HP/UX の LVM の設定方法を知っていれば、それでほとんど OK です。Linux は、HP で実現できることと、ほとんど同じにように動きます。 ドキュメントの改訂について

このドキュメントにはいくつか注意すべき点があります。私がこのドキュメントの 大半を書きましたが、そのようなやり方を続けるつもりは毛頭ありません。私は オープン・ソースを信奉していますから、フィードバックや更新、パッチその他を 皆さんにお願いしたいと思っています。誤植や明らかに古くなった間違いを遠慮なし に報告してください。 どのセクションでも、ご自分の方が改訂者として優れていると感じられたり、著者 もしくは新規セクションの改訂者になれるとお思いになったら、そうしてください。 歓迎します。HOWTO の SGML は CVS でいじることができます。私はこれが共同プロ ジェクトとなることを望んでいます。 手助けしていただくと分かりますが、このドキュメントの中にはたくさんの FIXME (修正して)があることに気づかれると思います。パッチはいつでも歓迎します! FIXME にどこで遭遇したとしても、そこは未知の領域であることを了解してくだ さい。 どこにも間違いがないとは言い切れませんので、くれぐれも注意してください。 もし確実なことがわかったなら、何でもお知らせください。 FIXME を削除したい と思います。 CVS アップデートは CVS へアクセス

HOWTO の正式な所在は、下記のところです。 世界中からアクセス可能な anonymous CVS を用意してあります。これで最新版の HOWTO を手軽に得られる上に、皆さんが変更や追加作業を簡単に行えます。 CVS を利用して HOWTO のコピーを持ってきたいならば、下記のようにしてください。 $ export CVSROOT=:pserver:anon@outpost.ds9a.nl:/var/cvsroot $ cvs login CVS password: [enter 'cvs' (without 's)] $ cvs co lvm-howto cvs server: Updating lvm-howto U lvm-howto/lvm-howto.sgml 間違いを見つけたり、追加したいことがあれば、まず手元で修正してから 「cvs diff -u」を実行して、その結果を送ってください。 postscript や dvi、pdf、html、テキストを作るのに役立つ Makefile が用意して あります。色々なフォーマットを作るために、sgml-tools や ghostscript、tetex をインストールする必要があるかもしれません。 このドキュメントの構成

まず LVM を動かすのに必要な基本的な要件をいくつか説明します。ただし例を あげながら、理解のできるように努めます。 LVM とは?

ずっと以前から、パーティションの大きさは一度決めたらそのままです。システム を導入する方は「このパーティションにどのくらいのデータを入れようかな」と 考えるというよりは、「『そもそも』このパーティションにどのくらいのデータを 入れるんだろう」と自問自答しなければなりません。ユーザがパーティションの空き を越えて使おうとすると、パーティションを切り直すか(システムの再インストール もありえます)、シンボリック・リンクなどのスマートとは言えない方法で修正 しなければなりません。 これまでパーティションは、物理的なディスク上の連続したブロックである、 という考え方にならってきました。最近の UNIX ライクなシステムのほとんどは、 物理的に複数のディスクを分割して、いくつかのユニットとして扱う機能を 備えています。 複数のドライブから成る記憶装置のユニットをまとめて「論理ボリューム」とし、 各パーティションに割り振れます。さらにこのユニットは、空きの調整が必要と なった時に、パーティションに対して追加や削除が行えます。 これが論理ボリュームマネージャ(LVM)の基本です。 たとえば 1 GB のディスクを持っていて、「/home」パーティションに 600 MB 割り当てるとします。空きが無くなって、「/home」に 1 GB 必要になったと 考えてみてください。今までのパーティションの考え方だと、少なくとも 1 GB の大きさを持つ他のドライブを用意するしかありませんでした。そしてできる ことはといえば、ディスクを追加し、新しい「/home」を作成し、既存のデータの コピーをすることです。 ところが LVM での設定は、ただ 400 MB(もしくはそれ以上の)ディスクを追加 するだけです。その記憶ユニットを「/home」パーティションに追加するのです。 別のツールを使えば、既存のファイルシステムの大きさを変更できます。こう してサイズを変更し、大きなサイズのパーティションのありがたさを感じつつ、 本来の仕事を再開できます。 LVM は「スナップショット」という非常にユニークな機能を持っていて、ある決まった 時点でのファイルシステムの内容をバックアップすることができます。 この興味をそそる機能が、実際に様々な用途に応用できることについては、後程 触れたいと思います。 次のセクションでは LVM の基本と、LVM が採用している考え方のポイントの 数々を説明します。 基本的な原則

では、脅かし文句はこれぐらいにしておきましょう。しかし LVM には理解しておか なければいけない専門用語がたくさんあります。理解しておかないと、ファイル システムを危険にさらすはめになってしまうかもしれません。 まずは基礎のあたりからはじめます。 物理媒体 「物理」という言葉の意味を複雑に考えないでください。単にハードディスク もしくはパーティションを仮定しています。たとえば、/dev/hda、/dev/hda6、 /dev/sda のような。ブロック・デバイスにある連続したブロックをいくらでも 物理ボリュームに割り当てられます。その物理ボリュームとは… 物理ボリューム (PV) 物理ボリュームとは管理データをいくつか物理媒体に付加した物理媒体そのもの を表します。 これを付加すると、LVM からは物理エクステントを入れる器に見えます。その物理 エクステントとは… 物理エクステント(PE) 物理エクステントは、いかにも大きいブロックのように見え、通常は数 MB の大きさ になります。 物理エクステントはボリューム・グループに配置されます。そのボリューム・ グループ とは… ボリューム・グループ (VG) ボリューム・グループは、いくつかの物理エクステント(複数の物理ボリュームや ハード・ドライブから成る)から構成されます。ボリューム・グループを多数の ハード・ドライブ(たとえば /dev/hda や /dev/sda)から構成されているものと 理解したくなるかもしれませんが、より正しくは、ボリューム・グループは複数の 物理エクステントから構成され、物理エクステントの機能はハード・ドライブに よって提供されているということになります。 >このボリューム・グループを元にして、物理エクステントは論理ボリュームに 割り当てられます。その論理ボリュームとは… 論理ボリューム (LV) そうです、やっとたどり着きました。解説の最終目標はこの論理ボリュームなのです。 情報を保存するのは、まさにここなのです。論理ボリュームは、従来のパーティション と同じ意味になります。 通常のパーティション上で作成するのと同じように、論理ボリューム上でファイル システムを構築するのが普通です。そのファイルシステムとは… ファイルシステム ファイルシステムは好みのものを何でも選べます。標準の ext2 や ReiserFS、NWFS、 XFS、JFX、NTFS 等どれでも。Linux のカーネルにとっては、普通のパーティション と論理ボリュームには何も違いはありません。 訳註:各種ファイルシステムについては、 をご覧ください。 ASCII 文字列による創作を試みることで、このしくみを図解してみましょう。 物理ボリュームは、物理エクステントを含みます。 +------[ 物理ボリューム ]------+ | PE | PE | PE | PE | PE | PE | +------------------------------+ ボリューム・グループは、2 つの物理ボリューム(PV)を含み、6 つの物理エクス テントから構成されます。 +------[ ボリューム・グループ ]---------+ | +--[PV]--------+ +--[PV]---------+ | | | PE | PE | PE | | PE | PE | PE | | | +--------------+ +---------------+ | +---------------------------------------+ もっと広げてみると、こうなります。 +------[ ボリューム・グループ ]---------+ | +--[PV]--------+ +--[PV]---------+ | | | PE | PE | PE | | PE | PE | PE | | | +--+---+---+---+ +-+----+----+---+ | | | | | +-----/ | | | | | | | | | | | | +-+---+---+-+ +----+----+--+ | | | 論理 | | 論理 | | | | ボリューム| | ボリューム | | | | | | | | | | /home | | /var | | | +-----------+ +------------+ | +---------------------------------------+ この図では、2 つのファイルシステムがあり、2 つのディスクにまたがっています。 /home ファイルシステムは 4 つ、/var は 2 つの物理エクステントから構成されて います。 bert hubert 氏は LVM をより視覚的に表示する を作成しています。 が見られます。私の ASCII 文字創作品より見栄えがします。 実例を見ながらの解説

そうなんです。LVM はとても頭の中で消化しづらい考えなので(「我々はボーグの LVM…」)、ここでは論理ボリュームを作成する例を注釈をつけながら進めたいと思 います。 この例をコンソールにそのまま入力「しないで」ください。データを壊してしまう 「恐れ」があります。たとえ手持ちのコンピュータが、/dev/hda3 や /dev/hdb2 を 使用していなくてもです。

訳註:ボーグ(Borg)とは、スタートレック(ネクスト・ジェネレーション) に登場するサイボーグ種族のことで、あらゆるものを非情な手段で自分達の中に取り 込む種族のことです。ハッカーたちの間では、その貪欲に何物をも自分に取り込む 姿から、 Microsoft にたとえる場合があります。

納得いかなければ、上記の ASCII文字で書かれた図をご覧ください。 まず /dev/hda3 と /dev/hdb2 のパーティションのタイプを 0x8e にしてください。 これが「Linux LVM」となります。ただし、お手持ちの fdisk のバージョンによって は、このタイプを認識できずに「Unknown」と表示されるかもしれません。 # fdisk /dev/hda Command (m for help): p Disk /dev/hda: 255 heads, 63 sectors, 623 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/hda1 1 2 16033+ 83 Linux /dev/hda2 3 600 4803435 83 Linux /dev/hda3 601 607 56227+ 83 Linux /dev/hda4 608 614 56227+ 83 Linux Command (m for help): t Partition number (1-4): 3 Hex code (type L to list codes): 8e Command (m for help): p Disk /dev/hda: 255 heads, 63 sectors, 623 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/hda1 1 2 16033+ 83 Linux /dev/hda2 3 600 4803435 83 Linux /dev/hda3 601 607 56227+ 8e Unknown /dev/hda4 608 614 56227+ 83 Linux Command (m for help): w /dev/hdb2 に対しても同様な操作をしてみますが、ここではその結果を表示しません。 この操作は、構成を失った場合に LVM を再構築するのに必要です。 必ずしも全てのコンピュータではありませんが、ここでリブートが必要になる場合 もあります。次の例がうまくいかないようなら、リブートしてみてください。 下記のようにすれば、物理ボリュームが作成できます。 # pvcreate /dev/hda3 pvcreate -- physical volume "/dev/hda3" successfully created # pvcreate /dev/hdb2 pvcreate -- physical volume "/dev/hdb2" successfully created では、2 つの物理ボリュームを「test」というボリューム・グループに追加して みます。 # vgcreate test /dev/hdb2 /dev/hda3 vgcreate -- INFO: using default physical extent size 4 MB vgcreate -- INFO: maximum logical volume size is 255.99 Gigabyte vgcreate -- doing automatic backup of volume group "test" vgcreate -- volume group "test" successfully created and activated これで未使用のボリューム・グループが 1 つできあがりました。ちょっと調べて みましょう。 # vgdisplay -v test --- Volume group --- VG Name test VG Access read/write VG Status available/resizable VG # 0 MAX LV 256 Cur LV 0 Open LV 0 MAX LV Size 255.99 GB Max PV 256 Cur PV 2 Act PV 2 VG Size 184 MB PE Size 4 MB Total PE 46 Alloc PE / Size 0 / 0 Free PE / Size 46 / 184 MB --- No logical volumes defined in test --- --- Physical volumes --- PV Name (#) /dev/hda3 (2) PV Status available / allocatable Total PE / Free PE 13 / 13 PV Name (#) /dev/hdb2 (1) PV Status available / allocatable Total PE / Free PE 33 / 33 情報がずらずら並んでいますが、今のところは大部分を理解できないはずです。 まだ論理ボリュームを定義していませんから、これを修正する必要があります。 50 MB の「HOWTO」というボリュームを「test」ボリューム・グループに作ってみ ます。 # lvcreate -L 50M -n HOWTO test lvcreate -- rounding up size to physical extent boundary "52 MB" lvcreate -- doing automatic backup of "test" lvcreate -- logical volume "/dev/test/HOWTO" successfully created これで、あと少しというところまできましたので、次はファイルシステムを作成 しましょう。 # mke2fs /dev/test/HOWTO mke2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 13328 inodes, 53248 blocks 2662 blocks (5.00%) reserved for the super user First data block=1 7 block groups 8192 blocks per group, 8192 fragments per group 1904 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961 Writing inode tables: done Writing superblocks and filesystem accounting information: done # mount /dev/test/HOWTO /mnt # ls /mnt lost+found これで完了です! 作成したボリューム・グループを見直してみましょう。もう これでボリューム・グループをデータで埋めつくせるようになっているはずです から。 # vgdisplay test -v --- Volume group --- VG Name test VG Access read/write VG Status available/resizable VG # 0 MAX LV 256 Cur LV 1 Open LV 1 MAX LV Size 255.99 GB Max PV 256 Cur PV 2 Act PV 2 VG Size 184 MB PE Size 4 MB Total PE 46 Alloc PE / Size 13 / 52 MB Free PE / Size 33 / 132 MB --- Logical volume --- LV Name /dev/test/HOWTO VG Name test LV Write Access read/write LV Status available LV # 1 # open 1 LV Size 52 MB Current LE 13 Allocated LE 13 Allocation next free Read ahead sectors 120 Block device 58:0 --- Physical volumes --- PV Name (#) /dev/hda3 (2) PV Status available / allocatable Total PE / Free PE 13 / 13 PV Name (#) /dev/hdb2 (1) PV Status available / allocatable Total PE / Free PE 33 / 20 そう、/dev/hda3 はまったく使用していませんが、/dev/hdb2 は 13 個の 物理エクステントを使用しています。 アクティブとインアクティブ - カーネル空間とユーザ空間

まともなオペレーティング・システムがそうであるように、Linux は システム構成 が 2 つに別れています。それは、カーネル空間とユーザ空間です。ユーザ空間は、 ユーザランドと呼ばれることもあります。「ユーザランド」は、人気のあるテーマ・ パークを表す意味でも使われています。 論理ボリュームに関連した新規作成や修正作業は、ユーザ空間で行われ、その結果 をカーネルとやりとりします。ボリューム・グループや論理ボリュームについての 情報がカーネルに渡ると、「アクティブ」と呼ばれる状態になります。修正作業の 中には、ある要素がアクティブな状態であることが必要だったり、インアクティブ な状態が必要なものもあります。 必要な条件

LVM は幅広いバージョンのカーネルで利用できます。Linux 2.4 では、LVM が全面的 に採用されています。カーネル 2.3.47 以降のバージョンでは、LVM はメインブランチ に統合される途中の状態です。 カーネル Linux 2.4

Linux 2.4 では必要な機能すべてが用意されています。大部分のディストリビュー ションで、LVM はモジュールとして含まれてリリースされると思われます。コン パイルする必要があれば、ブロック・デバイス選択のところで LVM の項目に チェックを付けてください。 Linux 2.3.99.*

最先端のカーネル開発が安定してしまえば、このセクションはなくなるでしょう。 さしあたりは、ぐちゃぐちゃすっきりしませんが。 これを書いている時点では Linux 2.3.99pre5 が最新版で、LVM を動作させるのには、 非常に小さいのですが、まだパッチが必要です。 Linux 2.3.99pre3 に対しては、2 つのパッチがリリースされています。 そのパッチは linux-kernel に投稿され、 から取ってこられ ます。 Andrea Arcangeli 氏はこのパッチを改良して として 上記の 2.3.99pre3 用の LVM パッチに当てられるようにしています。 Linux 2.3.99pre5 に対しては、bert hubert 氏が上記 2 つのパッチを 1 つに まとめて、2.3.99pre5 に移植しました。それがこのです。使用するに当たっ てはご注意を。 2.3.99pre6-1 はパッチを統合したプレリリース版です。はじめて LVM の機能を 完全にサポートしました! まだ Andreas 氏のパッチは取り込まれていませんが、 すぐにでもリリースする予定になっているはずです。 2.3.99pre4-ac1 はデフォルトで小さなパッチが取り込まれていて、動作します。 まだ Andreas 氏のパッチは取り込まれていません。 Linux 2.2

FIXME: ここに書いてください。 Linux 2.3

FIXME: ここに書いてください。 ユーザ空間

ツール類が必要なら、 から取ってこられます。glibc2.1 でコンパイルするなら、小さなパッチが必要です。 なお Debian 2.2 ではそのパッチを当ててもエラーがでます。 ファイルシステムを拡張する

色々な設定ができるスクリプトがあって、この作業はそれを使って行えます。必要で あれば、スクリプトを使わずに 1 つ 1 つ実行もできます。 e2fsadm を使って

ボリューム・グループ内に空きがあり、ext2 ファイルシステムを使っているなら (一般的に使用されています)、使い勝手の良いこのツールが使えます。 e2fsadm コマンドは、商用の resize2fs ツールを利用しています。 良いソフトウェアという評判ですが、広く使われているわけではありません。 FSF の ext2resize を使うなら、 e2fsadm に情報を下記のようにして渡す必要があります。 # export E2FSADM_RESIZE_CMD=ext2resize # export E2FSADM_RESIZE_OPTS="" 後は簡単です。e2fsadm は他の LVM のコマンドと非常によく似ています ので。 # e2fsadm /dev/test/HOWTO -L+50M e2fsadm -- correcting size 102 MB to physical extent boundary 104 MB e2fsck 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09 Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/test/HOWTO: 11/25688 files (0.0% non-contiguous), 3263/102400 blocks lvextend -- extending logical volume "/dev/test/howto" to 104 MB lvextend -- doing automatic backup of volume group "test" lvextend -- logical volume "/dev/test/HOWTO" successfully extended ext2_resize_fs ext2_grow_fs ext2_block_relocate ext2_block_relocate_grow ext2_grow_group ext2_add_group ext2_add_group ext2_add_group ext2_add_group ext2_add_group ext2_add_group direct hits 4096 indirect hits 0 misses 1 e2fsadm -- ext2fs in logical volume "/dev/test/HOWTO" successfully extended to 104 MB 論理ボリュームを拡張する

e2fsadm でこの作業は行えますが、e2fsadm を使わない方法を 理解しておいても損はないと思います。 # lvextend -L+12M /dev/test/HOWTO lvextend -- rounding size to physical extent boundary lvextend -- extending logical volume "/dev/test/HOWTO" to 116 MB lvextend -- doing automatic backup of volume group "test" lvextend -- logical volume "/dev/test/HOWTO" successfully extended ボリューム・グループを拡張する

これは vgextend ユーティリティを使いますが、とても簡単です。まず最初に 物理ボリュームを作ります。これは pvcreate ユーティリティを使います。 このツールを使ってブロック・デバイスを物理ボリュームに置き換えます。 それが終った後に、vgextend を実行します。 # pvcreate /dev/sda1 pvcreate -- physical volume "/dev/sda1" successfully created # vgextend webgroup /dev/sda1 vgextend -- INFO: maximum logical volume size is 255.99 Gigabyte vgextend -- doing automatic backup of volume group "webgroup" vgextend -- volume group "webgroup" successfully extended おぼえておいて欲しいことは、これを実行するには、ボリューム・グループが アクティブである必要があるということです。「vgchange -a y webgroup」を 実行すればアクティブにできます。 ファイルシステムを拡張する

ツールを使わずに実現したいなら、いくつかの方法があります。 オフライン状態の ext2 を ext2resize を使って

オフラインとは、ファイルシステムのマウントを外して、これから行う変更作業 ができる状態のことを指します。ファイルシステムやその中のデータは、この 状態では利用することができません。つまり、root や他の重要なパーティションの大きさ を変更する場合は、他にブートできる媒体が必要となることを忘れないでください。

ext2resize ツールは、GNU の ftp サイトから取ってこられますが、大抵のディス トリビューションは、パッケージの 1 つとして用意してあります。使い方はとても簡単 です。 # ext2resize /dev/HOWTO/small 40000 40000 という数字は、拡張もしくは縮小された後のファイルシステムのブロック数です。 オンライン状態の ext2

FIXME: ここに書いてください。 ディスクの交換

LVM の長所の 1 つにこれが上げられます。あるディスクでエラーが出はじめたら、 データをぼちぼち移動しなければいけません。LVM を利用すると、とても簡単に 実行できます。 まずはじめに典型的な交換作業の例をあげます。少なくとも、交換したいだけの 容量を持つディスクをシステムに追加してみます。 データを移動するには、ボリューム・グループの物理エクステントを他のディスク、 より正確には物理ボリュームに移動することになります。これを行うには LVM で 行うには pvmove ユーティリティを使用します。 おかしなディスクを /dev/hda1 として、これを /dev/sdb3 に置き換えることにしま しょう。まず /dev/sdb3 を /dev/hda1 が属しているボリューム・グループを追加 します。 この作業を行う前に、このボリューム・グループに属するファイルシステムのマウント を外してください。フル・バックアップをとればなお安全です。 FIXME: これは必要か? では pvmove を実行してみましょう。とても簡単に実行できるので、 外そうとしているディスクに注意を集中してください。実行は下記のように なります。 # pvmove /dev/hda1 pvmove -- moving physical extents in active volume group "test1" pvmove -- WARNING: moving of active logical volumes may cause data loss! pvmove -- do you want to continue? [y/n] y pvmove -- doing automatic backup of volume group "test1" pvmove -- 12 extents of physical volume "/dev/hda1" successfully moved この警告に注意してください。というのも、カーネルと LVM それぞれいくつかの バージョンでは、このコマンドで問題が生じます。2.3.99pre6-2 でテストして、 うまく動きましたが、警告が出ました。 これで物理エクステントは /dev/hda1 のどこにも存在しなくなったたので、 ボリューム・グループから外すことができます。 # vgreduce test1 /dev/hda1 vgreduce -- doing automatic backup of volume group "test1" vgreduce -- volume group "test1" successfully reduced by physical volume: vgreduce -- /dev/hda1 FIXME:いくつかはっきりさせる必要がある。ボリューム・グループはアクティブ にしておくべきか? データが失われるのはどんな場合か? 手遅れになる時

ディスクか何の警告もなしに壊れて、そのディスクの物理エクステントを他の物理 ボリュームに移行できなかった場合には、壊れてしまった物理ボリュームの論理 ボリュームをミラーしていなければ、データが壊れてしまうでしょう。適切な対応方法 は、壊れた物理ボリュームとまったく同じものと交換するか、最低でも同じ大きさの パーティションに交換するかのどちらかです。 /etc/lvmconf ディレクトリには LVM に関するデータと構成がバックアップされて います。構成とは、ディスクの物理ボリュームへの割り当てと物理ボリュームが 属しているボリューム・グループ、どの論理ボリュームがそのボリューム・グループ に入っているかの一覧から成ります。 壊れたディスクを交換した後、vgcfgrestore コマンドを使って LVM の データを新しい物理ボリュームに復活させます。この作業でボリューム・グループ をはじめ、すべての情報を復活できますが、論理ボリュームのデータは復活しません。 その理由は、LVM のコマンドの大部分が、変更が加わった時点で自動的に LVM 関連の データをバックアップしているからです。 確実なバックアップを行うには、スナップショットを取る

ここにあげるのは、本当に起こるかどうかも疑わしい例の 1 つです。たとえば 様々な処理を次々こなしているサーバを運用しているとします。有効なバック アップという点からすると、稼働中のあらゆるプログラムを落とす必要があります。 そうしないと、システムが不整合な状態に陥ってしまうからです。 典型的な例として、あるファイルを /tmp から /root に移す場合を見てみます。 /root がまずバックアップされていました。/root を見た時、まだそのファイルは ありませんでした。その時までに /tmp がバックアップが完了しましたが、ファイ ルは移動した後でした。 データベースやディレクトリの保存では状況が変わります。アプリケーションを きちんと落とす機会がないと、ファイルがバックアップ可能な状態になるきっかけ が得られません。 別の問題も出てきます。普通はアプリケーションを落し、バックアップをとってから、 再起動をかけます。これはバックアップが数分で取り終えればまったく問題になりま せんが、数時間かかったり、いつ終るともわからないなら、ダメージをこうむること になります。 LVM でこの状況を救いましょう。 LVM を使えば、その時々の論理ボリュームの状況をスナップショットにとること ができ、それをマウントしたり、バックアップをとることもできます。 試してみましょう。 # mount /dev/test/HOWTO /mnt # echo > /mnt/a.test.file # ls /mnt/ a.test.file lost+found # ls -l /mnt/ total 13 -rw-r--r-- 1 root root 1 Apr 2 00:28 a.test.file drwxr-xr-x 2 root root 12288 Apr 2 00:28 lost+found これで、対象となるファイルができました。スナップショットを作ってみましょう。 # lvcreate --size 16m --snapshot --name snap /dev/test/HOWTO lvcreate -- WARNING: all snapshots will be disabled if more than 16 MB are changed lvcreate -- INFO: using default snapshot chunk size of 64 KB lvcreate -- doing automatic backup of "test" lvcreate -- logical volume "/dev/test/HOWTO" successfully created 「--size」パラメタについては後で詳しく触れます。スナップショットをマウント してみます。 # mount /dev/test/snap /snap # ls /snap total 13 -rw-r--r-- 1 root root 1 Apr 2 00:28 a.test.file drwxr-xr-x 2 root root 12288 Apr 2 00:28 lost+found 元の位置から a.test.file を削除して、まだスナップショットの場所に存在する かをチェックしてみてください。 # rm /mnt/a.test.file # ls /snap total 13 -rw-r--r-- 1 root root 1 Apr 2 00:28 a.test.file drwxr-xr-x 2 root root 12288 Apr 2 00:28 lost+found これはすごい! どのように働く?

「--size」パラメタを設定しなければならなかったことをおぼえていますか? 「snap」ボリュームは、ブロックもしくは「チャンク」のすべてのコピーを LVM が 必要とする時、つまり元データが変更されてしまった時になければいけません。 訳註:チャンク(chunk)とは、あるデータ構造をいくつかにまとめた単位を 表します。この場合は、ディスク上で物理的に連続している LVM が利用可能な最小 単位を意味しています。 a.test.file を削除した時、その inode は削除されます。すると 64 KB 分(チャンク の大きさ)が「ダーティー(dirty)な」状態としてマークされ、元データのコピーが 「snap」ボリュームに書かれます。この場合ですと、スナップショットとして 16 MB 確保してありますから、 16 MB 以上の「チャンク」が変更されると、スナップ ショットは機能しなくなるでしょう。 スナップショットのパーティションの大きさを間違いなく決めるには、論理ボリューム 本来の使われ方を考慮して、スナップショットをアクティブにする時間を推測するしか ありません。たとえば、真夜中に誰も利用していないシステムを数時間かけてバック アップするなら、ごくわずかな空きしか必要ないと思います。 注意して欲しいのは、スナップショットはずっと存在するものではない、ということ です。LVM を落したり、リブートしたりすれば、スナップショットは消えてしまい、 再作成することになります。 冗長性とパフォーマンス

パフォーマンスを上げる点から見た場合、データを複数のディスクに「ストライプ」 して分散できます。 つまりブロック 1 は物理ボリューム A に、ブロック 2 は物理ボリューム B に、 ブロック 3 は再び物理ボリューム A に、というようにです。2 つ以上のディスクにも ストライプできます。 この処置をとることで、ディスクのバンド幅が広がるとともに、「スピンドル」が もっと必要になることを意味しています。スピンドルについては後程詳しく説明します。 訳註:スピンドル(spindle)は、ハードディスクを構成する部品の 1 つで、 情報を記録する部品である「プラッター」という磁気媒体を回転させている軸を指 します。つまり「スピンドル」が多ければ多いほど、それだけ平行してディスクに 読み書きができ、全体のパフォーマンスが上ることになります。 パフォーマンスをあげるだけでなく、あるデータを複数ディスク上にコピーして持たす こともできます。これをミラーリングと呼びます。現状の LVM はそもそもこの機能を サポートしていませんが、結果的に実現することが可能です。 なぜストライプするのか?

ディスクのパフォーマンスに影響を与える要因は、少なくとも 3 つあります。 最も顕著に影響がでるものは、ディスク上のデータを連続して読み書きする速度 です。 SCSI や IDE バス 1 本上に 1 つだけディスクがあり、そこで大きなファイル を読み書きする時には、これはパフォーマンスを低下させる要因となります。 ディスクが利用できる帯域幅は限られています。1 本の SCSI バスに 7 つのディス クを繋げれば、恐らくディスク自体に書き込む速度がバスの速度を越えてしまうで しょう。 お金さえあれば、このボトルネックを根本的に解決できます。 遅延が発生します。よく言われているように、遅延は以前から厄介な問題です。 なお悪いことに、お金を注ぎ込んでも遅延を減らすことができません! 近頃のディ スクはおおよそ 7 ms の遅延が生じます。SCSI の遅延も、25 ms 程度発生して いました。 FIXME: 最近の値が必要! これは何を意味するのでしょうか? 遅延を合算すると、標準で 30 ms 程度の遅延 が発生することになるでしょう。ということは、1 秒当たりわずか 33 回だけしか ディスクに対する操作ができないということになります。 秒当たりに多量の問い合わせしたいのに、キャシュも十分でないとなると、それは 不運としか言いようがありません。 並列に動く複数のディスクか「スピンドル」があれば、同時に複数の命令を実行でき ます。これは遅延の問題を回避する有効な手段です。大規模な news サーバーのよう な用途では、ストライピングか入出力をスムーズに行う別の手段なしには動作すら しません。 これがストライピングの動作です。バスを最大限に使えれば、連続した読み書きも もっと速くなるかもしれません。 なぜストライピングしないのか

ストライピングだけを行うと、「ビット単位」で破壊が起こる危険が出てきます。 ディスクが駄目になると、論理ボリュームの内容がおしゃかになってしまいます。 データを連続して置いてあれば、ファイルシステムの一部だけで済ませられます。 究極の手段は、ミラーリングした上でのストライピングです。 FIXME: LVM と md を使って、ミラーリングした上でストライピングしてみる 訳註:md は、ソフトウエア RAID のデバイスです。 を参考にしてください。 LVM でのストライピング

ストライプ構成の設定は、論理ボリュームの作成時に lvcreate を使って済ませます。 関連するパラメタは 2 つあります。-i でいくつの物理ボリュームに分散させるのか を指定します。実はストライピングはビット単位ではなく、ブロック単位で行われ ます。-I でキロバイト単位で増減の単位を指定をします。注意点は、指定するのが 2 の累乗単位で、 最大 128 KB であることです。 例です。 # lvcreate -n stripedlv -i 2 -I 64 mygroup -L 20M lvcreate -- rounding 20480 KB to stripe boundary size 24576 KB / 6 PE lvcreate -- doing automatic backup of "mygroup" lvcreate -- logical volume "/dev/mygroup/stripedlv" successfully created パフォーマンス上の注意点

同じディスクの 2 つのパーティション上でストライプすると、パフォーマンスが上る どころかおそらく逆効果になってしまうでしょう。- くれぐれもそうしないように してください。1 本の IDE バスに 2 つのディスクを接続してあってもやはり同じ ことが言えます。- 私が知っている IDE より進化していなければ。 FIXME: これは今でも正しいのか? 古めのマザーボードには、2 本の IDE バスがあるかもしれませんが、2 本目は 使い物にならない場合が多く、実質は低速な CD-ROM ドライブを動かすのに使われ ることになってしまいます。ツールを使ってベンチマークを取ることが可能で、 最も気になるツールは「Bonnie」です。ReiserFS の開発者たちは、 をリリース していて、これでパフォーマンスのデータを計ってもいいかもしれません。 ハードウェア RAID

ハイエンドなインテル x86 サーバーの多くには、ハードウェア RAID コントローラ がついています。その内の大部分には、少なくとも 2 つの独立した SCSI チャネル があります。幸いなことに LVM でそれ程苦労せずに利用できます。管理者は RAID コントローラ自身の機能を使って論理ドライブの構成を決めてから、Linux で RAID コントローラを通してディスクを認識させなければいけません。たとえば SCSI チャネル A 上の 2 つのディスクでストライプを行い、そのミラーを SCSI チャネル B 上の 2 つのディスク にしたとします。これは典型的な RAID 0/1 の構成で、 パフォーマンスとデータの安全性を最大限引出します。この構成のマシンで Linux をブートすると、RAID コントローラ上にある 1 つのディスク上にだけ、データ領域 があるように「見えます」。これこそが、 4 つのディスクで構成した RAID 0/1 の 論理ドライブなのです。 つまり LVM から見る限り、マシンはあたかもディスクを 1 つだけ備えていて、1 つ のディスクを扱うように使用できます。ディスクの 1 つが壊れても、LVM はそれを 知るよしもありません。管理者がディスクを交換しても(ホットスワップ機構を使って、 稼働中に)、LVM はそれを検知しないだけでなく、コントローラはミラーされている データを再同期させて、すべて元通りにします。 ここでたいていの方はちょっと考えてから、「RAID コントローラを LVM と併用する と何がいいのだろう?」という疑問が湧きます。 簡潔に説明すると、次のような答えになります。RAID コントローラの元で論理 ドライブを決定してしまうと、そのドライブに対して後でディスクを追加することは できなくなります。空きをどのくらい取るかの計算を間違ってしまったり、単にもう 少し空きが必要になった場合にも、新しいディスクがいくつであれ、既存のストライプ 構成には追加できません。つまりそのコントローラの元で、新しい RAID のストライプ 構成を作成しなければいけません。そこで LVM を使っていれば、ただ LVM の論理ボリュームを拡張すればいいだけなので、RAID コントローラの元で新旧 のストライプ構成をスムーズに拡張できます。 FIXME: このテーマに追加することはあるか? Linux のソフトウェア RAID

Linux 2.4 にはとても素晴らしい RAID がきちんと使える状態でついてきます。 Linux 2.2 にはデフォルトで Alan Cox 氏がリリースした初期バージョンの RAID 機能がついていますが、出来があまりよくありません。2.2 がまだこの初期のリリース を採用している訳は、カーネルの開発者が Linux の安定版でユーザランドのアップ デートをともなう変更を望まなかったためです。 Red Hat や Mandrake、SuSE をはじめとするディストリビュータの大部分は、素晴ら しい出来になると思われるバージョン 0.90 に置き換えることを決めました。 ここではバージョン 0.90 だけをを扱うことにします。 FIXME: ここに更に書いてください。 詳しい解説

コンピュータ間で LVM のディスクを移動する

この新しい技術を利用すると、単純な作業、たとえばあるマシンから他のマシンに ディスクを移すような作業が、やや手の混んだものになるかもしれません。LVM を 使用する以前であれば、やるべきことは、そのディスクを新しいマシンに取り付け て、ファイルシステムをマウントすることだけでした。LVM を用いると少しやること が増えます。LVM の構造は両方のディスク上と /etc/lvmconf に保存されています。 したがって唯一確認しなければいけないことは、ボリューム・グループが含まれている ディスクがいくつあっても、ボリューム・グループが属することになるマシン上で 認識できるかということです。これを行うのが、vgexport コマンドです。 vgexport は単純に /etc/lvmconf にあるボリューム・グループの構成から 削除するだけですので、ディスク上では何も変更ありません。後は、ディスクを新しい マシンに接続して(同じ ID であってはならない)、/etc/lvmconf をアップデートする だけです。それは vgimport を使って行います。 例 マシン No 1 で、 vgchange -a n vg01 vgexport vg01 マシン No 2 で、 vgimport vg01 /dev/sda1 /dev/sdb1 vgchange -a y vg01 注意すべき点は、同名のボリューム・グループを用いてはいけないということです。 もし vgimport コマンドが設定のバックアップを上げなければ、vgcfgbackup を使って上げてください。 /etc/lvmtab and /etc/lvmtab.d の再構成

FIXME: もっときちんとした内容を書く さらに詳しく

主要な LVM 関連リソースが利用できる ドイツ語が読めるなら、既にたくさんの情報が記述してある Peter.Wuestefeld@resnova.de 氏は、ドイツ語の HOWTO を英語に翻訳中。もうすぐ この HOWTO に多くの時間を割く模様。我々の HOWTO が疑わしかったり、間違って いたりしたなら、参考にすることをお勧めする Linux の LVM は HP/UX の実装とほぼ間違いなく同様に機能するので、HP/UX の ドキュメントがとても役に立つ。とても良い内容である。 謝辞と感謝

この HOWTO を書くのに当たって、助けていただいたすべての方々を記載しようと 心がけました。 アップデートや訂正、寄稿をしていただいた方々だけでなく、このテーマを我々が 理解できるように助言いただいた方々もあげさせていただきました。 Axel Boldt <axel@uni-paderborn.de> Sean Reifschneider <jafo@tummy.com> Alexander Talos <at@atat.at> Eric Maryniak <e.maryniak@pobox.com> 日本語版謝辞

この翻訳を行うに当たって、JF プロジェクトの武井さんよりアドバイスを いただきました。この場を借りてお礼申し上げます。