名称

GEOM — モジュラディスク I/O 要求変換フレームワーク

書式

options GEOM_AES
options GEOM_BDE
options GEOM_BSD
options GEOM_CACHE
options GEOM_CONCAT
options GEOM_ELI
options GEOM_FOX
options GEOM_GATE
options GEOM_JOURNAL
options GEOM_LABEL
options GEOM_LINUX_LVM
options GEOM_MBR
options GEOM_MIRROR
options GEOM_MULTIPATH
options GEOM_NOP
options GEOM_PART_APM
options GEOM_PART_BSD
options GEOM_PART_EBR
options GEOM_PART_EBR_COMPAT
options GEOM_PART_GPT
options GEOM_PART_LDM
options GEOM_PART_MBR
options GEOM_PART_PC98
options GEOM_PART_VTOC8
options GEOM_PC98
options GEOM_RAID
options GEOM_RAID3
options GEOM_SHSEC
options GEOM_STRIPE
options GEOM_SUNLABEL
options GEOM_UZIP
options GEOM_VIRSTOR
options GEOM_VOL
options GEOM_ZERO

解説

GEOM フレームワークは、上位のカーネルからデバイスドライバまでのパスとその逆でディスク I/O 要求の変換を実行することができる“classes”の基盤を提供します。

GEOM コンテキストの変換は、 RAID アルゴリズムとデバイスマルチパスリ解決上の典型的なディスクパーティショニングモジュールで実行された簡単なジオメトリ置換えから格納されたデータの本格的な暗号法の保護に及んでいます。

伝統的な“ボリューム管理”と比べて、 GEOM は、次の方法で以前のすべての実装とほとんど異なっています:

• GEOM は、拡張可能です。新しいクラスの変換を書き込むことは明らかに簡単であり、継承される子供の処理は与えられません。だれかがある理由で IBM MVS ディスクパックをマウントしたいなら、それらの VTOC 情報を認識して設定するクラスは、小さい事柄でしょう。
• GEOM は、トポロジ (位相的な) の不可知論者です。ほとんどのボリューム管理実装には、クラスがどのように一緒に適合することができるかに関する非常に厳しい概念があります。頻繁に、1 つの固定階層構造は、例えば、サブディスク - plex - ボリューム、を提供されます。

拡張できることは、新しい変換が既存の変換と異なって取り扱われないことを意味します。

固定の階層構造は、効率的に意図を述べるのを不可能にするので、良くないです。上記の固定階層構造では、2 つの物理的なディスクをミラーすることができません、そして、サブディスク中のミラーを区切り、代わりに、はるかに複雑な設定をもたらす 2 つずつミラーする、 1 つの物理的なボリュームで強制的にサブディスクを作ります。他方では、 GEOM は、どの順序でこれが行われるかは気にしません、唯一の制限は、グラフでの循環が許されないことです。

専門用語とトポロジ

GEOM は、かなりオブジェクト指向で、その結果として、専門用語は、オブジェクト指向 (OO) の語彙 (ボキャブラリ) から多くのコンテキストとセマンティクス (意味論) を借りています:

データ構造 g_class で表される“class”は、1 つの特定の種類の変換を実装しています。典型的な例は、MBR ディスクパーティション、BSD disklabel と RAID5 のクラスです。

クラスのインスタンスは、“geom”と呼ばれ、データ構造 g_geom で表されます。典型的な i386 FreeBSD システムでは、各ディスクのためのクラス MBR の 1 つの geom があります。

データ構造 g_provider で表される“provider”は、geom がサービスを提供するフロントゲートです。プロバイダは、“ /dev に現れるディスクのようなもの” - 言い換えれば、論理的ディスクです。すべてのプロバイダには、3 つの主要なプロパティ (特性) があります: “name”, “sectorsize”と“size”です。

“consumer”は、geom が別の geom プロバイダに接続し、 I/O 要求が送信されるバックドア (裏口) です。

これらの実体の間のトポロジ (位相的な) の関係は、次の通りです:

• クラスには、0 または geom インスタンスがあります。
• geom には、由来する、まさに 1 つのクラスがあります。
• geom には、0 または複数のカスタマがあります。
• geom には、0 または複数のプロバイダがあります。
• カスタマは、0 または 1 つのプロバイダにアタッチすることができます。
• プロバイダは、0 またはアタッチされた複数のカスタマを持つことができます。

すべての geom には、検出するために使用され、非循環の有向グラフでループを防ぐ、ランク番号を割り当てられています。このランク番号は、次のように割り当てられます:

1. アタッチされたカスタマがない geom は、ランク=1 を持ちます。
2. アタッチされたカスタマがある geom は、アタッチされたカスタマのプロバイダの geom の最も高いランクより 1 つ高いランクを持ちます。

特別なトポロジの技術操作

カスタマからプロバイダにアタッチする直接的なアタッチと結び付きを破るデタッチに加えて、多くの特別のトポロジの操作が設定を容易にするためと総合的な柔軟性を改良するために存在しています。

テイスティング (TASTING)

は、新しいクラスか新しいプロバイダを作成し、それ自身のものとして認識するプロバイダで自動的にインスタンスを設定するためのチャンスをクラスに提供するときはいつも、起こるプロセスです。典型的な例としては、最初のセクタで MBR テーブルを探す、MBR ディスクパーティションのクラスです、見つけられて有効であれば、 MBR の内容に従って多重化するために geom のインスタンスを作成します。

新しいクラスは、順番にすべての既存のプロバイダを提供し、新しいプロバイダは、順番にすべてのクラスを提供します。

受け付けるべきであるなら、どのクラスが正確に認識するためには、提供されたプロバイダは、 GEOM によって定義されませんが、目的にふさわしいオプションの組は、次の通りです:

• ディスク上で特定のデータ構造を調べます。
• プロバイダのために“sectorsize”または“mediasize”のようなプロパティ (特性) を調べます。
• プロバイダの geom のランク番号を調べます。
• プロバイダの geom のメソッド名を調べます。

親がないようにする (ORPHANIZATION)

は、それが潜在的にまだ使用されている間にプロバイダによって取り除かれるプロセスです。

geom がプロバイダを親がないようにするとき、すべての今後の I/O 要求が geom によって設定されたエラーコードでプロバイダで“bounce” (戻り) ます。プロバイダにアタッチされた任意のカスタマは、イベントループがそれをうまく避けるとき、親がないようにすること (orphanization) に関する通知を受信し、そして、それらは、その時、適切なアクションを取ることができます。

親のないプロバイダを欠いている間に、機能し続ける方法がない場合、通常の taste 操作の結果のように出現する geom は、自己破壊すべきです。したがって、ディスクスライサ (disk slicer) のような geom は、自己破壊すべきであるのに対して、 RAID5 またはミラーの geom は、それらが定足数を失わない限り、継続することができます。

プロバイダが親がないようにされるとき、必ずトポロジでのいくらかの即座の変更で終りません: どんなアタッチされたカスタマもまだアタッチされています。どんなオープンされたパスもまだオープンしています。どんな未解決の I/O 要求もまだ未解決のままです。

典型的なシナリオは、次の通りです:

• ディスクを検出するデバイスドライバは、それのためのプロバイダを死なせて親のない状態にします。
• ディスクの先頭の geom は、親がないようにすること (orphanization) のイベントを受信し、順番にそれらのすべてのプロバイダを親のない状態にします。アタッチされていないプロバイダは、通常すぐに自己破壊されます。このプロセスは、ツリーのすべての関連断片が悪いニュースを聞くまで、準再帰的な方法で継続します。
• 結局、それがスタックの先端で geom_dev に達するとき、責任を取ります。
• geom_dev は、それ以上の要求が入るのを止めるために destroy_dev(9) を呼び出します。任意の、そしてすべての未解決の I/O 要求が返されるまでスリープします。メッシュを通して端から端まで伝播される変更を明白にクローズします (すなわち、アクセスカウントが 0)。次に、geom をデタッチして破壊します。
• プロバイダが現在デタッチされている geom は、プロバイダを破壊し、カスタマをデタッチして破壊し、そして、geom を破壊します。
• このプロセスは、クリーンアップが完了するまで、メッシュを通して端から端まで浸透します。

このアプローチが複雑に見えるとはいえ、それは、見えなくなっているデバイスの取り扱いにおける最大の柔軟性と堅牢性を提供します。

承知している 1 つの絶対的に重要な詳細は、デバイスドライバがすべての I/O 要求を返さないなら、ツリーは、分解されません。

妨害 (SPOILING)

は、古いメタデータから守るために使用される親がないようにすること (orphanization) の特別な場合です。例を体験することによって妨害を解釈することがたぶん最も簡単です。

ディスクを推測してください。 MBR geom は、 da0s1 と da0s2 を提供し、その先頭は、 da0 で、BSD geom は、 da0s1a から da0s1e を提供する da0s1 の先頭であること MBR と BSD geom の両方は、ディスクメディア上のデータ構造に基づいて自動設定しました。今度は、 da0 が書き込みのためにオープンされる場合、それらのデータ構造は、変更されるか、または上書きされる場合を想像してください。今、そうでなければ、何らかの通知システムがそれらを通知することができないなら、 geom は、古いメタデータを操作するようになるでしょう。

この状況を避けるためには、書き込みのために da0 のオープンが起こるとき、すべてのアタッチされたカスタマは、これに関して通信され、 MBR と BSD のような geoms は、結果として自己破壊されます。 da0 が再びクローズされるとき、再び tasting のためにそれを提供し、そして、MBR と BSD のためのデータ構造がまだそこにあるなら、新しい geom は、新たにそれら自体のインスタンスを作成します。

現在の例外規定は、次の通りです:

MBR か BSD モジュールを通してパスのいすれかがオープンされたなら、排他的ビットレンダリングで下向きにオープンされるでしょう。その場合には、書き込みのために da0 をオープンすることは不可能で、逆に要求された排他的ビットがレンダリングされ、書き込みのために da0 がオープンされている間、 MBR geom を通してパスをオープンすることが不可能です。

また、これから、オープンされている geom のサイズを変更することは、それらの協力でのみ行えることが続きます。

最終的に: spoiling は、書き込みカウントが 0 から非 0 になるときのみ起こり、再 tasting (retasting) は、書き込みカウントが非 0 から 0 になるときのみ起こります。

設定 (CONFIGURE)

は、特定のクラスがそれ自体のインスタンスを作成するために管理者が指示を発行するプロセスです。この場合、目的を述べる複数の方法があり、- 特定のプロバイダは、例えば BSD disklabel モジュールが TASTE 操作の間においしさを見つけられなかったプロバイダにアタッチするために、強制的に上書きのレベルを指定することができます。

最終的に IO は、私たちがこれを行う理由です: それは、それ自体がグラフで I/O 要求を送信するのに対する懸念です。

I/O 要求 (REQUESTS)

は、カスタマに由来して struct bio によって表され、アタッチされたプロバイダでスケジュールされ、処理されたとき、カスタマに返ります。“反対側で出て来ない”特有の geom のプロバイダを通して入る struct bio を完全に理解することは重要です。 MBR と BSD のような簡単な変換でさえ、 struct bio のクローンであり、クローンを変更して、それら自身のカスタマ上でクローンをスケジュールします。 struct bio のクローン作成は、IO 要求で指定された実際のデータ領域のクローンを必要としないことに注意してください。

合計で 4 つの異なった IO 要求が GEOM に存在しています: 読み込み、書き込み、削除と“属性の取得”です。

読み込み、書き込みは、自明です。

データの特定の範囲は、もはや使われていない、そして基本的な技術サポートとして削除されるか解放できると示されるものを削除します。フラッシュ適合レイヤ (層) のような技術は、再割り当てようになる前に関連ブロックを消すように準備することができ、暗号デバイスは、攻撃に利用可能なデータの量を減少させるために範囲内にランダムなビットを満たしたいかもしれません。

削除指示が要求されず、そしてその結果、グラフによる特定の geom によって保証しない場合、データが実際に消されるか、または入手できなくするという保証がないことを認識することは重要です。“安全な削除”セマンティクスが要求されるなら、 geom は、削除指示を書き込み要求 (のシーケンス) に変換するものをプッシュするべきです。

“属性の取得”は、特定のプロバイダかパスで帯域外の属性の検査と操作をサポートします。属性は、 ASCII 文字列で指定され、それらについては、下記の別々のセクションで議論します。

(作者が彼の脳と指を休ませている間、この問題に引き続き注目してください: 将来もっと書く予定です。)

診断

GEOM 操作のトレースと、 kern.geom.debugflags sysctl を通して保護メカニズムをアンロックするために、いくつかのフラグが準備されています。これらのフラグのすべては、デフォルトでオフです、そして、それらをオンにするには、かなりの注意が必要です。

0x01 ( G_T_TOPOLOGY)

トポロジ変更イベントのトレースを提供します。

0x02 ( G_T_BIO)

バッファ I/O 要求のトレースを提供します。

0x04 ( G_T_ACCESS)

アクセスチェック制御のトレースを提供します。

0x08 (未使用)

0x10 (足の射撃を許可)

Rank1 プロバイダへの書き込みを可能とします。例えば、これで、スーパユーザが、ルートディスクに MBR 上書きするか、またはマウントされたディスクへのほかの場所でランダムなセクタを書き込むことを許します。意味は、明白です。

0x40 ( G_F_DISKIOCTL)

これは、今回未使用です。

0x80 ( G_F_CTLDUMP)

gctl 要求の内容をダンプします。

関連項目

libgeom(3), disk(9), DECLARE_GEOM_CLASS(9), g_access(9), g_attach(9), g_bio(9), g_consumer(9), g_data(9), g_event(9), g_geom(9), g_provider(9), g_provider_by_name(9)

歴史

このソフトウェアは、 DARPA CHATS 研究プログラムの一環として、 DARPA/SPAWAR 契約 N66001-01-C-8035 (“CBOSS”) の下で Poul-Henning Kamp と NAI Labs, the Security Research Division of Network Associates, Inc. によって FreeBSD プロジェクトのために開発されました。

GEOM のための最初の先駆けは、Minix1.2 への気味悪いハッキングであり、決して配布されませんでした。 FreeBSD でそれほど一般的でないスキーム (計画) を実装する以前の試みは、決して成功しませんでした。

作者

Poul-Henning Kamp <phk@FreeBSD.org>