特集
2003/08/08 13:00:00 更新
特集:LVMによるディスクパーティションの動的化(後編) (2/5)
LVをリサイズしよう
PVの追加によってVG容量に余裕ができれば、LV容量が不足した際にLV拡大を行える。ここでは実際にLV容量操作してみよう。
LVは、いちどマウントしてしまえば通常のディスクとシェル上での変わりがない。このため、作業に利用していれば、いずれ容量が減少していくことになる。次の例では、「/dev/system/work」ディレクトリの容量が限界間近であることが分かる。
# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda5 4134900 1928804 1996048 50% / /dev/hda1 69973 9668 56692 15% /boot /dev/system/work 2064208 1877832 81520 96% /work |
そこで、LVリサイズの操作を行い容量を増やしてみよう。その前に重要なのが、「ファイルシステムがリサイズに対応しているか」という点だ。
ext3(ext2)ファイルシステムは増減対応されているが、ほかのファイルシステムでは増加のみに対応している場合がある。通常の用途において容量を減らすという局面は少ないため、不要だと思われるだろう。しかし、筆者の見解では「予想外の空スペースを他のLVに使い回す」といった効率を考慮した利用方法もあるため、順次対応していってもらいたいと感じる。
また、ext3の場合には注意が必要だ。それは、ジャーナルファイルのロッキングなどで、標準カーネルでは行うことができないLVMパッケージに付属するカーネルパッチを適用していなければ行えないため、注意が必要である(LVM対応のカーネルを使っているディストリビューションでは、適用済みとなっているため問題ない)。
ext3のリサイズのためには、いちどアンマウントした後に「e2fsadm」コマンドを用いる。増加させたい容量と、対象となるLVを指定すればよい。ここでは、パラメータとして2GBの増量(-L+2g)と、LV(/dev/system/work)を指定している例だ。
# umount /work # /sbin/e2fsadm -L+2g /dev/system/work e2fsck 1.28 (31-Aug-2002) 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/system/work: 12/262144 files (0.0% non-contiguous), 477694/524288 blocks lvextend -- extending logical volume "/dev/system/work" to 4 GB lvextend -- doing automatic backup of volume group "system" lvextend -- logical volume "/dev/system/work" successfully extended resize2fs 1.28 (31-Aug-2002) Begin pass 1 (max = 16) Extending the inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX The filesystem on /dev/system/work is now 1048576 blocks long. e2fsadm -- ext2fs in logical volume /dev/system/work successfully extended to 4 GB |
最後の出力で、4GB(2GB+2GB)となっていることを確認し、次のように再度マウントをしてみると、領域容量が増えていることも分かるはずだ。
# mount /dev/system/work /work # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda5 4134900 1928984 1995868 50% / /dev/hda1 69973 9668 56692 15% /boot /dev/system/work 4128448 1877832 2082844 48% /work |
システム起動時にLVを自動マウントさせるには
LVMの利点であるリサイズが使えるようになれば、あとはこのパーティションを常時利用できるよう設定すればよい。ここではそのための手順を考えてみよう。
システム上にLVを作成し、利用する方法も分かっただろう。しかし、サーバを再起動しても問題なく利用できるようにするためには、確認しておく事項がある。ひとつはファイルシステムとデバイスを初期設定しておく/etc/fstabの設定である。LVM設定後は、通常のデバイス同様に記述しておく必要がある。
# cat /etc/fstab /dev/hda5 / ext3 defaults 1 1 /dev/hda1 /boot ext3 defaults 1 2 /dev/hda6 swap swap pri=42 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 proc /proc proc defaults 0 0 usbdevfs /proc/bus/usb usbdevfs noauto 0 0 /dev/cdrecorder /media/cdrecorder auto ro,noauto,user,exec,iocharset=sjis 0 0 /dev/cdrom /media/cdrom auto ro,noauto,user,exec,iocharset=sjis 0 0 /dev/fd0 /media/floppy auto noauto,user,sync 0 0 /dev/system/work /work ext3 defaults 1 2 |
上記のように書き足しておけばよい。次の確認事項は、「システムが起動する際にLVが利用可能になっているか」という点だ。カーネルがLVMを認識できるよう組み込む(もしくはモジュールで読み込む)よう設定されているのはもちろんだが、起動時に現在のPV状態からVGとLVを再構築しなければならない。そのために利用するのが、最初に用いた「vgscan」であるが。この処理は通常、ディストリビューションが提供するLVMパッケージを利用している限り、自動実行するようになっている。具体的な手順はLVMのソースコード付属のドキュメントを確認することが望ましいが、
1. vgscanでVGを再構成。
2. vgchangeで利用可能状態(active)にする。
という手順を行うだけである。
なお、「LVMはルートパーティションに利用できるのか」という疑問もあるだろう。「initrd内でlvmモジュールを読み込み、vgscan/vgchangeで検出、そして認識させる」ことで可能ではあるが、initrdが失敗した際に復旧が困難になるため、おすすめはしない。また、仮にルートパーティションをLVM化しても、ブートローダ(GRUBなど)がLVM内のカーネルファイルを認識することは(現状では)困難なため、カーネルとブートローダの置いてあるパーティション(通常は/boot)はLVMにしてはならない。
[佐藤大輔,ITmedia]
Copyright © ITmedia, Inc. All Rights Reserved.