gmirror, BIOS RAID, Fake RAID, SATA RAID

FreeBSD

ar0 -> ad0単発に戻す
Naguchi's Web(OCNサーバー設定-FreeBSD5)

>ataraidの場合 各カード毎に格納場所が異なります。これは、各カードの BIOS
>毎に構成情報の内容や格納する場所が異なるためです。atacontrolで書き込まれ
>る情報は、BIOSで構成した場合と同等になるよう配慮されています。
>で src/sys/dev/ata/ata-raid.[ch] を見ると、SiIは最終セクタから 512bytes
>がRAID構成用情報の領域として使用されていることが分かります。
>
>一方、geom label は(使用カードに関係なく)最後の1セクタ分をラベル用として
>使用しています。
>(src/sys/geom/label/g_label.c, src/sys/geom/mirror/g_mirror.c)
>
>というわけで、SiIの場合は ataraid と geom label の書かれる場所は同一の
>ようです。ただし書かれる内容は違うので、構成情報が壊れていると勘違いした
>カードBIOSが、当該領域を初期化してしまったという可能性はあります。
>＃ふつーはそんな余計なことはしないと思うんですが…。
>
おー、すばらしい。
さっそく確認してみました。

RAIDのBIOSは、構成がない状態("Delete RAID Set"を実行)で：

deneb# atacontrol delete ar0
deneb# diskinfo -c /dev/ad4
/dev/ad4
512 # sectorsize
500107862016 # mediasize in bytes (466G)
976773168 # mediasize in sectors
969021 # Cylinders according to firmware.
16 # Heads according to firmware.
63 # Sectors according to firmware.
...

最終セクタを0クリア：
deneb# dd if=/dev/zero of=/dev/ad4 bs=512 count=1 seek=976773167
deneb# dd if=/dev/zero of=/dev/ad6 bs=512 count=1 seek=976773167

deneb# dd if=/dev/ad4 bs=512 count=1 skip=976773167 | hd
1+0 records in
1+0 records out
512 bytes transferred in 0.000300 secs (1705706 bytes/sec)
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200

クリアされているようですので、gmirrorでRAID1構成：

deneb# gmirror label -v -b split -s 16384 ad46 /dev/ad4
Metadata value stored on /dev/ad4.
Done.
deneb# gmirror insert -v ad46 /dev/ad6
Done.

最終セクタは：

deneb# dd if=/dev/ad4 bs=512 count=1 skip=976773167 | hd
1+0 records in
1+0 records out
512 bytes transferred in 0.000895 secs (572205 bytes/sec)
00000000 47 45 4f 4d 3a 3a 4d 49 52 52 4f 52 00 02 00 00 |GEOM::MIRROR....|
00000010 03 00 00 00 61 64 34 36 00 c2 66 c0 80 fd 2a c3 |....ad46.ツfタ..*テ|
00000020 34 2a 3f d4 af d3 88 a6 5c 6d e5 e6 02 00 00 00 |4*?ヤッモ.ヲ\m......|
00000030 00 01 00 00 00 00 00 40 00 00 03 00 5e c0 70 74 |.......@....^タpt|
00000040 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000070 60 c0 70 74 00 00 00 84 4e f8 cc e7 1a 26 2b e3 |`タpt....N.フ..&+.|
00000080 fa cc 60 64 c0 dc b4 00 00 00 00 00 00 00 00 00 |.フ`dタワエ.........|
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
deneb# dd if=/dev/ad6 bs=512 count=1 skip=976773167 | hd
00000000 47 45 4f 4d 3a 3a 4d 49 52 52 4f 52 00 00 00 00 |GEOM::MIRROR....|
00000010 03 00 00 00 61 64 34 36 00 3c 96 da 8b 45 65 c0 |....ad46.<.レ.Eeタ|
00000020 80 0a 2b c3 af d3 88 a6 81 bd 90 27 02 00 00 00 |..+テッモ.ヲ.ス.'....|
00000030 00 01 00 00 00 00 00 40 00 00 03 00 5e c0 70 74 |.......@....^タpt|
00000040 00 00 00 00 02 00 00 00 00 26 77 00 00 00 00 00 |.........&w.....|
00000050 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000070 60 c0 70 74 00 00 00 a6 7e c1 0a c4 59 a5 39 fc |`タpt...ヲ~チ.トY・9.|
00000080 1a 4c 87 17 47 4b f9 00 00 00 00 00 00 00 00 00 |.L..GK..........|
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
1+0 records in
1+0 records out
512 bytes transferred in 0.084255 secs (6077 bytes/sec)
00000200

それっぽい感じで、構成情報と思われるデータが書かれています。

ここで再起動し、最終セクタを見てみると・・・

deneb# dd if=/dev/ad4 bs=512 count=1 skip=976773167 | hd
1+0 records in
1+0 records out
512 bytes transferred in 0.000264 secs (1938162 bytes/sec)
00000000 5a 04 ff 3f 37 c8 10 00 00 00 00 00 3f 00 00 00 |Z..?7ネ......?...|
00000010 00 00 00 00 20 20 20 20 20 20 46 56 34 44 30 30 |.... FV4D00|
00000020 34 52 4e 43 57 4e 43 34 03 00 a7 77 34 00 32 2e |4RNCWNC4..ァw4.2.|
00000030 31 30 20 20 20 20 48 69 74 61 63 68 69 20 48 44 |10 Hitachi HD|
00000040 54 37 32 35 30 35 30 56 4c 41 33 36 30 20 20 20 |T725050VLA360 |
00000050 20 20 20 20 20 20 20 20 20 20 20 20 20 20 10 80 | ..|
00000060 00 00 00 2f 00 40 00 02 00 02 07 00 30 58 38 3a |.../.@......0X8:|
00000070 00 00 00 00 00 00 00 01 ff ff ff 0f 00 00 07 04 |................|
00000080 03 00 78 00 78 00 78 00 78 00 00 00 00 00 00 00 |..x.x.x.x.......|
00000090 00 00 00 00 00 00 1f 00 06 07 00 00 5e 00 40 00 |............^.@.|
000000a0 fc 00 1a 00 6b 34 e9 7f 73 47 68 34 01 bc 63 47 |....k4..sGh4.シcG|
000000b0 7f 00 60 00 00 00 00 00 fe ff 00 00 fe 80 08 00 |..`.............|
000000c0 ca 00 f9 00 10 27 00 00 30 60 38 3a 00 00 00 00 |ハ....'..0`8:....|
000000d0 ca 00 00 00 00 00 87 5a 00 50 a2 cc c9 13 c9 65 |ハ......Z.P「フノ.ノe|
000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 40 |...............@|
000000f0 10 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |.@..............|
00000100 01 00 0b 00 14 31 95 10 04 00 02 00 43 49 08 05 |.....1......CI..|
00000110 04 07 00 00 64 00 00 fd ff ff 02 00 00 00 00 00 |....d...........|
00000120 00 00 00 00 08 00 00 00 01 02 00 00 00 00 53 69 |..............Si|
00000130 49 20 52 61 69 64 31 20 53 65 74 20 20 20 98 35 |I Raid1 Set .5|
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000190 00 00 00 00 00 00 00 00 00 00 00 00 3f 00 00 00 |............?...|
000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a5 39 |..............・9|
00000200

あー、書き換わってる！

文字列で見えている"SiI Raid1 Set"というのはカードのBIOSにも表示されていました。
前回にも指摘されましたが、BIOSがここを書き換えているようです。
("Delete RAID Set"しているにもかかわらず、削除する前の情報を書いている)

ためしにRAID0をカードBIOSで設定し、その後"Delete RAID Set"で削除して再起動、
見てみると、"SiI Raid0 Set"とか書かれています。

BIOSが書き換えていることは、ほぼ間違いないようです。

>
>gmirror構成後、カードBIOSでRAID構成いぢっていませんよね？
>ataraidを使用しない場合、カードBIOS側でのRAID構成は御法度です。単なる
>ATAデバイスとして見えるよう、事前に設定しておきましょう。
>
了解しました。

じつはJBODと指定するメニューがカードのBIOSにありませんでした。
(マニュアルには書いてありますが)
ので、構成がない状態がJBODだと思っていましたが、ちがうのかな？

Silicon ImageのホームページにBIOSがおいてありましたので、ひょっとしたら、
RAIDではないBIOSに書き換えれば、最終セクタに悪さすることもないかもしれません。
(少々怖いので今はできませんが)

いろいろと情報ありがとうございました。
おかげさまで原因がわかり、幾分すっきりした感じです。

http://osdir.com/ml/org.user-groups.freebsd.japan/2007-04/msg00018.html

metadataを削除する

最後に余談です。

gmirrorやarはHDDの後ろの方にmetadata(RAIDの管理情報)を書き込んで管理しています。で、atacontrolコマンドでいったん書きこまれたmetadataはごみデータが残りやすく、かなり厄介です。 特にテストのために一度抜いたHDDを戻したりすると、整合性が取れていないはずなのにReady状態に戻ってしまう(リビルドする方法が無い)ため、非常に危険です。

こういうどうしようもなくなったディスクからmetadataを削除する場合、ディスクの後の方の領域をクリアします。以下の例ではかなり適当に後の方をゴソッと消してますが、実稼働中のディスクでやる場合はちゃんと計算した方が良いと思います。

例えばad8のmetadataを消す場合、まずディスクの容量を調べます。
# diskinfo ad8
ad8 512 164696555520 321672960 319120 16 63 2番目の数字がセクタサイズで4番目の数字が総セクタ数です。これらの数字を参考に、最後の方を適当に消してしまいます。
# dd if=/dev/zero of=/dev/ad8 bs=512 seek=321650000 これで最後の約10MB(512×22960 byte)が消えます。seek=を省略すればディスク全体をクリアしますが、その場合はbsの値を大きめにすると早く終了します。

ちなみに、RAIDの情報が書き込まれる位置は/usr/src/sys/dev/ata/ata-raid.hに'*_LBA'という名前で定義されていますので、BIOS RAIDを使っている場合はRAIDコントローラのメーカを調べてそこから計算します。あるいは、起動画面で「5. Boot FreeBSD with verbose logging」を選択して起動し、dmesgをMetadataで検索すると、どのタイプのmetadataがディスクに記録されているか調べることができます。

Hideki SAKAMOTO の雑記 (2009-07-16)

$ sudo diskinfo -c /dev/ada1
/dev/ada1
	512         	# sectorsize
	320072933376	# mediasize in bytes (298G)
	625142448   	# mediasize in sectors
	0           	# stripesize
	0           	# stripeoffset
	620181      	# Cylinders according to firmware.
	16          	# Heads according to firmware.
	63          	# Sectors according to firmware.
	JP1430HN1S44BL	# Disk ident.

625142448 セクタ
先頭と最後の10MBを消す

# dd if=/dev/zero of=/dev/ada1 bs=512 count=20000
# dd if=/dev/zero of=/dev/ada1 bs=512 seek=625122448

512 × 20000 byte = 10240000 byte
625122448 = 625142448 - 20000