Linux RAID （その２）
Linuxのカーネル開発のうちで主要なテーマは、LKMLのほかのサブグループのメーリングリストがあり、そこを中心に開発がすすめられている。ハードウェアRAIDとソフトウェアRAIDの議論で使用されるのは、Linux-RAIDである。
提案
AdaptecのScott Longが、「Proposed enhancements to MD」というタイトルのLKMLとLinux-RAID宛のメールで、ソフトウェアRAIDドライバのソースのmd.cを、少しだけ改善するパッチを添付して言った。2004年1月12日のことだった。
Adaptecでは、オープンソースのソフトウェアRAIDスタックのベースとするため、MDのドライバを調べている。MDは、われわれを十分に助け、現在と将来のAdaptec RAID製品において、公開された充分なサポートを始めることができるようになるだろう。（われわれが現在持っているクローズドなドライバでのサポートには限界があり、反対の声もある）
MDはかなり安定動作して、クリーンであるにもかかわらず、多くの機能拡張がされてきた。われわれはしばらくの間、これを研究しており、コミュニティに対して、レビューとインテグレーションを要求したい。これらは次のものを含んでいる。
- mdデバイスのパーティションサポート
- MDは、fdiskパーティションのコンセプトをサポートしていない。今のところ、これを実現させるただ一つの方法は同じメディア上の複数のアレイの作成による。
これの修正は、機能を完全にするために必要であるばかりではなく、我々のBIOSがアレイ上のパーティションを認識し、かつ正常なディスクとしてブートできるように、適切に扱うために必要である。
- 一般的なデバイス到着通知メカニズム
これはデバイス・ホットプラグをサポートし、かつ、いつMDモジュールをロードするか初期化するかにかかわらず、自動的にアレイを形成することを可能にするために必要である。
RHEL3(RedHat Enterprise Linux 3)は、これのスケールダウンしたバージョンを既に持っている。しかしこれはMDに固有で、カーネルに静的にMDをリンクしたときにだけ、動作する。一般的なメカニズムがあれば、デバイスの「HOT ARRIVAL」通知を望む他の記憶システムと同様に、MDもにも役立つだろう。
- RAID0フィックス
MD RAID0パーソナリティは、チャンク境界にまたがるI/Oを行なうことができない。それが要求を受けることができ、それをディスクごとの1つ以上の要求に分割することができるように、修正は必要である。
- メタデータ抽象
我々は「従来のMDフォーマット」に加えて、複数のオンディスク・メタデータフォーマットをサポートするつもりである。これをするために、コアとパーソナリティ・モジュールから、MDオンディスク構造に関する情報を抽象化しなければならない。
- DDFメタデータサポート
将来の製品は「DDF」*オンディスク・メタデータスキームを使用するだろう。これらの製品はBIOSによってブートすることができるが、OSでもDDFサポートを得なくてはならない。この仕組みは、前述のメタデータ抽象にプラグインすることになる。
★訳注：DDLとは、SNIA(Storage Networking Industry Association）のDDFTWG(Common RAID Disk Data Format Technical Work Group)が策定している、Common RAID Disk Data Format Specificationを指している。
私はリスクを管理し、かつソースのバタツキを最小にするために、複数のフェーズでこれらの変更を押し進めるつもりである。付属のカーネル2.6.1用のパッチはパーティション・サポート用である。これは元々 Ingo Molnar(訳注： O(1)スケジューラの開発者として有名だが、 1998年頃からMDの開発に加わっている）からのものだったが、カーネル2.6のディスク/ブロックレイヤの根本的な変化のため、少しだけ変わった。2.6用はかなり新しいのだが、2.4用のバージョンは非常によく動作する。私が感じている一つの問題は、リブートの後にではなく、fdiskを実行した後に/proc/partitionsに、作成されたパーティションが現われるということである。
反応
Jakob Oestergaardは、Adaptecの計画に興味を持ったが、このMDのデバイス・パーティション・サポートは、直ぐには2.6のカーネルには入れられないと思った。実際のところ彼は、最良の解決策は、MDをカーネル2.6で標準サポートされているDM(Device Mapper)へ移動させることではないかと指摘した。彼はまた、AdaptecとIBMが誰かにそれをさせることを提案した。
それとは別に、Jeff Garzikもまた、カーネル2.6（そしてそのうち2.7）が今後の主流なので、「最新版で開発し、必要があればバックポートするという戦略を持て」とアドバイスして、AdaptecがDMが無い2.4の仕組みに注目したことは、良くないと指摘した。
Matt Domschは返答した。
「カーネル2.6では、理想的にDM(Device Mapper)を使用することができる。しかし2.4ベースのディストリビューションにはDM(Device Mapper)を組み入れていない。私はそれがRHEL3にはないことを知っている。そしてSLES8(SuSE Linux Enterprise Server 8)にもそれは無いだろう。誰か、DMの上にDDFソリューションを構築することに関して、考えを共有できる人はいないだろうか。そのDMとは2.4の資産であるRHEL3や、SLES8などにDMを含むことがある。そうでなければ、2.4用のエンハンスメントMDと2.6のDMという、2つの異なるソリューションでAdaptecをスタックさせるだろう。」
Arjan van de Venが言った。
「それは即ち、2.4にDMを導入するか、2.4でパーティションをサポートするMDの利用を強制させるかのどちらかである。2.6ではすでにmultiple-superblock-formatsが実装されているので、私はDMを強くすすめる。」
Scottは、なぜAdaptecが2.6ではなく2.4に注目したのかを次のように説明した。つまり、この仕事はつまずきながらも、すでに数年間かけて進んできて、彼は単に最近これを取り上げて公開しただけということである。2.4から2.6への大きな遷移はこのときにたまたま起こったに過ぎない。
Arjanは直接尋ねた。
「なぜMDの代わりにDMをプロジェクトで使用しなかったのだろうか。実際のところDMは、MDとは異なりディスクフォーマットから独立していることを目指しているので、カーネルがRAIDフォーマットを解析して、使用する方法のように思われるのだが。」
Hack
Wakko Warnerが答えた。
「私が知っているかぎりでは、DMの設定はユーザスペースに置かれるため、カーネルは自動検出を行うことができない。これは私にとって、ルートファイルシステムとして使用する気にはさせない。このような（そして私がかつて見たLVMのような）コンフィギュレーションは、デバイスをセットアップするためにinitrdまたは他の同様な方法を必要とする。不幸なことには、これはコンフィグを記述した設定ファイルが２箇所に必要となることを意味している。（そのうちひとつは、initrdでloopデバイスを経由してマウントする必要があるので、簡単ではない）」
それらのやりとりとは別にNeil Brownは、Adaptecのオープンソース・ソフトウェアRAID スタックへの取り組みを賞賛した。またScottが、2.6のことを気にしながら、2.4での実装を望んでいると指摘した。しかしすでに、2.4のカーネルツリーに何かを入れるには遅すぎるので、ベンダやユーザが選択できる外部パッチとして提供してはどうかとすすめた。
この後LKMLでは暫く、MDとDMに関してと、カーネル2.6に関する実装の議論と、それに関するハックや情報交換が続いた。
EMD
2004年3月17日には、Adaptecのこれまでの作業の成果をまとめて、Justin T. Gibbsから「”Enhanced” MD code avaible for review」と題したメールが、Linux-RAIDにポストされ、様々な議論を呼んだ。
また、2004年3月25日には、「”Enhanced” MD version 0.8.0 now available」と題したLKMLへのポストで、JustinがLKMLで正式にEMDを以下のようにアナウンスした。
Enahanced MD プロジェクトの最新版スナップショットを以下に公開する。
http://people.freebsd.org/~gibbs/linux/SRC/emd-0.8.0-tar.gz
現在のカーネル2.6のmd実装との差分は、以下にある。
http://people.freebsd.org/~gibbs/linux/SRC/emd-2.6-20040425-diffs.gz
また、このドライバ用の”emdadm”と呼ぶツールも以下にある。
http://people.freebsd.org/~gibbs/linux/SRC/emdadm-0.00.1.tgz
このスナップショットでは、 RAID0, RAID1と、Adaptec ASRとDDFメタデータ・フォーマットをサポートしている。残りのRAIDパーソナリティと、 Super90 とSuper 1 メタデータ・フォーマットへの対応は、今後２、３週間のうちに行われることになる。現状のMDに対して、スーパーセットとなるこれらの機能を載せることが、このプロジェクトのゴールである。
このプロジェクトでは、いくつかのバグフィックスに加えて、emdadmにより、DDFとASRメタデータに基づいたアレイを作成、削除、モニタする機能を付加している。
このリリースでは、まだMDを置き換えるものとして構成されている。我々は、レビューするの立場のためには、diff形式で提供した方がより適切であると考えた。しかし一方で、現時点のEMD開発では、個別のドライバとしてこれを提供した方が、はるかに合理的であるとも信じている。理想的には、EMDとMDがマージされ、コミュニティの要求にあわせてレビューされ、修正されることである。EMDのための、質問、コメントおよび提案を常に歓迎する。
今回の一連の件で、Adaptecのとった方法は微妙である。即ちEMD等の成果は現在のところ、Adaptecのオープンソース・サポートページでは無く、Justin T. Gibbsがfreebsd.orgに持つ個人ページでだけ公開しているのである。
