LVMパーティションの拡張
2005. 8.28

長らくARAID99-2000でhardware RAIDを組んでいると、何度かHDDがクラッシュして交換するはめになる。個人ではそんなに多くのスペアHDDをストックすることもできず、やがて容量の多いHDDをやむなく投入することになる。しかし、元々の(容量の少ない)HDDと新しい(容量の多い)HDDを組み合わせてRAID1を組むとRAIDディスクとしての容量は少ないHDDのほうに制限されてしまう。その後、残った少ないHDDを多いHDDに交換しても自動的にRAID容量を増やしてくれることはない。

(1) (2) (3)
Primary Secondary Primary Secondary Primary Secondary
HDD (A)
120 GB
HDD (B)
120 GB
HDD (B)
120 GB
HDD (C)
250 GB
HDD (C)
250 GB
HDD (D)
250 GB
RAID容量
120 GB
RAID容量
120 GB
RAID容量
120 GB
Primary HDD (A)が故障!
(大抵壊れるのは
Primary -_-;;;)
Secondary HDD (B)を
Primaryに回し、Secondary
に250 GBのHDD (C)を投入
Secondary HDD (C)を
Primaryに回し、Secondary
に250 GBのHDD (D)を投入


上の(3)の状態になったときには、せっかく250 GBもの容量のHDDを投入しているのに実際は120 GBしか使えない。これは誠に理不尽極まりない。

(3)の状態のときは、実際のところどうなっているかと言うと、元々の120 GB HDDのパーティション構造の他には空き領域があるだけなのである。ここは元のパーティションを空き領域一杯に広げたくなるのが人間と言うもの。しかも、たかがパーティションを広げるだけ・・・ と甘く見ていたけど、Fedora Coreで導入されたLVMが事態をややこしくする。Fdiskでパーティションを広げてresize2fsでfilesystemを拡張するだけ・・・ ではないのである。

そこでLVMのディスクのパーティションを拡大しようと試行錯誤してようやくその方法を見つけたのでここにまとめよう。ちなみに、市販のツール(Partition Magic, Partition Expert・・・)を使おうと思っていたけど、Linux ext2/ext3 filesystem(System ID = 83)をサポートしていてもLVM(System ID = 8e)をサポートしていないと全く意味が無いことも分かった。そして現在の市販ツールはどれもまだLVMはサポートしていない。これはある程度予想していたけど、partedも未サポートであるのはショックだった。

ちなみに、LVMのお勉強はインターネットサーバ構築 講義メモとか、@IT:LVMによる自動バックアップ・システムの構築あたりでどうぞ。

さらにちなみに、これはDell Optiplex GC(i810)+ Pentium III 700MHz + Fedora Core 3という環境で行っている。Fedora Coreのバージョンや他ディストリビューションでは事情が異なる場合がある。

0.事前準備

当然のことながら、これからの操作はとっても危険で、間違うと一発ですべて台無しになる可能性があるので、現状の情報収集、バックアップは入念に行おう。幸いARAID99-2000とスペアドライブがあるのでフルバックアップをいつでも手軽に出来るのは大きい。ちなみに、この方法を編み出すのに何回レプリケーションを行っただろうか・・・ 今使っているSeagateのST3250823ASの安定性、ARAID99-2000との相性の良さを再認識したのであった。

ちなみに、作業前はこのような状態であった。
[root@hoge ~]# fdisk -l

Disk /dev/sda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = シリンダ数 of 16065 * 512 = 8225280 bytes

デバイス  Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14       14593   117113850   8e  Linux LVM
HDD自体は250 GBとして認識されているけど、/dev/sda2の容量は実際は、
[root@hoge ~]# df -h
Filesystem          サイズ  使用  残り 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
                      110G   13G   92G  13% /
/dev/sda1              99M   42M   53M  45% /boot
none                  252M     0  252M   0% /dev/shm
110 GBしか確保されていない。全体でも111 GBしか使っていない。これはあまりにももったいない。

ちなみに、以下のコマンドは必ず実行して、dev_sizeを調べておこう。
[root@hoge ~]# pvs -o +dev_size --units s
  PV         VG         Fmt  Attr PSize      PFree DevSize
  /dev/sda2  VolGroup00 lvm2 a-   234436544S    0S 488183220S ← この値をメモする!
Dev_size(この場合は488,183,220)は必ずメモしておこう。

1.パーティションの拡張

@IT:LVMによる自動バックアップ・システムの構築の図(図3 論理ボリューム作成までの流れ)が分かりやすいけど、LVMといっても結局パーティションの設定はfdiskで行うのである。

ちなみに、以降の作業はFedora Core 3 Rescue CDで起動して、ネットワークなし、レスキュー画面にて「スキップ」を押してARAID99-2000をマウントしない状態にて行った。

Fdiskの作業の流れは、
[root@hoge ~]# fdisk /dev/sda
               ↑ARAID99-2000はS-ATAインタフェースカードに接続されているので
                 SCSI扱いなのである
と、fdiskで(このケースでは)sda2を一旦削除(fdiskメニューにて「d」、「2」)して、新たにsda2を先頭セクタを旧sda2と同じにして最終セクタを最大セクタに設定して登録する(メニューにて「n」、「p」、「2」、以降はデフォルトのまま)。新規に作成されたパーティションは83(ext2/ext3)なので、忘れずにsda2のファイルタイプを8e(Linux lvm)に変更して(メニューにて「t」、「2」、「8e」)おこう。そしてディスクに記録して(メニューにて「w」)fdiskを終了させる(メニューにて「q」)。そして
[root@hoge ~]# exit
でレスキューモードを終了させると自動でリブートする。

実はこの作業を行うまでfdiskでパーティションの変更ができるということを知らなかった (-_-;;;
メニューで「d」してしまうとパーティションが無くなってしまう錯覚をしてしまうけど、「w」を押すまではただ単にパーティションテーブル情報の書き換え候補をいじっているだけ、なんだね。

2.PVの拡張

以降の作業はFedora Core 3 Rescue CDで起動して、ネットワークなし、レスキュー画面にて「続行」を押してARAID99-2000をマウントした状態にて行った。ちなみに、レスキューモードではなぜか言語をJapanese、キーボードをjp106と指定しても英語キーボードの設定になっちゃうから、
+ はShift + ^
: はShift + ;
_ はShift + -
と覚えておく必要がある。

ディスク上のパーティションが拡張されたら、次にそのパーティション上に定義されているPhysical Volume(PV)の拡張が次の作業だけど、これが最大の難関でなかなか分からなかった。RedhatのBBSのある書き込みで助かった。確認したところではFC3、FC4には一応pvresizeというコマンドは定義されているけど実装されていない。これがあれば恐らく苦労しなかっただろうけどね。

迂回策は以下のとおりで、設定情報をダウンロードして、PVのあたりだけ編集して書き戻す、と言うかなり怪しい方法。
[root@hoge ~]# vgcfgbackup -f vgbackup(バックアップファイル名は任意)
・・・
[root@hoge ~]# pvs -o +dev_size --units s(前に実行していなかったらここでリベンジ!)
ここでvgbackupの書き換えるべき変数 pe_count の変更すべき値を計算する。Redhat BBSの書き込みのとおりなんだけど、
pe_start + pe_count * extent_size ≦ dev_size
pe_count ≦ (dev_size - pe_start) / extent_size
↓(この環境では・・・)
pe_count ≦ (488183220 - 384) / 65536
         ≦ 7449.07891845703125
なので、pe_count = 7449としよう。そして、viで編集すべきポイントはここ。
[root@hoge ~]# vi vgbackup(以降の作業では英語キーボード配列に注意)
・・・
pe_start = 384
pe_count = 3574 # 111.688 Gigabytes(ここの値は当然環境によって違う)

pe_count = 7449 # 238.371 Gigabytes
編集が終わったらviを終了させて、設定ファイルを書き戻そう。
# vgcfgrestore -f vgbackup VolGroup00

3.LVの拡張

PVの拡張が終わったら今度はいよいよLogical Volume(LV)の拡張に取り掛かれる。こちらはどうせならスワップ領域(LogVol01)も拡張しようと思ったので、こちらを先に拡張して、残りを / (LogVol00)に割り当てている。
[root@hoge ~]# lvextend -L+512M VolGroup00/LogVol01
               (↑ 元々512 MBだったところに512 MBを追加して1 GBにしたところ)

[root@hoge ~]# lvextend -L 250G VolGroup00/LogVol00
(とりあえず設定可能な最大LEを調べるために大きめ(250 GB)の数字を入れてみる)
Insufficient allocatable logical extents (7417) ・・・
(設定可能な最大LE=7417ね、ふむふむ)

[root@hoge ~]# lvextend -l 7417 VolGroup00/LogVol00
(今度はLE単位で拡張するから引数は小文字のエルなのに注意!)
Extending logical volume LogVol00 to 231.78 GB

4.Filesystemの拡張

そしていよいよお待ちかねのfilesystemの拡張。Filesystemのサイズ変更にはお馴染みのresize2fsを使う。従来のコマンド、LVM系のコマンド、従来のパーティション指定方法(/dev/sda2とか)とLVMでの指定方法(VolGroup00/LogVol00とか)が入り混じっているからとっても分かりづらい。

さて、resize2fsを実行する前に変更対象パーティション(/dev/sda関連、VolGroup00関連)のマウントを解除しないといけない。
[root@hoge ~]# umount /mnt/sysimage/boot
[root@hoge ~]# umount /mnt/sysimage/sys
[root@hoge ~]# umount /mnt/sysimage/proc
[root@hoge ~]# umount /mnt/sysimage/dev
[root@hoge ~]# umount /mnt/sysimage
[root@hoge ~]# swapoff /dev/VolGroup00/LogVol01
(すべてアンマウント完了!)

[root@hoge ~]# e2fsck -f /dev/VolGroup00/LogVol00
(いきなりresize2fsを行うとどうせe2fsckせよと言われるから自発的に行おう)
・・・
[root@hoge ~]# resize2fs /dev/VolGroup00/LogVol00
・・・
[root@hoge ~]# mkswap /dev/VolGroup00/LogVol01
ここまでエラーなしで来ることができたら無事成功。とりあえずレスキューモードを脱出しましょう。
[root@hoge ~]# exit
再起動してdfとかで容量がちゃんと増加しているのを確認してみよう。ちなみに、以下にハードウェアブラウザの前後をお見せしよう。見事に空き領域が使いきれているのが分かるでしょ! 気持ちいいね〜〜

[ 作業前 ]


[ 作業後 ]


[ 作業後(おまけ:Windowsで見てみると・・・ ]


今回はFC3をデフォルトインストールした状態で、パーティション拡張のうち一番簡単な最後のパーティションを容量一杯まで拡張する、と言うものだったけど、もっと高度なパーティション変更を行う際には手順が複雑になり、作業には細心の注意を払う必要があるだろう。FC4だったら変わってたかなぁ・・・ pvresizeが動いていない時点でそれは無いと思うけど。いや、そもそもLVM系のツールがもっと充実しないといけないよね。せめてpvresizeだけは早めに作って欲しい・・・


Top