michiga.comサーバーアップグレード
webサーバーを新システムへ移行した。(2008/8/15)
RAIDの容量が足りなくなって来たので思い切ってシステムを切り替えることにした。
考え始めるといろいろ改善点があるもので、ネタとして面白いので記録しておくことにしました。
旧サーバー
まずは旧サーバーのご紹介。
NEC Express5800/120Rc2にLSI LogicのRAIDカードを組み合わせ比較的安価に1TBの容量を確保していました。2002,3年ごろの話ですので、1TBを用意するのも10万以上は掛かりましたね。
SATA 250GBの玉を使って、4+1のRAID5を組んでいましたが、現在6ポート中1ポートが使えなくなっており、ホットスペアは刺しておけない状態になっています。ドライブはスペアがあるので、壊れたら大至急交換するといった具合です。
ドライブはは内臓することは出来ないためSATAケーブルは背面から引き出し、外部電源で駆動するドライブに接続しています。
見てのとおりドライブは棚板に立てて並べられているだけであり、某RAID装置のFANユニットで強制空冷を行っています。地震に弱いですが、これまで経験した震度3くらいまでの地震では倒れるようなことは無かったです。保守性は非常に良かったですね。
玄人志向の製品で似たようなのがありますが、その上を行っていると自負しておりました。ってか俺のが先だし(笑)
もう6年目くらいだったと思います。大きな障害も無くなかなかよく頑張ってくれました。
新サーバー用マシン
NEC Express5800/120Rg2です。別にNECの回し者ではありません。たまたまです。
ファンの音がけたたましいですが頂き物なので文句は言えません。
RAIDカードがついていたのでシステムディスクを構成するドライブを冗長構成とし、さらにホットスペアも配備。電源も冗長化したのでアベイラビリティは向上したと思います。
上に載っているのが、後述のDriveトレーですね。
内臓ドライブ用RAIDカード
内臓ドライブ用のRAIDカードとしてLSI Logic MegaRAID SCSI 320-1がついていました。
はじめドライブの障害が頻発し悩みましたが、U320とU160のドライブを混在させた場合はU160にBIOSで固定しないとダメらしい。混在させたらU160で動作すると思っていたんですけど、下位互換じゃないんでしょうかねぇ・・・
ステータスはmegarcコマンドを使って見ることが出来ました。本来対応しているモデルではない模様で、ロジカルユニットの追加やホットスペアの割り当ては出来ませんでした。この辺りの機能をあまりいじりまわしているとコマンドがハングすることもあったので、使わない方が無難ぽいです。
あと、障害時にアラームが鳴らない(実装されていない)のも今ひとつですが、毎日メールでステータスを報告するようにしているのでまあ良いでしょう。
外付けドライブ用RAIDカード
昔から憧れの3wareのRAIDカードを買いました。といっても最近のRAIDカードはPCI Expressしか対応していない。ホスト側が対応していないので、PCI-Xの9550SXUに決めた。
運用中にRAIDレベルの変更や容量の追加が出来るので、将来の容量増加に柔軟に対応できる。ちなみに、最初は0+1で運用し、容量が増えてきたらRAID5に変更。その後はドライブの追加で対応する予定だ。これなら、使っていない容量に対して無駄なコストを掛けずに済む。
当初RAID6対応のカードにして、WDなどの安いドライブでの運用も考えたが、2本分の容量をパリティにとられるのはある程度以上の本数が無いともったいないので却下。
また、コンカチにするとか、RAIDグループのうち一部の容量のみ切り出してLUNに割り当てるといった機能が無いのは少々不便であるが、コンシューマー向けの製品なんてこの程度なのでしょう。値段相応というところか。
結局、ドライブはSeagateの1TBを5本買った。MTBFと保障期間(5年)からの判断である。Western Digitalのドライブに比べ、1本当たり3,4k円の高くつくが、4本壊れれば元が取れる計算だ。システムは5年以上使う予定であるから、1年に1本と考えると妥当な線だろう。
遊びならもう少しチャレンジングな構成も面白いが、容量が大きくなるとバックアップも頻繁には出来ないので、リスクは犯せない。
Drive Tray
Draive Trayは今回自作することにした。
基本的なコンセプトは同じだが、ドライブの固定と冷却がキッチリできるような設計を目指す。
電源はATやATXの電源を使えるようにし、ボディは冷却性を考えてアルミにした。また、保守性を確保するため、ドライブはフロントから直ぐに引き出せる構造にしている。
材料はアルミの1.2tのアルミ版、Lアングル、角パイプ、Cチャンなどを組み合わせている。結合部は全てブラインドリベットを使用。
本当は、バックプレーンを設けて、ドライブを挿入すれば電源と信号線がコネクトするようしたかったが、残念ながら基板実装用のコネクタの入手が容易でないこと、コストや時間の都合からコネクタをフロント側に出して直接ケーブルを接続する構造とした。少々格好は悪いけどまあ良いでしょう。
所で、最近のドライブはアクセスランプがついていないため、アクセス状況がわからず寂しいものです。RAID Arrayを組むからには光らせたいのが心情というもの。
3ware 9550SXUには個々のドライブのアクセスやlocationを示すためのLEDコネクタが実装されているので、これを利用しない手はありません。フラットケーブルでSATAケーブルと一緒に引き出し、ケースにLEDを実装することにしました。マニュアルだとピンアサインはGNDがコモンみたいな事が書いてありますが、実際には+5Vがコモンで、各端子がアクセス時はGNDに落ちる挙動をしますので注意が必要です。
9550SXUの動作テスト
3ware 9550SXUはwebベースの3DMとCLIのtw_cliというソフトウェアが提供されている。
当然メーカーからも提供されているが、いずれもportsにあったのでとりあえずそれを入れてみた。バージョンは以下のとおりで少し古いが特に問題なく動作するようだ。
3dm 2.04.00.035
tw_cli 2.00.06.007
ちなみにドライバーとfirmwareのバージョンは次のとおりでした。
Driver Version = 3.70.05.001
Firmware Version = FE9X 3.08.00.016
最終的には若干新しいのがリリースされていたので、結局3ware提供のFreeBSD R6.1用のものを入れてみることにしました。GUIでfirmwareのアップグレードが出来るようになったりするあたりの新機能は便利かも。
と思ったがJREが動かないと来たもんだ。
新しいシステムはFreeBSD 7.0Rなのでそれが原因かもしれません。
# ./setupFreeBSD_x86.sh -console
Initializing Wizard........
Extracting Bundled JRE.
Bundled JRE is not binary compatible with host OS/Arch or it is corrupt. Testing bundled JRE failed.
面倒なのでバイナリーだけ置き換えてみることにする。
tw_cliはコマンドを置き換えるだけ。本当はmanなんかもあったりするが、そこは大きく変わっていなさそうなのでパス。
# cp /cdrom/packages/cli/freebsd/x86/tw_cli /usr/local/sbin/tw_cli
# tw_cli help | grep ver
AMCC/3ware CLI (version 2.00.06.016)
tw_cli.8.nroff
tw_sched.8.nroff
# rm /usr/local/man/man8/tw_cli.8.gz
# rm /usr/local/man/man8/tw_sched.8.gz
# rm /usr/local/man/cat8/tw_cli.8.gz
# rm /usr/local/man/cat8/tw_sched.8.gz
# gzip -9c tw_cli.8.nroff >/usr/local/man/man8/tw_cli.8.gz
# gzip -9c tw_sched.8.nroff >/usr/local/man/man8/tw_sched.8.gz
# tar xzf /cdrom/packages/drivers/freebsd/src/6.x/twa.tgz
# cd twa
# make
1TBのドライブ4本でRAID10のunitを作ってみる。
# tw_cli /c0 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
------------------------------------------------------------------------------
u0 RAID-10 OK - - 256K 1862.62 ON OFF
u1 SPARE OK - - - 931.505 - OFF
Port Status Unit Size Blocks Serial
---------------------------------------------------------------
p0 OK u0 931.51 GB 1953525168 5QJ0GF1T
p1 OK u0 931.51 GB 1953525168 5QJ0DN4W
p2 OK u0 931.51 GB 1953525168 5QJ0DFQY
p3 OK u0 931.51 GB 1953525168 5QJ0DMFC
p4 OK u1 931.51 GB 1953525168 5QJ0A138
p5 OK - 465.76 GB 976773168 3QG03EP9
p6 NOT-PRESENT - - - -
p7 NOT-PRESENT - - - -
# tw_cli /c0/u0 show initializestatus
/c0/u0 is not initialized.
initializeがされていないのが気になるが、initializeを行うコマンドも無いのでこのまま使ってみる。
デバイスは/dev/da0に出来たので、これを丸ごとUFS2でファイルシステムを作成してマウントしてみる。
特に問題なく使用できるようだ。initializeしなくても使えるタイプの製品ということなのでしょう。
# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/amrd0s1a 496M 131M 326M 29% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/amrd0s1e 1.9G 5.0M 1.8G 0% /tmp
/dev/amrd0s1f 7.3G 1.3G 5.4G 19% /usr
/dev/amrd0s1d 2.9G 78M 2.6G 3% /var
/dev/da0 1.8T 16K 1.6T 0% /mpg
/dev/amrd1 264G 1.8G 241G 1% /home
障害を模倣するためにp0のドライブを抜いてみる。
# tw_cli /c0/u0 show all
/c0/u0 status = REBUILDING
/c0/u0 is rebuilding with percent completion = 50%
/c0/u0 is not verifying, its current state is REBUILDING
/c0/u0 is not initialized.
/c0/u0 Cache State = off
/c0/u0 volume(s) = 1
/c0/u0 name = mpg
/c0/u0 serial number = 5QJ0GF1T535616006940
/c0/u0 Ignore ECC policy = off
/c0/u0 Auto Verify Policy = off
/c0/u0 Storsave Policy = protection
/c0/u0 Command Queuing Policy = on
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB)
------------------------------------------------------------------------
u0 RAID-10 REBUILDING 50 - - 256K 1862.62
u0-0 RAID-1 REBUILDING 1% - - - -
u0-0-0 DISK DEGRADED - - p4 - 931.312
u0-0-1 DISK OK - - p1 - 931.312
u0-1 RAID-1 OK - - - - -
u0-1-0 DISK OK - - p2 - 931.312
u0-1-1 DISK OK - - p3 - 931.312
u0/v0 Volume - - - - - 1862.62
ドライブのリビルドの進捗状況は1%だが、unitとしては50%と表示されている。どうもRAID-10だと、うち半分がdegradeした状態と判断して50%から始まるようだ。
リビルドの最中にp0のディスクを戻してみる。リビルドの最中にディスク交換を行ったイメージだ。
# tw_cli /c0 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
------------------------------------------------------------------------------
u0 RAID-10 REBUILDING 53 - 256K 1862.62 OFF OFF
Port Status Unit Size Blocks Serial
---------------------------------------------------------------
p0 OK u? 931.51 GB 1953525168 5QJ0GF1T
p1 OK u0 931.51 GB 1953525168 5QJ0DN4W
p2 OK u0 931.51 GB 1953525168 5QJ0DFQY
p3 OK u0 931.51 GB 1953525168 5QJ0DMFC
p4 DEGRADED u0 931.51 GB 1953525168 5QJ0A138
p5 OK - 465.76 GB 976773168 3QG03EP9
p6 NOT-PRESENT - - - -
p7 NOT-PRESENT - - - -
ドライブは認識しているようだが、unitが不明の状態になっている。リビルドが終わってコピーバックを行うかどうか待つしかないのか?
リビルドが終わってもコピーバックはされないようだ。また、GUIでは交換したドライブをホットスペアに割り当てることも出来なくなってしまった。
CLIでやってみるとうまくいった。一度removeしてから交換するのが正規の手順なのかもしれない。
# tw_cli /c0 add type=spare disk=0
Creating new unit on controller /c0 ... Done. The new unit is /c0/u1.
# tw_cli /c0 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
------------------------------------------------------------------------------
u0 RAID-10 OK - - 256K 1862.62 ON OFF
u1 SPARE OK - - - 931.505 - OFF
Port Status Unit Size Blocks Serial
---------------------------------------------------------------
p0 OK u1 931.51 GB 1953525168 5QJ0GF1T
p1 OK u0 931.51 GB 1953525168 5QJ0DN4W
p2 OK u0 931.51 GB 1953525168 5QJ0DFQY
p3 OK u0 931.51 GB 1953525168 5QJ0DMFC
p4 OK u0 931.51 GB 1953525168 5QJ0A138
p5 OK - 465.76 GB 976773168 3QG03EP9
p6 NOT-PRESENT - - - -
p7 NOT-PRESENT - - - -
また、一連のイベントはsyslogにも記録される。
Jun 14 19:47:28 oxygen kernel: twa0: WARNING: (0x04: 0x0019): Drive removed: port=0
Jun 14 19:47:28 oxygen kernel: twa0: ERROR: (0x04: 0x0002): Degraded unit: unit=0, port=0
Jun 14 19:48:47 oxygen kernel: twa0: INFO: (0x04: 0x000B): Rebuild started: unit=0, subunit=0
Jun 14 19:59:05 oxygen kernel: twa0: INFO: (0x04: 0x001A): Drive inserted: port=0
Jun 15 00:32:06 oxygen kernel: twa0: INFO: (0x04: 0x0005): Rebuild completed: unit=0, subunit=0
次に、RAID10からRAID5へのマイグレーションを試してみる。
将来的に2TBで足りなくなった場合にRAID5へ移行できるようにするテストだ。
# tw_cli /c0/u0 migrate type=raid5
Sending migration message to /c0/u0 ... Done.
# tw_cli /c0/u0 show
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB)
------------------------------------------------------------------------
u0 Migrator MIGRATING - 0 - - -
su0 RAID-10 OK - - - 256K 1862.62
su0-0 RAID-1 OK - - - - -
su0-0-0 DISK OK - - p4 - 931.312
su0-0-1 DISK OK - - p1 - 931.312
su0-1 RAID-1 OK - - - - -
su0-1-0 DISK OK - - p2 - 931.312
su0-1-1 DISK OK - - p3 - 931.312
su0/v0 Volume - - - - - 1862.62
du0 RAID-5 OK - - - 64K 2793.94
du0-0 DISK OK - - p4 - 931.312
du0-1 DISK OK - - p1 - 931.312
du0-2 DISK OK - - p2 - 931.312
du0-3 DISK OK - - p3 - 931.312
du0/v0 Volume - - - - - N/A
一時的にRAID10とRAID5のsu(source unit)とdu(destination unit)が出来ているという扱いになるのが特徴的だ。
これには非常に時間がかかる。この例の構成では2日くらいかかりました。
完了すると次のようになる。
oxygen# tw_cli /c0/u0 show
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB)
------------------------------------------------------------------------
u0 RAID-5 OK - - - 64K 2793.94
u0-0 DISK OK - - p4 - 931.312
u0-1 DISK OK - - p1 - 931.312
u0-2 DISK OK - - p2 - 931.312
u0-3 DISK OK - - p3 - 931.312
u0/v0 Volume - - - - - 2793.94
ログはこんな感じ。途中電源落としたりもしてみましたが、問題なく継続されました。
スケジュールを入れておけば、一日のうち繁忙期を避けたマイグレーションも可能です。
# grep twa0 /var/log/messages
Jun 15 18:38:42 oxygen kernel: twa0: INFO: (0x04: 0x003E): Migration paused: unit=0
Jun 15 18:39:27 oxygen kernel: twa0: INFO: (0x04: 0x0033): Migration started: unit=0
Jun 15 18:42:26 oxygen kernel: twa0: INFO: (0x04: 0x001A): Drive inserted: port=0
Jun 15 18:44:10 oxygen kernel: twa0: INFO: (0x04: 0x003E): Migration paused: unit=0
Jun 15 18:44:27 oxygen kernel: twa0: INFO: (0x04: 0x0033): Migration started: unit=0
Jun 15 18:44:51 oxygen kernel: da1 at twa0 bus 0 target 1 lun 0
Jun 16 09:01:00 oxygen kernel: twa0: INFO: (0x04: 0x003E): Migration paused: unit=0
Jun 16 09:01:14 oxygen kernel: twa0: INFO: (0x04: 0x0033): Migration started: unit=0
Jun 17 02:58:51 oxygen kernel: twa0: INFO: (0x04: 0x0035): Migration completed: unit=0
ファイルシステムの伸張を試す
前述のRAID10からRAID5のマイグレーションでLUNのサイズは2.7Tほどの容量に増えましたが、ファイルシステムは1.8Tのままです。UFS2にはgrowfsでファイルシステムを伸張する機能があるのできちんと大きく出来るか試してみます。
まず、テストファイルを作っておきます。
# dd if=/dev/random of=test bs=1024k count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 26.440134 secs (40610302 bytes/sec)
# md5 test
MD5 (test) = 83249fcc6f404b334f2b65ff27d489be
実行できない。逆に小さくしようとしている所も異常。
# umount /mpg
# growfs -N /dev/da0
growfs: we are not growing (244137984->97771520)
fdiskでみるとパーテーション1が切られているように見えるので、fdiskで広げてみるが、ジオメトリがおかしいとかでうまくいかない。
調べたところ、fdiskパーテーションでは2TB以上は扱えない模様。
growfsもラベルがないと動作しないようなので、別の方法を考えないといけないようだ。
geomを使ってみる。
# glabel label -v mpg /dev/da0
Metadata value stored on /dev/da0.
Done.
# glabel list
Geom name: da0
Providers:
1. Name: label/mpg
Mediasize: 2999967546880 (2.7T)
Sectorsize: 512
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 5859311615
length: 2999967546880
index: 0
Consumers:
1. Name: da0
Mediasize: 2999967547392 (2.7T)
Sectorsize: 512
Mode: r0w0e0
2TBでnewfs
newfs -b 65536 -s 4294967296 /dev/label/mpg
テストファイルを置いておく
# md5 test
MD5 (test) = d99cdb9ffda759c2e61e5dce370b0fd4
# growfs -N /dev/label/mpg
growfs: we are not growing (268435456->97771519)
だめだ。
gpt labelを使ってみる。
まず2TBで切ってみる。
# gpt create /dev/da0
# gpt show /dev/da0
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 5859311549
5859311583 32 Sec GPT table
5859311615 1 Sec GPT header
#
# gpt add -s 4294967296 /dev/da0
/dev/da0p1 added
# gpt show /dev/da0
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 4294967296 1 GPT part - FreeBSD UFS/UFS2
4294967330 1564344253
5859311583 32 Sec GPT table
5859311615 1 Sec GPT header
# newfs /dev/da0p1
# dd if=/dev/random of=test count=1024 bs=1024k
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 27.342131 secs (39270598 bytes/sec)
# md5 test
MD5 (test) = ee87c87ac75ef82671654a40e3ae46cd
# growfs -N /dev/da0p1
growfs: we are not growing (1073741824->391086063)
growfsはぜんぜん動かないな。
一時期、xfsやzfsの使用も考えたが、xfsはまだ不完全でpanicして使い物にならなかったし、zfsはあまりにも遅すぎて実用レベルに無いので却下。
調査したところ、growfsもまだ2TB越えに対応していないらしいが、次のようなパッチをあてる事で伸張は出来るようになった。
--- growfs/growfs.c 2006-07-18 05:48:36.000000000 +0900
+++ growfs.new/growfs.c 2008-08-12 20:26:58.000000000 +0900
@@ -87,7 +87,7 @@
/*
* Possible superblock locations ordered from most to least likely.
*/
-static int sblock_try[] = SBLOCKSEARCH;
+static intmax_t sblock_try[] = SBLOCKSEARCH;
static ufs2_daddr_t sblockloc;
static union {
@@ -156,7 +156,7 @@
static void updrefs(int, ino_t, struct gfs_bpp *, int, int, unsigned int);
static void indirchk(ufs_lbn_t, ufs_lbn_t, ufs2_daddr_t, ufs_lbn_t,
struct gfs_bpp *, int, int, unsigned int);
-static void get_dev_size(int, int *);
+static void get_dev_size(int, u_int64_t *);
/* ************************************************************ growfs ***** */
/*
@@ -259,8 +259,8 @@
*/
for (cylno = osblock.fs_ncg; cylno < sblock.fs_ncg; cylno++) {
initcg(cylno, utime, fso, Nflag);
- j = sprintf(tmpbuf, " %d%s",
- (int)fsbtodb(&sblock, cgsblock(&sblock, cylno)),
+ j = sprintf(tmpbuf, " %jd%s",
+ (intmax_t)fsbtodb(&sblock, cgsblock(&sblock, cylno)),
cylno < (sblock.fs_ncg-1) ? "," : "" );
if (i + j >= width) {
printf("\n");
@@ -1924,7 +1924,7 @@
* e.g. from vinum volumes.
*/
static void
-get_dev_size(int fd, int *size)
+get_dev_size(int fd, u_int64_t *size)
{
int sectorsize;
off_t mediasize;
@@ -1969,7 +1969,7 @@
DBG_FUNC("main")
char *device, *special, *cp;
int ch;
- unsigned int size=0;
+ u_int64_t size=0;
size_t len;
unsigned int Nflag=0;
int ExpertFlag=0;
@@ -1977,7 +1977,7 @@
struct disklabel *lp;
struct partition *pp;
int i,fsi,fso;
- u_int32_t p_size;
+ u_int64_t p_size;
char reply[5];
#ifdef FSMAXSNAP
int j;
@@ -2128,7 +2128,7 @@
sblock.fs_size = dbtofsb(&osblock, p_size);
if (size != 0) {
if (size > p_size){
- errx(1, "there is not enough space (%d < %d)",
+ errx(1, "there is not enough space (%lX < %lX)",
p_size, size);
}
sblock.fs_size = dbtofsb(&osblock, size);
@@ -2216,7 +2216,7 @@
sblock.fs_old_ncyl = sblock.fs_ncg * sblock.fs_old_cpg;
printf("Warning: %jd sector(s) cannot be allocated.\n",
(intmax_t)fsbtodb(&sblock, sblock.fs_size % sblock.fs_fpg));
- sblock.fs_size = sblock.fs_ncg * sblock.fs_fpg;
+ sblock.fs_size = ((int64_t)sblock.fs_ncg) * sblock.fs_fpg;
}
/*
@@ -2227,7 +2227,8 @@
fragroundup(&sblock, sblock.fs_ncg * sizeof(struct csum));
if(osblock.fs_size >= sblock.fs_size) {
- errx(1, "not enough new space");
+ errx(1, "not enough new space (II) (%jd->%jd)",
+ (intmax_t)osblock.fs_size, (intmax_t)sblock.fs_size);
}
DBG_PRINT0("sblock calculated\n");
このパッチをあてても、growfsでファイルシステムを伸張したあとで、fsckをかけるとPhase 1で UNKNOWN FILE TYPE I=376839785 というようなエラーが大量に出るが、これはgrowfsが伸張した領域をclean upしてくれない事によるもの。
実際に存在するファイルではなく、伸張した領域に存在するゴミを拾ってしまう模様で、このinodeをクリアしてしまっても問題はない。
いざというときに備えて、一度fsck -yをかけてcleanにしておくのがよいだろう。
気を取り直して、パッチをあてたgrowfsを使用してファイルシステム伸張のテストを行ってみる。
1TB 3本でRAOI0を作成し、ファイルシステムを作成あらかじめ/etcの中身をコピーしておく。次に1TBのドライブを追加し1TB x 4のRAID0にマイグレーション。気の長い作業である。
# tw_cli /c0/u0 show
Unit UnitType Status %RCmpl %V/I/M Port Stripe Size(GB)
------------------------------------------------------------------------
u0 Migrator MIGRATING - 0 - - -
su0 RAID-0 OK - - - 256K 2793.94
su0-0 DISK OK - - p1 - 931.312
su0-1 DISK OK - - p2 - 931.312
su0-2 DISK OK - - p3 - 931.312
su0/v0 Volume - - - - - 2793.94
du0 RAID-0 OK - - - 256K 3725.25
du0-0 DISK OK - - p1 - 931.312
du0-1 DISK OK - - p2 - 931.312
du0-2 DISK OK - - p3 - 931.312
du0-3 DISK OK - - p4 - 931.312
du0/v0 Volume - - - - - N/A
growfsでファイルシステムを伸張する。
# growfs.new /dev/da0
We strongly recommend you to make a backup before growing the Filesystem
Did you backup your data (Yes/No) ? Yes
new file systemsize is: 488275968 frags
Warning: 2883584 sector(s) cannot be allocated.
growfs: 3813248.0MB (7809531904 sectors) block size 65536, fragment size 8192
using 1984 cylinder groups of 1922.00MB, 30752 blks, 246016 inodes.
super-block backups (for fsck -b #) at:
5861085440, 5865021696, 5868957952, 5872894208, 5876830464, 5880766720,
.
.
.
7774105856, 7778042112, 7781978368, 7785914624, 7789850880, 7793787136,
7797723392, 7801659648, 7805595904
#
# mount /mpg
# df -h /mpg
Filesystem Size Used Avail Capacity Mounted on
/dev/da0 3.5T 4.1M 3.2T 0% /mpg
ファイルシステムサイズは大きくなっている。
念のためfsckもしてみたが、RAIDを作り直した場合は誤検出することはなかった。
# fsck -y /dev/da0
** /dev/da0
** Last Mounted on /mpg
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
402 files, 530 used, 472810458 free (18 frags, 59101305 blocks, 0.0% fragmentation)
では内容をチェックしてみよう。
# umount /mpg
# fsck -y /dev/da0
** /dev/da0
** Last Mounted on /mpg
** Phase 1 - Check Blocks and Sizes
# diff -r /etc /mpg/etc
diff -r /etc/ntp.drift /mpg/etc/ntp.drift
1c1
< -72.578
---
> -72.593
ntp.driftは常時書き換わっているので、壊れたファイルは無かったと考えられる。
結論としては、growfsにパッチをあてればUFS2で2TB以上のファイルシステムに伸張が可能。
パーテーションは、今回の場合LUN全体を割り当てているので使っていないが、geomやgptでも特に問題は無いと思われる。
若干遠回りはしたが、当初の予定通りUFS2で運用が可能であることが確認できた。