![[RSS]](http://static.sourceforge.jp/ic/feed-14x14.png){kind=small}
ハードディスクはアクセス速度が遅く、故障も多い。さすがにワーキングメモリとして使われることはなくなったが、固定サイズのハードディスク・パーティションは今なおストレージ領域の主流である。そのため、速度やデータ損失の問題だけでなく、サーバをインストールする際のパーティションサイズの計算が正しいか、また（ほとんど未使用のパーティションがほかにあるのに）特定のパーティションだけが空き領域不足に陥っていないかにも気を配る必要がある。さらに、実稼働中のシステムで物理ボリュームの境界を越えるパーティションの移動が必要になったりするとかなり厄介だ。
本稿は、最近出版された書籍『The Offical Ubuntu Book, Third Edition』(Prentice Hall、2008年6月刊、Copyright 2008 Canonical, Ltd.)からの抜粋。
RAIDは確かに役に立つ。パフォーマンスや耐故障性（フォールトトレランス）の問題に対してはすばらしい効果を発揮するが、あまりに下位のレベルで動作するのでパーティションのサイズや移動の柔軟性という面では役に立たない。我々が本当に求めているのは、パーティションの概念の抽象レベルを1つ引き上げる、つまり、根底にある物理媒体がパーティションの影響を受けずに済むようにする手段だ。その結果、パーティションサイズの容易な変更や、複数の物理ドライブで構成されるパーティションの作成が可能になる。また、あるパーティションから削った領域を簡単に別のパーティションに加えたり、稼働中のサーバに載っている物理ドライブ上でパーティションの設定を変更できたりするのだ。
論理ボリューム管理（LVM：Logical Volume Management）のすばらしさは、ストレージの基本単位を物理的なドライブから仮想（論理）的なドライブに換えてくれる仕組みにある。企業向けの高価なUNIXオペレーティングシステムの機能だったLVMは、以前はサードパーティのベンダから購入するしかなかった。やがてフリーソフトウェアの影響力が増大するなか、1998年にHeinz Mauelshagen氏によってLinux向けの論理ボリュームマネージャが実装された。我々がLVMと呼んでいるのはこれだ。それ以来、LVMは幾多の改良を重ね、今では実稼働環境で広く利用されている。Ubuntuインストーラでは、サーバに対するLVMの設定がインストール中に簡単に行えるようになっている。
LVMのしくみと用語
LVMは、しくみを理解するのがRAIDよりもいささか難しい。ストレージの扱い方が全体的に見直されており、新たな専門用語を覚える必要があるからだ。LVMでは、物理ボリューム（PV：Physical Volume）によってディスク領域が提供されるものとし、（OSにおけるマウントポイントへのパーティションの対応付けのような）特有の機構はない。PVをグループ化して得られるボリュームグループ（VG：Volume Group）は、古き良き時代の規格化されたハードディスクドライブに似た仮想的なストレージプールとなる。これらのVGを切り分けて作成されるのが論理ボリューム（LV：Logical Volume）であり、LVMでは、このLVが我々の扱い慣れた通常のパーティションに相当する。ファイルシステムをこれらのLV上に作成し、マウントすることでディレクトリツリーが形成される。内部では、LVMによって物理ボリュームが小さなブロック単位（デフォルトでは4MB）に分割されており、それぞれのブロックを物理エクステント（PE：Physical Extent）と呼ぶ。
LVMを利用するには、まずハードディスクドライブ上に1つ以上のパーティションを設定する。これらのパーティションが物理ボリューム（PV）となり、各PVは物理エクステント（PE）単位に分割される。続いてPEをグループ化することでボリュームグループ（VG）を作成し、最後にVG上で論理ボリューム（LV）の作成を行う。ハードディスクドライブの物理的なパーティションではなく、仮想的なパーティションであるこうしたLVがファイルシステムを形成し、OSへのマッピングとマウントの対象となる。結局は従来と同じ固定サイズのパーティションになるのに、こんな複雑なしくみに変えて何の利点があるのかと思われるかもしれない。続きを読めば、その利点がすぐにわかるだろう。