JP5027877B2 - ストレージシステム用コマンドの生成 - Google Patents

Description

本出願は、「Ｄｉｓａｇｇｒｅｇａｔｅｄ Ｒｅｓｏｕｒｃｅｓ ａｎｄ Ａｃｃｅｓｓ Ｍｅｔｈｏｄｓ」という名称で２００５年８月１６日に出願された共同所有の米国特許出願第１１／２０５，８９５号の一部継続出願である。

本発明の分野は、ストレージデバイスのためのコマンドの生成に関する。

仮想化ストレージシステムは、クライアントが複数の物理ストレージデバイスに、それらが単一の論理ボリュームであるかのようにアクセスできるようにする。一部のストレージシステムは、クライアントが、専用の管理サーバを必要とせずに、直接、物理ストレージデバイスにアクセスする分散方式で機能する。Ｚｅｔｅｒａ ＣｏｒｐｏｒａｔｉｏｎのＺ−ＳＡＮ（商標）テクノロジーは、クライアントが物理ストレージデバイスと直接対話できるようにした、そのような１つの実施態様である。

仮想ストレージシステムは、クライアントが、データストレージに堅固なアクセスができるようにしなければならない。システムは、システムが動的に変更される場合に、複数のクライアントがシステムへのアクセスを共用できれば、堅固であると考えることができる。さらに、システムは、クライアントが相互に独立して機能できるようにし、また、物理ストレージデバイスも相互に独立して機能できるようにしなければならない。独立したクライアントは、他のクライアントからの情報を必要とせずにシステム内の変更に適応できるとき、最も効率がよい。例えば、仮想ストレージシステム内の論理ボリュームを共用する２つのクライアントは、その論理ボリュームの異なるビューを持つことができる。往々にして、一方のクライアントは、論理ボリュームに関連付けられた、ある物理ストレージデバイスを見ることができるのに、他方のクライアントは同じ物理デバイスを見ることができないことがある。しかし、それでも、その論理ボリュームは両方のクライアントに有用であることがありえる。論理ボリュームが、それぞれ異なる物理デバイス上に冗長なデータを有している場合、両方のクライアントが読み取りアクセスの目的で論理ボリュームにアクセスできても、書き込みアクセスは、データが非同期にならないように制限が必要な場合がある。

クライアントは、仮想ストレージシステムの要素を発見できる機能を有していなければならない。この場合の要素には、論理デバイス、物理ストレージデバイス、パーティション、プロキシ、サービス、または仮想ストレージシステムの他の構成要素がある。仮想ストレージシステムの要素の発見については、引用により本明細書に全体が組み込まれる、「Ｄｉｓａｇｇｒｅｇａｔｅｄ Ｒｅｓｏｕｒｃｅｓ ａｎｄ Ａｃｃｅｓｓ Ｍｅｔｈｏｄｓ」という名称で２００５年８月１６日に出願された共同所有の米国特許出願第１１／２０５，８９５号明細書で説明されている。この引用された出願は、仮想ストレージシステムを含めて、論理デバイスのマップを発見する態様を説明している。仮想ストレージシステムの変更に応じて、マップも変更できる。仮想ストレージシステムのマップの発見に関連して、仮想ストレージシステムは、動的環境、特に、クライアントまたはデバイスが通知なしに現れる、または消えることができる環境でストレージコマンドを生成するための方法も提供しなければならない。仮想ストレージシステムまたは論理ボリュームが変更されるとき、変更は仮想ストレージシステムのボリュームレベルのビューより下で行われるので、論理ボリュームに関連付けられた高水準のストレージコマンドは必ずしも変更されるわけではない。しかし、物理デバイスを対象にする低水準のストレージコマンドは、システムの更新を反映するために変更される可能性が高い。これらの問題および他の問題は、想定された動的環境で対処される必要がある。

ストレージコマンドを生成するための好ましい解決法は、以下の機能を提供しなければならない。
・ コマンドの生成は、共用ストレージエリアの一部分の可視性を一部のクライアントは解放するが他のクライアントは解放しない、シナリオを扱わなければならない。
・ クライアントは、データの一部をミラーリングする物理デバイスが失われている場合のように、データセットを保管した論理ボリュームの一部分が欠落していても、整合性のあるデータセットにアクセスできなければならない。
・ システムは、ストレージサービスを管理するための追加機器の導入を必要としないで、より多くのクライアントまたはストレージデバイスを有する、より大きい展開に規模を拡大しなければならない。
・ コマンドは、ＲＡＩＤグループを含めて、論理ボリュームに関連付けられた異質なストレージグループタイプの混在をサポートするような形で生成されなければならない。
・ コマンド生成システムは、コマンド移送から独立し、標準プロトコルまたはプロプラエタリプロトコルを使用する環境を含めて、複数のストレージ環境で作動しなければならない。

動的環境での論理ボリュームの変更への対応を含めて、仮想化ストレージの様々な態様に対処している他の解決法もある。例えば、「Ｄｉｓｔｒｉｂｕｔｅｄ ｎｅｔｗｏｒｋ ｓｙｓｔｅｍ ｗｉｔｈ ｖｉｒｔｕａｌｉｚａｔｉｏｎ」という名称の米国特許第６，７３２，１７１号明細書および、やはり、「Ｄｉｓｔｒｉｂｕｔｅｄ ｎｅｔｗｏｒｋ ｓｙｓｔｅｍ ｗｉｔｈ ｖｉｒｔｕａｌｉｚａｔｉｏｎ」という名称の米国特許公開第２００５／００１４４１９９号明細書は、ストレージサーバおよび管理サーバに保管されたストレージ構成識別子を使用したストレージ仮想化を教示している。その識別子は、アプリケーションクライアントとストレージシステム間で交換される、ストレージシステム内のストレージ構成または割り振りの変更がいつ行われたかを示すタイムスタンプである。そのため、アプリケーションクライアントは、識別子が変更されると、ストレージシステムの、そのクライアントのビューを更新することができる。しかし、これらの参考文献は、ストレージシステムが、ストレージシステム内のストレージエリアのタイプに関連付けられたコマンドハンドラを用いてコマンドを生成する方法は教示していない。

上記の参考文献に加えて、次の参考文献は、様々なストレージ媒体に関連付けられた仮想ストレージシステムのためにマップを作成する多様な取り組みを記載している。すなわち、係属中の米国特許公開第２００５／０２７０８５６号明細書、第２００５／０２４６４０１号明細書、第２００３／０１７２１５７号明細書および第２００３／００２３８１１号明細書、ならびに発行済みの米国特許第６，７７５，６７３号明細書、第６，７７５，６７２号明細書、第６，７７２，１６１号明細書、第６，７３２，２３０号明細書、第５，７５８，０５０号明細書、および第５，１２９，０８８号明細書。これらの参考文献は、その文献が意図されている特定の問題に対処しているが、論理ボリュームを構成するストレージグループタイプに応じて構築される論理ボリュームのマップを使用するストレージコマンドの生成には対処していない。いくつかのケースでは、これらの参考文献はコマンドまたはコマンドセットを説明しているが、それでも、コマンドの生成方法は教示していない。

したがって、仮想化ストレージには、ストレージ環境が変更されるときにストレージコマンドを生成できる方法および装置の必要性が相当に残っている。

米国特許第６，７３２，１７１号明細書 米国特許公開第２００５／００１４４１９９号明細書 米国特許公開第２００５／０２７０８５６号明細書 米国特許公開第２００５／０２４６４０１号明細書 米国特許公開第２００３／０１７２１５７号明細書 米国特許公開第２００３／００２３８１１号明細書 米国特許第６，７７５，６７３号明細書 米国特許第６，７７５，６７２号明細書 米国特許第６，７７２，１６１号明細書 米国特許第６，７３２，２３０号明細書 米国特許第５，７５８，０５０号明細書 米国特許第５，１２９，０８８号明細書 米国特許第１１／１７３７６５号明細書

本発明の主題は、ストレージシステムのためのコマンドを生成するシステムおよび方法に関する。

ストレージシステムは１つまたは複数の論理ボリュームを有しており、論理ボリュームは、第１のストレージデバイスに第１のストレージエリアを有し、第２のストレージデバイスに第２のストレージエリアを有している。一般的には、ストレージエリアはパーティションを有している。方法は、第１または第２のストレージエリアのストレージエリアタイプに関連付けられた情報から論理ボリュームのマップを提供するステップを含む。特に、好ましい実施形態としては、ストレージエリアの第１のタイプが、ストレージエリアの第２のタイプとは異なる実施形態がある。また、方法は、ストレージエリアのタイプに応じてコマンドハンドラを論理ボリュームのマップに組み込むステップも含む。コマンドハンドラは、論理ボリュームを対象にするストレージコマンドをストレージエリアの１つを対象にするストレージコマンドに変換する。他の実施形態は、論理ボリュームが変更されたことの標識が受信されると、論理ボリューム内の変更にマップを更新することにより対応する機能を備えている。コマンドが生成されるとき、一部の実施形態は、マップ内のボリュームアドレスによって参照されるデータアドレスを、ストレージエリアアドレスによって参照されるデータアドレスに変換する。

用語解説
以下は、本明細書内で使用される用語についての説明である。用語は、本発明の主題の様々な態様を暗黙の制限なしに論ずる際に、明瞭さを確保するために提供される。

用語「ストレージグループ」は、あるタイプのストレージ機能を提供する１つまたは複数のストレージエリアのグループを意味し、ストレージエリアは、パーティションまたは関連したパーティションのグループを有する。ストレージ機能としては、ＲＡＩＤ機能、スパニング、パリティの提供、またはデータのアクセスに関連する機能がある。

用語「ストレージコマンド」は、データアクセス関連の、ストレージエリアを対象にするコマンドを意味する。一般的に、ストレージコマンドは、データアドレス、データ要求サイズ、またはそのストレージコマンドに関連付けられたデータを保管するバッファなどを含む、そのコマンドを定義するいくつかのパラメータを有する。他の可能なパラメータとしては、ストレージエリア識別子、実行されるコマンドの標識、またはストレージコマンドの処理時に有用な他の情報がある。好ましい実施形態では、データアドレスは論理ブロックアドレス（ＬＢＡ）である。バッファは、書き込みを行うときにデータを保管するため、または読み取りを行うときにデータを受信するために使用され、少なくともデータ要求サイズを保管できるだけのスペースを有する。バッファは、通常、メモリエリアを指すポインタによって参照される。ストレージエリア識別子は、特定のストレージエリアをアドレスするために使用され、ＩＰアドレスまたは論理ユニット番号（ＬＵＮ）を含むことができる。

本明細書における教示は、ストレージプロダクトまたはストレージ関連のテクノロジーの開発者によって有利に使用できる。開示された、ストレージコマンドを生成する方法は、ストレージシステムの要素が動的に変更される可能性のある仮想環境で機能するストレージプロダクトを作成するために使用できる。

同様の番号は同様の構成要素を表す添付の図面を参照しながら以下の本発明の好ましい実施形態の詳細な説明を読めば、本発明の様々な目的、特徴、態様および利点が、より明らかになろう。

仮想ストレージシステムの実施形態の例を示した図である。 複数のパーティションを有する論理ボリュームの実施形態の例を示した図である。 論理ボリュームがストレージグループをどのように有することができるかを示した図である。 グループタイプの組織化の実施形態の例を示した図である。 ストレージグループデータ構造体の実施形態の例を示した図である。 リンクされたストレージグループのコマンドスタックによって表された論理ボリュームのマップの実施形態の例を示した図である。 ミラーコマンドハンドラによるボリュームレベルコマンドの変換の実施形態の例を示した図である。 ストレージコマンドがどのように１つまたは複数のストライプレベルストレージコマンドに変換されるかの実施形態の例を示した図である。 ストレージコマンドがどのように１つまたは複数のスパンレベルストレージコマンドに変換されるかの実施形態の例を示した図である。 ストレージコマンドがどのように１つまたは複数のパーティションレベルストレージコマンドに変換されるかの実施形態の例を示した図である。

以下の詳細な説明は、本発明の主題の複数の実施例を提示している。具体的な実施例は、主題を明瞭にするために示されているが、伝えられる提示された概念を限定するものではない。読者は、読者自身のできるだけ広い範囲で概念を解釈すべきである。

仮想ストレージシステム
図１は、仮想ストレージシステムの実施形態の例を示している。一部の実施形態では、仮想ストレージシステム１２０は、通信リンク１１５を介して１つまたは複数のストレージデバイス１１０Ａから１１０Ｍにアクセスするクライアント１００Ａから１００Ｎのうちの１つまたは複数を有する。好ましい仮想ストレージシステム１２０は、各クライアント１００Ａから１００Ｎが、論理ボリュームに関連付けられた各ストレージデバイス１１０Ａから１１０Ｍに直接アクセスできるようにする。

クライアント１００Ａから１００Ｎは、ストレージデバイス１１０Ａから１１０Ｍ上のデータストレージにアクセスする、またはそれを利用するホストを表す。クライアント１００Ａは、汎用コンピュータシステムまたは専用コンピューティングデバイスを備えることができる。汎用コンピュータシステムは、オペレーティングシステム、おそらくＷｉｎｄｏｗｓ（登録商標）またはＬｉｎｕｘを稼働させ、好ましくはファイルシステムを備えている。汎用コンピュータシステムは、ストレージスペースへのアクセスを必要とする可能性がある多くの異なるタイプのアプリケーションを実行することができる。専用コンピューティングデバイスとしては、限定されたアプリケーションセットを有する組み込み型システム、例えば、メディアプレイヤ、メディアレコーダ、ゲームコンソール、または他の同様のシステムがある。好ましい実施形態は、ストレージデバイス１１０Ａから１１０Ｍのうちの１つまたは複数にまたがった論理ボリュームをマウントできるファイルシステムを備えた汎用コンピュータシステムを利用する。

ストレージデバイス１１０Ａ、１１０Ｂから１１０Ｍは、１つまたは複数のストレージ媒体へのアクセスを提供する物理的構成要素を表す。ストレージ媒体は、磁気または非磁気であることが可能である。磁気ストレージの例としては、ディスクドライブまたはテープがあり、非磁気媒体の例としては、光システム、フラッシュ、ＲＡＭ、または他のタイプのメモリがある。ストレージデバイス１１０Ａから１１０Ｍは、異質なストレージデバイスの混在である必要はないが、多数の異なるタイプのストレージデバイスを備えることができる。好ましい実施形態では、ストレージデバイス１１０Ａから１１０Ｍは、ディスクドライブ上でデータストレージを提供する専用ストレージデバイスである。専用ストレージデバイスとしては、ラックマウントシステム、デスクトップエンクロージャ、または他のタイプのエンクロージャがある。好ましいエンクロージャは、複数のディスクドライブのサポート、例えば、２台、４台、８台、１６台、またはそれより多いディスクドライブをサポートするサポートを提供する。一部の実施形態では、ストレージデバイス１１０Ａは、ディスクがクライアント１００Ａ内に組み込まれたディスクドライブそのものを表す。さらに、クライアント１００Ａは、それのストレージ媒体へのアクセスを例えばクライアント１００Ｎに提供する場合、ストレージデバイスを表すことができる。

通信リンク１１５は、通信上、クライアント１００Ａから１００Ｎをストレージデバイス１１０Ａから１１０Ｍに結合する。好ましい実施形態では、通信リンク１１５は、イーサネット（登録商標）を介してデータグラムが交換されるインターネットワーキングプロトコル（ＩＰ）ネットワークを利用する。しかし、通信リンク１１５には他の実施形態も可能である。通信リンク１１５は、クライアント１００Ａ内の内部リンク、またはクライアント１００Ａに関係のある外部リンクであってもよい。内部リンクとは、ＡＴＡ、ＳＡＴＡ、ＳＡＳ、ＳＣＳＩ、ＰＣＩまたは他のバスなど、ストレージデバイスとのインターフェースのことである。外部リンクは、有線または無線リンクを含むことができる。有線リンクの例としては、イーサネット（登録商標）、ＵＳＢ、Ｆｉｂｒｅ Ｃｈａｎｎｅｌ（ファイバチャネル）、Ｆｉｒｅｗｉｒｅ（ファイヤワイヤ）、シリアルリンクまたは他の有線通信システムがある。無線リンクの例としては、Ｂｌｕｅｔｏｏｔｈ、無線ＵＳＢ、８０２．１１、ＩｒＤＡ、または他の非物理リンクがある。

仮想ストレージシステム１２０の好ましい実施形態は、Ｚｅｔｅｒａ（商標）ＣｏｒｐｏｒａｔｉｏｎのＺ−ＳＡＮ（商標）テクノロジーを利用する。Ｚ−ＳＡＮテクノロジーは、クライアント１００Ａから１００Ｎのそれぞれが、ストレージコマンドを転送するために、ＵＤＰベースのストレージプロトコルで各ストレージデバイス１１０Ａから１１０Ｍと通信するＩＰベースのストレージエリアネットワーク（ＳＡＮ）環境に備えている。Ｚ−ＳＡＮテクノロジーは、ストレージデバイス内の各パーティションにＩＰアドレスを割り当てる。その結果、クライアントは、追加パーティション識別情報を必要としないで各パーティションと直接に通信できる。クライアントは各パーティションからの情報を集約し、その情報を使用して、それらのパーティションを含む論理ボリュームのマップを形成する。好ましい実施形態はストレージコマンドを移送するためにブロックレベルストレージプロトコルを使用するが、本発明の主題は移送プロトコルから独立して稼働する。したがって、本発明の主題は、標準に基づいたｉＳＣＳＩ、ｉＦＣＰ、ＦＣＩＰなどの他のストレージプロトコル、またはＡＴＡ、ＳＡＴＡ、ＳＡＳ、ＳＣＳＩなどの低水準のプロトコルまたはインターフェース、または他のストレージデバイスプロトコルでも同じように十分に稼働する。さらに、開示された手法は、ＮＦＳ、ＣＩＦＳなどのファイルシステムレベルストレージプロトコル、または他のファイル指向プロトコルでも稼働することが想定されている。

仮想ストレージシステム１２０では、クライアント１００Ａから１００Ｎは、多くの場合、論理ボリュームを、論理ボリュームがローカルに接続されたストレージエリアのように見えるようにマウントする。例えば、クライアント１００ＡはＣＩＦＳプロトコルをサポートすることができて、ディスクをストレージデバイス１１０Ｂにマウントすることができる。論理ボリュームとは、ストレージデバイス１１０Ａから１１０Ｍのうちの１つまたは複数に存在する１つまたは複数のストレージエリアの仮想の表現を表している。本明細書のコンテキストでは、用語「パーティション」は、ストレージデバイス内のストレージエリアを意味する。例えば、パーティションは、ハードディスクドライブの単一の一部分（ｐｏｒｔｉｏｎ）であってよいが、エクステントは、ディスクドライブの容量の一部分（ｆｒａｃｔｉｏｎ）である。あるいは、パーティションは、複数のディスクドライブを収容するシャーシ内の２つ以上のディスクにまたがったストレージエリアを表すこともできる。パーティションは、プロキシによって提示されるストレージエリアを表し、ストレージエリアは複数のリモートパーティションを含むことが想定されている。シャーシまたはプロキシは、集約ストレージエリアを単一のストレージエリアとして見せかける。

論理ボリューム
図２は、複数のパーティションを有する論理ボリュームの実施形態の例を示している。論理ボリューム２３０は、パーティション２２０Ａから２２０Ｍを有し、パーティションは、ストレージデバイス２１０Ａから２１０Ｍ間に広がっている。好ましくは、論理ボリューム２３０は、パーティション２２０Ａから２２０Ｍ上に広がったゼロから最大値までのＬＢＡのエクステントを表す。一部の実施形態では、ＬＢＡは４８ビット値で表される。しかし、他のＬＢＡサイズも想定されている。パーティション２２０Ａは、ストレージデバイス２１０Ａが、論理ボリューム２３０に加わっている単一のストレージエリアを有している例を示している。パーティション２２０Ｂおよび２２０Ｃは、ストレージデバイス２１０Ｂが、論理ボリューム２３０に属する２つ以上のストレージエリアをどのように備えることができるかを示す例を挙げている。さらに、パーティション２２０Ｍは、ストレージデバイス２１０Ｍ全体が論理ボリューム２３０のストレージエリアになれることを示している。

示された論理ボリューム２３０はパーティション２２０Ａから２２０Ｍにわたって線形スパンを示しているが、論理ボリュームを構成するパーティションから他のさらに複雑な構造体が形成できる。好ましい実施形態では、論理ボリューム２３０は、ミラーリング、ストライピング、スパニング、パリティ、またはＲＡＩＤ機能を提供する構造体など、複数の異なるタイプのストレージ構造体を有する。各タイプのストレージ構造体は、パーティションのグループを有する。したがって、論理ボリューム２３０はストレージグループのグループであると考えることができ、ストレージグループは、論理ボリューム２３０を管理するための１組の共通のルールをシステムに提供するように組織化される。

ストレージグループ
図３は、論理ボリュームがストレージグループをどのように有することができるかを示している。論理ボリューム３００は１つまたは複数のストレージグループを有しており、ストレージグループは最終的に１つまたは複数のパーティションを有する。好ましい実施形態では、ストレージグループは１つまたは複数のメンバを有し、各メンバはストレージグループでもある。例えば、グループ３１０Ａは２つのメンバを有している。グループ３１０Ａの第１のメンバはグループ３１０Ｃであり、グループ３１０Ａの第２のメンバはパーティション３２０である。パーティション３２０は、実質的にはストレージデバイス上のパーティションの特性を体現する単一のメンバを有するストレージグループを表す。図示されているように、論理ボリュームグループ３００は、グループ３１０Ａ、３１０Ｂおよびパーティション３２０を含む３つのメンバがある。グループ３１０Ｂは、グループ３１０Ｄおよびパーティション３２０を有する。

好ましくは、パーティション３２０は、ストレージグループの最小の表現であるという意味で要素的グループを表す。ストレージグループはすべて、クライアントがストレージデバイス上のストレージ媒体にアクセスできるようにするために、最終的に少なくとも１つのパーティションを有していなければならない。一実施形態では、パーティション３２０は、クライアントのメモリに保管されているデータ構造体で表すことができ、この場合のデータ構造体は、ストレージデバイス上のパーティションに関連した情報を有する。例えば、データ構造体は、好ましくは、パーティションをアドレスするために使用されるパーティション識別子、パーティションが期待するデータ転送サイズ、パーティションに関連付けられた属性、またはパーティションのアクセス時に有用な他の情報を有する。好ましい実施形態では、パーティション識別子は、クライアントに関係のある、ＩＰアドレス（ＩＰｖ４またはＩＰｖ６）またはＬＵＮなどの外部アドレスを含む。しかし、パーティション識別子は、パーティションがクライアント内でアクセスされる内部アドレスを含むことも想定されている。ＳＣＳＩ ＩＤは、内部アドレスを表すこともできる。

ストレージグループ：グループタイプ
好ましくは、ストレージグループは、それらが論理ボリューム内で提供するストレージ機能に応じて分類される。タイプ別のストレージグループを組織化すると、仮想ストレージシステムの要素によって理解される共通のルールシステムをすべてのクライアントがデータに整合的にアクセスできるように確立するのに役立つ。各グループタイプはストレージコマンドを別のグループタイプとは独立して処理できるので、ルールは、論理ボリューム用のストレージコマンドを生成するときにクライアントに役立つ。好ましいストレージグループタイプとしては、ＲＡＩＤグループタイプまたは非ＲＡＩＤグループタイプがある。ＲＡＩＤグループタイプには、ストレージグループに関連付けられたストレージデバイスに保管されたデータを保護するために何らかの形の冗長性が利用されるストレージグループがある。ＲＡＩＤグループタイプの例としては、ミラーグループ、パリティグループ、Ｚ−ＲＡＩＤグループ、または他の冗長な構成がある。非ＲＡＩＤグループタイプの例としては、スパングループ、ストライプグループ、またはパーティショングループがある。

ストレージデバイスの当業者は、「Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｉｓｋｓ」を表す用語ＲＡＩＤの使い方は理解されよう。ストライピングは、多くの場合、ＲＡＩＤレベル０と分類されるが、ストライピングは冗長な情報を運ばないので、本明細書では、非ＲＡＩＤタイプと分類されている。ＲＡＩＤは、多くの場合、ディスクレベルのストレージ構造体に関連していることにも留意すべきである。本明細書の目的上、ＲＡＩＤ機能はパーティションレベルで適用される。ミラーグループは、ミラーグループの各メンバが他のグループメンバ上にデータの複製を有するメンバを含むストレージグループを表す。言い換えれば、ミラーグループの各メンバは、論理ボリュームのＬＢＡのエクステントの複製を有する。ストライプグループは、個々のストライプ化要素であるメンバを含むストレージグループを表す。パリティグループは、パリティ情報を有するメンバを含むストレージグループを表す。パリティグループは、ストライプグループの変形として体現される。Ｚ−ＲＡＩＤグループは、引用により本明細書に全体が組み込まれる、「Ｔｏｐｏｌｏｇｙ Ｉｎｄｅｐｅｎｄｅｎｔ Ｓｔｏｒａｇｅ Ａｒｒａｙｓ ａｎｄ Ｍｅｔｈｏｄｓ」という名称の共同所有の米国特許出願第１１／１７３，７６５号明細書で説明されているスタッガ式ミラー化要素を形成するメンバを含むストレージループを表す。パーティショングループは、前に説明されているように、単に、パーティションに関する情報を含む要素的グループである。アーカイブグループ、バックアップグループ、据え置きミラーグループ、ＱｏＳグループ、または追加ストレージ機能を提供できる他のストレージグループを含むすべてのストレージグループタイプが想定されている。

ストレージグループ：グループタイプ組織化
図４は、グループタイプの組織化の実施形態の例を示している。グループは、グループが提供する機能に応じて異なるタイプに分類できるが、すべてのクライアントが動作するときに従う、およびすべてのパーティションがストレージデバイス上にインスタンス化されるときに従う１組の共通のルールを確立することにより、ストレージコマンドの生成を容易にするようにストレージグループタイプを組織化することも好ましい。特に好ましい組織化は、ストレージグループタイプの階層を含む。図４に提示された実施例は、明瞭にするために示されており、ミラー、ストライプ、スパン、およびパーティションに焦点を合わせている。しかし、概念は、追加のストレージグループタイプを扱うようにも拡大できる。この実施例では、ミラーグループ４００は、論理的に、階層の最高レベルに置かれている。ストレージシステム内の各論理ボリュームは、１つまたは複数のメンバを有するミラーグループを含むことができる。ミラーグループ４００の各メンバは、ミラータイプ以外の別の下位タイプのグループでもよい。さらに、ミラーグループ４００の各メンバは、各メンバは論理ボリュームのインスタンスを表すという意味で論理ボリュームの複製を表す。ストライプグループ４１０はそのデータをスパングループ４２０Ｂにミラーリングし、スパングループ４２０Ｂも、そのデータをパーティショングループ４３０Ｆにミラーリングする。これは、ミラーグループ４００などのミラーグループは、タイプがストライプグループタイプ、スパングループタイプ、またはこの特定の実施形態のグループ組織化用のパーティションタイプであるかどうかに関わらず、下位タイプの他のグループを含むことができることを表している。

ミラーグループを含む論理ボリュームにストレージコマンドが出されると、そのストレージコマンドは、ミラーグループの各メンバに対して複製される。例えば、ボリュームレベルストレージコマンドが、ミラーグループ４００によって表される論理ボリュームに出されると、そのボリュームレベルストレージコマンドは、そのグループの各メンバに対して複製される。すなわち、ストライプグループ４１０に対して１回、スパングループ４２０Ｂに対して１回、パーティション４３０Ｆに対して１回である。この意味で、ミラーグループは、単一のストレージコマンドを複数の複製ストレージコマンドに変換する。

例のストレージグループタイプ階層内で次に高いレベルは、ストライプグループ４１０で示されているストライプタイプである。ストライプグループは、スパングループ４２０Ａおよびパーティション４３０Ｃによって示されているように、スパングループまたはパーティションである２つ以上のメンバを含む。ストライプグループ４１０の各メンバは、完全なストライプのストライプ化要素を表す。したがって、データが、ストライプグループ４１０に関連付けられたパーティションに保管されるとき、データは、ストライプ要素０を表すスパングループ４２０Ａ全体にストライピングされ、次にストライプ要素１であるパーティション４３０Ｃにストライピングされる。

ストライプグループは、そのストライプグループの特性を定義する１組のパラメータを有する。パラメータには、次のメンバに進む前に各メンバに書き込まれるデータブロックの数を表すストライプブロックサイズがある。ストレージコマンドがストライプグループに出されると、そのコマンドは、グループの各メンバを対象にする１つまたは複数のストライプレベルコマンドに変換される。ストライプコマンドは、従来のストライプ化ＲＡＩＤシステムで行われていたように、ストライプブロックサイズに関してモジュロ算術によってデータアクセスサイズを計算することにより、データアクセスがグループのストライプ構造体と揃うようにしている。しかし、データアクセスはディスクレベルではなくグループまたはパーティションレベルで実行される。ストライプ化グループの各メンバは、均一のストライピングを得るために同じ容量を備える。

階層の例内の３番目のレベルは、スパングループ４２０Ａおよび４２０Ｂに示されているスパンタイプである。スパングループは２つ以上のメンバを結合して、そのスパングループ用のゼロから最大値までのＬＢＡの範囲によって表される単一の線形論理ストレージエリアにする。例えば、スパングループ４２０Ａは、パーティション４３０Ａによって示された第１の部分およびパーティション４３０Ｂによって示された第２の部分を含み、それぞれ、スパングループ４２０Ａのスパン要素０およびスパン要素１を表す。同様に、スパングループ４２０Ｂは、パーティション４３０Ｄおよびパーティション４３０Ｅを含み、単一の論理ストレージエリアを形成する。

スパングループは、パーティション間をつなぐために、ストレージコマンド内のデータはどこで分離されるべきかに関する情報を含む。スパングループがストレージコマンドを受信すると、ストレージコマンドのデータおよびデータサイズが検査されて、データのアクセスには、そのコマンドはスパングループの２つ以上のメンバに出される必要があるかが調べられる。必要な場合、そのコマンドは、データアクセスがメンバの境界に確実に揃うような形で１つまたは複数のスパンコマンドに変換される。

パーティショングループタイプは、階層の例の最下位レベルにある。パーティション４３０Ａから４３０Ｆは、それぞれ、１つのメンバを有するグループであって、その１つのメンバ要素は、ストレージデバイス上の個々のパーティションを表す。パーティションのそれぞれは一律のサイズである必要はなく、むしろ、互いに関係のある任意のサイズであってよいことに留意されたい。

好ましい実施形態は、ミラー、ストライプ、スパンおよびパーティションを含む階層を設定しているが、他の階層も可能であることに留意されたい。例えば、ミラータイプは、ボリュームレベルでのミラーリングとは違って、各パーティションが個別にミラーリングされるようにパーティションの下に配置することもできる。あるいは、ストライプおよびスパンは、階層内でレベルを切り替えることもできる。

ストレージグループ：共通ルール
論理ボリューム内のストレージグループの組織化上の構成を形成すると、ストレージコマンドを処理するための１組のルールの土台になる。もう一度、図４の階層の例を参照すると、ボリュームレベルコマンドは、ミラーレベルにストレージグループがあれば、最初はミラーレベルで処理される。ミラーレベルの処理は、ストレージコマンドを生成すること、およびそのストレージコマンドを下位レベルに渡すことを含む。ストライプグループのメンバがある場合、データが必ずそのストライプグループに関連付けられたストライピングルールに従ってアクセスされるようにするために、ストレージコマンドはストライプレベルで処理される。例えば、データは、ストライプブロックサイズおよびストライプグループのメンバの数に基づいてモジュロ算術を用いてアクセスされる。ストライプレベルの処理も、ストレージコマンドを生成すること、およびそのストレージコマンドを下位レベルに渡すことを含む。スパングループがある場合、ストレージコマンドはスパンレベルで処理され、スパンレベルでは、データアクセスは、スパンメンバの境界に揃えられる。最後に、パーティションレベルコマンドは、データアクセスがパーティションの特性に揃うように処理される。例えば、パーティションに適切な転送サイズを有するコマンドが形成される。ストレージコマンドの処理については、本明細書で、より詳しく後述する。

ストレージグループ：グループデータ構造体
一部の実施形態では、ストレージグループは、グループ間にリンクを提供するグループデータ構造体によって表される。好ましくは、ストレージグループは、親子関係またはピア関係を形成するために互いにリンクされる。親グループは、各メンバが親の子と考えられる１つまたは複数のメンバを有するグループを表す。同じ親のそれぞれの子は、他の子達のピアである。好ましい実施形態では、親グループは、グループ階層内で子より高いレベルにある。しかし、ピアは、それぞれについて同じレベルまたは下位レベルであってよい。例えば、ミラーグループは３つの子を有することができる。それぞれの子は、論理ボリュームのインスタンスである。子達は、ストライプ化グループ、スパングループ、またはパーティショングループを任意に組み合わせて有することができるが、ミラーグループ内で子達のそれぞれは、ピアと考えられる。

好ましい実施形態では、グループデータ構造体は、他のグループおよび関数ポインタとのリンクを表す汎用データ構造体を有する。汎用構造体は、特定のグループタイプ、すなわち、ミラータイプ、ストライプタイプ、スパンタイプ、または他のストレージグループタイプに関する情報を有する追加データ構造体に組み込まれる。この手法は、組み込み型システム用のＣでの実施に役立つ。しかし、コンピュータプログラミングの当業者は、グループデータ構造体を形成するには多くの代替手法があることが理解できよう。オブジェクト指向の手法を含めて、すべての代替手法が想定されている。

図５は、ストレージグループデータ構造体の実施形態の例を示している。ストレージグループは、そのストレージグループに関連付けられたストレージグループタイプを表す特性を定義するグループパラメータ群５１０を含むグループデータ構造体５００によって表すことができる。グループパラメータ群５１０は、グループのタイプ、またはそのデータ構造体が表す特定のグループの特性に応じて異なる。さらに、データ構造体５００は、いくつかのポインタも有している。グループポインタは、ストレージコマンドの処理を容易にするためにグループのリンクリストを形成する。好ましいグループポインタには、オプションの親グループポインタ５２０またはオプションの直前ピアグループポインタ５３０がある。親グループポインタ５２０は、現行グループを、そのストレージグループがメンバになっている親グループにリンクする。そのストレージグループが論理ボリューム内の最高レベルのグループである場合、親ポインタ５２０は値ＮＵＬＬを持つ。親グループは、好ましい実施形態では、グループ階層内の上位レベルのストレージグループを表す。例えば、ストレージグループがパーティションであり、ストライプグループのメンバである場合、親ポインタ５２０はストライプグループに戻ってリンクする。直前ピアポインタ５３０は、ストレージグループのピアであるグループに戻ってリンクする。例えば、現行グループがパーティションであり、ストライプ化グループの３番目のメンバである場合、直前ピアポインタ５３０は、ストライプ化グループの２番目のメンバに戻ってリンクする。親ポインタ５２０および直前ピアポインタ５３０は、好ましい実施形態ではオプションである。

特に好ましいポインタとしては、ピアグループポインタ５４０、子グループポインタ５５０、または関数ポインタ５６０がある。ピアポインタ５４０は、ストレージグループを同じ親グループ内の次のメンバにリンクする。子ポインタ５５０は、ストレージグループの最初のメンバを指す。ピアポインタ５４０および子ポインタ５５０を提供することにより、コマンドの処理時、グループのリンク化リストがトラバースできる。

データ構造体５００内のグループポインタのそれぞれは、別のグループを指すのとは違って、値ＮＵＬＬも有することができる。値ＮＵＬＬは、リンクのチェーンの終わりが検出されたことを表す。例えば、ストレージグループに関連付けられたストレージコマンドの処理中、ストレージグループのそれぞれの子は、ＮＵＬＬが検出されるまで、ピアポインタ５４０リンクをトラバースすることにより調べられる。ＮＵＬＬは、ストレージグループのすべての子達の処理が終了したことを表す。

コンピュータプログラミングの当業者は、ストレージグループ間の関係を設定する可能な実施形態は多数あることが理解できよう。例えば、ピアリンクリストの代わりにピアレベルストレージグループのアレイが使用できる。ストレージグループの関係を形成するすべての実施形態が想定されている。

関数ポインタ５６０は、ストレージグループのタイプ用のストレージコマンドを処理する、ストレージグループタイプ固有のコマンドハンドラを指すポインタを表す。好ましい実施形態では、ストレージグループの各タイプは、少なくとも１つの関連付けられたコマンドハンドラを有する。コマンドハンドラ関数は、好ましくは、ストレージコマンドを処理するためにグループパラメータ５１０を使用し、それによって、そのグループ用のストレージコマンドを生成する。さらに、コマンドハンドラは、実行されるとき、ストレージグループの特定のタイプ用のルールに従ってストレージコマンドを変換し、子メンバのそれぞれに対してコマンドハンドラによって処理される１つまたは複数のストレージコマンドを生成する。

各グループは、区画から、単一の論理ボリュームを形成する複数のミラーまでの論理ストレージエリアを表す。好ましい実施形態は、各論理ストレージエリア内のデータに、そのストレージエリアに関連付けられたデータアドレッシング方式によってアクセスする。好ましい方式は、そのストレージエリア内でデータの各ブロックが固有にアドレスされるブロックレベルのアドレッシングを使用することである。好ましい実施形態は、５１２バイトのサイズを有する各データブロックをアドレスするためにＬＢＡを使用する。ストレージグループタイプのコマンドハンドラは、コマンドのデータ、およびコマンドのデータに関連付けられたＬＢＡに対する変換機能と考えることができる。また、好ましい実施形態では、ストレージグループによって表される各ストレージエリアは、範囲がゼロから最大値までのＬＢＡのエクステントを有する。各ストレージグループのＬＢＡのエクステントは、パラメータ群５１０にも保管される。各ストレージグループをＬＢＡの個別のエクステントと定義することにより、各コマンドハンドラは、親グループから独立した形でストレージコマンドを処理することができる。この独立というレベルは、ストレージグループまたはコマンドハンドラを所望どおりに互いにリンクして論理ボリュームを形成する能力を与える。

コマンドハンドラによって提供される機能は、ストレージグループのタイプに関連付けられた機能を表す。しかし、これは、コマンドハンドラの動作をストレージグループタイプの機能のみに限定するのではない。コマンドハンドラは、ストレージコマンドの処理を助けるため、または他の機能を提供するために追加の命令を実行することができる。例えば、ＲＡＩＤ５システム用のパリティグループコマンドハンドラは、そのグループメンバに読み取り・変更・書き込み動作を実行し、ストライプグループコマンドハンドラと同様に機能する命令を含む。そのような命令は、パリティグループのメンバに対してＸＯＲパリティを計算することを含む。さらに、追加命令は、ＯＯＢ（ｏｕｔ ｏｆ ｂａｎｄ）管理、仮想ストレージシステムのモニタ、エラーチェック、リモート関数の呼び出しもしくは実行、または任意の他の機能を組み込むことができる。

ストレージグループ：コマンドスタック
リンクされたストレージグループが、ストレージグループタイプに関連付けられたコマンドハンドラに結合されることは、ストレージコマンドを生成するためのコマンドスタックを確立する備えとなる。コマンドスタックは、データ構造体が関数へのポインタを含むデータ構造体コンストラクトを表す。関数ポインタを用いて関数を呼び出すと、ポインタを変更することにより、実行中に関数の再割り当てが可能になり、オンザフライで構成できる動的呼び出しチェーンが提供できる。コマンドハンドラ手法を用いると、ホストは、他の論理ボリュームを処理するための追加オーバーヘッドを発生させずに論理ボリューム固有のコマンドスタックを作成することができる。言い換えれば、システム内の各論理ボリュームは、ボリュームのトポロジーを反映するコマンドスタックを有する。しかし、どんなトポロジーが使われても、各コマンドスタックは、同じ１組のコマンドハンドラにアクセスする。例えば、ストレージグループの各タイプ（ミラー、ストライプ、スパンまたはパーティション）用の４つのコマンドハンドラがある場合、ストレージグループは、ストレージグループのグループのコンテキストをストレージグループのデータ構造体パラメータに入れて運ぶので、システムはその４つのコマンドハンドラが必要なだけである。好ましい実施形態では、クライアントが論理ボリュームを発見すると、クライアントは、階層のルールに従って、ストレージグループのリンク化リストをまとめて作成する。ストレージグループがリンクされて、まとめられると、各ストレージグループ用のパラメータおよびコマンドハンドラを有するリンク化構造体は、論理ボリュームのマップになる。さらに、リンク化構造体は、論理ボリュームのコマンドスタックを表す。すると、クライアントは、同じコマンドハンドラを再使用しながら追加論理ボリュームを発見することができる。追加論理ボリュームは、追加論理ボリューム自身のストレージグループのリンク化構造体によって、追加論理ボリュームのマップ情報を運ぶからである。

論理ボリュームの変更が発見された場合、リンク化構造体は速やかに更新できることに注意されたい。例えば、追加スパンが追加された場合、追加ストレージグループが構造体の適切なスポットにリンクされ、それにより、論理ボリュームのアクセスをほとんど混乱させることなく論理ボリュームを更新する。

代替リンク
ストレージグループ構造体内では、他のリンクも想定されている。一実施形態では、特にミラーグループメンバがストライプグループを含む場合、ミラーグループメンバを相互リンクするために代替リンクが提供される。そのような代替リンクでは、ストレージ構造体と同様に、ＲＡＩＤ １０を確立することができる。一部の実施形態では、要求されたデータへのアクセスが可能な代替ストレージグループを検出するためにストライプ化グループメンバに必ずアクセスできるとは限らない場合、代替リンクをトラバースするためにＲＡＩＤ １０コマンドハンドラも提供されている。代替リンクは、パーティションレベルのミラーリングを行うためにパーティションレベルでも機能できる。

論理ボリュームのマップ：コマンドスタック
好ましい実施形態では、論理ボリュームのコマンドスタックは入力として高水準のストレージコマンドを受け入れる。コマンドスタックはストレージコマンドを処理して、そのストレージコマンドを最高レベルのコマンドハンドラに渡す。各コマンドハンドラは、ストレージコマンドを階層内の各レベルに合った１つまたは複数のストレージコマンドに変換する。次に、これらのストレージコマンドのそれぞれが、パーティションレベルの最下部に到達するまで、次のレベルのコマンドハンドラに渡される。パーティションレベルコマンドハンドラはパーティションレベルストレージコマンドを生成し、それらを、後でパッケージングするため、またはパーティションに送信するためにキューに入れる。

図６は、リンクされたストレージグループのコマンドスタックによって表された論理ボリュームのマップの実施形態の例を示している。この具体的な例は、明瞭にするために、リンクされたストレージグループおよびコマンドハンドラの概念がどのように組み合わされてコマンドスタックによって表されるような論理ボリュームのマップを形成するかを示すように構成されている。この例は、包括的なものではない。しかし、概念は、より大きい、複雑で異質な論理ボリュームに普遍的に適用できる。論理ボリュームはストレージグループにマッピングされ、ストレージグループはパーティションにマッピングされる。ストレージコマンド生成プロセスの各ステップにおいて、ストレージコマンドは、データをチャンク（ｃｈｕｎｋ）に分割しながら高水準データアドレスを低水準データアドレスに変換することにより変換されると考えることができる。例えば、論理ボリュームのＬＢＡはストレージグループのＬＢＡに変換され、ストレージグループのＬＢＡは最終的にパーティションのＬＢＡに変換される。好ましい実施形態では、次に、ストレージデバイスがパーティションのＬＢＡをそのストレージデバイスのストレージ媒体内のデータアドレスに変換する。

論理ボリュームのマップ：ミラーレベル
この実施例では、論理ボリュームはミラーグループ６００によって表されている。この実施例では、論理ボリュームに関連付けられた２つのミラーがある。最初のミラーはストライプグループ６２０によって表され、２番目のミラーはパーティショングループ６８０によって表されている。様々なストレージグループのパラメータ、ストレージグループのグループのリンク、およびストレージグループのコマンドハンドラを指すストレージグループのポインタを保管するためにグループデータ構造体が使用される。ミラーグループ６００は、ミラーコマンドハンドラ、ピアポインタ６０５および子ポインタ６０７を指す関数ポインタ６０３を含む。ピアポインタ６０５は、このミラーグループに関連付けられたピアはないことを示す値ＮＵＬＬを有する。子ポインタ６０７はストライプグループ６２０を指し、ストライプグループ６２０は、ミラーグループ６００のメンバを表すリンクのチェーンを開始する。

システムが論理ボリュームのデータにアクセスする場合、システムは、ボリュームレベルコマンドを出し、関数ポインタ６０３によってミラーコマンドハンドラを呼び出す。コマンドが読み取りコマンドの場合、そのボリュームコマンドは、データで満杯のバッファではなく、受信バッファへのポインタを有することができる。好ましい実施形態では、ミラーコマンドハンドラは、そのコマンドを処理するためにミラーグループ６００のパラメータを使用する。ミラーコマンドハンドラは、ボリュームコマンドへのポインタをミラーグループの子達のそれぞれのコマンドハンドラに渡すことにより、ボリュームレベルコマンドを複写する。例えば、ミラーコマンドハンドラは、まず、ストライプグループ６２０の関数ポインタ６２３によってストライプコマンドハンドラを呼び出し、ボリュームレベルコマンドをストライプコマンドハンドラに渡す。ストライプコマンドハンドラが戻ると、ミラーコマンドハンドラは、パーティショングループ６８０の関数ポインタ６８３によってパーティションコマンドハンドラを呼び出し、この場合も、ボリュームレベルコマンドをパーティションコマンドハンドラに渡す。パーティションハンドラは、そのボリュームレベルコマンドを処理し、それを１つまたは複数のパーティションレベルコマンドに変換する。このとき、各パーティションレベルコマンドは、パーティションＤとの通信に適した形式になっている。パーティショングループ６８０は、ＮＵＬＬ値を有するピアポインタ６８５によって示されているようにピアチェーン内の最後であり、子ポインタ６８７のＮＵＬＬ値によって示されているように子はない。パーティションコマンドハンドラは、ボリュームレベルコマンドをパーティションレベルコマンドのリンク化リストに変換し、そのパーティションレベルコマンドはパッケージングできる、またはターゲットパーティションに送信できる。

好ましいボリュームレベルコマンドは、ファイルシステムから出される。ファイルシステムは、マルチイニシエータファイルシステムまたは非マルチイニシエータファイルシステムを含むことが想定されている。マルチイニシエータファイルシステムは、データが破壊されることなく、複数のクライアントがストレージデバイス上の同じデータに共用アクセスできるようにする。好ましいマルチイニシエータファイルシステムの例としては、ＤａｔａＰｌｏｗ（商標）Ｓａｎ Ｆｉｌｅ Ｓｙｓｔｅｍ （ＳＦＳ）がある。非マルチイニシエータファイルシステムは、単一クライアントのためのアクセスを提供し、例えば、ＮＴＦＳがある。

論理ボリュームのマップ：ストライプレベル
この実施例では、ストライプグループ６２０はミラーグループ６００の子であり、したがって、論理ボリュームの１つのインスタンスである。ピアポインタ６２５は次のミラーを指し、次のミラーは、この実施例では、パーティショングループ６８０である。この実施形態では、ストライプグループ６２０は２つのストライプ化要素、すなわち、スパングループ６４０およびパーティショングループ６７０を有している。ストライプグループ６２０は、グループデータ構造体を用いてメモリにも保管される。

ストライプコマンドハンドラは、ストライプコマンドハンドラが関数ポインタ６２３によって呼び出された場合、ボリュームレベルコマンドを受信する。ストライプコマンドハンドラは、ボリュームレベルコマンドをストライプグループの子達のそれぞれ用に、ストライプのストライプブロックサイズを用いてボリュームレベルコマンドのＬＢＡを子達のＬＢＡエクステントにマッピングすることにより、１つまたは複数のコマンドに変換する。この実施例では、ストライプコマンドハンドラは、ストライプグループのパラメータ情報を用いてボリュームレベルコマンドのＬＢＡをストライプグループの子グループのそれぞれへのオフセットに変換する。各グループは、好ましい実施形態では、各グループをその親グループから独立させておくために、ゼロから最大値までのＬＢＡのエクステントを有することを思い出されたい。ストライプグループの場合、ストライプコマンドハンドラは、ストライプグループのブロックサイズおよびストライプグループ内のメンバの数に基づいたモジュロ算術を用いることにより、それぞれの子へのオフセットを計算する。オフセットが計算されて、それぞれの子にとって必要な場合にデータがチャンクに分割されると、ストライプコマンドハンドラは、コマンドハンドラ群の中をストライプグループの子達のそれぞれを探してウォーキングを開始する。ストライプコマンドハンドラは、第１の子に第１のストライプレベルストレージコマンドを渡し、第２の子に第２のストライプレベルストレージコマンドを渡すなどする。さらに、ストライプコマンドハンドラは、必要な場合、第１の子にループバックする。この実施例の場合、ストライプコマンドハンドラは、関数ポインタ６４３によってスパンコマンドハンドラを呼び出し、次に、グループ６７０に関連付けられた関数ポインタ６７３によってパーティションコマンドハンドラを呼び出し、必要ならば、グループ６４０に戻ることもある。関数ポインタ６７３は、関数ポインタ６８３と同じパーティションコマンドハンドラを指す。パーティションコマンドハンドラは、パーティションの好ましいデータ転送サイズを含むパーティショングループ６７０のパラメータ情報を用いてストライプレベルコマンドを、ターゲットパーティションに合った適切な転送サイズを有する１つまたは複数のパーティションレベルコマンドに変換する。パーティションレベルコマンドは、送信の準備ができているパーティションレベルコマンドのキューにリンクされる。パーティションレベルコマンドは、実質的には、ストレージデバイス上のターゲットパーティションに提出される準備ができている。通信リンクを介して送信されるパケットまたはデータグラムには、おそらく輻輳回避のために、さらに処理が必要なことがある。

パーティショングループ６７０はスパングループ６４０の最後のメンバであることに留意されたい。ピアポインタ６７５は、ストライプコマンドハンドラに、処理のためのこれ以上の子はいないことを示す値ＮＵＬＬを有している。さらに、パーティショングループ６７０はパーティションＣ、すなわち、要素的メンバを表すので、パーティショングループ６７０には子がない。その結果、子ポインタ６７７は値ＮＵＬＬを有する。したがって、パーティションコマンドハンドラは、それ以上のコマンドハンドラ呼び出しを行わず、ストライプコマンドハンドラによる各呼び出し後にストライプコマンドハンドラに戻る。

論理ボリュームのマップ：スパンレベル
スパングループ６４０はストライプグループ６２０の子であり、ストライプ化グループの単一のストライプ化要素である。スパングループ６４０は、パーティショングループ６５０およびパーティショングループ６６０によって表される２つのパーティションを有する。ミラーグループ６００およびストライプグループ６２０の場合とちょうど同じように、スパングループ６４０は、スパングループ用のパラメータを有するグループデータ構造体としてメモリに保管される。この実施例では、パラメータは、各パーティショングループのエクステント、およびデータアクセスがどこでパーティション間をつなぐべきかの場所を含む。

現在の実施例では、スパンコマンドハンドラがストライプコマンドハンドラから呼び出されたとき、スパンコマンドハンドラはストライプレベルコマンドを受信する。スパンコマンドハンドラはストライプレベルコマンドを、スパングループ６４０のそれぞれの子を対象にした１つまたは複数のスパンレベルコマンドに変換する。変換は、高水準のＬＢＡを子達のＬＢＡエクステントにマッピングすることにより行われる。パーティショングループ６５０は最初の子であり、ピアポインタ６５５によってパーティショングループ６６０にリンクする。パーティショングループ６６０は、ピアポインタ６６５のＮＵＬＬ値によって示されているように、スパングループメンバのうちの最後のメンバである。スパンコマンドハンドラは、高水準コマンドのＬＢＡおよびデータ要求のサイズを子達のＬＢＡエクステントと比較して、必要な場合、データはどこで分割されるべきかを判定する。次に、スパンコマンドハンドラは、関数ポインタ６５３および６６３によって子達のパーティションハンドラの呼び出しを開始する。関数ポインタ６５３および６６３は、関数ポインタ６７３および６８３とも同じパーティションコマンドハンドラを指す。パーティションコマンドハンドラは、前に説明されているように、スパンレベルコマンドをパーティションＡおよびＢ用のパーティションレベルコマンドに変換する。パーティショングループ６５０および６６０は、それらの子ポインタ６５７および６６７がそれぞれＮＵＬＬ値を有しているので、コマンドスタック内の最後のメンバである。パーティションハンドラはパーティションレベルコマンドを、ストレージデバイスに送信されるパーティションレベルコマンド用のキューにリンクし、処理を完了すると、スパンハンドラに戻る。

図６に示された実施例は、コマンドスタックが、最初にパーティションレベルまで降下することにより、ストレージコマンドを処理する実施形態を示している。この降下手法は、パーティションレベルコマンドのキューを形成できるようにし、最小の処理オーバーヘッドを提供する。

図６に示された実施例の場合、パーティションＡ、Ｂ、ＣおよびＤは、論理ボリューム内で異なる機能的保管の役割を果たすので、同一の構造を有している必要はない。しかし、この特定の実施例の場合、パーティションＡ、Ｂ、ＣおよびＤは、互いに関連付けられた容量を有しているべきである。例えば、パーティションＤは、パーティションＡ、ＢおよびＣの結合された容量と同じストレージ容量を有すべきであるが、それは、パーティションＤが論理ボリュームの１つの完全なインスタンスであり、Ａ、ＢおよびＣは、論理ボリュームの別の完全なインスタンスを形成するからである。さらに、パーティションＣは、パーティションＡおよびＢの結合された容量と同じ容量を有すべきであり、それは、パーティションＣが１つのストライプ化要素を表し、結合されたパーティションＡおよびＢは、ストライプ化グループのさらに別のストライプ化要素を表すからである。パーティションＡおよびＢは、それらの結合された容量がパーティションＣと同等である限り、異なる容量であってよい。この実施例は、論理ボリュームが異質なパーティションまたはストレージグループタイプの混在をどのように有することができるかを示している。

好ましい実施形態は、ストレージグループ間の関係を形成するためにリンク化リストを使用するが、コンピュータプログラミングの当業者は、他の実施形態も可能であることが理解できよう。例えば、メンバ間のピア関係は、階層内の同じレベルのメンバをアレイ内に置くことに代えることができる。その結果、コマンドハンドラは、ピアリンクチェーン内をウォーキングするのではなく、アレイのインデックスを繰り返し見ることができる。コマンドスタックのすべての実施形態が想定されている。

コマンドハンドラ
コマンドハンドラは、ストレージコマンドを形成し、そのストレージコマンドを下位レベルのコマンドハンドラに渡すことにより、ストレージコマンドを処理する。ストレージコマンドは、好ましくは、ボリュームレベルのＬＢＡ、ストレージグループへのオフセットを表すグループＬＢＡ、データ要求サイズ、またはメモリにデータを保管するためのバッファを指すポインタなど、いくつかのメンバを有するデータ構造体に保管される。好ましい実施形態では、ボリュームレベルのＬＢＡは、ストライプグループまたはスパングループの子達を対象にしたストレージコマンドを生成するためにストレージコマンドの処理方法を適切に計算するためにストライプコマンドハンドラまたはスパンコマンドハンドラによって使用される。グループのＬＢＡは、グループのゼロからのオフセットを表す値である。さらに、ストレージグループは、ストレージコマンドに関連付けられたパーティションレベルコマンドキューへのリンクを有する。

ストレージグループのタイプに関連付けられたコマンドハンドラは、ストレージグループの機能を表すルールに従ってストレージコマンドを変換する。好ましいコマンドハンドラは、それらが処理するコマンドのコンテキストを運ばないで、むしろ、ストレージグループおよびコマンドハンドラに渡されるコマンドからコンテキスト情報を入手するという意味で汎用である。以下の説明は、好ましいコマンドハンドラはストレージコマンドをどのように処理するかについての追加の詳細である。コマンドハンドラは、読み取りまたは書き込みなどの様々なタイプのストレージコマンドを、ストレージコマンドに関連付けられたデータバッファをパーティション化することにより処理する。好ましい実施形態では、低水準のストレージコマンドがストレージグループまたは、最終的には、パーティションに送信できるように、コマンドハンドラはデータアクセスを高水準から低水準へ分割する責務を有する。

コマンドハンドラ：ミラーコマンドハンドラ
図７Ａは、ミラーコマンドハンドラによるボリュームレベルコマンドの変換の実施形態の例を示している。ミラーコマンドハンドラ７２５はストレージコマンド７００を処理する。ミラーは論理的にストレージグループタイプの階層の最高位に置かれているので、この好ましい実施形態ではストレージコマンド７００はミラーハンドラ７２５用のボリュームレベルストレージコマンドを表す。言い換えれば、ミラーハンドラ７２５は、この好ましい実施形態では、ボリュームレベルストレージコマンドのみを受信する。各コマンドハンドラは、ストレージコマンド７００によって表されるようなストレージコマンドを処理することができる。しかし、コマンド構造体内の要素の値は、以前のコマンドハンドラがある場合、それらがストレージコマンドをどのように処理したかに応じて異なってよい。

ストレージコマンド７００は、バッファポインタ７０３、ボリュームＬＢＡ ７０５、グループＬＢＡ ７０７、要求データサイズ７０９、グループポインタ７１１、およびコマンドポインタ７１３を含んでいる。バッファポインタ７０３は、ストレージコマンド７００に関連付けられたデータを保管するために使用されるバッファ７２０の先頭を指す。ストレージコマンド７００がデータ書き込みを表す場合、バッファ７２０は、書き込まれるデータを保管する。しかし、ストレージコマンド７００がデータ読み取りを表す場合、バッファ７２０は、ストレージデバイスから読み取られたデータを保管するためのストレージエリアである。好ましくは、バッファ７２０はデータのブロック単位で組織化される。ボリュームＬＢＡ ７０５は、ストレージコマンド７００に関連付けられたボリュームレベルデータアドレスを表し、例えば、いくつかのコマンドハンドラ、ストライプおよびスパンコマンドハンドラによって使用される。グループＬＢＡ ７０７は、現行ストレージグループへのオフセットを表す。各ストレージグループは、ゼロから最大値までの範囲の固有のＬＢＡ範囲を有することを思い出されたい。データサイズ７０９は、バッファ７２０内のブロックの数を表す。グループポインタ７１１は、どのグループがストレージコマンドの処理対象の現行ストレージグループであるかを引用しているだけである。コマンドポインタ７１３はパーティションレベルコマンドキューのアンカーを表し、そのため、コマンドスタックがストレージコマンドの処理を完了したら、システムはパーティションレベルコマンドの送信を開始することができる。

ストレージコマンド７００は、ストレージエリアを対象にする任意のタイプのコマンドを表す。コマンド７００は、読み取りコマンド、書き込みコマンド、状況チェックコマンド、または論理ボリューム、もしくは論理ボリュームの部分を対象にすることができる他のコマンドであってよい。好ましい実施形態では、ボリュームレベルストレージコマンドはファイルシステム、特にマルチイニシエータファイルシステムから発信される。

ミラーコマンドハンドラ７２５は、ボリュームレベルストレージコマンドを、ミラーグループの子達のそれぞれに関連付けられたコマンドハンドラに渡す責務を有する。その結果、ミラーコマンドハンドラは、ストレージコマンド７００Ａから７００Ｎによって示されているような１つまたは複数のストレージコマンドを形成するが、これらのコマンドは、実質的には、ストレージコマンド７００の複製である。ストレージコマンド７００Ａは最初のミラーメンバのコマンドハンドラに対して形成されて渡される。そのコマンドハンドラが戻ったら、次のストレージコマンドが次のミラーメンバのコマンドハンドラに対して形成されて渡され、ストレージコマンド７００Ｎが処理され終わるまで同様に続けられる。ストレージコマンド７００Ａから７００Ｎは、それぞれが、ミラーリングされたボリュームの所有物である論理ボリュームのインスタンスを対象にするので、実質的には同じである。例えば、バッファポインタ７０３Ａから７０３Ｎは、データバッファ７２０の最初のブロックを指す。また、ボリュームＬＢＡ ７０５Ａから７０５Ｎは、ボリュームＬＢＡ ７０５と同じ値、すなわち、この実施例では値ＶＬＢＡを有する。さらに、ミラーグループの各メンバは、ボリュームレベルＬＢＡの範囲と同じサイズまたはエクステントであるグループＬＢＡ範囲を有するので、グループＬＢＡ ７０７Ａから７０７ＮはボリュームＬＢＡ ７０５と同じ値、すなわち、この実施例では値ＶＬＢＡを有する。さらに、データサイズ７０９Ａから７０９Ｎは、ストレージコマンド７００のデータサイズ７０９と同じ値を有する。グループポインタ７１１Ａは、最初のメンバに関連付けられたグループを指し、グループポインタ７１１Ｎは、Ｎ番目のメンバに関連付けられたグループを指す。また、コマンドポインタ７１３もストレージコマンドと共に伝搬されて、パーティションレベルに到達した時に、パーティションコマンドハンドラが、パーティションレベルコマンドの中でコマンドポインタ７１３にリンクすることにより、パーティションレベルコマンドキューを生成するようになっている。

ミラーコマンドハンドラ７２５はボリュームレベルストレージコマンドを生成して、その子達のそれぞれ用にコマンドハンドラを呼び出す。子のコマンドハンドラが呼び出されると、ミラーコマンドハンドラ７２５は、新しく生成されたストレージコマンドをその子用のコマンドハンドラに渡す。子コマンドハンドラが戻ると、子に送られたストレージコマンドは、もはや不要になり、次のストレージコマンドが形成および処理できる。パーティションコマンドハンドラは、コマンドスタック処理の結果を保管するパーティションコマンドキューを生成するので、ストレージコマンドは、もはや不要になる。

コマンドハンドラ：ストライプコマンドハンドラ
図７Ｂは、ストレージコマンドがどのように１つまたは複数のストライプレベルストレージコマンドに変換されるかの実施形態の例を示している。ストライプコマンドハンドラ７４５は、ストレージコマンド７３０Ａから７３０Ｎによって示されているような１つまたは複数のストライプレベルストレージコマンドを作成することにより、ストレージコマンド７００を処理する。好ましい実施形態では、ストレージコマンド７００は、ミラーコマンドハンドラから発信されることもあるし、ミラーがない場合、ファイルシステムから直接に送られることもある。

ストレージコマンドハンドラ７４５は、ストライプグループメンバのコマンドハンドラによって処理されるストレージコマンド７３０Ａ、７３０Ｂから７３０Ｎを形成するために、ストライプブロックサイズおよびストライプ化メンバの数などのストライプグループ固有の情報を使用する。ストライプレベルコマンド７３０Ａ、７３０Ｂから７３０Ｎのそれぞれは、ストライプの配置のために、論理ボリューム内の異なるストレージエリア部分を対象にする異なるストレージコマンドを表す。その結果、データサイズ７０９が十分なデータがあることを示していると仮定すると、ストレージコマンド７３０Ａから７３０Ｎは、ストライプグループメンバ全体のデータアクセスを表す。ＲＡＩＤシステム、特にストライプ化の当業者は、本明細書に提示された単純な実施例以外に他の可能なデータアクセス処置があることが理解できよう。そのような処置のすべてが想定されている。

ストレージコマンド７３０Ａは、グループポインタ７４１Ａによって参照されたストライプグループメンバに関連付けられた第１のストライプレベルストレージコマンドを表す。バッファポインタ７３３Ａは、ストライプコマンド７３０Ａが、処理される最初のストライプレベルコマンドなので、バッファ７２０の先頭を指す。さらに、ボリュームＬＢＡ ７３５Ａは、やはり、ストライプストレージコマンド７３０Ａがデータアクセスの最初の部分なので、ボリュームＬＢＡ ７０５と同じ値を有する。グループＬＢＡ ７３７Ａは、ボリュームＬＢＡ ７３５Ａに応じて計算される値、ストライプメンバの数、およびディスクとは違ってデータがストレージグループ全体にわたってストライピングされることを除いて従来のストライピングで行われていたと同じストライプブロックサイズを有する。結果の値は、ストライプグループメンバのＬＢＡエクステントへのオフセットを表す。データサイズ７３９Ａは、データサイズ７０９がストライプブロックサイズより大きいか、等しいと仮定して、ゼロからストライプブロックサイズまでの範囲である。コマンドポインタ７１３は、やはり、パーティションレベルコマンドハンドラによって使用されるようにするために、コマンドスタックを介して下位に渡される。

ストレージコマンド７３０Ａが処理され、そのコマンドハンドラが戻ると、ストライプコマンドハンドラ７４５がストレージコマンド７３０Ｂを形成し、次のストライプグループメンバのコマンドハンドラを呼び出す。バッファポインタ７３３Ｂは、バッファ７２０内のデータの、ストライプブロックサイズの次のチャンクを指す。ボリュームＬＢＡ ７３５Ｂは、次のストライプブロックのデータに関連付けられたボリュームレベルＬＢＡを参照し、ボリュームＬＢＡ ７０５プラスブロックサイズの値を有する。グループＬＢＡ ７３７Ｂも、グループＬＢＡ ７３７Ａの場合と同じように計算される。この実施例では、グループ７３７Ｂおよびグループ７３７Ａの両方のコマンドがストライプ内の同じ深さでデータにアクセスしていると仮定すると、グループ７３７Ｂはグループ７３７Ａと同じ値を有する。この実施例でのデータサイズ７３９Ｂも、ストライプブロックサイズのサイズを有する。グループポインタ７４１Ｂは、そのストライプグループメンバに関連付けられたターゲットグループを指し、最終的に、ストレージコマンド７３０Ｂはコマンドポインタ７１３を運ぶ。

ストライプコマンドハンドラ７４５は、最後のストライプレベルストレージコマンド７３０Ｎに到達するまで、このやり方で、次のストライプレベルコマンドの形成および次のメンバのコマンドハンドラの呼び出しを続ける。バッファポインタ７３３Ｎは、最後のチャンクのサイズを表す値を有するデータサイズ７３９Ｎによって示される、ストライプブロックサイズに等しいか、より小さいサイズを有するバッファ７２０の最後の部分を指す。また、ストライプコマンドハンドラ７４５はボリュームＬＢＡ ７３５Ｎを、ストライプメンバ全体にわたっていくつのブロックが書かれているかに応じて計算する。ストライプコマンドハンドラ７４５は１つの全ストライプのコマンドを完了して別の周回を開始し、結果として、ストライプグループメンバのＬＢＡエクステントの中のより深いデータにアクセスすることが可能なので、グループＬＢＡ ７３７Ｎは、グループＬＢＡ ７３７Ａとは異なる値を有してよい。同様に、グループポインタ７４１Ｎは、前に使用されたグループを指すこともできる。複数のストレージデバイスにまたがったデータのストライピングに精通した人達は、この単純な実施例で説明されたものを超えた、適切なデータストライピングに必要な様々な計算および様々なシナリオを理解できるであろう。それらはすべて、本発明の主題に適用される。

ストライプコマンドハンドラ７４５は、ＲＡＩＤ ４、ＲＡＩＤ ５、ＲＡＩＤ ６、または他のパリティ構成をサポートするためのパリティＲＡＩＤハンドラを提供するためにパリティ計算を行うように変更できることが想定されている。好ましくは、パリティコマンドハンドラは、パリティ情報を求める読み取り要求を出し、次に、いずれかの書き込み要求に基づいてパリティ値を変更し、次に、パリティグループのメンバに書き込みコマンドを出す。一部の実施形態では、パリティのための追加処理は、別のデバイスに置かれたプロキシを用いて扱うことができる。

コマンドハンドラ：スパンコマンドハンドラ
図７Ｃは、ストレージコマンドがどのように１つまたは複数のスパンレベルストレージコマンドに変換されるかの実施形態の例を示している。スパンコマンドハンドラ７６５は、ストレージコマンド７５０Ａおよび７５０Ｂによって示されているように、ストレージコマンド７００を１つまたは複数のスパンレベルストレージコマンドに変換することにより、ストレージコマンド７００を処理する。好ましい実施形態では、スパンコマンドハンドラ７６５は、ストレージグループタイプ組織化においてファイルシステム、ミラーコマンドハンドラ、またはストライプコマンドハンドラのそれぞれより下位なので、スパンコマンドハンドラ７６５はストレージコマンド７００をファイルシステムから直接、ミラーコマンドハンドラから、またはストライプコマンドハンドラから受信することができる。

スパンコマンドハンドラ７６５は、スパン境界はスパングループのＬＢＡエクステント内のどこであるかを計算するために、その子達のそれぞれのＬＢＡエクステントに関する情報を利用する。次に、この情報は、ストレージコマンド７００がパーティション間をつなぐときに、ストレージコマンド７５０Ａおよび７５０Ｂを形成するために使用される。ストレージコマンド７５０Ａは、第１のパーティションからデータをアクセスする第１のスパンレベルストレージコマンドを表し、ストレージコマンド７５０Ｂは、第１のパーティションの後の第２のパーティションからデータをアクセスする第２のスパンレベルストレージコマンドを表す。

ストレージコマンド７５０Ａは、第１のパーティションアクセスに関する情報を有する。バッファポインタ７５３Ａは、先頭バッファ７２０を指す。ボリュームＬＢＡ ７５５Ａは、それがデータアクセスの最初の部分を表すので、ボリュームＬＢＡ ７０５と同じである。グループＬＢＡ ７５７Ａは、スパンハンドラ７６５によって計算される値を有しており、スパンメンバのグループへのオフセットを表す。この値は、ボリュームＬＢＡ ７０５から、およびスパングループメンバのＬＢＡエクステントのそれぞれのエクステントから計算される。同様に、データサイズ７５９Ａも、特にスパン境界がボリュームＬＢＡ ７５５Ａと関係がある場合、同じ情報から計算される。当然ながら、この実施例は、スパン境界の値はボリュームレベルＬＢＡエクステントと同じマップスペース内にあると仮定している。グループポインタ７６１Ａは、ストレージコマンド７５０Ａが対象にしているパーティショングループを指すが、それでもやはり、パーティションレベルコマンドハンドラにコマンドポインタ７１３が渡される。

ストレージコマンド７５０Ａが処理されると、パーティションコマンドハンドラは戻り、次いでスパンコマンドハンドラ７６５がストレージコマンド７５０Ｂを処理する。ストレージコマンド７５０Ｂは、次のパーティションを対象にするストレージコマンド７００の２番目の部分を表している。バッファポインタ７５３Ｂは、パーティション境界７５５によって示されているように、データがパーティション間をつなぐバッファ７２０内の場所を指す。ボリュームＬＢＡ ７５５Ｂは、前のパーティションのスパン境界はどこで「プラス１」であったかの値を有する。さらに、グループＬＢＡ ７５７Ｂは、アクセスはパーティションの先頭で行われることを示す値ゼロを有する。データサイズ７５９Ｂも、スパン境界の使い方を含むパーティションエクステント情報から計算される。グループポインタ７６１Ｂは、ストレージコマンド７５０Ｂの宛先であるパーティションを指す。

前の好ましいコマンドハンドラの場合と同じように、スパンコマンドハンドラ７６５はストレージコマンド７５０Ａを生成し、グループポインタ７６１Ａに関連付けられたコマンドハンドラを呼び出す。ストレージコマンド７５０Ａは、処理されると、もはや不要になる。スパンコマンドハンドラ７６５は、次いで、ストレージコマンド７５０Ｂの生成に進み、次にそのコマンドを処理する。

コマンドハンドラ：パーティションコマンドハンドラ
図７Ｄは、ストレージコマンドがどのように１つまたは複数のパーティションレベルコマンドに変換されるかの実施形態の例を示している。パーティションレベルコマンドを生成することは、好ましい実施形態では、ストレージグループ階層の最下部を表し、データにアクセスするためのパーティションレベルコマンドを、ストレージデバイスを対象にして生成するための実際の構造を提供する。パーティションコマンドハンドラ７８５はストレージコマンド７００を、パーティションレベルストレージコマンド７７０Ａ、７７０Ｂから７７０Ｎによって表される１つまたは複数のパーティションレベルコマンドに変換する。好ましい実施形態では、パーティションコマンドハンドラ７８５は、コマンドポインタ７１３によって参照されるコマンドのリストにパーティションコマンド７７０Ａから７７０Ｎを追加することにより、パーティションコマンドキュー７９０を形成する。このリストは、論理ボリュームのコマンドスタックによってボリュームレベルストレージコマンドが完全に処理されるにつれて大きくなり続ける。好ましくは、ストレージコマンド７００は、ストレージグループの提示の好ましい階層があるとすると、ボリュームレベルストレージコマンド、ストライプレベルストレージコマンド、またはスパンレベルストレージコマンドを表す。

パーティションコマンドハンドラ７８５は、パーティションの特性に関する情報を使用して、ストレージコマンド７７０Ａから７７０Ｎの生成方法を決定する。好ましい実施形態では、パーティションコマンドは明確にストレージエリアを対象とし、パッケージされるか、またはストレージデバイスに送信されるので、パーティションコマンドは、汎用のストレージコマンドとは少し異なる。

パーティション関連のパラメータとしては、データ転送サイズ、パーティションのブロック単位でのサイズ、またはパーティション識別子がある。好ましい転送サイズは、広く普及しているストレージデバイスのブロックサイズと一致するように、５１２バイト単位のブロックである。特に好ましい転送サイズとしては、単一のデータグラムでの転送に合うように、１、２、４、８、１６、３２または６４データブロックがある。しかし、他のブロックサイズも想定されている。パーティションサイズ情報は、パーティションへの高水準ストレージコマンドデータアクセスを適切にマッピングするためにコマンドハンドラによって使用される。前に説明されているように、パーティション識別子は、特定のパーティションをアドレスするために使用される。好ましくは、パーティション識別子はＩＰアドレスである。しかし、適用可能性を失うことなく、ＬＵＮまたは他のアドレスも使用できる。ｉＳＣＳＩを使用する一実施形態では、ストレージデバイスへのストレージコマンドをアドレスするためにＩＰアドレスを使用することができ、ストレージデバイス上の特定のストレージエリアをアドレスするためにＬＵＮが使用される。

パーティションコマンドハンドラ７８５は、データの多くても１つの転送サイズを要求する単一アクセスを表す、パーティションコマンド７７０Ａから７７０Ｎのそれぞれを形成するために転送サイズ情報を使用する。パーティションコマンド７７０Ａは、第１のパーティションコマンドを表す。バッファポインタ７７３Ａは、バッファ７２０の最初の部分を指す。パーティションコマンド７７０Ａは、ボリュームレベルのすべての処理が前の層（複数）によって完了されているので、その要求の中にボリュームＬＢＡ ７０７情報を必要としない。グループＬＢＡ ７７７Ａは、ターゲットパーティション内のオフセットを参照し、データサイズ７７９Ａは、要求されたデータアクセスは、少なくとも、パーティションの期待される転送サイズであることを示す。コマンドリンク７８３Ａは、コマンドリンク７８３Ｂと同様に、次のパーティションレベルコマンドにリンクすることにより、パーティションコマンドキュー７９０を形成し続ける。パーティションコマンドハンドラ７８５は、パーティションコマンド７７０Ａの生成を完了すると、パーティションコマンド７７０Ｂを生成する。

パーティションコマンド７７０Ｂは、パーティションコマンド７７０Ａと同様な方法で生成される。バッファポインタ７７３Ｂは、バッファ７２０の、次のデータチャンクの先頭から１つの転送サイズだけ深い場所を指す。グループＬＢＡ ７７７Ｂは、前のパーティションコマンドより１つの転送サイズだけ大きい値を有し、データサイズ７７９Ｂは、やはり、転送サイズである。パーティションコマンドハンドラ７８５は、バッファ７２０のすべてのデータが処理され終わるまでパーティションコマンドを生成し続ける。パーティションコマンド７７０Ｎによって表される最後のパーティションコマンドは、バッファポインタ７７３Ｎがバッファ７２０の最後の部分を指すようにすることにより、バッファ７２０の末尾部分を扱う。グループＬＢＡ ７７７Ｎは、ストレージコマンド７００を処理するために必要なチャンクの数に応じて計算される値を有する。データサイズ７７９Ｎは、パーティションの転送サイズより小さいか、等しい値を有する。最終的に、コマンドリンク７８３Ｎは、必要な場合，ＮＵＬＬで終了し、それは、コマンドキュー７９０の終わりを表す。

ストレージデバイスは、パーティションレベルコマンドを受信すると、パーティションレベルＬＢＡを、物理ストレージデバイスに関連付けられたデバイスレベルＬＢＡに変換する。例えば、ストレージコマンド７７０Ａは、関連付けられたグループＬＢＡ ７７７Ａを有しており、グループＬＢＡ ７７７Ａは、そのターゲットパーティション用の０から最大値までの範囲の値を有する。しかし、ストレージデバイスは、ストレージコマンド７７０Ａを受信すると、グループＬＢＡ ７７７Ａを、おそらく実際のハードディスクドライブ内の絶対ＬＢＡ基準にマッピングする。

コマンドハンドラ：コマンドスタックの処理
リンクされたストレージグループおよびコマンドハンドラによって形成されるコマンドスタックは、高水準ストレージコマンドを、パーティションを担当するストレージデバイスによって処理できる低水準ストレージコマンドに変換する。コマンドスタックは、高水準コマンドを、パーティションの様々なストレージグループによって提供される機能にマッピングすることにより、コマンドを生成する。コンピュータプログラミングの当業者は、ストレージコマンドを処理するための可能な実施形態は多数あることが理解できよう。

好ましい実施形態では、ストレージコマンドは、コマンドデータ構造体へのポインタを介してコマンドスタックまたはグループコマンドハンドラに渡される。コマンドデータ構造体は、コマンドの特質に関連する情報、すなわち、要求のタイプ（読み取り、書き込み、状況など）、データ要求のサイズ（ある場合）、またはデータを保持するためのバッファへのポインタなどを有する。データバッファへのポインタを使用すると、コマンドハンドラは、書き込み要求および読み取り要求を実質的に同じ方法で扱うことができる。コマンドハンドラは、高水準ストレージコマンドを低水準ストレージコマンドに変換するとき、低水準ストレージコマンドを、好ましくはパーティションレベルで、ストレージコマンドのリンク化リストに入れる。ストレージコマンドリストは、最終的には、パーティションレベルストレージコマンドのリストのみになり、それらのコマンドはパッケージされて、ストレージデバイスに送信されることができる。リスト内のパーティションレベルストレージコマンドのそれぞれは、バッファへのオフセット、要求サイズ、パーティションＬＢＡ、パーティション識別子、またはパーティションレベルストレージコマンドをパッケージングするときに有用な他の情報を有する。

コマンドスタック自体は複雑な構造体であってよいが、構造体は数個の関数、すなわち、ストレージグループのタイプごとに１つの関数を呼び出す。このことは、論理ボリュームが４つのストレージグループタイプ、すなわち、ミラー、ストライプ、スパン、またはパーティションをサポートする場合、コマンドスタックは４つの関数、ミラーコマンドハンドラ、ストライプコマンドハンドラ、スパンコマンドハンドラ、またはパーティションコマンドハンドラを呼び出すだけであることを意味する。各グループは、コマンドハンドラが使用するための、そのグループのコンテキスト定義情報をグループデータ構造体に入れて収容する。このように機能するコマンドスタックを開発すると、反復を使用する必要性が減少するので、メモリ制限がある組み込み型システムにとって有益である。

ストレージコマンドのパッケージ化
最終的には、低水準ストレージコマンドは、ストレージデバイスへの送信のためにパッケージされる。好ましい実施形態では、パーティションレベルコマンドは、ストレージデバイスによって理解されるストレージプロトコルに従ってパッケージされる。しかし、コマンドスタックをさらに処理するために、より高水準のストレージコマンドをパッケージして、それらを、プロキシを含めて、他のデバイスに送信することも可能である。例えば、ＺｅｔｅｒａのＺ−ＳＡＮプロトコルでは、各パーティションレベルコマンドは、Ｚ−ＳＡＮコマンド、適切な転送サイズのデータペイロード、およびパーティションのＩＰアドレスを有するＵＤＰデータグラムにパッケージされる。Ｚ−ＳＡＮ使用可能なデバイスは、複数のＩＰアドレス、すなわち、そのデバイスが担当するパーティションごとに１つのＩＰアドレスを有することができる。Ｚ−ＳＡＮ使用可能なデバイスは、パーティションとＩＰ層を区別するためにＺ−ＳＡＮデータグラムのＩＰアドレスを使用する。あるいは、パーティションレベルコマンドはｉＳＣＳＩプロトコルを使用してパッケージすることもできる。パーティションを識別するためにＩＰアドレスを使用するのではなく、ｉＳＣＳＩはストレージデバイスをアドレスするためにＩＰアドレスを使用し、パーティションをアドレスするためにＬＵＮを使用する。ｉＳＣＳＩは、より高水準のストレージコマンドを転送するためにも使用できるｉＳＣＳＩセッション内で、パーティションレベルコマンドもＴＣＰ／ＩＰ接続を介して転送する。パーティションレベルストレージコマンドまたは他のストレージコマンドの移送の方法はコマンドの生成とは独立していることに留意されたい。したがって、ＦＣＩＰ、ｉＦＣＰ、ＳＡＴＡ、ＡＴＡ、ＳＡＳ、ＳＣＳＩ、ＵＳＢ、無線ＵＳＢ、ＩＥＥＥ １３９４、８０２．１１、またはストレージコマンドを運ぶことができる他のプロトコルなど、任意のプロトコルが使用できる。

一実施形態では、パーティションレベルストレージコマンドを、コマンドのキューを表すリンク化リストにリンクするのとは違って、生成されたストレージコマンドをパッケージするためのパーティションハンドラを提供する。パーティションレベルストレージコマンドは、生成されると、パケットにパッケージされて、パーティションに送ることができる。これはストレージシステム内で最も迅速な応答を行うので、有利である。しかし、送信された各コマンドに応答を期待するトランザクションプロトコルの場合、システムは、コールバックが戻されない場合、応答を待つ間、ストレージコマンドの処理をブロックする。

好ましい実施形態において、パーティションハンドラがパーティションレベルストレージコマンドのリンク化リストを介して後で送信するためのコマンドをキューに入れる場合、パーティションレベルストレージコマンドはパッケージされて、送信される。この手法の利点は、コマンド処理がストレージプロトコル処理と分離されているので、コマンド生成がストレージプロトコルの処理によって中断されないことである。例えば、ｉＳＣＳＩプロトコルでパッケージされた各パーティションレベルコマンドがパーティションまたはストレージデバイスからの応答を必要とする場合、パーティションコマンドハンドラは、次のパーティションレベルストレージコマンドを送信する前に応答を待つ必要がない。

論理ボリュームマップの構成
リンクされたストレージグループおよびコマンドハンドラによって表されるコマンドスタックは、論理ボリュームのマップを表す。クライアントおよびストレージデバイスが通知することなく現れ、消えることが期待されている想定された分散仮想環境では、クライアントにシステムの事前知識は必要ない。好ましくは、クライアントは、１つまたは複数のパーティションを発見することにより、ストレージシステムにアクセスする。システムに入るクライアントは、おそらくＵＤＰブロードキャストを使用して、発見メッセージをストレージデバイスに送信し、ストレージデバイスはパーティション情報で応答する。パーティション情報は、クライアントが使用するための論理ボリュームマップ情報を表す属性を含む。すると、クライアントは、発見されたマップデータに応じて論理ボリュームのマップを構成する。例えば、パーティションは、ストレージグループタイプの階層内におけるそのパーティションのグループ所属を定義する属性で応答できる。属性は、例えば、名前を含むが、そのパーティションが所属するグループに関する階層関係の情報を含んでよい。クライアントは、パーティションからの属性情報を解析して、パーティションがどのように組み合わされて論理ボリュームを形成しているかを理解する。属性は、ストレージグループの組織化に関する一般ルール情報を、クライアントが理解できて、論理ボリュームを構成できるような方法で符号化する。クライアントは、組織化上のルールおよび属性情報から論理ボリュームのマップを表すコマンドスタックを構築する。ある意味で、属性は、論理ボリューム用のコマンドスタックの構成方法に関する、クライアントへの指示と考えることができる。「Ｄｉｓａｇｇｒｅｇａｔｅｄ Ｒｅｓｏｕｒｃｅｓ ａｎｄ Ａｃｃｅｓｓ Ｍｅｔｈｏｄｓ」という名称の共同所有の米国特許出願第１１／２０５８９５号明細書で、クライアント発見パーティション情報、階層上の名前、またはストレージグループ組織化を符号化する属性の使い方に関して詳細が記載されている。

クライアントは論理ボリュームのコマンドスタックを構築しながら属性情報を解釈するので、オプションの親ポインタまたはオプションの透過ピアポインタを使用することが有利である。これらのポインタを使用することは、穴（ｈｏｌｅ）またはエラーがないことを確認するためにグループ構造体の中をウォーキングする備えとなる。

仮想ストレージシステム内のストレージエリアは、発見要求に個別にまたは一括で応答することが想定されている。個別の応答は、各パーティションからの単一の応答を表し、その応答はパーティション情報を有する。一括応答は、システム内の要素からの、複数のパーティションに関する情報を有する応答を表す。一部の実施形態では、プロキシが多数のパーティションからの個別の応答を集約し、クライアント発見に対して、それが単一のストレージエリアであるかのように１つの個別の応答で応答する。例えば、プロキシが、ストライプ化ストレージグループを集約した場合、プロキシはそのストライプ化ストレージグループをそれが単一のパーティションであるかのように扱い、クライアントにそのグループは個別のパーティションであるかのような発見応答を提示する。他の実施形態では、ストレージデバイスまたは他のデバイスがパーティションに関する情報を収集し、複数のパーティション用の情報を有するメッセージを形成する。例えば、単一のストレージデバイスが、発見要求に対して、各個別パーティションの名前または属性を有するメッセージで応答する。

結果のコマンドスタックは単純にも、複雑にもなりうる。単純なコマンドスタックとは、論理ボリューム内のすべてのストレージグループに対して単一のコマンドハンドラを使用するコマンドスタックを表す。例えば、パーティションに直接にマッピングされる論理ボリュームは、パーティションコマンドハンドラが必要なだけである。複雑なコマンドスタックは、ミラー、ストライプ、スパン、パーティション、パリティ、または他のコマンドハンドラの混在など、ストレージグループの異なるタイプに対する複数のコマンドハンドラを含む。

論理ボリュームマップの更新
論理ボリュームのマップは、ストレージグループのリンク化構造体を有する。どのリンク化リストとも同じように、メンバは、リスト内のポインタを調整することにより更新できる。ストレージグループは、追加ストレージグループをリンクすることにより論理ボリュームに追加できる、またはストレージグループをリンク解除することにより論理ボリュームから除去される。

ストレージグループを追加する例として、論理ボリュームに追加パーティションを追加することにより、論理ボリュームの容量を増やすことが挙げられる。例えば、論理ボリュームが３つのメンバを有するスパングループのみを有する場合、その論理ボリュームは、スパングループのピアリンクに第４のメンバをリンクすることにより、容量を増やすことができる。クライアントは、論理ボリュームを取り外すことなく論理ボリュームの容量が増えたことに気付くだろう。

ストレージグループを除去する例として、失われたパーティションの処理が挙げられる。ボリュームが２つ以上のメンバを有するミラーグループを有している場合、各メンバは、論理ボリュームのインスタンスを表す。クライアントは、ある１つのメンバに関連付けられたパーティションにアクセスできなくなった場合でも、他のミラーグループメンバの１つまたは複数のパーティションからのデータにはアクセスできる。クライアントは、失われたパーティションとのリンク、または失われたパーティションが関連付けられているグループを、ピアリンクまたは子リンクをＮＵＬＬ終了させることにより除去し、それにより論理マップを更新できる。その場合でも、コマンドスタックは有効であり、ストレージコマンドを通常に処理する。ただし、コマンドスタックは、単純に、除去されたストレージグループを検出しない。クライアントが破壊されたミラー化ボリュームへの書き込みを続行するか否かを決定するための命令をクライアントが組み込むことが想定されている。

好ましい実施形態では、クライアントは、データについての論理ボリュームの整合性に関するパーティション情報を入手する。整合性とは、論理ボリュームの部分がアクセスできない場合でも、クライアントが、論理ボリュームのＬＢＡの範囲によって表されるとおりの論理ボリュームの完全なインスタンスにアクセスできることを指す。一実施形態では、クライアントは、論理ボリュームに関連付けられたパーティションが使用可能であることを確認するために、パーティションの属性についてシステムを定期的にプローブする。クライアントが属性情報を分析することによって論理ボリュームの構成体の変更を検出した場合、そのクライアントは、適切なストレージグループを追加または除去することにより、論理ボリュームのマップを更新することができる。

クライアントがＬＢＡ範囲に関して整合性のある論理ボリュームマップを形成し終わると、そのクライアントは、ローカルに接続されたストレージデバイスとしてその論理ボリュームをマウントできる。好ましい実施形態では、クライアントが論理ボリュームの変更を検出した場合、そのクライアントは、論理ボリュームを取り外さずに論理ボリュームマップを更新できる。ストレージグループはオペレーティングシステムまたはファイルシステムに影響を与えることなくリンクまたはリンク解除できるので、クライアントが論理ボリュームを取り外す必要はない。

補足の考察
好ましい実施形態では、パーティションレベルストレージコマンドはストレージデバイスへの送信用にパッケージされるが、賢明な読者は、パッケージングについてはパーティションレベルストレージコマンドと、より高水準のストレージコマンドとの間にはほとんど違いがないことを理解できるだろう。したがって、本発明の主題は、ストレージデバイス、またはストレージデバイス上のストレージエリアへの送信用にすべてのレベルのストレージコマンドをパッケージする概念をも含む。そのような手法は、コマンドハンドラが、クライアント、プロキシ、ストレージデバイス、またはメモリ内にコマンドハンドラを保管する他のデバイスを接続する通信リンクを介して機能できる分散コマンドスタックを確立する備えとなる。プロキシとは、別のデバイスには１つまたは複数の単一ストレージエリアに見えるが、他のストレージデバイス（複数）から１つまたは複数のストレージデバイスを集約しているデバイスを表す。プロキシはストレージデバイスに対してはクライアントとして機能する。しかし、クライアントに対してはストレージデバイスのようにも機能する。

実際的な意味では、ストレージグループのタイプに関連付けられたストレージコマンドを処理するコマンドハンドラに結合されるストレージグループ組織化は、ＬＢＡ変換を定義する「数学」と考えることができる。コマンドハンドラは、ＬＢＡおよびデータ要求サイズを入力として受け入れる様々な演算子を表す。その後、コマンドハンドラは、１つまたは複数の変換済みＬＢＡおよびデータ要求サイズを出力する。したがって、データアドレスおよび要求サイズを変換するすべてのコマンドハンドラが想定されている。例えば、本発明の主題は、ストレージグループのタイプのための追加機能を反映する機能をコマンドハンドラ内に追加することの備えとなる。コマンドハンドラは論理ボリュームの構造体から十分に分離されているので、コマンドハンドラ機能への変更は、論理ボリュームのトポロジーを変更させることはない。パリティを扱うようにストライプコマンドハンドラを変更することは、１つの例である。

別の例として、論理ボリュームのパフォーマンスを向上させるためにミラーコマンドハンドラを変更することが挙げられる。２つ以上のメンバを含むミラーグループを有する論理ボリュームは、２組以上のＬＢＡを使用してアクセスされる２組以上の論理ボリュームのデータを有する。したがって、ミラーコマンドハンドラは、読み取りストレージコマンドをミラーグループメンバ全体に拡散するように変更できる。ミラーコマンドハンドラは、ボリュームレベル読み取りコマンドを処理するとき、負荷を複数のストレージデバイスに分散するために、ストレージコマンド、またはストレージコマンドの部分を各ミラーメンバの全体にわたって回転（ｒｏｔａｔｅ）させることができる。ミラーメンバに関連付けられているパーティションが別々のストレージデバイスに置かれている場合、読み取りのパフォーマンスは、同じストレージデバイスに置かれているミラーメンバからデータを読み取るより優れている。一実施形態では、変更されたミラーコマンドハンドラは、ミラーメンバ上のデータを、ミラーグループメンバがストライプ化グループに属しているかのように扱う。そのような手法は、一方のディスクが他方のディスクをミラーリングする２つのハードディスクを備えたコンピュータなど、内部ストレージデバイスを有するクライアントで有利に展開できる。さらに、コマンドハンドラは、要求のタイプ間で差異があってよい。例えば、コマンドハンドラは、追加機能を得るために、書き込み要求または読み取り要求の処理を変えてよい。

本明細書で開示された構造体は、ストレージを超えた他のテクノロジーに適用できる。概念は、分散デバイスまたは非集約型デバイスにコマンド処理を提供するように汎用化できる。クライアントは非集約型デバイスの構造体を発見して、発見情報に基づいてコマンドスタックを形成できる。他の実施形態では、クライアントは、必要な通信インフラストラクチャのみが確実に使用されるようにするために、サーバからの情報を使用して通信スタックを構成できる。例えば、クライアントおよびサーバが同じイーサネット（登録商標）ＬＡＮ上で接続されている場合、クライアントは、効率的な通信のために、通信用の完全ＴＣＰ／ＩＰスタックではなくイーサネット（登録商標）のみを使用する通信スタックをサーバの命令から作成できることもあり得る。そのようなコマンドスタックは、アトミックなコマンド応答アプリケーションプロトコルによく適合する。

コマンドスタックをチェーンすることも想定されている。前に説明されているように、コマンドスタックは、クライアント、プロキシ、ストレージデバイス、またはストレージシステム内の他の要素間で拡散できる。これは、ストレージ機能にさらにアクセスするために、クライアントが、自身がコマンドスタックを使用するストレージデバイスと対話する概念を含む。例えば、クライアントは、論理ボリュームがパーティションのスパングループを有していることに気付くことができる。しかし、各パーティションは、実際には、ストレージデバイス内のＲＡＩＤ−５ストライプグループである。ストレージデバイスはＲＡＩＤ−５コマンドハンドラを使用してローカルパーティションと対話するが、クライアントはスパンコマンドハンドラを使用してストレージデバイス上のパーティションと対話する。基本的には、スパンレベルコマンドはストレージデバイスに送信され、ストレージデバイスはスパンレベルコマンドを高水準コマンドとして扱い、さらにスパンレベルコマンドを、ＲＡＩＤ−５コマンドハンドラを使用して処理する。

パーティションのＬＢＡ範囲はストレージグループの範囲から独立しているので、各ストレージデバイスは各パーティションを、０からストレージエリアの最大ＬＢＡまでのＬＢＡ範囲を有するストレージエリアとして扱うことができる。これは、ストレージデバイスが追加計算を行う必要がある場合と違って、ストレージデバイスに高速処理を提供する。さらに、このことは、ストレージデバイスは、ストレージグループ組織化のルールに従ってどのように機能するかを理解する能力を必要としないことを意味する。パーティションがインスタンス化される時、パーティションの名前または属性は、論理ボリュームのマップを構成するためにクライアントによって使用されるルール情報を運ぶように更新される。パーティションは、単に、データをＬＢＡの線形範囲に保管する。

利点
コマンドハンドラを含む論理ボリュームマップからストレージコマンドを生成することを利用して多数の利点が実現される。各クライアントが相互に独立して機能するシステムでは、各クライアントは、論理ボリュームのクライアント自身のビューを確立するが、論理ボリュームを構成するためにすべてのクライアントが同じ共通ルールを使用するので、クライアントのそれぞれは実質的には同じマップを有する。１つのクライアントが論理ボリュームの一部を見ることができなくなって、論理ボリュームマップが更新されることになった場合、他のクライアントは影響を受けない。さらに、論理ボリュームが、２つ以上のメンバを有するミラーグループを含んでいるシナリオでは、ミラーリングされたメンバの一部分がアクセス不能になった場合でも、クライアントは、論理ボリューム上のデータの整合性のあるビューを保持できている。異なるミラーグループメンバからであっても完全なデータセットまたはボリュームレベルのＬＢＡ範囲が使用可能な場合、クライアントはデータにアクセスする能力を保持している。アクセス不能になったグループまたはパーティションのみを、それらを論理ボリュームマップからリンク解除することにより、論理ボリュームの再マウントを必要としないでマップから除去される。

開示された技術を使用するストレージシステムは、多くのストレージデバイスまたは多くのクライアントを有する、より大きい展開へ規模が拡大される。前に説明されているように、各クライアントは独立して機能し、ストレージデバイスに負担をかけることなく参加することができる。システムは、クライアントとストレージデバイス間の通信リンク帯域幅の限界まで規模を拡大する。さらに、論理ボリュームコマンドスタックは、単一のホストから他のデバイス（複数）に拡大できる。例えば、クライアントがコマンドスタックの一部を有すことができて、おそらく、リモート関数を実行するためのＷｅｂサービスを使用することにより、そのコマンドスタックの一部は、ストレージコマンドの生成を続行するプロキシデバイス上のコマンドスタックに呼び込まれる。開示された方法は、ストレージコマンドを移送するために使用されるプロトコルとは独立していて、そのことは、ｉＳＣＳＩなどの標準ベースの実施態様だけでなく、プロプラエタリストレージ実施態様による採用の備えとなる。

ストレージグループタイプに関連付けられたコマンドハンドラの使用は、異質なストレージグループタイプの混在の備えとなる。前に説明されているように、ミラー、ストライプ、スパンまたはパーティションは、単一の論理ボリュームを作成するために様々な方法で結合できる。異質なストレージグループの混在を、要求のタイプを様々に扱うコマンドハンドラの能力に結合することは、特殊な特性を有する論理ボリュームを確立する備えとなる。例えば、ストライプグループおよびスパングループを含む論理ボリュームは、アーカイブの目的でスパングループが使用されてもよい場合に両方のグループに書き込む一方で、優先的にストライプグループから読み取られてもよい。

さらに、論理ボリュームコマンドスタックは、ストレージコマンド移送とは独立したストレージコマンドを生成し、各プロトコルが異なるタイプのストレージデバイスを対象にする異質の移送プロトコルの混在をサポートすることが可能である。一実施形態では、例えば、単一の論理ボリュームが、内部コントローラを介してアクセスされる直接接続のデバイスに置かれているパーティション、またはネットワークストレージプロトコルを介してアクセスされるリモートデバイスに置かれているパーティションを含むことができる。パーティションコマンドハンドラは、各タイプのプロトコルの特定の詳細を扱うように構成されることができる。特定の実施形態の例では、直接接続のＳＡＴＡハードディスクドライブ上のパーティション、ｉＳＣＳＩを介してアクセスされるパーティション、およびＺｅｔｅｒａのＺ−ＳＡＮプロトコルを介してアクセスされるパーティションを含む論理ボリュームを備えてよい。

ストレージグループタイプの組織化に関連したルールに従って論理ボリュームマップが構成されるので、クライアントはストレージコマンドを迅速に生成する。好ましい実施形態では、高水準のボリュームコマンドは、反復を使用することなく、最大限４レベルのコマンドハンドラ内で１つまたは複数のパーティションレベルコマンドに変換される。これは、ストレージコマンドの高速処理を提供する。

ハードウェア
他の態様は、本発明の主題に関係のあるハードウェアに関する。保管、プロトタイプ化、製作、操作、管理、パッケージ化、テスト、物理的制御またはサポートのためのハードウェア、または本発明の主題の物理的態様に関係のある他のアクティビティのためのハードウェアを開発できることが想定されている。したがって、本発明の主題は、そのようなハードウェアを開発、創作、製造または稼働するためのシステム、方法、または装置を含む。この意味において、そのようなハードウェアは本発明の主題の範囲内である。

ソフトウェア
さらに別の態様では、本発明の主題の様々な態様およびその関連インフラストラクチャを構成、シミュレート、または管理するソフトウェアを書けることが想定されている。この観点から、本発明の主題は、そのようなソフトウェアを書く方法、そのソフトウェアを機械可読形式で記録すること、そのようなソフトウェアの使用許諾、販売、配布、導入、または適切なハードウェア上での稼働を含む。さらに、そのようなソフトウェア自体が本発明の主題の範囲内であると見なされる。

このように、具体的な構成およびストレージコマンドを生成するための方法が開示されている。しかし、当業者には、本明細書における発明の概念から逸脱することなく、すでに記載されたもの以外に、さらに多くの変更が可能であることは明らかであろう。したがって、本発明の主題は、開示の精神であることを除いて限定されることはない。さらに、本開示を解釈する際、すべての用語は、コンテキストと矛盾しない、可能な限り広い意味で解釈されるべきである。特に、用語「含む、有する、備える（ｃｏｍｐｒｉｓｅおよびｃｏｍｐｒｉｓｉｎｇ）」は、要素、構成要素またはステップを非排他的に指していて、言及された要素、構成要素またはステップが存在できる、または利用できる、または明示的に言及されていない他の要素、構成要素またはステップと組み合わせることができることを表していると解釈すべきである。

Claims (17)

1. 複数のストレージパーティションのそれぞれが複数のストレージグループのうちの選択された１つに関連付けられ、複数のストレージグループのそれぞれが、階層に組織化された複数のグループタイプのうちの選択された１つに関係付けられた、複数のストレージグループとして組織化される複数のストレージパーティションと、
   複数のストレージグループをリンクした論理ボリュームのマップを使用することにより、複数のストレージパーティションにアクセスするためのコントローラであって、該マップがグループデータ構造体を含み、該グループデータ構造体が、複数のストレージグループのストレージグループを表し、そのストレージグループが関連付けられた第１のグループタイプ用のコマンドハンドラを指すように構成された関数ポインタ、そのストレージグループのピアストレージグループを指すように構成されたピアグループポインタ、およびそのストレージグループの、階層上で第１のグループタイプより下に組織化される第２のグループタイプに関連付けられた子ストレージグループを指すように構成された子グループポインタを有する、コントローラと
   を備えた、ストレージシステム。
2. ピアストレージグループが、階層上で第１のグループタイプより下に組織化される第３のグループタイプに関連付けられる、請求項１に記載のストレージシステム。
3. ストレージグループが、そのピアストレージグループを含む複数のピアストレージグループを有し、ピアグループポインタは、そのピアストレージグループを指すようにのみ構成される、請求項１に記載のストレージシステム。
4. ストレージグループが、その子ストレージグループを含む複数の子ストレージグループを有し、子グループポインタは、その子ストレージグループを指すようにのみ構成される、請求項１に記載のストレージシステム。
5. 複数のグループタイプのそれぞれ用のコマンドハンドラをさらに含む、請求項１に記載のストレージシステム。
6. 複数のストレージパーティションのそれぞれがパーティショングループタイプに関連付けられ、パーティショングループタイプは、最下位の階層上で組織化されたグループタイプである、請求項１に記載のストレージシステム。
7. 複数のストレージパーティションのうちの少なくとも２つのストレージパーティションを有するストレージデバイスをさらに含む、請求項６に記載のストレージシステム。
8. 前記コントローラが、そのストレージグループ宛ての第１のコマンドを受信し、少なくとも部分的に第１のコマンドに基づいて、その子ストレージグループ宛ての第２のコマンドを生成するように構成されたコマンドハンドラを有し、前記コントローラが、
   その子ストレージグループを表し、第２のグループタイプ用のパラメータを有する別のデータ構造体と、
   少なくとも部分的にそのパラメータに基づいて第２のコマンドを生成するように構成されたコマンドハンドラと
   をさらに使用する、請求項１に記載のストレージシステム。
9. コマンドハンドラは、少なくとも部分的に第１のコマンドに基づいて、その第２のコマンドを含む複数の第２のコマンドを順次に生成するように構成されている、請求項８に記載のストレージシステム。
10. 複数のパーティションのうちの第１のパーティションを有し、この第１のパーティションがそのストレージグループのメンバである第１のストレージデバイスと、
    複数のパーティションのうちの第２のパーティションを有し、この第２のパーティションがその複数のストレージグループのうちの別のストレージグループのメンバである第２のストレージデバイスと、
    そのストレージグループに関連付けられた第１のストレージコマンドを、該別のストレージグループに関連付けられた第２のストレージコマンドに変換するように構成されたコマンドハンドラと
    をさらに含む、請求項１に記載のストレージシステム。
11. そのストレージデバイスをストレージシステムに結合するように構成された通信インターフェースと、
    その通信インターフェースに結合され、
    ストレージグループを表し、そのストレージグループが関連付けられたグループタイプ用のコマンドハンドラを指すように構成された関数ポインタ、そのストレージグループのピアストレージグループを指すように構成されたピアグループポインタ、およびそのストレージグループの子ストレージグループを指すように構成された子グループポインタを有するグループデータ構造体を受信し、
    少なくとも部分的にそのグループデータ構造体に基づいて、そのストレージグループ、そのピアストレージグループ、およびその子ストレージグループを含み、複数のストレージグループのそれぞれが、階層に組織化された複数のグループタイプのうちの選択された１つに関連付けられた、複数のストレージグループのボリュームマップを構成するように構成されたコントローラと
    を備えた、ストレージデバイス。
12. そのグループタイプが第１のグループタイプであって、その子ストレージグループが、階層上で第１のグループタイプの下に組織化される第２のグループタイプに関連付けられた、請求項１１に記載のストレージデバイス。
13. そのストレージグループが、そのピアストレージグループを含む複数のピアストレージグループを有し、そのピアグループポインタは、そのピアストレージグループを指すようにのみ構成される、請求項１１に記載のストレージデバイス。
14. ストレージシステムが、複数のストレージグループとして組織化され、それぞれのストレージパーティションが、グループタイプの中にあって階層上で最下位のグループタイプとして組織化されるパーティショングループタイプに関連付けられた複数のストレージパーティションを備え、コントローラが、少なくとも部分的にボリュームマップに基づいて複数のストレージパーティションにアクセスするようにさらに構成されている、請求項１１に記載のストレージデバイス。
15. ストレージグループを表し、そのストレージグループが関連付けられたグループタイプ用のコマンドハンドラを指すように構成された関数ポインタ、そのストレージグループのピアストレージグループを指すように構成されたピアグループポインタ、およびそのストレージグループの子ストレージグループを指すように構成された子グループポインタを有するグループデータ構造体を受信するステップと、
    少なくとも部分的にそのグループデータ構造体に基づいて、第１のストレージグループ、ピアストレージグループ、および子ストレージグループを含み、複数のストレージグループのうちのそれぞれが、階層に組織化されている複数のグループタイプのうちの選択された１つに関連付けられた、複数のストレージグループにアクセスするための複数のストレージグループのボリュームマップを構成するステップと
    を含む、ストレージグループにアクセスする方法。
16. 複数のストレージパーティションが複数のストレージグループとして組織化され、その複数のストレージパーティションのそれぞれが、グループタイプの中にあって階層上で最下位のグループタイプとして組織化されるパーティショングループタイプに関連付けられており、
    少なくとも部分的にボリュームマップに基づいて、複数のストレージパーティションにアクセスするステップをさらに含む、請求項１５に記載の方法。
17. そのグループタイプが第１のグループタイプであり、その子ストレージグループが第２のグループタイプに関連付けられており、
    コマンドハンドラで、そのストレージグループ宛ての第１のコマンドを受信するステップと、
    少なくとも部分的にその第１のコマンドに基づいて、その子ストレージグループ宛ての第２のコマンドを生成するステップと、
    コマンドハンドラで、その第２のグループタイプ用のパラメータを受信するステップと、
    少なくとも部分的にそのパラメータに基づいて、第２のコマンドを生成するステップと
    をさらに含む、請求項１５に記載の方法。

Images