他にも、もっと確実な方法があるのかも知れないが、繰り返しの操作でも安定しているように見える環境と、操作方法を何とかみつけることができた。前回まで繰り返して来たテストから、替えた点は以下の通りである。
- BIOSでHyper-Threadingを無効にした
マルチCPU対応は「出来が悪い」デバイスドライバの安定動作に影響する場合があるので、不安定になりそうな要素を排除した。これに合わせてカーネルも、UP（シングル・プロセッサ）用のカーネルを使用した。
- コントローラはIntel ICH5Rだけを使用した
これまでの経験から、dmraidがより不安定になり易いPromiseやHighPointのコントローラの使用を避けて、余計な作業工数を使わないようにした。特に今回の動作実験では、ネット上の情報から比較的成功例が多いと思われるICH5Rだけを使用した。
- dmraidは、最新版のdmraid-1.0.0.rc6だけを使用した
以前からずっとテストを行っていたという経緯で、これまでは古いバージョンのdmraidも合わせて使用していたのだが、dmraidのバージョンによって動作結果が違うことと、複数バージョンのdmraidを使用すると、メタデータ（後述）の扱いに不整合が起きるのではないかと考え、使用するdmraidコマンドのバージョンを統一した。
- マザーボードのBIOSが最新のものであることを確認した
ASUSTEK製のマザーボードを2種類使用してテストをしているが、SATA関係の修正があるので最新版である事を一応確認した。
以上の対策のうちで、どれが有効であったのかはわからないが、各環境別のテスト結果を以下に示す。
| ディストリビュ-ション | カーネル | テスト結果 |
| Fedora Core 3 | 2.6.10-1.766_FC3(FC3) | ○ |
| 2.6.11.6(kernel.org) | ○ | |
| Debian sarge | 2.6.10-1(sarge) | ○ |
| 2.6.11-1(sarge) | × | |
| 2.6.11.6(kernel.org) | ○ |
dmraidの実際（その２）
まず前回に続いてdmraidに関する不満を並べてみる。ソフトウェアの品質を別にしたとしても、以下のような不備があるプロジェクトは最近では珍しいものである。
- ドキュメント
インストールで得られる主なドキュメントはREADME、dmraid_design.txtという内部仕様に関する文書と、manページである。使用方法や手順に関しては、READMEに最初に使うコマンドは、"dmraid -cs"となるだろうとしか書いてない。使用法に関して一番情報量が多いのはmanページであるが、ここ最近メンテナンスされてないようで誤りが多く、注意を必要とする。
- ユーザインタフェイス
ドキュメントが悪くてもソフトウェアそのもの、特にユーザインタフェイスの出来が良ければカバーされるものである。dmraidには、ユーザに親切で、わかり易いインタフェイスが備わっているとは決して言えない。
- インターネット上の情報
ドキュメントが悪くても、インターネット上に利用者の情報やコミュニティがあれば補われるものだが、検索してもあまり有益な情報は得られない。dmraidの本家をはじめ、恐らく関連性が一番高いと思うDevice Mapperのコミュニティや過去ログを漁っても、dmraidをRAID1(mirror)で安定運用させるためのヒントはほとんど得られなかった。
そこで仕方がないので今回は、筆者の経験によるカーネル2.6でdmraidを動作させるためのヒントをここに載せてみることにした。
このコラムでは時に、実験結果や操作方法を載せることがあるが、あくまでもカーネル開発の現場で起きていることの裏を取るための実験という位置付けである。初心者向けのHOWTOや、ノウハウ集では無いので注意されたい。そのため説明する手順の一部は省略し、またすべての環境で動作するものでもなく、サポートもないことをご理解されたい。
- 初期化・設定
当然ながらIntel SATA RAIDに接続した2台のSATAドライブがあり、BIOSのミラー設定が終っているものとする。カーネルは、dmraidがミラー・ターゲットで使用するCONFIG_DM_MIRROR付きでコンパイルされている必要がある。
- インストール
まずdmraid-1.0.0.rc6.tar.bz2を展開して、コンパイルし、dmraidアプリケーションをインストールする。古いバージョンのdmraidには､このtarballにカーネルパッチも含まれていたが、2.6.8以降はdm_mirror.koをコンパイルするためのCONFIG_DM_MIRRORがあるので、パッチは不要である。逆に言うとdmraid-1.0.0.rc6にはカーネル・パッチは含まれないので、カーネルは2.6.8以降を使用する必要がある。FC3では、動作が怪しいやや古いバージョンのdmaidがインストールされている場合があるので、誤ってこれを起動しないように名前を変更しておく。
- 起動
まずREADMEに習って、
# dmraid -cs
と入力してみる。
isw_eabjjjfjig_RAID_Volume1
等と表示されれば認識されているので良いのだが、初期のdmraidや、コントローラの種類によっては、この段階でどうやっても認識しないので、注意が必要である。dmraid -csで正常に認識すれば、より詳細な情報を入手する
# dmraid -s -ccc
が使える。問題が無ければ、以下のように表示される。
/dev/sda:isw:isw_eabjjjfjig_RAID_Volume1:mirror:ok:398296576:0 /dev/sdb:isw:isw_eabjjjfjig_RAID_Volume1:mirror:ok:398296576:0
dmraidの起動は以下のようにする。
# dmraid -ay
/dev/mapper以下に次のようなiswで始まるデバイスファイルができているはずである。（後述するが、合わせて余計なデバイスもできることがある）
/dev/mapper/isw_eabjjjfjig_RAID_Volume1
これがdmraidがサポートするmirrorドライブとなる。接頭辞のiswはIntel SoftWareの略なので、コントローラが異なれば、pdc, sil等と接頭辞も異なる。全てのサポートしているコントローラの種類は、dmraid -lで表示できる。デバイスファイルが確認できれば、fdiskでパーティションを設定し、仮想のミラードライブに設定情報を書き込む。
# fdisk /dev/mapper/isw_eabjjjfjig_RAID_Volume1
ここで新しく設定したパーティションをdmraidに認識させる必要があるので、ここでいったんdmraidを停止して再起動する。
# dmraid -an RAID set "isw_eabjjjfjig_RAID_Volume11" is not active RAID set "isw_eabjjjfjig_RAID_Volume12" is not active RAID set "isw_eabjjjfjig_RAID_Volume13" is not active RAID set "isw_eabjjjfjig_RAID_Volume14" is not active
等という「作ったばかりのデバイスファイルが無い」という意味のメッセージが表示されるが、これはdmraidの行う/dev/mapper以下のデバイスファイルの操作が誤っているためである。この辺のユーザインタフェイスの出来が悪く、逆にパーティションを削除した後では、無いはずのパーティションがいつまでも存在することになる。
# dmraid -ay
再度dmraidを起動する。運が良ければ新しく設定したパーティションに対応した、デバイスファイル(isw_eabjjjfjig_RAID_Volume1[1-n])が/dev/mapper以下に出来ているはずである。dmraidのバージョンが古いか、運が悪いとパーティションを沢山作っても、デバイスファイルは最大5個程度に制限されてしまう。後はmke2fsし、mountして通常ドライブのパーティションのように利用できるはずである。
ただし安心してはいけない。前記2.6.11-1(sarge)のテスト結果もそうであるが、3GB程度のデータをtarやcpで操作すると、途中でコマンドの応答が全く無くなる場合がある。そのときにはエラーメッセージは出ないが、コマンドを受け付けないか、コマンド入力ができても、シャットダウンは出来ないのでシステムをリセットするしかない。
- その他の注意
dmraidの実体は、各ベンダのRAIDコントローラが使用するRAID管理情報とのインタフェイスであるとも言える。このようなRAID管理情報は「メタデータ」と呼び、いずれのベンダのコントローラを利用しても、RAIDに組み入れられる各ドライブの最後の部分に書かれるようになっている。dmraidは現在のコントローラの種類やRAIDの状況に関係なく、起動時や状態表示時には接続している全ての（あるいは指定された）コントローラの全てのメタデータを読み、管理対象とする。従って以前何らかのRAIDコントーラに接続したことがあるドライブを/dev/hdaに接続した場合には、そのドライブの現在の接続状態に関係なく、メタデータ情報に基づいた表示と管理を行おうとする。また各ベンダのメタデータは上書きされずに共存するので、テスト等でいろいろなコントローラのRAIDで使用したドライブには、接続したことがある全てのベンダの管理情報が表示される。
例えば以下のように、物理的に接続していないPromiseコントローラの管理情報が表示されるケースがある。
# dmraid -s -ccc pdc_cgihbhddji:160086400:128:stripe:ok:0:1:0 /dev/hda:pdc:pdc_cgihbhddji:stripe:ok:160086400:0
このような場合は以下のような手順でメタデータを削除するのだが、現在有効でないRAIDでもstripe:ok等と表示されることと、コントローラによっては接続先の実デバイス名(/dev/sda, /dev/hde, ...)が異なるので、削除操作には注意が必要である。
# dmraid -E -r /dev/hda pdc Do you really want to erase "pdc" ondisk metadata on /dev/hda ? [y/n] :y
この方法はmanページに載っている書式とは異なり、正しい操作かどうか、また他に影響が無いかのは不明であるが、筆者がテストした時には、この方法以外で古いメタデータを消す方法がわからなかったため、やむを得ず使用している。
カーネル2.4のiswraid
IntelがサポートするSATA RAIDを使用するためには、ICH5R等のR付のサウスブリッジが付いているマザーボードを使用する必要があるという注意点は、前回書いた通りである。このIntel SATA RAIDを、カーネル2.4でDM(Device Mapper)無しでも動作させようという動きがあるので紹介する。
Martins Krikisは "iswraid" (ICH5R/ICH6R ataraid sub-driver) for 2.4.28-pre3と題した、メールをLKMLにポストした。2004年の10月のことである。
カーネル2.4シリーズ用の、Version0.1.4.3のIntel Sofware RAIDドライバ(iswraid)を以下に載せた。
http://prdownloads.sourceforge.net/iswraid/2.4.28-pre3-iswraid.patch.gz?download
これはataraidの「サブドライバ」であるが、RAIDメンバディスクを見つけるためにSCSIサブシステムを使用する。これはlibataライブラリ、特にICH5/ICH6チップセットのシリアルATA機能を有効にするata_piixドライバにも依存する。従って2.4.28より古いカーネルでは、Jeff Garzikのlibataパッチを適用しておく必要がある。追加情報と、ICH6Rについては、http://iswraid.sourceforge.net/にあるプロジェクトのホームページを参照されたい。
どうかこのドライバをカーネル2.4ツリーに含める事について、検討をお願いしたい。Documentation/iswraid.txtに文書がある。このドライバを2.4のカーネルに受理可能にするために、何か私ができることがあれば知らせて欲しい。
Alan Coxは、「これは私とっては興味を持たざるを得ない。我々は2.6ではDMレイヤを持っているが、2.4ではataraidを使用しているからだ。」と好意を持って注目した。
しかしBartlomiej Zolnierkiewiczが答えた。「これは私には無知のように聞こえる。なぜ、替わりに2.4用のDevice Mapperにマージできなかったのか？2.4用のDevice Mapperのパッチには悪いところがあるのだろうか？カーネル2.4と2.6に同じ機能を持たせる方が、アップグレードが便利だと思うのだが」
訳注：DMレイヤが必要なEVMS(Enterprise Volume Management System)のカーネル2.4実装は、2.4用のDevice Mapperパッチを使用している。
Martins Krikisがこれに反論したのだが、それがかえって余計な議論を引き起こした。一方でJeff Garzikは、この全く新しいRAID/LVMまで伴ったDMを、安定版である2.4シリーズに正式導入することは容易ではないと感じた。
Bartlomiej Zolnierkiewiczは、カーネル2.4のメンテナであるMarcelo Tosattiの「既存の機能を壊さないことと、利用者が得られる利益が大きければ、新しいドライバの追加実装は許される」というメールを引用して、2.4用のDMがこれを満足するはずだと述べた。
Jeff GarzikはLVM1がDM無しですでにカーネル2.4に安定実装されており、LVM2はDMの上に実装されているので同じものが付いて来ると指摘した後、ついに2.4カーネルメンテナのMarcelo Tosattiが出てきて「その通り、今回の状況は全く違う。」と言った。「我々はすでに2.4上でDeviceMapperの"ような"ものの上に、RAID/LVMを構築している。私は本当のところ、Device Mapperをマージするという選択肢があるとは思わっていない。」Marceloは続けた。
一般的な意見の一致は、iswraidを（次のカーネル・ツリーに）マージすることだと思える。私はそれで良い。Martins、我々は次の-rcが近いのだが、2.4.29-preの最初でマージしたいのだが、大丈夫かい?
Martinsが「勿論だ。これ以上コメントすると2.4の列車に乗り遅れそうだ。」と答えた。