タグ別アーカイブ: LVM

4KBセクタのことを考えずにパーティション切っちゃってたことに気づいて何とか切り直そうとしてみる

最近4KBセクタのHDD増えましたよね。
ってか割と今更感もあると感じる人も多いかと思うけど、実際のところうちのサーバ機の構成HDDはちょっと前まで4KBセクタのHDDは混じってなかったんです。
でも、HDDの寿命やら故障やらで交換してたら、気づかぬうちに6 本中3本が4KBセクタものになっていました。
そして、そのことに気づいたのが昨日。

さて、パーティションは普通にfdiskで切ってましたよ、ええ。
パーティション開始位置みたら先頭パーティションおもいっきり63セクタですよええ。

ということで、パーティションを切り直す必用がある、というか、必用ではないけど切り直した方がいいのは間違いないわけで。

あ、何が問題なのかわからない人のために一応4KBセクタのお話をすっげー簡単にしておきます。
HDDは基本的に一セクタ512byteでした。
でも大容量化に伴い、一セクタ512byteだと非効率になってきたんで、一セクタ4KiBのHDDが出てきました。
なんだけど、BIOSとかドライバとかまあ根本的なところがHDDの一セクタは512byteっていう前提のものがまだまだ多いんで、内部的には4KiBだけど外面は今まで通り512byteな奴らが出てきました。
でもその関係でなんも考えずに従来通りのパーティション切りをしてると、書き込み性能が低下することがある問題が発生しました。
これ以上詳しい話はこちらのエントリをご覧ください。
そして今まさにその状態なわけです。

さて、そうすると、まず何をしなければならないか。
今のHDDの内訳を作ろう。

sda – ST2000DL003-9VT166
sdb – ST2000DL003-9VT166
4KBセクタ
/bootをミラーリングで構築
各種システムパーティションをLVMミラーで構築
各1.5TずつファイルサーバのRAID5へ組み込み

sdc – WDC WD10EADS-00M2B0
非4KBセクタ
バックアップ用

sdd –  WDC WD15EADS-00P8B0
sde – WDC WD15EADS-00S2B0
sdf – WD15EARS
sdfが4KBセクタ
ファイルサーバ用でRAID5くんでる
このうちsdfは不良により現在失踪中

んーと。
とりあえずRAID5が致命的にやばそうなんだが。。。
sdaの状態を確認してみる。
単位はシリンダじゃなくてセクタに変更してある。

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63      546209      273073+  fd  Linux raid autodetect
/dev/sda2          546210   976751999   488102895   8e  Linux LVM
/dev/sda3       976752000  3907024064  1465136032+  fd  Linux raid autodetect

はい、第一、第二パーティション開始セクタが8の倍数じゃないですね。
んーと。
sda1の開始位置を64にして終了位置を546199に
sda2の開始位置を546200にして終了位置はこのまま
とかやれれば良さそうだ、とりあえず。
ところで今までresize2fsとか結構やってきたけど、それで変わるのってパーティションの終了位置なんだよね。
開始位置の変え方を知らないことに気がついた。

で、resize2fsのmanページにこんなことが書いてある。

resize2fs プログラムは、パーティションのサイズは操作しない。 ファイルシステムを大きくしようとする場合は、 そのファイルシステムがあるパーティションのサイズを大きくできるかを 最初に確認しなければならない。 これは、 fdisk(8) を使ってパーティションを削除した後に より大きなパーティションを再作成することで確認できるし、 論理ボリュームマネージャ lvm(8) を使っている場合は、 lvextend(8) を使って確認できる。 パーティションを再作成する場合、 必ず以前と同じ開始ディスクシリンダで作成すること! そうしないと、サイズ変更の操作は絶対にうまく行かず、 ファイルシステム全体を失ってしまう。 fdisk(8) を実行した後、resize2fs を実行すること。 これにより、ext2 ファイルシステムのサイズを変更し、 拡大した新しいパーティションの全ての領域を使うことができる。

あ、はい。
要するに、一回ファイルシステム消せってことですね、わかります。
とりあえずRAID5の構成要素である第3パーティションはふれないでいいのは幸いだった。
ほんと1/8の偶然。

ということでまずシステムのバックアップとる。
sdb1, sdb2のパーティションを切り直す。

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048      546199      272076   fd  Linux raid autodetect
/dev/sdb2          546200   976751999   488102900   8e  Linux LVM
/dev/sdb3       976752000  3907024064  1465136032+  fd  Linux raid autodetect

再起動。
死んだ。
LVMボリュームがみつからねーっていわれた。
ブートしない。
さすがに無茶だったか。
LVMのミラーリングってじゃあ役に立つのか?
どうせミラーリングするんだからmdにしてしまいたいな。
まあ、この展開になったならもういいわ。
レスキューモードに入ってsda1とsda2のパーティションもぶった切る。
ということでぶった切り。
sda2もLVMじゃなくてLinux RAID autodetectに変更。
で、論理ボリュームとかぼこぼこ削除していったら、vgremoveがうまくいかず、vgreduce –removemissingをしてみろてきな。
あれ、もしかしてこれやれば良かった?
でももうおそい、あとには引けない。
削除。
そして綺麗に掃除したあと、アレイを作り直す。

# mdadm --create /dev/md1 -l1 -n2 --metadata=0.9 /dev/sd[ab]1
# mdadm --create /dev/md2 -l1 -n2 /dev/sd[ab]2

md1にファイルシステムを作ってバックアップを流し込む。
md2はLVMに。

# pvcreate /dev/md2
# vgcreate ms09 /dev/md2
# lvcreate -L 32G -n ms09 ms09

あとはmke2fsしてバックアップから流し込む。

これでとりあえずsdaとsdbはおっけー。

と思ったら起動しない。
grub loading
error 17
でました。
update-grubでいけるかと思ったけど駄目だったのでインストールし直す。
grubの画面までいくようになったけど今度はカーネル選択するとUnknown filesystemでマウントできないっていってerror 17。
レスキューから確認するとmd1がsdb1の方肺になっててgrubはsda1(hd(0,0))みにいってたっていうことでした。
まじね。
ということでmdadm /dev/md1 -a /dev/sda1して同期かけてgrubコマンドで確認して認識したので再起動。
漸くブートきたと思ったら、rootファイルシステムがみつからねーよっていうかmdadmでRAID ARRAY起動失敗っつーてこける。
きてる、きてるよくそはまりパターン。
んーと、なにをやりのがしてる?
んー、initramfsか?initramfsだろ。

update-initramfs -uk ‘all’

と。
はあ、やっと起動した。

とりあえず一旦ここで休憩。

LVMで割り当てたPVを縮小させたい

2TのHDDのPVを縮小させたい。
ということでメモ。

まずは論理ボリュームの縮小。
論理ボリュームを縮小するときは、ファイルシステムを縮小してから論理ボリュームを縮小する。(拡大するときは逆)

縮小させたい論理ボリュームを縮小。
e2fsck -fyv /dev/ms09/file
resize2fs /dev/ms09/file 16G
lvresize -L 16G /dev/ms09/file
警告でるのでちゃんとサイズがあってるか確認して実行
resize2fs /dev/ms09/file
サイズがあってるか確認

ほかも同じ感じで論理ボリュームの縮小を行う。
システムのルートパーティションの場合はレスキューCDからブートしてやりましょう。

で、PVの縮小。
pvresize –setphysicalvolumesize 500G /dev/sda1
このとき、切り詰めた物理ボリュームの終端よりあとに論理ボリュームっていうかPEがあったりする場合、失敗する。
自動で再配置なんて気の利いたことはしてくれない。
なので、そういう場合は一旦論理ボリュームのバックアップをとって削除してから行うとか、pvmoveで別の物理ボリュームにデータを移してから行わなければならない。

PVが縮小できたらパーティションをPVにあわせて切り直す。
fdiskだと単位がシリンダとかで計算がいやだったのでcfdiskでやった。

パーティション切り直したら再起動して終わり。

LVMのスナップショットの動作が怪しい

うちのサーバ機はxenを使って仮想化して運用している。
そして毎日定期バックアップをLVMのスナップショット機能を利用して行っているのだけども、どうも最近挙動がおかしいことに気づいた。
作成したスナップショットが高確率でファイルシステムにエラーを含んでいる。

# xm pause debian
# lvcreate -s -n snapdebian -L 200G /dev/ms09/debian
  Logical volume "snapdebian" created
# xm unpause debian

としてスナップショットを作成する。
ここまではいい。
が、ここでfsckを走らせるとエラーが出る。

# e2fsck -yfv /dev/ms09/snapdebian
e2fsck 1.41.12 (17-May-2010)
/dev/ms09/snapdebian: recovering journal
Clearing orphaned inode 15466504 (uid=109, gid=109, mode=0100600, size=0)
Clearing orphaned inode 15466503 (uid=109, gid=109, mode=0100600, size=0)
Clearing orphaned inode 15466502 (uid=109, gid=109, mode=0100600, size=0)
Clearing orphaned inode 15466501 (uid=109, gid=109, mode=0100600, size=20)
Clearing orphaned inode 15466500 (uid=109, gid=109, mode=0100600, size=0)
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/ms09/snapdebian: ***** FILE SYSTEM WAS MODIFIED *****

  715619 inodes used (2.13%)
     738 non-contiguous files (0.1%)
     182 non-contiguous directories (0.0%)
         # of inodes with ind/dind/tind blocks: 0/0/0
         Extent depth histogram: 706955/133
23572155 blocks used (17.56%)
       0 bad blocks
       6 large files

  677160 regular files
   29784 directories
     126 character device files
      40 block device files
       2 fifos
      16 links
    8469 symbolic links (8324 fast symbolic links)
      29 sockets
--------
  715626 files

マウントしてrsyncでバックアップをとるとumountでえらい時間がかかる。
カーネルが文句いってる。

[  647.099517] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466504
[  647.099539] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466503
[  647.099548] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466502
[  647.099556] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466501
[  647.099591] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466500
[  647.099599] EXT4-fs (dm-18): 5 orphan inodes deleted
[  647.099710] EXT4-fs (dm-18): recovery complete
[  647.433114] EXT4-fs (dm-18): mounted filesystem with ordered data mode
[ 1080.113046] INFO: task umount:4061 blocked for more than 120 seconds.
[ 1080.113114] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1080.113201] umount        D 0000000000000000     0  4061   2294 0x00000000
[ 1080.113331]  ffffffff8147b1f0 0000000000000282 0000000000000000 ffff8801e6971de8
[ 1080.113544]  0000000000000000 0000000000000000 000000000000f9e0 ffff8801e6971fd8
[ 1080.117004]  0000000000015780 0000000000015780 ffff8801c17654c0 ffff8801c17657b8
[ 1080.117004] Call Trace:
[ 1080.117004]  [<ffffffff8100e629>] ? xen_force_evtchn_callback+0x9/0xa
[ 1080.117004]  [<ffffffff8100ece2>] ? check_events+0x12/0x20
[ 1080.117004]  [<ffffffff8110926b>] ? bdi_sched_wait+0x0/0xe
[ 1080.117004]  [<ffffffff81109274>] ? bdi_sched_wait+0x9/0xe
[ 1080.117004]  [<ffffffff8130d19a>] ? _spin_unlock_irqrestore+0xd/0xe
[ 1080.117004]  [<ffffffff8130c3e7>] ? __wait_on_bit+0x41/0x70
[ 1080.117004]  [<ffffffff8100f0ac>] ? xen_smp_send_reschedule+0x0/0x7
[ 1080.117004]  [<ffffffff8110926b>] ? bdi_sched_wait+0x0/0xe
[ 1080.117004]  [<ffffffff8130c481>] ? out_of_line_wait_on_bit+0x6b/0x77
[ 1080.117004]  [<ffffffff81065f24>] ? wake_bit_function+0x0/0x23
[ 1080.117004]  [<ffffffff811092ec>] ? sync_inodes_sb+0x73/0x12a
[ 1080.117004]  [<ffffffff8110cea1>] ? __sync_filesystem+0x4b/0x70
[ 1080.117004]  [<ffffffff810f1aa2>] ? generic_shutdown_super+0x21/0xfa
[ 1080.117004]  [<ffffffff8100eccf>] ? xen_restore_fl_direct_end+0x0/0x1
[ 1080.117004]  [<ffffffff810f1b9d>] ? kill_block_super+0x22/0x3a
[ 1080.117004]  [<ffffffff810f226d>] ? deactivate_super+0x60/0x77
[ 1080.117004]  [<ffffffff81104bc0>] ? sys_umount+0x2dc/0x30b
[ 1080.117004]  [<ffffffff81011b42>] ? system_call_fastpath+0x16/0x1b

場合によってはこのままumountできずにプロセスが残り続けて死ねる。
とりあえずディスクI/Oがロックされた状態になるんだろう。

この問題は稼働中のext4ファイルシステムのスナップショットを作成した際に起きるようだ。
おそらくジャーナルに書き出したデータが実データに反映されていないような状況でスナップショットを作成した場合に起きるんじゃないかと予測している。
のでext3でも同じ現象が起きるだろう。たぶん。
まあ、別にそれでも変更差分をきちんと吸収してくれているならかまわないんだけども、使い終わったスナップショットをアンマウントするのになんで何分もかかるのかがわからない。

その上、使用済みのスナップショットボリュームを削除しようとしても失敗することがある。

# lvremove -f /dev/ms09/snapdebian
  Unable to deactivate open ms09-debian-real (254:5)
  Failed to resume debian.

これに関してはバグレポートが見つかった
とりあえず4ヶ月経過しても治っていないらしい。

んーむ。
こうなるとバックアップ手法を見直す必要性が出てくる。
Dom0とDomUとで疑似遠隔rsyncでバックアップとなるのだろうか。
だけどそれだとrootでのリモートログインが必要となるから駄目だな。
ゲストはゲストでバックアップパーティションをディスクとしてアタッチして、各自でバックアップしてもらうような形ならいけるか。

あー、設定するのがめんどくさい。

LVMでのfstab記述メモ

最近はfstabに記述するデバイスをUUIDで記述することが主流になっている。ような気がする。
UUIDで記述すればデバイスの順序が入れ替わったりしても問題ないからだ。
が、LVMではスナップショットを利用する際やミラーリングを行っていたりしていると、UUIDが重複するファイルシステムが複数現れたりする。
ので、従来通りデバイスのパスを記述する方が無難だと思う。
それだけ。

論理ボリュームを別物理ボリュームへ移す方法

LVMで実データの配置は基本的に自動で行われる。
そこで特定のLVを別のPVへ移動させたい場合に使える方法。
つまりLV単位でのPEの移動方法。
ミラーリングの再構築について調べているときに気づいた。
ちなみに特定のPV上の全PEをほかのPVに移動させたい場合(ディスクを交換したい時なんか)はpvmoveを使う。

で、手順。

  1. ミラーリング機能を利用してLVのコピーとしてのミラーイメージを移したいPVに作る
  2. コピー元のミラーイメージを削除

とまあ単純な方法。
lvmoveってないからたぶんこういう方法をとらないといけないんだと思う。
で、PV /dev/sda1と/dev/sdb1で構成されるVG vol上のLV logを、sda1からsdb1へ移動させるケースを例としてあげる。

# lvconvert -m1 –alloc anywhere /dev/vol/log /dev/sdb1
# lvconvert -m0 /dev/vol/log /dev/sda1

とまあこんな感じ。
やり方に気づいただけで実際には試していないけど。

LVMでのミラーリング再構築

LVMでのミラーリング状況を確認してみたらおかしなことが起きていることに気づいた。

# lvs -a -o +devices
  LV                VG     Attr   LSize   Origin Snap%  Move Log         Copy%  Convert Devices
  debian            ms09   mwi-ao 512.00g                    debian_mlog 100.00         debian_mimage_0(0),debian_mimage_1(0)
  [debian_mimage_0] ms09   iwi-ao 512.00g                                               /dev/sda2(8704)
  [debian_mimage_1] ms09   iwi-ao 512.00g                                               /dev/sda2(148992)
  [debian_mlog]     ms09   lwa-ao   4.00m                                               /dev/sdb2(1)
  ms09              ms09   mwi-ao  32.00g                                100.00         ms09_mimage_0(0),ms09_mimage_1(0)
  [ms09_mimage_0]   ms09   iwi-ao  32.00g                                               /dev/sda2(0)
  [ms09_mimage_1]   ms09   iwi-ao  32.00g                                               /dev/sda2(140800)

ミラーイメージが両方sda2で同一物理ディスクに存在する。
どう考えても意味がありません本当にありがとうございます。

とりあえず、ミラーリングを解除するのは lvconvert で -m0 すればいいだけなようだ。

# lvconvert -m0 –alloc anywhere /dev/ms09/ms09
# lvconvert -m0 –alloc anywhere /dev/ms09/debian

これでミラーリングは解除できた。
たぶん –alloc anywhere はいらない。
んで。
とりあえず、もっかいミラーリングしてみようかということで、試しにミラーリングしてみる。

# lvconvert -m1 –alloc anywhere /dev/ms09/ms09
# lvs -a -o +devices
  LV              VG     Attr   LSize   Origin Snap%  Move Log       Copy%  Convert Devices
  ms09            ms09   mwi-ao  32.00g                    ms09_mlog 100.00         ms09_mimage_0(0),ms09_mimage_1(0)
  [ms09_mimage_0] ms09   iwi-ao  32.00g                                             /dev/sda2(0)
  [ms09_mimage_1] ms09   iwi-ao  32.00g                                             /dev/sda2(311296)
  [ms09_mlog]     ms09   lwa-ao   4.00m                                             /dev/sda2(140800)

なめっく。
ミラーイメージがなんで両方ともsda2にあるんだ。
ミラーする先のディスクの指定方法はないのかということで調べてみる。
あった。
ということでまたミラー解除してミラーしなおすことに。

# lvconvert -m0 --alloc anywhere /dev/ms09/ms09
# lvs -a -o +devices
  LV         VG     Attr   LSize   Origin Snap%  Move Log Copy%  Convert Devices
  ms09       ms09   -wi-ao  32.00g                                       /dev/sda2(0)

VG ms09はPV /dev/sda2と/dev/sdb2で構成されているので、ミラーイメージはsda2とsdb2の両方に置きたい。
元々がsda2にあるので、新規ミラーイメージの作成先を指定。
指定って言っても最後にPVを指定するだけだった。

# lvconvert -m1 --alloc anywhere /dev/ms09/ms09 /dev/sdb2
# lvs -a -o +devices
  LV              VG     Attr   LSize   Origin Snap%  Move Log       Copy%  Convert Devices
  ms09            ms09   mwi-ao  32.00g                    ms09_mlog 100.00         ms09_mimage_0(0),ms09_mimage_1(0)
  [ms09_mimage_0] ms09   iwi-ao  32.00g                                             /dev/sda2(0)
  [ms09_mimage_1] ms09   iwi-ao  32.00g                                             /dev/sdb2(0)
  [ms09_mlog]     ms09   lwa-ao   4.00m                                             /dev/sdb2(8192)

ようやく意図通り別の物理ディスクにミラーイメージを作成することができた。
同じ要領でミラーリングしておきたいパーティションをミラーリングして、と。

にしても未だにミラーログが何のための存在なのかわかってない。

既存のパーティションをミラーリングする方法

すでに運用に入っているパーティションをミラーリングする方法。

一つは、LVMで運用されているならlvconvertで簡単にできる。
普通にext3なんかのパーティションの場合はどうするか。
sda1, sda2がすでに運用に入っていて、sdb1, sdb2をミラーリングディスクとして追加する例を考える。

ここではmdadmを使うことにする。

で、今回の作業の流れ。

  1. ブロックデバイスの作成
  2. 新規追加するディスクを方肺でミラー化
  3. 既存運用のディスクからデータを移行
  4. 既存運用のディスクをRAID1に参加

ということでブロックデバイスの作成。

# mknod /dev/md1 b 9 0
# mknod /dev/md2 b 9 1

sdb1, sdb2はsda1, sda2と同じサイズでパーティションを切る。
パーティションのタイプはsda1, sda2も含めてすべてfd(Linux raid autodetect)にする。
で、新しく追加する方のディスクを方肺でミラー化する。

# mdadm --create /dev/md1 --level=1 --raid-devices=2 missing /dev/sdb1
# mdadm --create /dev/md2 --level=1 --raid-devices=2 missing /dev/sdb2

ミラー化したら、ファイルシステムを作成して、既存運用のディスクからデータを移行する。
この辺は/dev/md1, md2をmkfsしてsda1, sda2からmd1, md2にデータをcpする。

コピーが終わったら、元のディスクもミラーリングに参加させる。

# mdadm --add  /dev/md1 /dev/sda1
# mdadm --add  /dev/md2 /dev/sda2

っていう感じだろうか。

LVMでミラーリング

LVMにはミラーリングやストライピングといった機能がある。
って最近知った。
とりあえずデータが飛びかけた今回の障害から復旧するにあたって、LVMで構築したパーティションをミラーリングしようと思っていて調べていて気づいた。
以前と同じようにmdadmを使ったソフトウェアRAIDでミラーリングしようと思っていたけど、LVM自前のミラーリング機能を使った方が楽そうなのでこっちにした。

とりあえず、ミラーリングなのでディスクは最低2本いる。
で、同一ボリュームである必要があるようだ。
ということで、

# pvcreate /dev/sda1 /dev/sdb1
# vgcreate vg1 /dev/sda1 /dev/sdb1

みたいな感じで。
で、ミラーリングするのは至極簡単なようだ。
普通に論理ボリュームを作成するのと同じような感じで、-m 1とかつければいいみたい。

# lvcreate -L 30G -n lv1 -m 1 --alloc anywhere vg1

みたいな。
–alloc anywhere ってのが謎だが、これがないとLVMのミラーリングはディスクを3個必要になるらしい。基本は。
というのは、一つはログ用で用いるようだ。
で、このログを配置する先を、一つのディスクを利用しないで適当なファイルに書き出すようにするのがこのオプションらしい。
っていうのも、allocオプションの詳しい話がman lvcreateじゃ出てこないからよくわからん。
単純にこのオプションを使わずに、–mirrorlogオプションを使った方が平和かもしれない。
–mirrorlogオプションでは、以下のようになる。

  • disk ミラーリングしてるディスクとは異なるディスクにログを保存
  • core in-memoryログ
  • mirrored ログ自体をミラーリング。保存先はどこだろね。

で、論理ボリュームをミラーリングにしたりするのは、作成時だけじゃなくてすでに稼働している状態からでも簡単に行える。

lvconvertで似たような感じで指定すればいい。
mountしている状態でも、オンラインミラーリング化なんてことも問題なくできた。

# lvconvert -m 1 --alloc anywhere /dev/ms09/ms09

これで、普通の論理ボリュームがミラーリングされたボリュームに化けた。
このLVMの柔軟性はすばらしいというほかない。

 

ファイルサーバのHDD交換

ファイルサーバのHDDが一本いってたので、lvreduceやらvgremoveやらpvremoveやらを使って引っこ抜いて修理に出してたのがようやく届いた。
修理っていっても当然ながら交換対応だけど。

ということでLVMでHDDを引っこ抜いたり追加したりするやり方をメモしておく。
というかLVMおさらいってことで簡単に全体メモっておく。

LVMはPV(物理ボリューム)を一つないし複数用いてVG(ボリュームグループ)を作成し、VGを仮想的な一つのディスクとして取り扱い、LV(論理ボリューム)をパーティションのごとく扱う。
一つのPVは一のディスクあるいは一パーティションで対応する。

ということで、pvcreateしてvgcreateしてlvcreateすればLVMで運用できる。

LVMで扱っているPVの一つがやばくなったりした場合はそれを引っこ抜かなくてはならない。
今回みたいにHDDが死にかけた場合とか。
その場合、手順は以下のようになる。

  1. 引っこ抜きたいHDDの容量分の空き容量を作る
  2. 引っこ抜きたいHDD上にあるデータをほかのHDDにうつす
  3. 引っこ抜く

まず、空き容量の作成だが、たとえばLVMで1.5T*3で構成していて、1Tと3.5TのLVを作っていて、HDDのうち一本が死にそうな場合。
データで埋まっている場合は削除するなりなんなりしてまずあける。
そして、次に、ファイルシステムを縮小する。
この場合は1.5Tの削減が必要。
1Tと3.5Tの両方あわせて合計1.5T削減できればいい。
ファイルシステムの縮小はext3の場合はfsckしてからresize2fsする。
アンマウントは事前にしておく。

# e2fsck -yfv /dev/fileserver/fileserver
# resize2fs -f /dev/fileserver/fileserver 1500G

ファイルシステムの縮小が終わったら、次にLVの縮小を行う。

# lvreduce -L -1.5T /dev/fileserver/fileserver

死にかけのディスク上にあるデータをほかのディスクに移す。

# pvmove /dev/sde1
 PV Name               /dev/sde1
 PV UUID               3Hgl3d-0EO6-QOXa-NnrX-2h8X-1fk8-c4b7AL
 PV Status             allocatable
 Total PE / Free PE    357699 / 357699

Total PE / Free PEが等しくなったら移し残しはない状況だ。
あとはVGから切り離してPVを削除する。

# vgreduce fileserver /dev/sde1
# pvremove /dev/sde1

これで完全にLVMからHDDが切り離された状態になった。
ということで修理持ち込みして帰ってくるのを待つと。

で、帰ってきた。
取り付ける。
LVMへの追加の方は既存のデータ移行などを気にしないでいいので楽だ。

PVを作成してVGへ追加して拡張したいLVを拡張するなり新規のLVを作るなり。

# fdisk /dev/sde
(sde1をLVMパーティションとして作成)
# pvcreate /dev/sde1
# vgextend fileserver /dev/sde1
# lvextend -L +1.5T /dev/fileserver/fileserver

LVを拡張した場合は最後にファイルシステムの拡張を行う。

# resize2fs /dev/fileserver/fileserver

これにて完了。

-L -1.5T /dev/fileserver/fileserver

xen-toolsを使わないでdebianホストをセットアップ

ファイルサーバのHDDが死にかけたので再セットアップ。

lvmでパーティションきりきり。

で、ファイルシステム作成。

# mkfs.ext3 /dev/fileserver/fssystem
# mkswap /dev/fileserver/fsswap
# mkfs.ext4 /dev/fileserver/file

ベースシステムのセットアップ。

# mount /dev/fileserver/fssystem /mnt/temp
# debootstrap --arch=amd64 lenny /mnt/temp http://ftp.jp.debian.org/debian

いろいろと書き換え

fstabの設定
# cd temp
# vi etc/fstab

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/xvda1      none            swap    sw              0       0
/dev/xvda2      /               ext3    errors=remount-ro 0     1
/dev/xvda3      /fileserver     ext4    defaults        0       0

ホスト名の設定
# vi etc/hostname

files

hostsの設定
# vi etc/hosts

127.0.0.1       localhost
192.168.1.x     files.waterblue.net     files

nicの設定
# vi etc/network/interfaces

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
 address 192.168.1.x
 network 192.168.1.0
 netmask 255.255.255.0
 broadcast 192.168.1.255
 gateway 192.168.1.1

ネームサーバの設定
# vi etc/resolv.conf

nameserver 192.168.1.x

aptの設定
# vi etc/apt/sources.list

deb http://security.debian.org/ lenny/updates main contrib non-free
deb http://ftp.jp.debian.org/debian lenny main contrib non-free

シリアルコンソールの設定
hvc0を使うようにしてttyは起動しない
# vi etc/inittab

1:2345:respawn:/sbin/getty 38400 hvc0
#1:2345:respawn:/sbin/getty 38400 tty1
#2:23:respawn:/sbin/getty 38400 tty2
#3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6

# vi etc/securetty
hvc0

hvc0の作成
# cd dev
# mknod hvc0 c 229 0

xenのDomU用設定ファイルを作る。

#
# Configuration file for the Xen instance file, created
# by xen-tools 3.9 on Sun Oct 11 14:47:01 2009.
#

#
#  Kernel + memory size
#
kernel      = '/boot/vmlinuz-2.6.32-5-xen-amd64'
ramdisk     = '/boot/initrd.img-2.6.32-2-xen-amd64'
memory      = '512'

#
#  Disk device(s).
#
root        = '/dev/xvda2 ro'
disk        = [
 'phy:/dev/fileserver/fsswap,xvda1,w',
 'phy:/dev/fileserver/fssystem,xvda2,w',
 'phy:/dev/fileserver/file,xvda3,w',
 ]

#
#  Hostname
#
name        = 'file'

#
#  Networking
#
vif         = [ 'ip=192.168.1.x,mac=xx:xx:xx:xx:xx:xx' ]

#
#  Behaviour
#
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

あとは/mnt/tempをアンマウントしてxm create file -cで起動してコンソールログインしてお好きに。
ちなみに、ext4ファイルシステムはカーネル2.6.26だと

# tune2fs -E test_fs /dev/fileserver/file

やってからext4devじゃないとマウントできなかった。
2.6.32だとext4じゃないとマウントできなかった。