(57)【要約】　　　（修正有）【課題】データアクセス要求（例えばストライプ書き込み）を個別にスケジュールすることが可能な複数の下位レベルの同期Ｉ／Ｏタスクに分解するＩ／Ｏタスクアーキテクチャを実現する。【解決手段】負荷とリソース使用のバランスを有効にとるため、それら下位レベルのＩ／Ｏタスクに必要なリソースを必要に応じて動的に割り当てることで、高いスケーラビリティを達成する。それらのＩ／Ｏタスクに階層順位を割り当てることにより、高レベルＩ／Ｏタスクの順方向伝搬を保証するとともに、リソースがデッドロック状態にならないことを保証する。【選択図】　図４
2004038932.tif 000002
【特許請求の範囲】
【請求項１】
ＲＡＩＤシステムにおいてデータアクセス要求を複数の下位レベルＩ／Ｏタスクに分解するための方法であって、
ＲＡＩＤシステムの構成要素をオブジェクトの階層集合として表現するステップと、
データアクセス要求に応じて前記階層集合における第１のオブジェクトに対応する第１のＩ／Ｏタスクを生成するステップと、
前記階層集合において前記第１のオブジェクトよりも下位にある第２のオブジェクトに対応する第２のＩ／Ｏタスクを生成するステップと、
イベントの発生に応じて、前記第１のＩ／Ｏタスクを複数の状態のうちの第１の状態から前記複数の状態のうちの第２の状態に変更するステップと、
からなる方法。
【請求項２】
前記方法は、前記第１のＩ／Ｏタスクを生成するときに該第１のＩ／Ｏタスクに所定のリソースを動的に割り当てるステップをさらに含み、
前記変更するステップは、前記第１のＩ／Ｏタスクについて前記所定のリソースのすべてがすでに割り当てられていた場合、前記第１のＩ／Ｏタスクを前記第１の状態から前記第２の状態に変更する、請求項１の方法。
【請求項３】
ＲＡＩＤシステムにおいてデータアクセス要求を複数の下位レベルＩ／Ｏタスクに分解するためのストレージシステムであって、
ストレージシステムの実施形態を表わすオブジェクトの階層集合を提供し、データアクセス要求に応じて前記階層集合内の第１のオブジェクトから親Ｉ／Ｏタスクを生成し、前記階層集合内の第２のオブジェクトから子Ｉ／Ｏタスクを生成して前記親Ｉ／Ｏタスクの少なくとも一部を実現するように構成されたインスタンス化モジュールと、
前記親Ｉ／Ｏタスクおよび子Ｉ／Ｏタスクを受信して前記親Ｉ／Ｏタスク及び子Ｉ／Ｏタスクの実行をスケジューリングし、前記子Ｉ／Ｏタスクのスケジューリングをイベントの発生に応じて行い、前記子Ｉ／Ｏタスクの生成に続く前記親Ｉ／Ｏタスクと同期しないようにするように構成されたＩ／Ｏマネージャと、
からなるストレージシステム。
【請求項４】
前記子Ｉ／Ｏタスクが生成されたときに該子Ｉ／Ｏタスクにリソースを動的に割り当てるように構成されたリソースマネージャをさらに含む、請求項３のストレージシステム。
【請求項５】
前記Ｉ／Ｏマネージャは、前記子Ｉ／Ｏタスクに割り当てられるリソースが利用可能でない場合は前記子Ｉ／Ｏタスクの処理を保留するようにさらに構成されている、請求項４のストレージシステム。
【請求項６】
前記リソースマネージャは、前記子Ｉ／Ｏタスクが完了したときに該子Ｉ／Ｏタスクに割り当てられたリソースの割り当てを解除するようにさらに構成されている、請求項４のストレージシステム。
【請求項７】
前記子Ｉ／Ｏタスクは、該子Ｉ／Ｏタスクが完了したときにその完了を前記親Ｉ／Ｏタスクに示すように構成されている、請求項３のストレージシステム。
【請求項８】
前記インスタンス化モジュールは、前記子Ｉ／Ｏタスクがエラーに遭遇した場合は前記第１のオブジェクトに対するコールによってエラー処理タスクを生成するようにさらに構成されている、請求項３のストレージシステム。
【請求項９】
前記インスタンス化モジュールは、バイパスＩ／Ｏタスクをインスタンス化するようにさらに構成されている、請求項３のストレージシステム。
【請求項１０】
各Ｉ／Ｏタスクが、ディスク読み出し、ディスク書き込み、ボリューム書き込み、ボリューム読み出し、ミラー書き込み、ミラー読み出し、プレックス書き込み、プレックス読み出し、グループ読み出し、アレイ書き込み、ＲＡＩＤグループのパリティ復元、ストライプパリティ復元、及び、ミラー検証のうちのいずれか１つである、請求項３のストレージシステム。
【請求項１１】
ＲＡＩＤシステムにおいてデータアクセス要求を複数の下位レベルＩ／Ｏタスクに分解するためのストレージシステムにおけるコンピュータ読み取り可能な媒体であって、
ストレージシステムの実施形態を表わすオブジェクトの階層集合を提供し、データアクセス要求に応じて前記階層集合内の第１のオブジェクトから親Ｉ／Ｏタスクを生成し、前記階層集合内の第２のオブジェクトから子Ｉ／Ｏタスクを生成して前記親Ｉ／Ｏタスクのうちの少なくとも一部を実施するステップと、
前記親Ｉ／Ｏタスクおよび子Ｉ／Ｏタスクを受信して前記親Ｉ／Ｏタスクおよび子Ｉ／Ｏタスクの実行をスケジューリングし、前記子Ｉ／Ｏタスクのスケジューリングをイベントの発生に応じて行い、前記子Ｉ／Ｏタスクの生成に続く前記親Ｉ／Ｏタスクと同期しないようにするステップと、
を実施するためのプログラム命令を含むコンピュータ読み取り可能な媒体。
【請求項１２】
前記子Ｉ／Ｏタスクが生成されたときに該子Ｉ／Ｏタスクにリソースを動的に割り当てることをさらに含む、請求項１１のコンピュータ読み取り可能な媒体。
【請求項１３】
前記子Ｉ／Ｏタスクに割り当てられるリソースが利用可能でない場合は前記子Ｉ／Ｏタスクの処理を保留することをさらに含む、請求項１２のストレージシステム。
【請求項１４】
前記子Ｉ／Ｏタスクが完了したときに該子Ｉ／Ｏタスクに割り当てられた前記リソースの割り当てを解除することをさらに含む、請求項１２のストレージシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、概して高信頼性の電子データ記憶装置に関するものであり、詳しくはデータアクセス要求を複数の小さなタスクに分解するためのアーキテクチャに関するものである。
【０００２】
【従来の技術】
ファイルサーバは、メモリ、テープまたはディスクのアレイ等、書き込み可能な持続性記憶装置上で、情報の編成に関するファイルサービスを提供するコンピュータである。ファイルサーバまたはファイラーには、記憶装置（例えばディスクなど）上で情報をディレクトリ及びファイルの階層構造として論理編成するためのファイルシステムを実現するオペレーティングシステムが含まれる。各「ディスク上」のファイルは、データ構造（例えばディスクブロックなど）の集まりとして構成され、そのファイルの実際のデータ等の情報を格納するように構成される。一方、ディレクトリは、他のファイル及びディレクトリに関する情報を格納する特別な形態のファイルとして実現される。
【０００３】
ファイルサーバは、クライアント／サーバ形態の情報配送に従って動作するように構成され、多数のクライアントがそのサーバに格納されたファイルにアクセスできるようになっている。この形態の場合、クライアントは、ポイント・ツー・ポイントリンク、共有ローカルエリアネットワーク、ワイドエリアネットワーク、あるいは、インターネット等の公共ネットワーク上で実施される仮想私設ネットワークなどのコンピュータネットワークを介してストレージシステムに「接続」するためのアプリケーションを、コンピュータ上で実行している場合がある。各クライアントは、ネットワークを介してファイルシステムプロトコルメッセージをストレージシステムに発行（パケットの形態で）することによって、ファイルシステムのサービスをファイラーに要求することができる。しかしながら、ファイラーは、（例えばクライアントまたは「ホスト」）コンピュータに直接取り付けられた記憶装置のアセンブリとして動作するように構成される場合もある。その場合，ミューザは、それらの記憶装置に対してデータアクセス（即ち、読み出し及び／又は書き込み）を行なうため、ファイルシステムのサービスを要求することができる。
【０００４】
一般的なタイプのファイルシステムは「定位置書き込み」ファイルシステムであり、その一例はバークレイ・ファーストファイルシステムである。定位置書き込みファイルシステムでは、データブロック等のデータ構造のディスク上での位置が通常、固定になっている。データブロックに対する変更は、定位置書き込みファイルシステムに従って「定位置」で行なわれる。ファイルの更新がそのファイルのデータ量を超えるものである場合、データブロックがさらに割り当てられる。
【０００５】
ディスクアレイの運用時にディスクやテープ等の他の記憶媒体が故障することは、極めて一般的である。高性能ストレージシステムの目標は、データ損失が生じるまでの平均時間（ＭＴＴＤＬ）を可能な限り長くすることであり、システムの推定サービス寿命よりも長くすることが望ましい。１以上の記憶装置が故障した場合、データが失われる可能性があり、その装置からデータを復元することが不可能になる。データ損失を回避するための一般的な方法としては、ミラーリング、バックアップ、及び、パリティ保護などが挙げられる。ミラーリングは、同一のデータを２台以上のディスクに記憶することにより、１台のディスクが故障しても、そのミラーディスクを用いてデータの読み出しができるようにする方法である。バックアップは、あるディスクから他のディスクにデータを定期的に複製する方法であり、両方のディスクが同時に故障することはめったに起こりえないということを前提にしている。パリティ保護が一般的である理由は、この方法が最小限の数のディスクドライブをストレージシステムに追加するだけで、データ損失を招くことなく１台以上のディスクの故障を許容するデータの冗長符号化を可能にするからである。
【０００６】
パリティ保護は、ディスク等の記憶装置上のデータ損失に対する保護のために、コンピュータシステムで用いられる。パリティ値は特定のワードサイズ（通常は１ビット）のデータを異なるデータを有する複数の同様のディスクにわたって加算（通常はモジューロ２で）することによって計算され、その結果がディスクに格納される。すなわち、パリティは、各ディスク上の所定位置にあるビットから構成された１ビット幅のベクトルに対して計算される。１ビットベクトルに対する加算と減算は排他的論理和（ＸＯＲ）演算と等価であり、加算および減算は、ＸＯＲ演算で置き換えることができる。その後、ディスクはいずれのディスクの故障からも保護される。パリティを格納しているデータが故障した場合、そのパリティはデータから復元することができる。データディスクのうちの１台が故障した場合、そのデータは、残りのデータディスクの内容を加算した後、その結果を記憶されているパリティから減算することによって、再現することができる。
【０００７】
一実施形態において、通常、ディスクは複数のパリティグループに分割され、各グループが１台以上のパリティディスクと１台のパリティディスクとを有する。ディスク空間は複数のストライプに分割され、各ストライプが各ディスクから１ブロックを保持する。ストライプのブロックは通常、パリティグループ内の各ディスク上で同じ位置にある。１ストライプ内で、１ブロックを除くすべてのブロック（「データブロック」）はデータを保持し、１ブロック（「パリティブロック」）はすべてのディスクからのすべてのデータのＸＯＲをとることによって計算されたパリティを保持する。パリティブロックがすべて１台のディスク上に格納され、すべて（かつ唯一）のパリティ情報を保持する１台のディスクが設けられる場合、そのシステムはＲＡＩＤレベル４実施形態と呼ばれる。各ストライプにおいてパリティブロックが異なるディスク内に格納される場合、通常は回転パターンで格納され、実施形態はＲＡＩＤレベル５である。当業者であれば、ＲＡＩＤレベル４及び５の他にも、いくつかの他の周知のＲＡＩＤレベル、及び、それらのＲＡＩＤレベルの組み合わせが存在することは、知っているはずである。
【０００８】
既知の実施形態において、ＲＡＩＤサブシステムの頂点で動作するファイルシステムは、ＲＡＩＤディスクアレイをブロックの大きな集合として扱い、ＲＡＩＤディスクアレイ内で、各ブロックに連続的に番号を付ける。ファイルのデータブロックは各ストライプをできる限り完全に埋めるように複数のデータディスクに分散され、これによって各データブロックを異なるディスク上のストライプに配置している。最初のストライプのＮ個のデータブロックをＲＡＩＤアレイのＮ台のデータディスクに割り当てたあと、ファイル全体がＲＡＩＤアレイに書き込まれるまで、同様のやり方で残りのデータブロックも後続のストライプに割り当てる。このように、ファイルは、ＲＡＩＤシステムの複数のデータディスクにわたって、モジューロＮ台のデータディスクから成るストライプに書き込まれる。ストライプが埋まると、それらのストライプはＲＡＩＤサブシステムに送信されて格納される。
【０００９】
既知の実施形態において、ＲＡＩＤサブシステムはロッキングタスク及びＩ／Ｏタスクをストライプレベルで実施し、これらのタスクがストライプ所有者専用スレッドの集合を通して実施されている。各スレッドは、１ストライプに対して一度に同時のＩ／Ｏ処理を実施し、同一のストライプに対するさらなるＩ／Ｏ要求は、そのストライプ所有者に対する待ち行列に並べられる（相互排他にする）。ストライプＩ／Ｏ及びＸＯＲ演算に利用可能なスレッド数が限られていることは、ボトルネックを引き起こし、特に復元処理中のシステム応答時間に悪影響を与える可能性がある。
【００１０】
既知の実施形態において、ディスク故障やディスクの取り外しによるＲＡＩＤ状態移行は、Ｉ／Ｏパスとうまく連携しないことがある。その結果、バッファが未使用ディスクを指し示し、エラーを引き起こし、それが原因でシステムが復元不能になる場合がある。上記のように、ＲＡＩＤストライプ所有者からディスクドライバへのＩ／Ｏは同期している。Ｉ／Ｏパスが状態移行を取り扱う場合があるということと合わせると、これはデッドロック状態を引き起こす可能性がある。
【００１１】
これらの既知のシステムで用いられるリソース（スレッド及びメモリバッファ）はブート時に静的に割り当てられるものであり、Ｉ／Ｏ処理を実施する前にバッファを予約するための単純な予約手段が存在する。こうした割り当ては、一般的に最悪ケースのエラー処理を考慮しているので、大量のリソースが二度と使用されないにも関わらず割り当てられ、システム内の他のＩ／Ｏスレッドから利用できないようになっている。そのため、システムの負荷変動及び構成変更に適応するための能力が削減される場合がある。
【００１２】
発明の概要
本発明は、ファイルシステムによって要求されたデータアクセス要求、例えばストライプ書き込みを、個別にスケジュール可能な複数の下位レベルの同期Ｉ／Ｏタスクに分解するための、Ｉ／Ｏタスクアーキテクチャを実現する。これらの下位レベルＩ／Ｏタスクに必要なリソースは必要に応じて動的に割り当てられ、負荷のバランスをとり、リソースを効率的に利用して、性能損失を招くことなく高い安定性を実現する。これらのＩ／Ｏタスクには階層順位が割り当てられ、高レベルＩ／Ｏタスクの順方向伝搬を保証するとともに、リソースがデッドロック状態にならないことを保証している。このアーキテクチャは、同一ディスク上の複数のデータブロックを効率的に処理することが可能であり、例えばディスク書き込みが最適なチェーン長になる。
【００１３】
一態様において本発明は、ＲＡＩＤシステムにおいてデータアクセス要求を複数の下位レベルＩ／Ｏタスクに分解するための方法に関するものである。この方法は、ＲＡＩＤシステムの構成要素をオブジェクトの階層集合として表現すること、データアクセス要求に応じて前記階層集合内の第１のオブジェクトから親Ｉ／Ｏタスクを生成すること、前記階層集合内の第２のオブジェクトから子Ｉ／Ｏタスクを生成して前記Ｉ／Ｏタスクの少なくとも一部を実施すること、及び、第１のイベントの発生に応じて前記子Ｉ／Ｏタスクの実行をスケジューリングし、前記子Ｉ／Ｏタスクの実行が前記親Ｉ／Ｏタスクの実行を条件としないようにすることを含む。
【００１４】
他の実施形態において、本方法は、第１のイベントの発生に応じて子Ｉ／Ｏタスクの実行をスケジューリングし、子Ｉ／Ｏタスクの生成直後に、子Ｉ／Ｏタスクの実行が親Ｉ／Ｏタスクの実行を条件としないようにすることを含む。さらに他の実施形態において、本方法は、第１のイベントの発生に応じて子Ｉ／Ｏタスクの実行をスケジューリングし、親Ｉ／Ｏタスクと子Ｉ／Ｏタスクとの間に何も同期点が必要ないようにすることを含む。さらに他の実施形態において、本方法は、親Ｉ／Ｏタスクと子Ｉ／Ｏタスクを個別のスレッドにキューイングすることを含む。さらに他の実施形態において、本方法は、親Ｉ／Ｏタスクと子Ｉ／Ｏタスクを個別のコンピュータ装置にキューイングすることを含む。
【００１５】
さらに他の実施形態において、本方法は、親Ｉ／Ｏタスクと子Ｉ／Ｏタスクを個別のプロセスにキューイングすることを含む。さらに他の実施形態において、本方法は、第２のイベントに応じて親Ｉ／Ｏタスクの実行をスケジューリングすること、及び、前記親Ｉ／Ｏタスクの実行に応じて子Ｉ／Ｏタスクを生成することを含む。さらに他の実施形態において、本方法は、親Ｉ／Ｏタスク及び子Ｉ／ＯタスクをＩ／Ｏスレッドにキューイングし、親Ｉ／Ｏタスク及び子Ｉ／Ｏタスクが個別にスケジュール可能なエンティティにすることを含む。さらに他の実施形態において、本方法は、子Ｉ／Ｏタスクが生成されたときに、リソースを子Ｉ／Ｏタスクに動的に割り当てることを含む。さらに他の実施形態において、本方法は、子Ｉ／Ｏタスクが完了したときに、子Ｉ／Ｏタスクに割り当てられたリソースの割り当てを解除することを含む。
【００１６】
さらに他の実施形態において、本方法は、リソースが利用可能でない場合、子Ｉ／Ｏタスクを保留することを含む。さらに他の実施形態において、本方法は、子Ｉ／ＯタスクをＩ／Ｏスレッドから待ち行列に移動させることを含む。さらに他の実施形態において、本方法は、子Ｉ／Ｏタスクが、階層集合内で第２のオブジェクトよりも高レベルある第１のオブジェクトに対して何も依存関係を有しないことを含む。さらに他の実施形態において、本方法は、子Ｉ／Ｏタスクがエラーに遭遇した場合、親Ｉ／Ｏタスクによってエラー処理Ｉ／Ｏタスクを生成することを含む。さらに他の実施形態において、本方法は、標準インタフェースを有する親Ｉ／Ｏタスク及び子Ｉ／Ｏタスクを定義することを含む。さらに他の実施形態において、本方法は、開始処理および終了処理を含む子Ｉ／Ｏタスクを定義することを含む。
【００１７】
さらに他の実施形態において、本方法は、開始処理、終了処理、及び、子Ｉ／Ｏタスク終了処理を含む親Ｉ／Ｏタスクを定義することを含む。さらに他の実施形態では、子Ｉ／ＯタスクがバイパスＩ／Ｏタスクである。さらに他の実施形態では、子Ｉ／Ｏタスクが第１の子Ｉ／Ｏタスクであり、本方法は、第２の子Ｉ／Ｏタスクを生成して親Ｉ／Ｏタスクの少なくとも一部を実施すること、及び、第２のイベントの発生に応じて前記第２の子Ｉ／Ｏタスクの実行をスケジューリングし、前記第２の子Ｉ／Ｏタスクの実行が前記親Ｉ／Ｏタスクまたは前記第１のＩ／Ｏタスクの実行を条件としないようにすることを含む。
【００１８】
さらに他の実施形態において、本方法は、第１のＩ／Ｏタスク及び第２のＩ／Ｏタスクの完了時に、親Ｉ／Ｏタスクを完了することを含む。さらに他の実施形態では、前記第１及び第２のイベントのうちの一方が、ディスクＩ／Ｏの完了、ＲＡＩＤグループＩ／Ｏの完了、ミラーＩ／Ｏの完了、網Ｉ／Ｏの完了、ボリュームＩ／Ｏの完了、及び、ＲＡＩＤクライアントからの要求のうちの１つである。さらに他の実施形態において、本方法は、階層集合内の第３のオブジェクトから孫Ｉ／Ｏタスクを生成し、子Ｉ／Ｏタスクの少なくとも一部を実施すること、第２のイベントの発生に応じて孫Ｉ／Ｏタスクの実行をスケジューリングし、孫Ｉ／Ｏタスクの実行が、親Ｉ／Ｏタスクの実行又は子Ｉ／Ｏタスクの実行を条件としないようにすること、及び、孫Ｉ／Ｏタスクから孫Ｉ／Ｏタスクの実行の完了を子Ｉ／Ｏタスクに示すことを含む。
【００１９】
他の態様において本発明は、ＲＡＩＤシステムにおいてデータアクセス要求を複数の下位レベルＩ／Ｏタスクに分解するための方法に関するものである。この方法は、ＲＡＩＤシステムの構成要素をオブジェクトの階層集合で表現すること、データアクセス要求に応じて前記階層集合内の第１のオブジェクトい対応する第１のＩ／Ｏタスクを生成すること、前記階層集合内で前記第１のオブジェクトよりも下位にある第２のオブジェクトに対応する第２のＩ／Ｏタスクを生成すること、及び、イベントの発生に応じて前記第１のＩ／Ｏタスクを複数の状態のうちの第１の状態から前記複数の状態のうちの第２の状態に変更することを含む。さらに他の実施形態において、各Ｉ／Ｏタスクは、ディスク読み出し、ディスク書き込み、ボリューム書き込み、ボリューム読み出し、ミラー書き込み、ミラー読み出し、網書き込み、網読み出し、グループ読み出し、アレイ書き込み、ＲＡＩＤグループのパリティ復元、ストライプパリティ復元、及び、ミラー検証のうちの１つである。
【００２０】
さらに他の実施形態において、本方法は、第１のＩ／Ｏタスクが生成されたときに所定のリソースを第１のＩ／Ｏタスクに動的に割り当てることを含み、前記変更するステップは、前記所定のリソースのすべてが前記第１のＩ／Ｏタスクに割り当てられたときに前記第１のＩ／Ｏタスクを第１の状態から第２の状態に変更することを含む。さらに他の実施形態において、本方法は、標準インタフェースを有する第１及び第２のＩ／Ｏタスクを定義することを含む。さらに他の実施形態では、前記第２のＩ／Ｏタスクは、前記第１のＩ／Ｏタスクの下方に２つ以上生成される。さらに他の実施形態では、前記第１の状態及び第２の状態は、Ｉ／Ｏタスク実行状態、子Ｉ／Ｏタスク保留状態、ＸＯＲタスク保留状態、Ｉ／Ｏタスク終了状態、及び、Ｉ／Ｏタスク保留状態のうちの１つである。
【００２１】
さらに他の態様において本発明は、ＲＡＩＤシステムにおいてストライプに関する複数のデータアクセス要求を複数の下位レベルＩ／Ｏタスクに分解するための方法に関するものである。この方法は、ＲＡＩＤシステムの構成要素をオブジェクトの階層集合で表現すること、第１のストライプに関する第１のデータアクセス要求に応じて前記階層集合内の第１の親オブジェクトから第１の親Ｉ／Ｏタスクを生成すること、第２のストライプに関する第２のデータアクセス要求に応じて前記階層集合内の第２の親オブジェクトから第２の親Ｉ／Ｏタスクを生成すること、及び、前記第１の親Ｉ／Ｏタスク及び第２の親Ｉ／ＯタスクをＩ／Ｏスレッドにキューイングすることを含む。
【００２２】
さらに他の態様において本発明は、ＲＡＩＤシステムにおいてデータアクセス要求を複数の下位レベルＩ／Ｏタスクに分解するためのコンピュータ読み取り可能なプログラム部分が内部に実装された製品に関するものであり、当該製品のコンピュータ読み取り可能なプログラム部分は上に列挙した方法を実現する。さらに他の態様において本発明は、ＲＡＩＤシステムにおいてデータアクセス要求を複数の下位レベルＩ／Ｏタスクに分解するためのストレージシステムに関するものである。このストレージシステムは、インスタンス生成モジュール及びＩ／Ｏマネージャを含む。さらに他の実施形態において、このストレージシステムは、リソースマネージャを含む。
【００２３】
【発明の実施の形態】
全体図、図１は、本発明に有利に用いられるストレージシステム１０５を含む環境１００を示すものである。ストレージシステム１０５は、ディスクアレイ１１５のディスク１１０ａ、１１０ｎ等、まとめて１１０で示す記憶装置に対して情報の編成に関するサービスを提供するコンピュータである。このストレージシステム１０５は、システムバス１４０によって相互接続されたプロセッサ１２０、メモリ１２５、ネットワークアダプタ１３０及びストレージアダプタ１３５を含む。
【００２４】
図示の実施形態において、メモリ１２５は、データアクセス要求を処理するためのＩ／Ｏタスクアーキテクチャを実施するインスタンス生成モジュール１４５及びＩ／Ｏマネージャ１５０を含む。インスタンス生成モジュール１４５は、例えばＩ／Ｏタスクなど、オブジェクトのデータ構造を定義するソフトウェア及び／又はハードウェアの一部であり、Ｉ／Ｏタスクの各インスタンスの生成を管理するものである。Ｉ／Ｏマネージャ１５０は、Ｉ／Ｏスレッド化手段を実現するソフトウェア及び／又はハードウェアの一部である。また、メモリ１２５は、リソースの割り当てを管理するためのリソースマネージャを実施するリソースマネージャモジュール１５５も含む。一実施形態において、Ｉ／Ｏタスクの各インスタンスが一種のリソースである理由は、Ｉ／Ｏタスクのインスタンスを生成するために、メモリの一部が必要とされ、ＣＰＵ時間が必要とされるからである。このような実施形態の場合、リソースマネージャ１５５とインスタンス生成モジュール１４５は、同一エンティティである。
【００２５】
また、メモリ１２５は、ディスク１１０上のデータを論理編成するためのストレージマネージャを実施するストレージオペレーティングシステム１６０も含む。一実施形態において、ストレージシステム１０５はデータをファイルの形態で受信し（例えば、ストレージシステム１０５がファイルサーバの場合など）、ストレージマネージャが受信したデータをディスク１１０上でディレクトリ及びファイルの階層構造として論理編成する。他の実施形態では、ストレージシステム１０５はデータをデータブロックの形態で受信し、ストレージマネージャが受信したデータブロックをディスク１００上の保管位置に論理編成する。
【００２６】
この例示の実施形態は、本発明に関するソフトウェアプログラム及びデータ構造を格納するため、メモリ１２５がプロセッサ１２０及びアダプタ１３０、１３５によってアドレス指定可能な記憶位置を含むので、図示のように構成されている。これらのブロックは、本発明の範囲を外れることなく、完全に実施することも部分的に実施することもできる。
【００２７】
例えば、プロセッサ１２０及びアダプタ１３０、１３５は、前記ソフトウェアコードを実行し、前記データ構造を操作するように構成された処理要素及び／又は論理回路を含む。同様に、モジュール１４５、１５０、１５５は、例えばＦＰＧＡ及び／又はＡＳＩＣデバイスを用いてハードウェアで実施することができる。他の実施形態では、分散コンピューティングモデルが用いられる場合もある。独自にプロセッサ（図示せず）を有する他のストレージシステム（図示せず）は、ネットワーク１４０及び／又はネットワーク１８０を介してストレージシステム１０５及びそのプロセッサ１２０と通信する。Ｉ／Ｏタスク処理は、複数のストレージシステムのうちの任意のものにわたって分散され、それらのプロセッサはロード・バランシング等、様々な最適化技術を利用している。ストレージシステム１０５が分散環境で実施される実施形態の中には、ファイルシステム及びファイルシステムセマンティックが、モジュール１４５、１５０及び１５５を含む他のコンピュータ装置と個別に通信する１以上のコンピュータ装置によって管理されるものもある。当業者であれば、本明細書に記載する本発明に関するプログラム命令を格納および実行するために、様々なコンピュータ読み取り可能な媒体を含めて、他の処理手段及び他の記憶手段を用いることも可能であることは明らかである。
【００２８】
ネットワークアダプタ１３５は、ポイント・ツー・ポイント接続やローカルエリアネットワーク等の共用媒体を含むコンピュータネットワーク１８０を介してストレージシステム１０５をクライアント１７５に接続するために必要な機械回路、電気回路及び／又は信号回路を含む。クライアントコンピュータ１７５は、アプリケーションを実行するように構成された汎用コンピュータである。さらに、クライアントコンピュータ１７５は、クライアント／サーバ形態の情報配送に従ってストレージシステム１０５と対話することができる。すなわち、クライアント１７５がストレージシステム１０５のサービスを要求すると、ストレージシステム１０５はクライアント１７５によって要求されたサービスの結果を返すことができる。ストレージシステム１０５がファイルサーバである一実施形態において、これはファイルシステムプロトコルフォーマット（例えば共通インターネットファイルシステム（ＣＩＦＳ）プロトコルやネットワークファイルシステム（ＮＦＳ））をカプセル化するパケットを、ネットワーク１７５を介して交換することによって行なわれる。
【００２９】
ストレージアダプタ１３５は、ストレージシステム１０５上で実行されているストレージオペレーティングシステム１６０と協働して、クライアント１７５から要求された情報にアクセスする。情報は、ビデオテープ、光学装置、ＤＶＤ、磁気テープ、バブルメモリ、並びに、データ及びパリティ情報を含む情報を記憶するのに適した何らかの同様の媒体など、任意の種類の書き込み可能媒体の取り付けアレイに格納することができる。しかしながら、本明細書に記載する例示の実施形態では、情報はディスク１１０のアレイ１１５に格納されるのが好ましい。ストレージアダプタ１３５は、Ｉ／Ｏ相互接続構成によってディスク１１０を従来の高性能ファイバーチャネルシリアルリンク接続形態などに接続するための入出力（Ｉ／Ｏ）インタフェース回路を含む。情報はストレージアダプタ１３５によって取得され、システムバス１４０を介してネットワークアダプタ１３０に転送する前に、必要であればプロセッサ１２０（またはアダプタ１３５自体）で処理が施され、そこで情報がパケットに成形され、クライアント１７５に返送される。
【００３０】
アレイ１１５における情報の格納は、ディスク空間の全体的な論理配置を定義する、物理記憶ディスク１１０のあつまりを含む１以上のストレージ「ボリューム」として実施することが好ましい。各ボリュームは通常、独自のストレージマネージャに関連付けられる。ボリューム内のディスクは、ＲＡＩＤグループと呼ばれる場合もある１以上のＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ　Ａｒｒａｙ　ｏｆ　Ｉｎｄｅｐｅｎｄｅｎｔ（ｏｒ　Ｉｎｅｘｐｅｎｓｉｖｅ）　Ｄｉｓｋｓ）グループに編成されるのが通常である。ＲＡＩＤ実施形態は、データ「ストライプ」をＲＡＩＤグループ内の所定数の物理ディスクにわたって冗長書き込みし、そのストライプ化されたデータに関する冗長情報を適切に記憶することによって、データ記憶の信頼性／完全性を向上させるものである。この冗長情報によって、記憶装置が故障したときに失われたデータの復元が可能になる。
【００３１】
図２は、ディスクアレイ１１５（図１）に含まれるボリュームの構成情報を表す一連の論理オブジェクト２００の例示的実施形態を示している。図示のように、一連のオブジェクト２００は、階位に従ってツリー状に配置される。集合２００を成すこれらのオブジェクトは、ＲＡＩＤオブジェクトと呼ばれることもある。一連のオブジェクト２００には、ボリュームオブジェクト２０５、ミラーオブジェクト２１０、並びに、プレックスオブジェクト２１５ａ及び２１５ｂ（まとめて２１５と記す）が含まれる。一連のオブジェクト２００には、ＲＡＩＤグループオブジェクト２２０ａ、２２０ｂ、２２０ｃ及び２２０ｄ（まとめて２２０で記す）、並びに、ディスクオブジェクト２２５ａ、２２５ｂ、２２５ｃ、２２５ｄ、２２５ｅ、２２５ｆ、２２５ｇ、２２５ｈ、２２５ｉ、２２５ｊ、２２５ｋ及び２２５ｌ（まとめて２２５で記す）が更に含まれる。一連のオブジェクト２００は、ボリュームオブジェクト２０５をルートノードとして階層ツリーに構成される。一実施形態においてこれら一連のオブジェクト２００はオブジェクト指向プログラミングパラダイムにおけるオブジェクトを用いて実施される場合もあるが、この用語はかかる実施形態に制限されるものではない。概して、こうしたオブジェクトは、物理記憶装置の論理的組み合わせ／構成を表す抽象エンティティを指すものであり、例えば図１に図示した実施形態のディスク１１０、あるいはそれらの一部を指すものである。
【００３２】
図示の実施形態は、ハイブリッドＲＡＩＤレベルを表している。ＲＡＩＤグループ２２０は、データを２台のディスク（即ち２２５ａ及び２２５ｂ）上にストライピングするとともに第３のパリティディスクを有するＲＡＩＤレベル４の実施形態を表している。ミラーオブジェクトは、ミラーオブジェクト２１０の両側の各々にあるディスクオブジェクトを２ディスクオブジェクト２２５づつツリー下ってゆき、データをミラーリングするＲＡＩＤレベル１の実施形態を表している。例えば、ディスクオブジェクト２２５ｇはディスクオブジェクト２２５ａをミラーリングしており、つまりこれは両オブジェクトが同じデータを格納することを意味している。図示の実施形態は、一連のオブジェクト２００をハイブリッドＲＡＩＤレベルにするための可能な構成の１つを描いたものである。当業者であえば、他の構成及び／又は実施形態のオブジェクトも考えられるであろう。さらに、本発明の方法が特定ＲＡＩＤレベルの実施形態に限られることはなく、本明細書に記載する本発明の方法には、ハイブリッドＲＡＩＤレベルが有利に用いられる。同様に、プレックスオブジェクト２１５間の対称性も必須ではない。例えば、ディスクレベルのミラーリングは、下記の物理ディスクオブジェクトを用いて論理複製されたディスクオブジェクトとして表現することができる。
【００３３】
実施形態によっては、設定情報は、ディスクブロック番号（「ＤＢＮ」）にマッピングされた仮想ブロック番号（「ＶＢＮ」）を含む場合がある。図２には、仮想ブロック番号の範囲２３０ａ及び２３０ｂ（まとめて２３０で記す）が図示されている。ＶＢＮはＤＢＮの論理表現である。ＤＢＮは、アレイ１１５内のディスク１１０上に配置された所定サイズの実際の記憶空間を表すものである。一実施形態では、仮想ブロックサイズは４キロバイトである。ＶＢＮは、例えば整数値を用いて表現される。ＶＢＮの範囲２３０は、上向き法で決定され、一連のオブジェクト２００において各オブジェクトがそのオブジェクトに関連する範囲のＶＢＮを有する。ディスク１１０に対応するディスクオブジェクト２２５が有するＶＢＮの範囲は、そのディスク上で利用可能な記憶空間の記憶ブロック（即ち、ＤＢＮ）の数以下である。記憶ブロックサイズがＶＢＮのサイズと同じである場合、１対１の対応が存在する。ＶＢＮは論理マッピングであるから、ＶＢＮの範囲はディスク１１０上で連続している必要がない。例えば、ディスクオブジェクト２２５ａが０〜１０の範囲のＶＢＮおよび４０〜５０の範囲のＶＢＮに関連し、ディスクオブジェクト２２５ｂが２０〜４０の範囲のＶＢＮに関連し、ディスクオブジェクト２２５ｃが１０〜２０の範囲のＶＢＮおよび８０〜９０の範囲のＶＢＮに関連するという場合もある。
【００３４】
ＲＡＩＤグループオブジェクト２２０は、そのディスクオブジェクト２２５のＶＢＮの総計に関連している。例えば、ＲＡＩＤグループ２２０ａのＶＢＮの範囲は、ディスクオブジェクト２２５ａ、２２５ｂおよび２２５ｃの総計である。これらのディスクオブジェクトを用いた上記例の場合、ＲＡＩＤグループオブジェクト２２０ａは０〜５０及び８０〜９０の範囲のＶＢＮを有し、この範囲はディスクオブジェクト２２５ａ、２２５ｂ及び２２５ｃのＶＢＮを結合したものになっている。プレックスオブジェクト２１５は、そのＲＡＩＤグループオブジェクト２２０のＶＢＮの総計に関連している。例えば、プレックスオブジェクト２１５ａのＶＢＮの範囲は、ＲＡＩＤグループオブジェクト２２０ａ及び２２０ｂの総計である。ＲＡＩＤグループオブジェクトを用いた上記例において、ＲＡＩＤグループ２２０ｂがＲＡＩＤグループ２２０ａと同じサイズであれば、プレックス２１５は０〜１２０の範囲のＶＢＮを有することになる。
【００３５】
この実施形態において、ミラーオブジェクト２１０はプレックス２１５ａを２１５ｂに（あるいはその逆に）ミラーリングするので、このミラーオブジェクトのＶＢＮの範囲２３０はそのプレックスオブジェクト２１５の総計にはならない。そうではなく、ミラーオブジェクト２１０のＶＢＮの範囲は、そのプレックスオブジェクト２１５のＶＢＮの結合になる。従って、複数のプレックスオブジェクト２１５の各々に関するディスク１１０の実装が同一であり、そのマップの範囲が同一であれば、ＶＢＮ２３０ａは２３０ｂと同一になり、ミラーオブジェクト２１０のＶＢＮの範囲２３０は２３０ａと同一になる。ボリュームオブジェクト２０５のＶＢＮの範囲２３０は、ミラーオブジェクト２１０のＶＢＮの範囲２３０である。一実施形態において、ＤＢＮからＶＢＮへの変換はミラーオブジェクト２１０レベルで実施される。この実施形態の場合、ミラーオブジェクト下方のレベルにあるオブジェクトはＤＢＮ参照を用いて対象記憶空間を参照し、ミラーオブジェクト上方にあるオブジェクトはＶＢＮ参照を用いて対象記憶空間を参照する。
【００３６】
他の実施形態では、ストレージマネージャが、受信したデータを各ＶＢＮ範囲２３０ａおよび２３０ｂに個別に関連付ける場合がある。非対称の場合であっても、ミラーリングされるデータは、ＶＢＮ２３０ａ及び２３０ｂの各々において、同一ブロックに入れなければならない。他の実施形態では、プレックスオブジェクト２１５ａと２１５ｂが非対称になっていて、一方のプレックスが他方のプレックスよりも微小ＶＢＮだけ広い範囲のＶＢＮを有する場合がある。ミラーオブジェクト２１０のＶＢＮの範囲２３０のサイズは、ミラーリングされたＶＢＮの範囲にミラーリングされていない微小ＶＢＮを加えたものになる。
【００３７】
各レベルのオブジェクトに対するＶＢＮ範囲の関連付けは、ＲＡＩＤマップとよばれることがある。一連のオブジェクト２００のＲＡＩＤマップをストレージマネージャに送信することによって、ストレージマネージャは、ディスクアレイ１１５トポロジに関する構成情報を得て、ディスク書き込み及び／又はディスク読み出しを最適化しつつ、データをストライプ（「アレイ」）のアレイとしてＶＢＮに関連付けることができる。
【００３８】
図１を参照すると、ストレージシステム１０５がクライアントから要求を受信した場合、例えば、何らかのデータをディスク１１０に送信してセーブすることの要求を受信した場合、ストレージシステム１０５はその要求を満たすためのタスクを実行する。送信データは、アレイ１１５のディスク１１０のうちの１以上に無事に書き込まれるまで、メモリ１２５に存在する。一実施形態では、送信データは不揮発性ＲＡＭ（「ＮＶＲＡＭ」）に格納される場合がある。ストレージシステム１０５のストレージマネージャ部分は、送信データを１以上のボリュームのＶＢＮ範囲２３０（図２）に関連付ける。ストレージシステム１０５のストレージマネージャ部分は、データをＶＢＮに関連付けた後、そのデータを割り当てに従ってディスク１１０に書き込むための要求をストレージシステム１０５のＲＡＩＤシステム部分に送信する。その要求を満たすため、ＲＡＩＤシステム部分は、Ｉ／Ｏタスクと呼ばれる複数のタスクを実行する必要がある。一実施形態において、ストレージシステム１０５のストレージマネージャ部分とＲＡＩＤシステム部分は、同一エンティティにある場合もある。
【００３９】
Ｉ／Ｏタスクは、オブジェクトに対してＩ／Ｏ処理を実施するものであり、例えば、一連のオブジェクト２００（図２）のうちの一オブジェクトに対してＩ／Ｏ処理を実施するものであり、Ｉ／Ｏ要求メッセージで表現される。一実施形態において、インスタンス化モジュール１４５は、あるオブジェクトにおいて上位Ｉ／Ｏタスクが下位Ｉ／Ｏタスクの新たなインスタンスを姿勢する関数を呼び出したときに、Ｉ／Ｏタスクをインスタンス化する。一実施形態において、下位Ｉ／Ｏタスクは、その上位Ｉ／Ｏタスクから１以上のプロパティを引き継ぐ。Ｉ／Ｏタスクは、そのＩ／Ｏタスクを実行するのに必要な情報を含む１以上のパラメタを有する。例示的Ｉ／Ｏタスクは８つのパラメタを有する。例示的Ｉ／Ｏタスクの第１のパラメタは、ストレージシステム１０５のオペレーティングシステムが与えられた複数のＩ／Ｏタスクを識別し、個々のＩ／Ｏタスクを管理するために使用さするヘッダ要素である。このヘッダ要素は、そのタスクに関する優先度情報、統計バッファ、及び／又は、一意の名称をスケジューリングを行なうストレージシステム１０５のオペレーティングシステムによって使用されるメモリ参照ポインタを含む場合がある。
【００４０】
例示的Ｉ／Ｏタスクの第２のパラメタは、そのＩ／Ｏタスクが処理対象とするＲＡＩＤ構成要素（例えばボリューム２０５、プレックス２１５、ＲＡＩＤグループ２２０、ディスク２２５など）に関する構成情報へのメモリ参照ポインタである。例示的Ｉ／Ｏタスクの第３のパラメタは、Ｉ／Ｏタスクのタイプを示す数値である。例示的Ｉ／Ｏタスクの第４のパラメタは、そのＩ／Ｏ処理に関する開始位置（ＶＢＮ）の値である。例示的Ｉ／Ｏタスクの第５のパラメタは、そのＩ／Ｏ処理に必要な仮想ブロックの数に関する値である。例示的Ｉ／Ｏタスクの第６のパラメタは、そのＩ／Ｏ処理に必要なデータを保持する一連のメモリバッファへのメモリポインタ参照である。
【００４１】
例示的Ｉ／Ｏタスクの第７のパラメタは、一連のＩ／Ｏ処理の集まりにおける上位Ｉ／Ｏタスク（例えば、親Ｉ／Ｏタスク）へのメモリポインタ参照である。例示的Ｉ／Ｏタスクの第８のパラメタは、このタイプのＩ／Ｏタスクに関する特定の機能を定義する一連の標準処理ベクトルへのメモリポインタ参照である。他の実施形態では、Ｉ／Ｏタスクが有するパラメタの数は８つより多い場合も少ない場合もある。例えば、Ｉ／Ｏタスクは、このタイプのＩ／ＯタスクおよびＩ／Ｏタスクのインスタンス（プライベートデータ）に特有のデータを保持するバッファへのメモリポインタ参照を含む場合がある。
【００４２】
Ｉ／Ｏタスクは、それらのパラメータの他に、１以上の機能ベクトルを有する。機能ベクトルは、Ｉ／Ｏタスクのタイプに基づいて特定の処理集合を実施する。各タイプのＩ／Ｏタスク（例えば、ディスク読み出し、ミラー書き込み、パリティ復元など）は、特定の機能集合を定義するそのタイプに固有の処理ベクトルを有する。例示的Ｉ／Ｏタスクは４つの機能ベクトルを有する。例示的Ｉ／Ｏタスクの第１の機能ベクトルは、Ｉ／Ｏタスクを開始したり、過去に保留したＩ／Ｏタスクを再開したりするために実施される機能ベクトルである。例示的Ｉ／Ｏタスクの第２の機能ベクトルは、所与のＩ／Ｏタスクが要求された処理をすべて完了したことを示すために実施される機能ベクトルである。例えば、ディスクドライバは、このルーチンを用いて読み出しや書き込みの完了をディスクオブジェクト２２５（図２）に通知する。
【００４３】
例示的Ｉ／Ｏタスクの第３の機能ベクトルは、所与の下位Ｉ／Ｏタスク（例えば子Ｉ／Ｏタスク）が要求された処理をすべて完了したことを示すために実施される機能ベクトルである。一実施形態において、この機能は、子Ｉ／Ｏタスクエラーをチェックしてそれらの復旧を試みることによって実施される。例えば、ＲＡＩＤグループオブジェクト２２０（図２）は、単一のディスク読み出しエラーから復旧させることが可能である。ＲＡＩＤグループオブジェクト２２０（図２）は、新たなＩ／Ｏタスクを生成してそのエラーを処理する。エラー処理Ｉ／Ｏタスクは、ＲＡＩＤグループ２２０内の使用可能な他のディスクからのデータ及びパリティ情報を用いて、単一ディスクのエラーの起きたデータを判定する。
【００４４】
例示的Ｉ／Ｏタスクの第４の機能ベクトルは、排他的論理和演算が完了したことを示す機能ベクトルである。例示的実施形態にはこれを含めているが、パリティチェックを行なわないＲＡＩＤレベルであれば、このルーチンは不要である。他の実施形態では、Ｉ／Ｏタスクが有する機能ベクトルの数は、例示した４つより多い場合も少ない場合もある。他の実施形態では、Ｉ／Ｏタスク構造が標準インタフェースを利用していて、各Ｉ／Ｏタスクはオブジェクトを考慮することなく同一の方法で呼び出すことが好ましい場合がある。例えば、ストレージマネージャは、オブジェクトがＲＡＩＤレベル４であるかＲＡＩＤレベル０であるかを知ることなく、そのオブジェクトに対してストライプ書き込みＩ／Ｏを実施することができる場合がある。
【００４５】
Ｉ／Ｏタスクが開始されると、そのＩ／ＯタスクはＩ／Ｏスレッドによってキューイングされ、処理される。一実施形態では、Ｉ／Ｏマネージャ１５０（図１）がＩ／Ｏスレッドを実施する。Ｉ／Ｏスレッドは、Ｉ／ＯタスクのスケジューリングやＩ／Ｏタスクへのサービス提供を行なう働きがある。一実施形態では、１つのストレージシステム１０５について１つのＩ／Ｏスレッドが存在する場合がある。他の実施形態では、複数のスレッドが用いられ、Ｉ／Ｏタスクは、最適化アルゴリズムによって複数のＩ／Ｏスレッドのうちの１つに分配される場合がある。例えば、Ｉ／Ｏタスクは、キュー内の最小量のＩ／ＯタスクでＩ／Ｏスレッドに送信される場合がある。
【００４６】
一実施形態では、Ｉ／ＯタスクはメッセージとしてＩ／Ｏスレッドにキューイングされ、Ｉ／Ｏスレッドが、そのＩ／Ｏタスクの機能ベクトルを用いて特定の一連の処理を実施することにより、そのＩ／Ｏタスクをサービスする場合がある。Ｉ／Ｏスレッドは、イベント、例えばリソース利用不可などが発生すると、そのＩ／Ｏタスクを保留する。Ｉ／Ｏタスクが保留されると、Ｉ／Ｏスレッドは、そのＩ／Ｏタスクのスケジューリングを行なわない。一実施形態において、Ｉ／Ｏスレッドは、保留したＩ／Ｏタスクを個別の待ち行列に入れることにより、Ｉ／Ｏタスクを保留する場合がある。他のイベントが発生した場合、例えばリソースが利用可能になった場合、そのメッセージをＩ／Ｏスレッドに再度送信することによって、そのＩ／Ｏタスクが再開される。Ｉ／Ｏスレッドは、Ｉ／Ｏ要求を受信すると、適当なオブジェクトルーチンを呼び出すことによりその要求にサービスを提供する。Ｉ／Ｏスレッドは、Ｉ／Ｏルーチンから戻ると、次の要求にサービスを提供する。一実施形態において、Ｉ／Ｏスレッドの待ち行列はＦＩＦＯ待ち行列である場合がある。他の実施形態では、Ｉ／Ｏタスクは、そのＩ／Ｏタスクの特定の性質に基づく優先度値が例えばそのＩ／Ｏタスクのヘッダ要素に保持される場合がある。これらの特性には、例えば、クライアントがデータアクセス（またはデータ記憶）要求をしたとき又はシステムがデータアクセス要求（例えばパリティ確認、ミラーリング確認など）をしたときの、オブジェクト２００の階位におけるＩ／Ｏタスクのレベルや、Ｉ／Ｏタスクのステータスなどが含まれる。
【００４７】
図３は、受信したデータの要求された書き込みを実施するために用いられる例示的処理３００を示している。この例示的処理は、ボリュームのミラーリングを表している。図示の処理は、ＲＡＩＤレベル４の実施形態（即ち２台のディスク１台のパリティディスク）を利用した３つのディスクアレイに対して書き込みを行なっている。ストレージマネージャは、受信したデータを、ＶＢＮアレイ３０２で表現された２ストライプのアレイに割り当てる。ＶＢＮアレイ３０２は、この例示的処理３００の間に書き込みが行なわれることになる３台のディスク１１０上の３つのデータ記憶ブロック及び２つのパリティ記憶ブロックを示している。各記憶ブロックはＶＢＮを有する。データに関するＶＢＮには２６から２９まで連続番号が付けられ、パリティブロックにはＰ１及びＰ２のラベルが付けられる。図示のように、ストライプは水平方向である（例えば、ＶＢＮ２６、２８、Ｐ１など）。ディスク１１０は垂直方向である（例えば、ＶＢＮ２６、２７など）。
【００４８】
ＶＢＮアレイ３０２に示すように、ＶＢＮ２８は満杯で利用することができない。ストレージマネージャは受信したデータを残りのＶＢＮ２６、２７及び２９に割り当てる。ＶＢＮアレイ３０２は単なる例示にすぎず、他の実施形態では、様々なストライプ及び／又はアレイのストライプＶＢＮ構成を用いることが可能である。例えば、ＶＢＮ２７とＶＢＮ２８を交換し、ＶＢＮがストライプと水平に交差して並ぶようにすることもできる。他の実施形態では、例えばＲＡＩＤレベル５の実施形態を用いて、パリティブロックＰ１及びＰ２を異なるディスクに分散することもできる。
【００４９】
特定ボリュームに割り当てられたＶＢＮにデータを書き込むためのストレージマネージャの要求を満たすため、ストレージマネージャは、ボリュームオブジェクト２０５（図２）からＩ／Ｏタスクをコールして、要求された書き込みを実施する。インスタンス化モジュール１４５（図１）は、例えば上記の例示的Ｉ／Ｏタスク構造に記載した情報など、このタスクを実行するために必要な情報を保持してるボリューム書き込みＩ／Ｏタスク３０４をインスタンス化する。このボリューム書き込みＩ／Ｏタスク３０４はＩ／Ｏスレッドに送信され、スケジューリングされる（例えばＩ／Ｏタスク処理待ち行列に追加される）。Ｉ／Ｏマネージャ１５０（図１）は、このボリューム書き込みＩ／Ｏタスク３０４が待ち行列の先頭に達すると、ボリューム書き込みＩ／Ｏタスク３０４処理を開始する。この実施形態の場合、ボリューム書き込みＩ／Ｏタスク３０４は、ミラーオブジェクト２１０からＩ／Ｏタスクをコールして（ステップ３０６）、要求された書き込みを実施する。
【００５０】
インスタンス化モジュール１４５は、このタスクを実行するために必要な情報を保持しているミラー書き込みＩ／Ｏタスク３０８をインスタンス化する。ボリューム書き込みＩ／Ｏタスク３０４は、その子Ｉ／Ｏタスクが完了するまで保留される（例えば待ち行列に入れられる）。ミラー書き込みＩ／Ｏタスク３０８はＩ／Ｏスレッドに送信され、スケジューリングされる。Ｉ／Ｏマネージャ１５０は、ミラー書き込みＩ／Ｏタスク３０８が待ち行列の先頭にくると、ミラー書き込みＩ／Ｏタスク３０８処理を開始する。この実施形態の場合、ミラー書き込みＩ／Ｏタスク３０８は、マスタープレックスオブジェクト２１５ａからＩ／Ｏタスクをコールし、スレーブプレックスオブジェクト２１５ｂから書き込みＩ／Ｏタスクをコールして、要求された書き込みを実施する。
【００５１】
プレックスオブジェクト２１５ａ及び２１５ｂにマスター及びスレーブの識別子が用いられる理由は、例示の実施形態の場合、各プレックスオブジェクト２１５によるディスクオブジェクト２２５（図２）の実施形態がミラーリングされていて、対称になっているからである。この対称性によって、スレーブアレイ書き込みＩ／Ｏタスク３１６は、マスターアレイ書き込みＩ／Ｏタスク３１４のパリティ計算を利用することができるので、スレーブはパリティ計算に関するＩ／Ｏタスクを回避することができる。アレイ書き込みＩ／Ｏタスク３１４および３１６のうち、いずれをマスターにしていずれをスレーブするかは自由である。第１のアレイ書き込みＩ／Ｏタスク３１４によるパリティ計算の最適化によって、第２のアレイ書き込みＩ／Ｏタスク３１６がパリティ計算のために必要としていたリソースを、他のＩ／Ｏタスクに利用できるようになる。一実施形態では、何も最適化を行なわず、Ｉ／Ｏタスク３１４及び３１６が両方ともパリティ計算を実施する場合がある。さらに他の実施形態では、要求がミラーリングされず、従ってマスター／スレーブ関係も存在しない場合がある。この実施形態の場合、アレイ書き込みＩ／Ｏタスク３１４及び３１６の各々は、個別に同等のものとして機能する。アレイ書き込み３１６のパス及び子タスクは、アレイ書き込み３１４と同様のものである。
【００５２】
例示の実施形態において、インスタンス化モジュール１４５は、このタスクを実行するために必要な情報を保持しているマスターアレイ書き込みＩ／Ｏタスク３１４及びスレーブアレイ書き込みＩ／Ｏタスク３１６をインスタンス化する。ミラー書き込みＩ／Ｏタスク３０４は、その子Ｉ／Ｏタスクが完了するまで保留される（例えば待ち行列に入れられる）。アレイ書き込みＩ／Ｏタスク３１４及び３１６が項アレイを用いる理由は、図示のようにそれらが複数のストライプを同時に処理することができ、ＶＢＮ３０２を２つの個別ストライプとして処理するのではなく、ＶＢＮ３０２を１つのエンティティとして処理することができるからである。これによってディスクに対する書き込みが最適化される。
【００５３】
マスターアレイ書き込みＩ／Ｏタスク３１４及びスレーブアレイ書き込みＩ／Ｏタスク３１６は、いずれもＩ／Ｏスレッドに送信され、個別にスケジューリングされる。換言すれば、各Ｉ／Ｏタスクは、お互いを考慮することなく別個のエンティティとしてスケジューリングされる。そのため、Ｉ／Ｏスレッドは、Ｉ／Ｏタスクをスケジューリングするときに、各Ｉ／Ｏタスクの関係を考慮する必要はない。以下で説明するように、各Ｉ／Ｏタスクは個別のエンティティであり、その進行はそのタスクの現在の状態、及び、その状態を変化させる特定のイベント（例えば子Ｉ／Ｏタスクの完了）の発生によって決まるものであるから、Ｉ／ＯスレッドはＩ／Ｏタスクと互いに同期している必要はない。Ｉ／Ｏスレッドは、Ｉ／Ｏタスクを待ち行列においた順番又は優先順位アルゴリズムによって判定された順番で処理し、特定のイベントがまだ発生していない（例えば子タスクが完了していないとか、必要なリソースがすべて利用できないなど）という理由からＩ／ＯスレッドがそのＩ／Ｏタスクをサービスできない場合、それらのイベントが発生するまでそのＩ／Ｏタスクを保留する。
【００５４】
Ｉ／Ｏマネージャ１５０は、マスターアレイ書き込みＩ／Ｏタスク３１４が待ち行列の先頭にくると、そのマスターアレイ書き込みＩ／Ｏタスク３１４処理を開始する。Ｉ／Ｏマネージャ１５０は、スレーブアレイ書き込みＩ／Ｏタスク３１６が待ち行列の先頭にくると、そのスレーブアレイ書き込みＩ／Ｏタスク３１６処理を開始する。この実施形態の場合、スレーブアレイ書き込みＩ／Ｏタスク３１６は、マスターアレイ書き込みＩ／Ｏタスク３１４がパリティ計算を実施するまで保留される。
【００５５】
一実施形態において、マスターアレイ書き込みＩ／Ｏタスク３１４は、ＶＢＮ２８が満杯であるから、そのＶＢＮを読み出して、マスターアレイ書き込みＩ／Ｏタスク３１４がＶＢＮ２８に対応するストライプについてパリティ計算を実施できるようにする必要がある、ということを判断する。マスターアレイ書き込みＩ／Ｏタスク３１４は、ＲＡＩＤグループオブジェクト２２０（図２）からＩ／Ｏタスクをコールして（ステップ３１８）、要求された書き込みを実施する。他の実施形態では、マスターアレイ書き込みＩ／Ｏタスク３１４は、ＶＢＮ２８が満杯であるから、ＶＢＮ２６及びＰ１を読み出して、マスターアレイ書き込みＩ／Ｏタスク３１４がＶＢＮ２８に対応するストライプについてパリティ計算を実施できるようにする必要がある、ということを判断する場合がある。
【００５６】
例示の実施形態において、インスタンス化モジュール１４５は、このタスクを実行するために必要な情報を保持しているグループ読み出しＩ／Ｏタスク３２０をインスタンス化する。アレイ書き込みＩ／Ｏタスク３１４は、その子Ｉ／Ｏタスクが完了するまで保留される。グループ読み出しＩ／Ｏタスク３２０はＩ／Ｏスレッドに送信され、スケジューリングされる。Ｉ／Ｏマネージャ１５０は、グループ読み出しＩ／Ｏタスク３２０が待ち行列の先頭にくると、そのグループ読み出しＩ／Ｏタスク３２０処理を開始する。この実施形態の場合、グループ読み出しＩ／Ｏタスク３２０は、ディスクオブジェクト２２５ｂ（図２）からＩ／Ｏタスクをコールして、要求された読み出しを実施する。
【００５７】
インスタンス化モジュール１４５は、ＶＢＮ２８を読み出すために必要な情報を保持しているディスク読み出しＩ／Ｏタスク３２４をインスタンス化する。グループ読み出しＩ／Ｏタスク３２０は、その子タスクが完了するまで保留される。ディスク読み出しＩ／Ｏタスク３２４は、Ｉ／Ｏスレッドに送信され、スケジューリングされる。Ｉ／Ｏマネージャ１５０は、ディスク読み出しＩ／Ｏタスク３２４が待ち行列の先頭にくると、そのディスク読み出しＩ／Ｏタスク３２４処理を開始する。ディスク読み出しＩ／Ｏタスク３２４が開始されると、ディスク読み出しＩ／Ｏタスク３２４は、ディスク１１０からＶＢＮ２８を読み出し、読み出したデータを所定のバッファに格納する。ディスク読み出しＩ／Ｏタスク３２４が完了する。ディスク読み出しＩ／Ｏタスク３２４は、要求されたＩ／Ｏタスクが完了したことを、親Ｉ／Ｏタスクに、この場合グループ読み出しＩ／Ｏタスク３２０に通知する。この実施形態において、ディスク読み出しＩ／Ｏタスク３２４は、グループ読み出しＩ／Ｏタスク３２０から下位Ｉ／Ｏタスク（例えば、例示的Ｉ／Ｏタスクの第３の機能ベクトルなど）が完了したことを示す機能ベクトルを実行することによって（ステップ３２６）、ＲＡＩＤグループオブジェクト２２０ａに通知を行なう。他の実施形態において、アレイ書き込みＩ／Ｏタスク３１４は、ディスクオブジェクト２２５ｂからディスク読み出しＩ／Ｏタスク３２４を直接コールし、グループ読み出しＩ／Ｏタスクを使用しない場合がある。この実施形態では、ディスク読み出しＩ／Ｏタスク３２４が完了すると、ディスク読み出しＩ／Ｏタスク３２４は、要求されたＩ／Ｏタスクが完了したことを、その親タスクであるアレイ書き込みＩ／Ｏタスク３１４に通知する。
【００５８】
例示の実施形態において、グループ読み出しＩ／Ｏタスク３２０は、その子Ｉ／Ｏタスクが完了すると、要求されたグループ読み出しＩ／Ｏタスク３２０を実行するために必要な子Ｉ／Ｏタスクがもうないことを判断する。グループ読み出しＩ／Ｏタアスク３２０が完了すると、グループ読み出しＩ／Ｏタスク３２０は、要求されたＩ／Ｏタスクが完了したことを、その親Ｉ／Ｏタスクであるアレイ書き込み３１４に通知する。これは、アレイ書き込みＩ／Ｏタスク３１４から下位Ｉ／Ｏタスク（例えば、例示的Ｉ／Ｏタスクの第３機能ベクトル）が完了したことを示す機能ベクトルを実行することによって（ステップ３２８）アレイ書き込みＩ／Ｏタスク３１４に通知を行なうグループ読み出しＩ／Ｏタスク３２０によって実行される。アレイ書き込みＩ／Ｏタスク３１４は、その子Ｉ／Ｏタスクグループ読み出し３２０が完了すると、パリティを計算するために十分な情報が得られたと判断する。
【００５９】
インスタンス化モジュール１４５は、Ｐ１及びＰ２についてのパリティを計算するために必要な情報を保持しているＸＯＲ計算Ｉ／Ｏタスク３３２をインスタンス化する（ステップ３３０）。Ｐ２を計算するために何も読み出しが必要ないので、他の実施形態では、Ｐ２についてのＸＯＲ計算Ｉ／ＯタスクはＰ１から分離する場合もある。Ｐ２の計算を分離した場合、アレイ書き込みＩ／Ｏタスク３１４は、ＸＯＲ計算Ｉ／Ｏタスクをコールすることにより、グループ読み出しＩ／Ｏタスク３２０より前かそれと同時に、Ｐ２を計算することができる。
【００６０】
図示のように、グループ読み出しＩ／Ｏタスク３２０は、その子Ｉ／ＯタスクであるＸＯＲ計算Ｉ／Ｏタスク３３２が完了するまで保留される。ＸＯＲ計算Ｉ／Ｏタスク３３２は、Ｉ／Ｏスレッドに送信され、スケジューリングされる。Ｉ／Ｏマネージャ１５０は、ＸＯＲ計算Ｉ／Ｏタスク３３２が待ち行列の先頭にくると、そのＸＯＲ計算Ｉ／Ｏタスク３３２処理を開始する。ＸＯＲ計算Ｉ／Ｏタスク３３２が開始されると、ストレージシステム１０５の処理装置、例えばプロセッサ１２０は、Ｐ１及びＰ２についてのパリティを計算し、計算したデータをバッファ３２６に格納する（ステップ３３４）。他の実施形態では、ストレージシステム１０５が個別のＸＯＲスレッドを有し、ＸＯＲ計算Ｉ／Ｏタスク３３２は、Ｉ／Ｏスレッドではなく、そのＸＯＲスレッドに送信される場合もある。
【００６１】
計算値が格納されると（ステップ３３４）、ＸＯＲ計算Ｉ／Ｏタスク３３２は、要求されたＩ／Ｏタスクが完了したことを、その親タスクに、この場合アレイ書き込みＩ／Ｏタスク３１４に通知する。この実施形態の場合、ＸＯＲ計算Ｉ／Ｏタスク３３２は、アレイ書き込みＩ／Ｏタスク３１４から排他的論理和演算が完了したことを示す機能ベクトル（例えば、例示的Ｉ／Ｏタスクの第４の機能ベクトル）を実行する（ステップ３４８）ことによって、アレイ書き込みＩ／Ｏタスク３１４に通知を行なう。アレイ書き込みＩ／Ｏタスク３１４は、その子Ｉ／ＯタスクであるＸＯＲ計算Ｉ／Ｏタスク３３２が完了すると、ＶＢＮ３０２に関連するディスク１１０にデータを書き込むのに十分なだけの情報が得られたと判断する。マスターアレイ書き込みＩ／Ｏタスク３１４は、ＲＡＩＤグループオブジェクト２２０ａからＩ／Ｏタスクをコールすることによって（ステップ３５０）、要求された書き込みを実施する。
【００６２】
インスタンス化モジュール１４５は、このタスクを実行するために必要な情報を保持しているグループ書き込みＩ／Ｏタスク３５２をインスタンス化する。アレイ書き込みＩ／Ｏタスク３１４は、その子Ｉ／Ｏタスクが完了するたで保留される。グループ書き込みＩ／Ｏタスク３５２は、Ｉ／Ｏスレッドに送信され、スケジューリングされる。Ｉ／Ｏマネージャ１５０は、グループ書き込みＩ／Ｏタスク３５２が待ち行列の先頭にくると、そのグループ書き込みＩ／Ｏタスク３５２処理を開始する。この実施形態では、グループ書き込みＩ／Ｏタスク３５２は、ディスクオブジェクト２２５ａ（図２）からＩ／Ｏタスクをコールすることによって（ステップ３５４）、要求された書き込みをそれに対応するＶＢＮを用いて実施する。また、グループ書き込みＩ／Ｏタスク３５２は、ディスクオブジェクト２２５ｂからＩ／Ｏタスクをコールすることによって（ステップ３５６）、要求された書き込みをそれに対応するＶＢＮを用いて実施する。さらにグループ書き込みＩ／Ｏタスク３５２は、ディスクオブジェクト２２５ｃ（図２）からＩ／Ｏタスクをコールすることによって、要求された書き込みをそれに対応するパリティ計算値を用いて実施する。他の実施形態では、アレイ書き込みＩ／Ｏタスク３１４は、ディスク書き込みＩ／Ｏタスク３６０、３６２及び３６４をそれらに対応するディスクオブジェクト２２５ａ、２２５ｂ及び２２５ｃから直接コールし、グループ書き込みＩ／Ｏタスクを使用しない場合もある。この実施形態では、ディスク書き込みＩ／Ｏタスク３６０、３６２及び３６４は、それらのタスクが完了すると各々、要求された子Ｉ／Ｏタスクが完了したことを、その親タスクであるアレイ書き込みＩ／Ｏタスク３１４に通知する。
【００６３】
例示の実施形態では、インスタンス化モジュール１４５は、ＶＢＮ２６及び２７に書き込みを行なうために必要な情報を保持しているディスクオブジェクト２２５ａに対するＩ／Ｏタスクのコール（ステップ３５４）に対応するディスク書き込みＩ／Ｏタスク３６０をインスタンス化する。また、インスタンス化モジュール１４５は、ＶＢＮ２９に書き込みを行なうために必要な情報を保持しているディスクオブジェクト２２５ｂに対するＩ／Ｏタスクのコール（ステップ３５６）に対応するディスク書き込みＩ／Ｏタスク３６２もインスタンス化する。さらに、インスタンス化モジュール１４５は、Ｐ１及びＰ２に書き込みを行なうために必要な情報を保持しているディスクオブジェクト２２５ｃに対するＩ／Ｏタスクのコール（ステップ３５８）に対応するディスク書き込みＩ／Ｏタスク３４０もインスタンス化する。グループ書き込みＩ／Ｏタスク３５２は、その子Ｉ／Ｏタスク３６０、３６２及び３６４が完了するまで保留される。
【００６４】
ディスク書き込みＩ／Ｏタスク３６０、３６２及び３６４は、個別にＩ／Ｏスレッドに送信され、個別にスケジューリングされる。Ｉ／Ｏマネージャ１５０は、ディスク書き込みＩ／Ｏタスク３６０、３６２及び３６４がそれぞれ待ち行列の先頭にくると、そのディスク書き込みＩ／Ｏタスク処理を開始する。ディスク書き込みＩ／Ｏタスク３６０、３６２及び３６４が開始されると、それらディスク書き込みＩ／Ｏタスク３６０、３６２及び３６４は、ＶＢＮに対応するディスクにデータを書き込む。
【００６５】
ディスク書き込みＩ／Ｏタスク３６０、３６２及び３６４は、個別にスケジューリングされるので、別々に完了する。完了の順番は、それらのディスク書き込みＩ／Ｏタスク３６０、３６２及び３６４を完了させるのに必要なイベントの発生に応じて決まる。イベントは例えば、ディスク書き込みＩ／Ｏタスクを完了するのに必要な全てのリソースの利用可能性、及び、データの書き込み先であるディスク１１０の利用可能性などである。ディスク書き込みＩ／Ｏタスク３６０、３６２及び３６４の各々が完了すると、それら各々は要求されたＩ／Ｏタスクが完了したことを親タスクに、この場合グループ書き込みＩ／Ｏタスク３５２に通知する。この実施形態では、ディスク書き込みＩ／Ｏタスク３６０、３６２及び３６４の各々は、グループ書き込みＩ／Ｏタスク３２０から下位Ｉ／Ｏタスクが完了したことを示す機能ベクトル（例えば例示的Ｉ／Ｏタスクの第３の機能ベクトル）を実施することによって（それぞれステップ３６６、３６８、３７０）、ＲＡＩＤグループオブジェクト２２０ａに通知を行なう。
【００６６】
グループ書き込み３５２は、その子Ｉ／Ｏタスク（即ち３６０、３６２及び３６４）が完了すると、要求されたグループ書き込みＩ／Ｏタスク３５２を実施するために必要な子Ｉ／Ｏタスクがもうないことを判断する。グループ書き込みＩ／Ｏタスク３５２が完了すると、グループ書き込みＩ／Ｏタスクは、要求されたＩ／Ｏタスクが完了したことを、その親タスクであるアレイ書き込み３１４に通知する。グループ書き込みＩ／Ｏタスク３５２は、アレイ書き込みＩ／Ｏタスク３１４から下位Ｉ／Ｏタスクが完了したことを示す機能ベクトル（例えば例示的Ｉ／Ｏタスクの第３の機能ベクトル）を実施することによって（ステップ３７２）、アレイ書き込みＩ／Ｏタスク３１４に通知を行なう。アレイ書き込みＩ／Ｏタスク３１４は、その子Ｉ／Ｏタスクであるグループ書き込み３２０が完了すると、要求されたアレイ書き込みＩ／Ｏタスク３１４を実施するために必要な子Ｉ／Ｏタスクがもうないことを判断する。アレイ書き込みＩ／Ｏタスク３１４が完了すると、アレイ書き込みＩ／Ｏタスク３１４は要求されたＩ／Ｏタスクが完了したことをその親タスクであるミラー書き込み３０８に通知する（ステップ３７４）。
【００６７】
例示のマスター／スレーブ実施形態において、ミラー書き込みＩ／Ｏタスク３０８が完了するのは、アレイ書き込みＩ／Ｏタスク３１４及び３１６が両方とも完了したときである。上記のように、各Ｉ／Ｏタスクが個別にスケジューリングされるので、アレイ書き込みＩ／Ｏタスク３１４は、例えばリソースの利用可能性およびディスク１１０に対するアクセスに応じて、スレーブアレイ書き込みＩ／Ｏタスク３１６より前に完了する場合も後に完了する場合もある。上記のように、スレーブアレイ書き込みＩ／Ｏタスク３１６は、スレーブタスクとして扱われるので、マスターアレイ書き込みＩ／Ｏタスク３１４によってＶＢＮアレイ３０２に書き込みを行なうために必要なＸＯＲ計算が実施されるまで待機する。一実施形態において、ミラーリング及び／又は対象性がない場合、アレイ書き込みＩ／Ｏタスク３１６は、この計算を待つ必要がなく、リソースを利用可能であれば必要な子Ｉ／Ｏタスクのすべてを生成する。
【００６８】
例示の実施形態において、ＸＯＲの計算およびバッファ３３６への格納（ステップ３３４）が完了すると、スレーブアレイ書き込みＩ／Ｏタスク３１６は、アレイ書き込みＩ／Ｏタスク３１４に関して示したのと同様に、ディスクに対するデータの書き込みを進める（ステップ３８０）。Ｓｌａｖｅ＿アレイ書き込みＩ／Ｏタスク３１６はグループ書き込みＩ／Ｏタスクを生成し、次いでこのグループ書き込みＩ／Ｏタスクがデータをディスクに書き込むための３つのタスクを生成する。グループ書き込みＩ／Ｏタスクは、その子Ｉ／Ｏタスクが完了すると、要求されたスレーブアレイ書き込みＩ／Ｏタスク３１６を実施するために必要な子Ｉ／Ｏタスクがもうないことを判断する。Ｓｌａｖｅ＿アレイ書き込みＩ／Ｏタスク３１６が完了すると、Ｓｌａｖｅ＿アレイ書き込みＩ／Ｏタスク３１６は、要求されたＩ／Ｏタスクが完了したことを、その親タスクであるミラー書き込み３０８に通知する（ステップ３８２）。他の実施形態では、スレーブアレイ書き込みＩ／Ｏタスク３１６がディスクオブジェクト２２５からディスク書き込みＩ／Ｏタスクを直接コールし、グループ書き込みＩ／Ｏタスクを使用しない場合もある。この実施形態では、ディスク書き込みＩ／Ｏタスクが完了すると、それらタスクの各々は、要求された子Ｉ／Ｏタスクが完了したことを、親Ｉ／Ｏタスクであるスレーブアレイ書き込みＩ／Ｏタスク３１６に通知する。
【００６９】
ミラーオブジェクト２１０は、その子Ｉ／Ｏタスク（即ち３１４及び３１６）が完了すると、要求されたミラー書き込みＩ／Ｏタスク３０８を実施するために必要な子Ｉ／Ｏタスクがもうないことを判断する。ミラー書き込みＩ／Ｏタスク３０８が完了すると、ミラー書き込みＩ／Ｏタスク３０８は、要求されたＩ／Ｏタスクが完了したことを、その親タスクであるボリューム書き込み３０４に通知する（ステップ３７６）。ボリューム書き込みＩ／Ｏタスク３０４は、データアクセス要求が無事に満たされたことを、ストレージマネージャに通知する。
【００７０】
単純なデータアクセス要求が多数のＩ／Ｏタスク処理を必要とする場合がある。図３に示すように構成されたシステムにおけるＶＢＮの書き込みの例を考える。図示のように、ストレージマネージャは書き込みＩ／Ｏタスクを得てそれをボリュームオブジェクト２０５に送信し、次いでボリュームオブジェクト２０５がＩ／Ｏタスクを得てそれをミラーオブジェクトに送信し、以下同様である。オブジェクト２００の階層ツリーの最下層では、ディスク１１０に対する読み出し及び／又は書き込みに対応するＩ／Ｏタスクがディスクオブジェクト２２５に送信され、ディスク１１０がディスクドライバにメッセージを送信する。このように、経路に沿って連続したＩ／Ｏタスク対の各々は、親子関係にある。ディスクドライバからの応答も、一連のＩ／Ｏタスクを上ってゆき、最終的にストレージマネージャに配送される。
【００７１】
一実施形態では、この処理が最適化される。ストレージマネージャまたは何らかの親オブジェクトは、一連のオブジェクト２００（図２）の中を移動して、適当なディスクオブジェクト２２５を探し、そこからＩ／Ｏタスクを得て、そのＩ／ＯタスクをＩ／Ｏスレッドに送信する。こうしたＩ／Ｏタスクは、１以上の親オブジェクトからの直接の親Ｉ／Ｏタスク（すなわち直上階層のＩ／Ｏタスク）の割り当てをバイパスして、２世代以上下方のオブジェクトに直接送信されるので、バイパスＩ／Ｏタスクと呼ばれる。
【００７２】
バイパスＩ／Ｏタスクが使用されない実施形態では、各Ｉ／Ｏタスクが直接の親を有する（ルートを除いて）。そのような実施形態では、Ｉ／Ｏタスクが完了すると、直接の親Ｉ／Ｏタスクが、応答においてエラーステータスをチェックし、起こり得るエラーをすべて処理する。バイパスＩ／Ｏタスクを用いた実施形態の場合、バイパスＩ／Ｏタスクは直接の親オブジェクトを持たないので、エラーが発生した場合、バイパスＩ／Ｏタスクは、階層順位２００で直接の親オブジェクトにあたるものからエラー取り扱い処理をコールする。エラー取り扱いＩ／Ｏ処理は、かかるエラーを処理するために子Ｉ／Ｏタスクを割り当てるのが一般的ある。
【００７３】
例えば、ボリュームオブジェクト２０５は、バイパスＩ／Ｏタスクを用いてディスクオブジェクト２２５に対する直接コールを行い、読み出しＩ／Ｏタスクを得る。バイパスＩ／Ｏタスクの場合、ディスクオブジェクト２２５の直接の親であるＲＡＩＤグループオブジェクト２２０は使用されない。しかしながら、ＲＡＩＤグループ２２０においてディスクオブジェクト２２５に対するバイパス読み出しＩ／Ｏタスクにエラーが発生した場合、このバイパスＩ／Ｏタスクは、ボリュームオブジェクト２０５が親Ｉ／Ｏタスクを生成した場合であっても、親ＲＡＩＤグループオブジェクトの２２５エラー処理Ｉ／Ｏタスクをコールする。ＲＡＩＤグループ２２５は、エラー処理Ｉ／Ｏタスクを生成する。以下で説明するように、エラー処理を局所化することによって、リソースの読み込みをさらに最適することができる。
【００７４】
図４は、Ｉ／Ｏタスクの例示的実施形態の状態図を示すものである。このＩ／Ｏタスクがコールされる場合、Ｉ／Ｏタスクは初期状態４０５で生成される（例えば、オブジェクト指向パラダイムではＩ／Ｏタスクのインスタンスが生成される）。例示の実施形態では、Ｉ／Ｏタスクは、Ｉ／ＯスレッドがＩ／Ｏタスクをスケジューリングできるようになる前に、そのＩ／Ｏタスクが必要とするすべてのリソースを取得しなければならない。必要なリソースのすべてが利用可能である場合、必要なリソースをそのＩ／Ｏタスクに割り当て、開始／再開処理（パス４１０）をコールし、そのＩ／ＯタスクをＩ／Ｏタスク実行状態４１５に変更する。この状態で、Ｉ／Ｏタスクは、要求されたＩ／Ｏタスクを実施するために必要な手順を開始する準備ができる。必要なリソースのすべてを利用することができない場合（パス４２０）、Ｉ／Ｏタスクの状態を保留状態４２５に変更する。この場合、そのＩ／Ｏタスクは、例えば「必要なリソースがすべて利用可能になる」というイベントが発生するまで、例えば待ち行列で待機する。そのイベントが発生すると、開始／再開処理（パス４１０）がコールされ、必要なリソースがそのＩ／Ｏタスクに割り当てられ、そのＩ／ＯタスクはＩ／Ｏタスク実行状態４１５に変更される。
【００７５】
オブジェクトは、それに関連するＩ／Ｏタスクを３タイプの例示的手順のうちの１つを用いて実施することができる。第１のタイプの手順では、オブジェクトが必要なＩ／Ｏタスクを直接実行する。例えば、ディスクオブジェクト２２５は、適当な読み出しコマンドをディスクドライブ１１０に直接送信することにより、ディスク読み出しタスク３２４を実施する。
【００７６】
第２のタイプの手順では、オブジェクトは必要なＩ／Ｏタスクを直接実行することができない（例えば、オブジェクトが一連のオブジェクト２００においてより高いレベルのオブジェクトである場合に行なわれるので）。Ｉ／Ｏタスクを完了するため、オブジェクトは子Ｉ／Ｏタスクを生成する（パス４４０）。Ｉ／Ｏタスク（即ち親Ｉ／Ｏタスク）の状態は、Ｉ／Ｏタスク保留状態４４５に変わる。この状態で、Ｉ／Ｏタスクは、例えば「子Ｉ／Ｏタスクの完了」というイベントの発生まで、例えば待ち行列で待機する。このイベントが発生すると、子Ｉ／Ｏタスク終了処理がコールされ（パス４５０）、Ｉ／ＯタスクはＩ／Ｏタスク実行状態４１５に戻る。そのＩ／Ｏタスクを実施するためにさらに子Ｉ／Ｏタスクが必要な場合、それらも生成され（パス４４０）、Ｉ／Ｏタスクは子Ｉ／Ｏタスクがすべて完了するまで保留状態４４５に留まる。
【００７７】
オブジェクトが子Ｉ／Ｏタスクを生成する場合（パス４４０）、その子Ｉ／Ｏタスクの個別の独立したインスタンスが初期状態４０５で生成される。Ｉ／Ｏスレッドがその子Ｉ／Ｏタスクをスケジューリングできるようになる前に、子Ｉ／Ｏタスクは、その子Ｉ／Ｏタスクに必要なすべてのリソースを取得しなければならない。必要なリソースのすべてが利用可能である場合、必要なリソースをその子Ｉ／Ｏタスクに割り当て、開始／再開処理がコールされ（パス４１０）、その子Ｉ／ＯタスクはＩ／Ｏタスク実行状態４１５に移る。この状態で、子Ｉ／Ｏタスクは、要求されたＩ／Ｏタスクを実施するために必要な手順を直ちに開始する。必要なリソースのすべてを利用することができなかった場合（パス４２０）、子Ｉ／Ｏタスクの状態は保留状態４２５に移る。この状態で、Ｉ／Ｏタスクは、例えば「必要なリソースがすべて利用可能になる」というイベントの発生まで、例えば待ち行列で待機する。このイベントが発生すると、開始／再開処理がコールされ（パス４１０）、必要なリソースがそのＩ／Ｏタスクに割り当てられ、そのＩ／ＯタスクはＩ／Ｏタスク実行状態４１５に移る。子Ｉ／Ｏタスクが必要なＩ／Ｏタスクを直接実行することができない場合、オブジェクトは、自分の子Ｉ／Ｏタスク（例えば、元のＩ／Ｏタスクに対する孫Ｉ／Ｏタスク）を生成し、このサイクルを再帰的に続ける。
【００７８】
第３のタイプの手順では、オブジェクトは、パリティ計算（例えばＸＯＲの計算）を実施することなく必要なＩ／Ｏタスクを実行することができない。Ｉ／Ｏタスクを完了するため、オブジェクトは、パリティ計算を実施するための要求を生成する（パス４５５）。Ｉ／Ｏタスクの状態はＩ／Ｏタスク保留状態４６０に移る。この状態で、Ｉ／Ｏタスクは、例えば「パリティ計算の完了」というイベントの発生まで、例えば待ち行列で待機する。このイベントが発生すると、ＸＯＲタスク終了処理がコールされ（パス４６５）、Ｉ／ＯタスクはＩ／Ｏタスク実行状態４１５に戻る。そのＩ／Ｏタスクを実施するためにさらにＸＯＲ計算タスクが必要な場合、それらも生成され（パス４５５）、Ｉ／Ｏタスクは、すべてのＸＯＲ計算が完了するまで保留状態４６０に留まる。一実施形態では、ＸＯＲ計算に関連する部分のみが保留される場合もある。例えば、そのＩ／Ｏタスクが複数のストライプに対するアレイ書き込みである場合、１ストライプについてのＸＯＲ計算が完了すれば、アレイ内の他のストライプについてのＸＯＲ計算が終了していなくても、そのストライプに関する書き込みＩ／Ｏ子タスクを生成することができる。
【００７９】
Ｉ／Ｏタスクが完了すると（例えば、ディスクからデータが読み出されてバッファに配置された場合、子Ｉ／Ｏタスクが完了した場合、及び／又は、ＸＯＲ計算タスクが完了した場合など０、Ｉ／Ｏタスク終了処理（パス４３０）がコールされる。Ｉ／Ｏタスクに割り当てられた必要なリソースが開放され、Ｉ／ＯタスクはＩ／Ｏタスク完了状態４３５に移る。子Ｉ／Ｏタスクの場合、このＩ／Ｏタスク完了状態４３５は、親Ｉ／Ｏタスクに完了を通知することも含む（例えば、親Ｉ／Ｏタスクの例示的第３の機能ベクトルをコールすることによって下位Ｉ／Ｏタスクが完了したことを示す。例示の実施形態では、Ｉ／Ｏタスクは、中間状態情報を持続性記憶装置４８０に格納することができ、電源遮断やシステムリブートの後でも復元することができる。
【００８０】
図５は、データアクセス要求を実施するために用いられる他の例示的処理を示すものである。データアクセス要求を満たすため、ストレージシステム１０５は、ツリーのルートノード（例えばオブジェクト２００の階層順位におけるボリュームオブジェクト２０５）でＩ／Ｏタスクを開始する（ステップ５０５）。このオブジェクト（例えばボリュームオブジェクト２０５）は、１以上の子Ｉ／Ｏタスクを生成して（ステップ５１０）、必要なＩ／Ｏタスクを実施する。これらの子Ｉ／Ｏタスクは、ツリーの次の階層である場合もあるし（例えば、ボリュームオブジェクト２１０によるミラーオブジェクト２０５など）、数世代下の階層である場合（例えば、ボリュームオブジェクト２０５によるＲＡＩＤグループオブジェクト２２０）もある。子Ｉ／Ｏタスクが生成されると、ストレージシステム１０５は、その子Ｉ／Ｏタスクについて必要なリソースがすべて利用可能であるか否かを判定する（ステップ５１５）。リソースが利用可能でなかった場合、Ｉ／Ｏタスクは必要なリソースが利用可能になるまで保留される（ステップ５２０）。
【００８１】
リソースが利用可能であった場合、ストレージシステム１０５は、子Ｉ／Ｏタスクが何らかの読み出し（例えば、親Ｉ／Ｏタスクの要求を満たすための、ディスク１１０ｄからのデータの読み出しなど）を実行する必要があるか否かを判定する。親Ｉ／Ｏタスクがディスクからのデータの読み出し要求であった場合、ストレージシステム１０５は、読み出しが必要であることを判定する（ステップ５２５）。親Ｉ／Ｏタスクがディスクに対する書き込み要求であった場合、ストレージシステム１０５は、ストライプ内のデータブロックのうちのいくつかがデータを保持していて、パリティ計算のためにそのデータの値を読み出す必要がある場合、読み出しが必要であることを判定する（ステップ５２５）。ストレージシステム１０５が読み出しが必要であることを判定した場合（ステップ５２５）、ストレージシステム１０５は、そのオブジェクトが直接読み出しを実施できるか否かを判定する（ステップ５３０）。そのオブジェクトが直接読み出しを実施できない場合、ストレージシステム１０５は、別の子Ｉ／Ｏタスク（即ち、前のＩ／Ｏタスクよりも少なくとも１レベル低いＩ／Ｏタスク）を生成する（ステップ５１０）。オブジェクトが直接読み出しを実施できる場合、ストレージシステム１０５は、要求された読み出しを実施する（ステップ５３５）。ストレージシステム１０５は、親Ｉ／Ｏタスクを満たすため、子Ｉ／Ｏタスクによるさらなる読み出しが必要であるか否かを判定する（ステップ５２５）。
【００８２】
それ以上読み出しが必要ない場合、ストレージシステム１０５は、親Ｉ／Ｏタスクを満たすために、ＸＯＲ計算（即ちパリティ計算）が必要であるか否かを判定する（ステップ５４０）。ストレージシステム１０５は、ＸＯＲ計算が必要であることを判定した場合、その要求をＸＯＲスレッドに送信し（ステップ５４５）、その結果をバッファ（ステップ５１５で割り当てられる）に保存する。ストレージシステム１０５は、親Ｉ／Ｏタスクを満たすため、子Ｉ／ＯタスクによるさらなるＸＯＲ計算が必要であるか否かを判定する。
【００８３】
それ以上ＸＯＲ計算が必要ない場合、ストレージシステム１０５は、親Ｉ／Ｏタスクを満たすため、子Ｉ／Ｏタスクによるさらなる書き込み（即ちディスク１１０への書き込み）が必要であるか否かを判定する（ステップ５４５）。データアクセス要求がディスクからの読み出し要求であった場合、ストレージシステム１０５は、書き込みが不要であることを判定する（ステップ５４５）。データアクセス要求がディスクへの書き込み要求であった場合、ストレージシステム１０５は、書き込みが必要であることを判定する（ステップ５４５）。ストレージシステム１０５は、書き込みが必要であると判定した場合（ステップ５４５）、そのオブジェクトが直接書き込みを実施できるか否か（例えばディスクオブジェクト２２５）を判定する（ステップ５５０）。そのオブジェクトが直接書き込みを実施できない場合、ストレージシステム１０５は、別の子Ｉ／Ｏタスク（即ち、前のＩ／Ｏタスクよりも少なくとも１レベル低いところにあるＩ／Ｏタスク）を生成する（ステップ５１０）。オブジェクトが直接書き込みを実施できる場合、ストレージシステム１０５は、要求された書き込みを実施する（ステップ５５５）。ストレージシステム１０５は、親Ｉ／Ｏタスクを満たすため、子Ｉ／Ｏタスクによるさらなる書き込みが必要であるか否かを判定する（ステップ５４５）。
【００８４】
ストレージシステム１０５は、この子Ｉ／Ｏタスクレベルで何らかのエラーに遭遇した場合（ステップ５６０）、親オブジェクトレベルでエラー処理を開始する（ステップ５６５）。このエラー判定は処理５００の終端に向かって探索されるが、処理中のいかなる時点であっても、エラーに遭遇すれば、この処理はステップ５６５へジャンプする（分かりやすくするため、この接続は図示しない）。子Ｉ／Ｏタスクが完了すると、子Ｉ／Ｏタスクは、その親Ｉ／Ｏタスクに通知を行なう（ステップ５７０）
【００８５】
上記のように、一実施形態において、Ｉ／Ｏタスクは、必要な動作を開始できるようになる前に、必要なリソースすべてを取得しなければならない場合がある。一実施形態では、リソースマネージャ１５５がストレージシステム１０５に対して利用可能なすべてのリソースの割り当てを管理する場合がある。リソースマネージャ１５５は、Ｉ／Ｏタスクからの要求に応じて、リソースの割り当て及び割り当て解除を行なうものである。リソースマネージャ１５５によって管理されるリソースには、例えば、ストライプロック、メモリデータ構造、データバッファメモリ割り当て、ＮＶＲＡＭスロットなどがある。ストライプロックは、一連のオブジェクト２００のうちの特定オブジェクトにおいて、ある範囲のＤＢＮに対して得られるロックである。メモリデータ構造は、生成されたＩ／Ｏタスクのインスタンスを保持するために十分なだけのメモリの割り当てである。データバッファメモリ割り当ては、読み出したデータの保持および実行に十分なだけのメモリの割り当てであり、パリティ計算を実施してそのパリティ計算の結果を保持するのに十分なだけのメモリを割り当てるようにする。また、データバッファメモリ割り当ては、ストライプ内の１台のディスクが正しく動作しなくなった場合の劣悪な状況における読み出しデータの保持、及び、ストライプを復元するための計算に必要なだけのメモリの割り当てでもある。ＮＶＲＡＭスロットは、タスク特有の中間状態情報を保持するような大きさの不揮発性メモリの割り当てである。書き込みＩ／Ｏタスク中にデータが書き込まれるまでデータ記憶用にこのＮＶＲＡＭを用いることにより、システムクラッシュやディスク故障からの復旧が可能になる。
【００８６】
上記のように、Ｉ／ＯタスクはＩ／Ｏスタックへ個別に送信され、スケジューリングされ、互いの関係とは無関係にサービス提供される。リソースマネージャ１５５は、Ｉ／Ｏタスクが生成され、そのＩ／Ｏタスクが必要なリソースの要求をリソースマネージャに送信したときに、リソースをそのＩ／Ｏタスクに割り当てる。換言すれば、リソースマネージャ１５５は、特定のリソースをタスクの特定のインスタンスに割り当て、そのＩ／Ｏタスクの特定のインスタンス以外のいかなるプロセスからもそのリソースを使用されないようにする。リソースマネージャ１５５が構成されるのは、リソースに対する負荷のバランスをとり、Ｉ／Ｏタスクの順方向伝搬を維持し、互いのリソースを待ち続けるＩ／Ｏタスクのデッドロック状態を防止するためである。
【００８７】
一実施形態では、Ｉ／Ｏタスクは、リソースマネージャ１５５を通してリソースの割り当てを要求する場合がある。リソースマネージャ１５５は、Ｉ／Ｏタスクの状態、ＩＯタスクが行なう要求の順番、または、特定Ｉ／Ｏタスクの将来のリソース要件に関する独立した知識を何ももたない。上記のように、各Ｉ／ＯタスクはそのＩ／Ｏタスクの進行を通じて一連の状態を有し、そのうちの１以上はリソースの割り当て（例えば、メモリ、ＮＶＲＡＭ、子Ｉ／Ｏタスクなど）を必要とする。リソースの割り当てが必要になった各時点で、Ｉ／Ｏタスクはリソースマネージャ割り当て関数を実施して、その要件を満たす。割り当てが満たされなかった場合、リソースマネージャ１５５は、要求されているＩ／Ｏタスクの保留に責任を負う。他の実施形態では、実施されるリソースマネージャ割り当て関数は、要求されたリソースを割り当てることができないという指示を、そのＩ／Ｏタスクに返す場合がある。Ｉ／Ｏタスクは、その指示（例えば、保留状態への変更、リソースの後続の要求のスケジューリングなど）に応じて所定の動作を実施することに責任を負う。
【００８８】
図６は、リソースの割り当てを管理してデッドロックを回避するための、リソース（即ち６０５、６１０、６１５、６２０、６２５、６３０、６３２、６３５、６４０、６４５、６５０、６５５、６６０、６６５、６７０、６８０及び６９０）の割り当ての階層順位の例示的実施形態の有向非周期性グラフ６００を示している。リソースマネージャ１５５は、Ｉ／Ｏタスクが開始される際にリソースをそのＩ／Ｏタスクに動的に割り当て、割り当ての順番がグラフ６００に図示した階層順位に従うようにする。図示のリソースには、バッファ（例えば６１５、６２５、６５５及び６９０等）、ミラーロック（例えば６３０等）、ストライプロック（例えば６５０等）及びＮＶＲＡＭスロット（例えば６６０等）など、特定タイプのリソースが含まれる。また、図示のリソースには、Ｉ／Ｏタスクであるリソースも含まれる。これらのＩ／Ｏタスクの中には、非エラー処理Ｉ／Ｏタスクとエラー処理Ｉ／Ｏタスクとが含まれる。非エラー処理Ｉ／Ｏタスクには例えば、ボリューム書き込みＩ／Ｏタスク６０５、ボリューム読み出しＩ／Ｏタスク６８０、ミラー書き込みＩ／Ｏタスク６１０、ミラー読み出しＩ／Ｏタスク６８５、ディスク書き込みＩ／Ｏタスク６６５及びディスク読み出しＩ／Ｏタスク６７０が含まれる。さらに、Ｉ／Ｏタスクの中には、両方であるものもあり、エラー処理状況にも非エラー処理にも割り当てられる場合があり、例えばプレックス読み出しＩ／Ｏタスク６３２及びアレイＩ／Ｏタスク６３５である。
【００８９】
概して、最上位のＩ／Ｏ（例えば、読み出しや書き込みを含むデータアクセス要求など）が与えられると、デッドロックを回避するため、有効グラフ６００に指示された順番でリソースの割り当てが行なわれる。リソースマネージャ１５５がリソース「Ａ」を割り当てると（例えば６３２）、リソースのプールが割り当てられたリソース「Ａ」よりも階層順位で上位にある他のリソースは、リソース「Ａ」が開放されるまで割り当てることができない。また、リソースマネージャ１５５は、全てのリソースを所与のプールから一度に割り当てる。例えば、リソースマネージャ１５５は、ミラー書き込みＩ／Ｏタスク６１０について要求されたすべてのリソースを、バッファヘッダ６１５について必要なリソースを割り当てるよりも前に割り当てる。リソースはいかなる順番で開放してもよい。所与のＩ／Ｏ（例えば、読み出し及び／又は書き込みを含むデータアクセス要求）について、すべてのリソースプールが必要になるわけではない。例えば、エラーに関するリソース（例えば６２０、６２５及び６４５）は、実際にエラーが発生したときにしか割り当てられない。
【００９０】
例えば図３に示した処理を用いると、ボリューム書き込みＩ／Ｏタスク３０４が生成される場合、リソースマネージャ１５５は、そのボリューム書き込みＩ／Ｏタスク３０４のインスタンスを保持するために十分なだけのメモリデータ構造６０５を割り当てる。グラフ６００を下方に向かって処理してゆき、ミラー書き込みＩ／Ｏタスク３０８が生成される場合、リソースマネージャ１５５は、例えばそのミラー書き込みＩ／Ｏタスク３０８のインスタンスを保持するために十分なだけのメモリデータ構造６１０を割り当てる。それらのリソース６１０が割り当てられると、リソースマネージャ１５５はさらに、バッファヘッダについてメモリデータ構造６１５を割り当てる。エラーを処理するためにミラー読み出しエラーＩ／Ｏが必要な場合、リソースマネージャ１５５は、何らかのパリティ計算のために書き込む必要があるストライプデータを保持するのに十分なだけのデータバッファ６２０も割り当てる。また、リソースマネージャ１５５は、ミラー書き込みＩ／Ｏタスク３０８が書き込みを行なっている先のＤＢＮ範囲をロックするのに十分なだけのミラーロック６３０も割り当てる。
【００９１】
リソースを割り当てる際、リソースマネージャ１５５は、上位レベルにあるＩ／Ｏタスクに割り当てられたリソースの割り当てまたは待機が防止される。例えば、リソースマネージャ１５５は、ミラー書き込みＩ／Ｏタスク３０８についてのメモリデータ構造６１０が利用可能でなかった場合、ボリューム書き込みＩ／Ｏタスク３０４にリソースを割り当てたり、ボリューム書き込みＩ／Ｏタスク３０４にリソース（例えばメモリデータ構造６０５）が割り当てられるのを待機したりすることはない。一実施形態では、特定Ｉ／Ｏタスクについてのリソースがすべて利用不能であった場合、リソースマネージャ１５５は、そのＩ／Ｏタスクにすでに割り当てられているリソースを開放し、必要なＩ／Ｏタスクのすべてが利用可能になるまで開放する。例えば、リソース６１０、６１５及び６２０をミラー書き込みＩ／Ｏタスク３０８に割り当てた後でリソースマネージャ１５５が必要なミラーロック６３０を割り当てることができなかった場合、リソースマネージャは、リソース６１０、６１５及び６２０の割り当てを解除する（例えば、それらが利用可能であることを示すことによって、それらのリソースをストレージシステム１０５に開放する）。
【００９２】
他の実施形態では、保留中であってもＩ／Ｏタスクがそれに割り当てたれたリソースを維持し、必要なリソースすべてを得ると、そのＩ／Ｏタスクを再開するようになっている場合がある。さらに別の実施形態では、リソースの割り当ては維持されるが、グラフ６００の逆順でリソースの割り当てをすることができない場合もある。例えば、ミラー書き込みＩ／Ｏタスク３０８についてリソース６１０及び６１５を割り当て、エラー状況が存在しないという理由から６３０へ飛んだ後、リソースマネージャ１５５は、逆行することができないので、エラーに遭遇した場合、ミラー読み出しエラーＩ／Ｏリソース６２０を実質的に割り当てることができない場合がある。このような状況では、リソースマネージャは、リソース６１０、６１５及び６３０の割り当てを解除し（例えば、それらが利用可能であることを示すことによってそれらのリソースをストレージシステム１０５に返す）、割り当て処理を再び開始する。
【００９３】
リソースマネージャ１５５は、エラー処理が必要な場合、ミラーオブジェクト２１０によるエラー処理のために、データを保持するための所定サイズのデータバッファ６２５を割り当てる場合がある。このレベルでのエラー処理が必要になるのは、同一のＲＡＩＤグループ２２０に関する２台のディスク１１０が故障して、ストライプの復元ができず、ミラー記憶装置からデータを読み出さなければならない場合である。所定サイズのデータバッファ６２５は、ＲＡＩＤグループ２２０の物理構成、及び、書き込みを行なうＶＢＮアレイ（例えば３０２）のサイズに基づくものなどでよい。好ましい実施形態では、エラー処理用のリソースは、エラーが発生したときにしか割り当てされない。
【００９４】
グラフ６００を下方に処理してゆき、アレイ書き込みＩ／Ｏタスク３１４が生成された場合、リソースマネージャ１５５は、例えば、ストライプデータを含んでいるアレイ書き込みＩ／Ｏタスク３１４のインスタンスを保持するために十分なだけのメモリデータ構造６３５を割り当てる。ミラーレベルでのエラー処理が必要な場合、リソースマネージャ１５５は、プレックス読み出しＩ／Ｏ６３２及びグループ読み出しＩ／Ｏ６４０に必要なリソースも割り当てる。パスに関係なく、リソースマネージャ１５５は、読み出しエラーＩ／Ｏタスクと呼ばれる読み出しＩ／Ｏエラー処理タスクをサポートするためのリソースも割り当てる。この読み出しエラーＩ／Ｏタスクは、劣悪な状態で故障したディスクに属するブロックの通常読み出しまたは読み出し中におけるエラーを処理するために用いられる。
【００９５】
読み出しエラーＩ／Ｏエラー処理タスクに対して、リソースマネージャ１５５は、例えば、読み出しエラーＩ／Ｏエラー処理タスクのインスタンスを保持するために十分なだけのメモリデータ構造６４５を割り当てる。これと同時に、リソースマネージャ１５５は、パリティ計算のために読み出す必要があるストライプデータを保持するのに十分なだけのデータバッファも割り当てる。
【００９６】
グラフ６００を下方に処理してゆき、リソースマネージャ１５５は、アレイ書き込みＩ／Ｏタスク３１４において書き込みを行なう先にあたるＤＢＮ範囲をロックするのに必要なすべてのストライプロック６５０も割り当てる。リソースマネージャ１５５は、アレイ書き込みＩ／Ｏタスク３１４による処理のために、データを保持するための所定サイズのデータバッファ６５５も割り当てる。書き込みＩ／Ｏタスクの場合、リソースマネージャ１５５は、タスク特有の中間状態情報を保持するのに十分なだけのＮＶＲＡＭスロット６６０も割り当てる。
【００９７】
この場合も、リソースを割り当てる際、リソースマネージャ１５５は、上位レベルのＩ／Ｏタスクに割り当てられたリソースを割り当てたり、それを待機したりすることはない。例えば、アレイ書き込みＩ／Ｏタスク３１４についてメモリデータ構造６３５が利用できない場合、リソースマネージャ１５５は、ボリューム書き込みＩ／Ｏタスク３０４に割り当てられたリソース（例えばメモリデータ構造６０５）やミラー書き込みＩ／Ｏタスク３０８に割り当てられたリソース（例えばメモリデータ構造６１０）を割り当てたり、それらを待機したりすることはない。
【００９８】
ディスク書き込みＩ／Ｏタスク３６０が生成されると、リソースマネージャ１５５は、例えばそのディスク書き込みＩ／Ｏタスク３６０のインスタンスを保持するのに十分なだけのメモリデータ構造６７５を割り当てる。ディスク書き込みＩ／Ｏタスク３６０についてメモリデータ構造６７５が利用できない場合、リソースマネージャ１５５は、ボリューム書き込みＩ／Ｏタスク３０４に割り当てられたリソース（例えばメモリデータ構造６０５）、ミラー書き込みＩ／Ｏタスク３０８に割り当てられたリソース（例えばメモリデータ構造６１０）またはアレイ書き込みＩ／Ｏタスク３１４に割り当てられたリソース（例えばメモリデータ構造６３５）を割り当てたり、それらを待機したりすることはない。
【００９９】
読み出しデータアクセス要求についてのリソースも、同様の方法で割り当てられる。幾つかの相違点だけを強調しておく。ボリューム読み出しＩ／Ｏタスクが生成されると、リソースマネージャ１５５は、例えば、そのボリューム読み出しＩ／Ｏタスクのインスタンスを保持するのに十分なだけのメモリデータ構造６８０を割り当てる。ミラー読み出しＩ／Ｏタスクが生成されると、リソースマネージャ１５５は、例えば、そのミラー読み出しＩ／Ｏタスクのインスタンスを保持するのに十分なだけのメモリデータ構造６８５を割り当てる。ミラー読み出しＩ／Ｏタスクについての他のリソースは、リソースマネージャ１５５がメモリデータ構造６１５ではなく読み出しを検証するために必要なデータを保持するのに十分なだけのデータバッファ６９０を割り当てる点を除けば、ミラー書き込みＩ／Ｏタスクの場合と同様である。
【０１００】
書き込みＩ／Ｏタスクの場合と同様に、リソースを割り当てる際、リソースマネージャ１５５は、上位レベルのＩ／Ｏタスクに割り当てられたリソースを割り当てたり、それを待機したりすることはない。例えば、ミラー読み出しＩ／Ｏタスクについてメモリデータ構造６８５が利用できない場合、リソースマネージャ１５５は、ボリューム読み出しＩ／Ｏタスクに割り当てられたリソース（例えばメモリデータ構造６８０）を割り当てたり、それを待機したりすることはない。
【０１０１】
もう１つの違いは、読み出しＩ／Ｏタスクの場合、読み出しＩ／ＯタスクはＮＶＲＡＭスロット６６０を割り当てる必要がないということである。読み出しＩ／Ｏタスクの場合、リソースマネージャ１５５がバッファ６５５を割り当てれば、読み出しＩ／Ｏタスクは、ＮＶＲＡＭスロットの利用可能性を考慮することなくディスク読み出しＩ／Ｏタスクを生成することができる。ディスク読み出しＩ／Ｏタスクが生成されると、リソースマネージャ１５５は、そのディスク読み出しＩ／Ｏタスクのインスタンスを保持するのに十分なだけのメモリデータ構造６９５を割り当てる。ディスク読み出しＩ／Ｏタスクについてメモリデータ構造６９５が利用できない場合、リソースマネージャ１５５は、ボリューム読み出しＩ／Ｏタスクに割り当てられたリソース（例えばメモリデータ構造６８０）やミラー読み出しＩ／Ｏタスクに割り当てられたリソース（例えばメモリデータ構造６８５）を割り当てたり、それらを待機することはない。
【０１０２】
他の実施形態では、リソースマネージャ１５５は、リソースの割り当てに優先順位を設けるためのリストを使用し、リストにあるＩ／Ｏタスクがりスト中でそれよりも上位にあるＩ／Ｏタスクからリソースを得ることを防止する。かかるリストは、例えば、高優先順位から低優先順位の順番で、ボリューム読み出し、ボリューム書き込み、ミラー読み出し、ミラー書き込み、ミラー読み出しエラー、プレックス読み出し、ＲＡＩＤグループ読み出し、アレイ読み出し、ディスク読み出し、ディスク書き込み、ストライプ読み出し、ストライプ書き込み、ＲＡＩＤグループのパリティ復元、ストライプパリティ復元、及び、ミラー確認になっている。リスト中の特定のＩ／Ｏタスクにリソースを割り当てる際、リソースマネージャ１５５は、リスト中でそれよりも上位にあるＩ／Ｏタスク（即ち、リスト中でその特定Ｉ／Ｏタスクよりも先にくるＩ／Ｏタスク）に割り当てられたリソースを割り当てたり、それを待機したりすることが防止される。例えば、ミラー書き込みＩ／Ｏタスクについてメモリデータ構造が利用できない場合、リソースマネージャ１５５は、ボリューム読み出しＩ／Ｏタスク、ボリューム書き込みＩ／Ｏタスクまたはミラー読み出しＩ／Ｏタスクに割り当てられたリソースを割り当てたり、それを待機したりすることはない。
【０１０３】
図７は、複数７００のリソースプール（まとめて７０５と呼ぶ）の例示的実施形態の論理表現を示している。３つのリソースプール、すなわちリソースプールＡ　７０５ａ、リソースプールＢ　７０５ｂおよびリソースプールＣ　７０５ｃが示されている。リソースプールＡ　７０５ａは、リソースタイプＡの集合７１０ａ、リソースタイプＢの集合７１５ａおよびリソースタイプＣの集合７２０ａを格納している。リソースプールＢ　７０５ｂは、リソースタイプＡの集合７１０ｂ、リソースタイプＢの集合７１５ｂ、リソースタイプＣの集合７２０ｂおよびリソースタイプＤの集合７２５ｂを格納している。リソースプールＣ　７０５ｃは、リソースタイプＡの集合７６０およびリソースタイプＤの集合７６５を格納している。リソースマネージャ１５５は、リソースプール７０５のうちの１つを各Ｉ／Ｏタスクに関連づけ、そのＩ／Ｏタスクが関連付けられたリソースプールの中からそのＩ／Ｏタスクに必要なリソースを割り当てる。換言すれば、関連付けられたリソースプール７０５からのリソース割り当てを必須とすることで、リソースマネージャ１５５は、利用可能にした複数タイプのリソース（例えばタイプＡ　７１０ａ、タイプＢ　７１５ａ及びタイプＣ　７２０ａなど）に対して、下限および上限を設定する。以下で詳しく説明するように、プール７０５は、特定のＩ／Ｏタスク、Ｉ／Ｏタスクの階層、特定オブジェクトに関連するＩ／Ｏタスクまたはある種のＩ／Ｏタスクなどに関連付けて定義することができる。これらの境界は、システムの現在の構成情報（例えば、ボリュームやディスクの数、メモリの量、ＣＰＵ、ＮＶＲＡＭなど）に基づいて、動的にサイズ変更することができる。Ｉ／Ｏタスクへのリソースの割り当てをそのＩ／Ｏタスクに関連付けられたプール７０５から行なうことにより、リソースマネージャ１５５は、１つのＩ／Ｏタスクが利用可能なシステムリソースのすべてを消費してしまわないことを保証する。１つのＩ／Ｏタスクがそれらのリソースのほとんどを消費できるようにした場合、他のＩ／Ｏタスクが待機状態になり、データアクセス要求に対するストレージシステム１０５の応答性が極度に低下することになる。
【０１０４】
リソースタイプには例えば、ストライプロック、メモリデータ構造、データバッファメモリ割り当て、ＮＶＲＡＭスロットなどがある。特定タイプのリソースの集合（例えば、タイプＡ　７１０ａ、タイプＢ　７１５ａおよびタイプＣ　７２０ａ）を定義するため、リソースマネージャ１５５は、例えばそのリソースタイプの量および位置を、集合に定義する。リソースタイプの位置は、物理的位置でも、物理的位置にマッピングされた論理／仮想位置でもよく、リソースマネージャ１５５は最適化アルゴリズムに従ってそのマッピングを動的に変更できるようになっている。
【０１０５】
一実施形態において、３つのリソースプール７０５ａ、７０５ｂおよび７０５ｃに格納されたリソース集合の合計は、ストレージシステム１０５が利用可能なリソースの全てを表している。例えば、リソースタイプＡ、７１０ａ、７１０ｂおよび７１０ｃの合計は、まとめて７１０と呼ばれ、リソースマネージャ１５５が割り当てることのできるタイプＡ　７１０のリソースの全集合を表している。同様に、リソースタイプＢ、７１５ａ及び７１５ｂの合計は、まとめて７１５と呼ばれ、リソースマネージャ１５５が割り当てることのできるタイプＢ　７１５のリソースの全集合を表している。リソースタイプＣ、７２０ａ及び７２０ｂの合計は、まとめて７２０と呼ばれ、リソースマネージャ１５５が割り当てることのできるタイプＣのリソースの全集合を表している。リソースタイプＤ、７２５ａ及び７２５ｂの合計は、まとめて７２５と呼ばれ、リソースマネージャ１５５が割り当てることのできるタイプＤのリソースの全集合を表している。
【０１０６】
リソースマネージャ１５５は、Ｉ／Ｏタスク（例えば、ボリューム書き込み３０４、ミラー書き込み３０６、ディスク読み出し３２４など）の各々をリソースプール７０５に関連付ける。Ｉ／Ｏタスクが生成されると、リソースマネージャ１５５は、その生成されたＩ／Ｏタスクに関連するリソースプール７０５から必要なリソースを割り当てる。その生成されたＩ／Ｏタスクが完了すると、リソースマネージャ１５５は、割り当てたリソースを元のプール７０５に戻す（即ち、割り当てを解除する）。
【０１０７】
例えば、リソースタイプＡ７１０は、メモリデータ構造タイプのリソースである。リソースマネージャ１５５は、ボリューム書き込みＩ／ＯタスクをリソースプールＡ７０５ａに関連付ける。ボリューム書き込みＩ／Ｏタスクを生成するときに必要なリソースは、そのボリューム書き込みＩ／Ｏタスクのインスタンスを保持するのに十分なだけのメモリデータ構造６０５である。ボリューム書き込みＩ／Ｏタスクのインスタンス（例えば、ボリューム書き込みＩ／Ｏタスク３０４）が生成されたとき、リソースマネージャ１５５は、リソースプールＡ７０５ａのリソースタイプＡ７１０ａのうちの未割り当ての量が、必要なメモリデータ構造を割り当てるのに十分な大きさであるか否かを判定する。
【０１０８】
換言すれば、リソースプールＡ７０５ａのリソースタイプＡ７１０ａの集合のうちの一部が、現在存在している１以上の他のボリューム書き込みＩ／Ｏタスクに割り当てられる。現在未割り当てのリソースタイプＡ７１０ａの部分が十分な大きさでなかった場合、リソースマネージャは要求されたリソースを割り当てることができない。Ｉ／Ｏスレッドは、ボリューム書き込みＩ／Ｏタスク３０４を、関連するリソースプールＡ７０５ａからリソースが利用可能になるまで保留する。リソースマネージャ１５５は、未割り当てのリソースタイプＡ７１０ａの部分がボリューム書き込みＩ／Ｏタスク３０４を収容するのに十分な大きさに増加するまで待機する。他の実施形態では、Ｉ／Ｏスレッドがボリューム書き込みＩ／Ｏタスク３０４を保留しない場合もある。代わりに、リソースマネージャが呼び出された場合、割り当て機能は、要求されたリソースを割り当てることができないという指示をそのＩ／Ｏタスクに返し、その指示に応じてＩ／Ｏタスクが予め定義された動作（例えば、保留状態への変更や、後続のリソースの要求のスケジューリングなど）を実施する場合もある。
【０１０９】
そのような増加が起こるのは、例えば、別のボリューム書き込みＩ／Ｏタスクが完了して、そのタイプＡ７１０ａのリソースがリソースプールＡ７０５ａに返還された場合である。また、増加は、リソースマネージャ１５５がリソースタイプＢ７０５ｂからリソースタイプＡの集合７１０ｂの一部を移転させることにより、リソースタイプＡの集合７１０ａを動的に増加させた場合にも起こる。リソースマネージャ１５５は、例えば統計データや履歴的最大使用量などに応じて、この動的割り当てを行なう。
【０１１０】
一実施形態において、リソースマネージャ１５５は、Ｉ／Ｏタスクのタイプに応じてプールを定義し、同タイプのあらゆるＩ／Ｏタスクをそのプールに関連づける。例えば、リソースプール７０５ａは、書き込みＩ／Ｏタスクとして定義される。リソースマネージャは、書き込みＩ／Ｏタスクの類（例えばボリューム書き込みやディスク書き込みなど）をそのリソースプール７０５に関連付ける。リソースの集合７１０ａ、７１５ａ及び７２０ａの下限は、例えば１ストライプへの書き込みがそれらの定義されたリソースを用いて実行できるように制限される。リソースの集合７１０ａ、７１５ａ及び７２０ａの上限は、例えば他のプール７０５ｂに関する読み出しタイプのＩ／Ｏタスクに利用可能な他のシステムリソースが存在するように制限され、このようなＩ／Ｏタスクは書き込み処理中に順方向伝搬を保証するため必要に応じて割り当てられることがある。
【０１１１】
他の実施形態では、リソースマネージャ１５５は、ディスクアレイ１１５の階層表現（例えば２００）に従ってリソースプール７０５を定義する場合がある。例えばリソースマネージャ１５５は、ボリュームオブジェクト２０５に関連するＩ／Ｏタスク（例えばボリューム書き込みやボリューム読み出しなど）について、第１のリソースプール７０５ａを定義する。リソースマネージャ１５５は、そのボリュームオブジェクト２０５に関連するＩ／Ｏタスクに必要なリソースタイプのすべてを、その第１のリソースプール７０５ａに含める。リソースマネージャ１５５は、ミラーオブジェクト２１０に関連するＩ／Ｏタスク（例えばミラー書き込みやミラー読み出しなど）について、第２のリソースプール７０５ｂを定義する。リソースマネージャ１５５は、ミラーオブジェクト２１０に関連するＩ／Ｏタスクに必要なリソースタイプの全てを、そのリソースプール７０５ｂに含める。リソースマネージャ１５５は、各階層に関連するＩ／Ｏタスク（例えば、プレックスオブジェクト２１５、ＲＡＩＤグループオブジェクト２２０およびディスクオブジェクト２２５など）について、さらなるプールを同様に定義する。
【０１１２】
リソースマネージャ１５５は、定義されたリソースプール７０５の各々について、リソースプール７０５の各々に関連づけられたリソースの集合を判定する。リソースのタイプによって判定されているリソースの集合に加えて、階層の各Ｉ／Ｏタスクは、リソースマネージャ１５５がそのリソースの集合を構成情報にも基づいて判定することを要求する。構成情報は、記憶装置（例えばディスクアレイ１１５のディスク１１０）の実施形態を表すものである。
【０１１３】
図２に示す実施形態において、この構成情報は、オブジェクト２００の階層順位として表現されている。図示のように、プレックスオブジェクト２１５はミラーリングされていて、各プレックスオブジェクト２１５が２つのＲＡＩＤグループオブジェクト２２０を有し、各ＲＡＩＤグループ２２０が３つのディスクオブジェクト２２５を有するようになっている。オブジェクト２００のこの階層順位は、互いに論理的に関連する１２台のディスク１１０を表している。物理的関係は様々でよい。例えば、大惨事を回避するため、一方のプレックスオブジェクト２１５ａに関連する６台のディスク１１０は、他方のプレックスオブジェクト２１５ｂに関連する６台のディスクから離れた場所（例えば、離れた建物や、離れた州など）に配置することができる。
【０１１４】
しかしながら、配置を行なうときは常に、リソースマネージャ１５５がこの構成情報に基づいて各ミラー書き込みＩ／Ｏタスク（例えば３０８）についてそれを判定し、図示の構成では、２つのプレックスＩ／Ｏタスク（例えば３１４及び３１６）が必要になる。同様に、図示の構成では、ＲＡＩＤ＿グループ書き込みＩ／Ｏタスク（例えば３５２）の各々について、３つのディスク書き込みＩ／Ｏタスク（例えば３６０、３６２、３６４）が必要になる。リソースマネージャ１５５は、それらのＩ／Ｏタスクに関連する各リソースプール７０５のリソースの集合を構成情報に応じて割り当てなければならいことを判定する。
【０１１５】
図７を参照する例では、リソースマネージャ１５５は、ＲＡＩＤ＿グループ書き込みＩ／Ｏタスクをリソースプール７０５ａに関連付けている。ＲＡＩＤ＿グループ書き込みＩ／Ｏタスクが要求するリソースタイプの１つは、メモリデータ構造リソースタイプ７１０ａである。メモリマネージャ１５５は、メモリデータ構造リソースタイプ７１０ａの量をリソースプール７０５ａに関連づけ、同時に、このリソースタイプのＲＡＩＤ＿グループ書き込みＩ／Ｏタスクへの割り当てを可能にする。
【０１１６】
リソースマネージャ１５５は、ディスク書き込みＩ／ＯタスクをリソースプールＢ７０５ｂに関連付ける。ディスク書き込みＩ／Ｏタスクが要求するリソースタイプの１つは、メモリデータ構造リソースタイプ７１０ｂである。ＲＡＩＤ＿グループ書き込みＩ／Ｏタスク対ディスク書き込みＩ／Ｏタスクの所定の比率は１対３であるから、リソースマネージャ１５５は、メモリデータ構造リソースタイプ７１０ａの量をリソースプールＢに関連づけ、同時に、このリソースタイプの３０個のディスク書き込みＩ／Ｏタスクへの割り当てを可能にする。リソースプール７０５の各々におけるリソース集合のサイズ変更によって、子Ｉ／Ｏタスクの順方向伝搬の存在が保証される。必要なリソースを得たＲＡＩＤ＿グループ書き込みＩ／Ｏタスクの各々について、その３つの子Ｉ／Ｏタスクもそれらに必要なリソースを得ることができる。リソースプール７０５のサイズ変更によって、Ｉ／Ｏタスクのフローが制御される。
【０１１７】
この所定の比率は、変更することもできる。例えば、ディスク１１０を追加または除去することによって、構成情報を変更し、例示の１対３の所定比率を変化させることができる。また、劣悪な環境では、エラーが生じる可能性があり、Ｉ／Ｏタスクを処理するためにさらにリソースが必要になる場合がある。先の例を続けると、ＲＡＩＤグループ内でエラーに遭遇した場合、各ディスク書き込みＩ／Ｏタスクについて２倍の量のリソースタイプＡ７１０ｂが必要になる。従って、このエラー状況では、所定の比率が１対６の比率に変更される。
【０１１８】
エラー条件があると、劣悪なエラー条件下ではディスク書き込みＩ／Ｏタスクに必要なリソースを２重化するので、１０個のＲＡＩＤ＿グループ書き込みＩ／Ｏタスクがリソースプール７０５ａからリソースを得た場合でも、それらの子ディスク書き込みＩ／Ｏタスク（即ち、１５個のディスク書き込みＩ／Ｏタスク）のうちの半分だけしか、リソースプールＢ７０５ｂからリソースを得ることができない。ディスク書き込みＩ／Ｏタスクのうちの半分は、他のディスク書き込みＩ／Ｏタスクが完了してリソースプールＢ７０５ｂからリソースの割り当てが解除されるまで、保留される。この状態は、ライブロック状態または枯渇と呼ばれる。換言すると、ライブロックが発生するのは、システムが複数のＩ／Ｏタスクを処理しているが、子ディスク書き込みＩ／Ｏタスクのうちの一部（例えば１つまたは２つ）だけしかりソースを得ることができないために、親ＲＡＩＤ＿グループ書き込みＩ／Ｏタスクが１つも順方向伝搬を行なうことができない場合や、完了することができない場合である。一実施形態では、プール７０５は、システム内の最大ＲＡＩＤグループサイズの１ストライプを書き込むのに必要な最小リソースを少なくとも含むようなサイズにする場合がある。プール７０５内で必要な最小リソースの分配は、Ｉ／Ｏタスクをプール７０５に関連付けるのに用いられる方法に応じて決まる。
【０１１９】
一実施形態では、Ｉ／ＯスレッドがＩ／Ｏタスクのフローを制御して、子Ｉ／Ｏタスクの保留を解除する場合がある。この実施形態では、Ｉ／ＯスレッドがＲＡＩＤグループ書き込みＩ／Ｏタスクを５つだけ同時にスケジューリングするようにすることで、子ディスク書き込みＩ／Ｏタスクが必要なリソースを得られるようにし、順方向伝搬を維持する。エラー状況が除去されると、Ｉ／Ｏスレッドは、全てのリソースを完全に使用するのには十分なだけの１０個のＲＡＩＤ＿グループ書き込みＩ／Ｏタスクのスケジューリングを同時に行うように戻り、子Ｉ／Ｏタスクの順方向伝搬を保証するだけに制限される。
【０１２０】
他の実施形態では、リソースマネージャ１５５は、第１のプール７０５ａを定義し、長期動作に関連する何らかのＩ／Ｏタスクをその第１のプールに関連付ける場合がある。長期動作とは、完了するまでに何度もディスク１１０にアクセスする必要があるタスクの類であり、一般的にはデータ管理の必要性から計算を行なう必要があり、バックグラウンドタスクとして実行することができるものである（例えば、他のタイプのＩ／Ｏタスクよりも高い優先順位を有してはならない）。長期動作に関連するタスクには、例えば、パリティ検証Ｉ／Ｏタスク、ミラー検証Ｉ／Ｏタスク、ＲＡＩＤグループのパリティ復元、ミラー際同期などが含まれる。
【０１２１】
リソースマネージャ１５５は、第２のプール７０５ａを定義し、長期動作に関連する何らかのＩ／Ｏタスクをその第２のプールに関連付ける。タイムクリティカル動作は、ディスク１１０に直ちにアクセスする必要があるタスクの類であり、典型的にはクライアント１７５からの要求を満たす必要があり、バックグラウンドタスクとして実行されるものではない（例えば、他のタイプのＩ／Ｏタスクよりも高い優先順位を有しなければならない）。タイムクリティカル動作に関連するＩ／Ｏタスクには、例えば、劣化の無いＲＡＩＤグループからのディスク読み出し、劣化の無いＲＡＩＤグループについてのディスク書き込みなどが含まれる。
【０１２２】
この方法でプールを分割することによって、リソースマネージャ１５５は、ストレージシステム１０５の全リソースのうちの長期動作に用いられる量を制御し、クライアント１７５のデータアクセス要求を処理するために利用可能な十分なリソースの存在を確保することができる。リソースマネージャ１５５は、第１のプール７０５ａおよび第２のプール７０５ｂに対するリソースタイプの割り当てを動的に変更することができる。リソースマネージャ１５５は、例えば、統計データ、履歴的最大使用量などに応じて、この動的割り当てを行なう。
【０１２３】
他の実施形態では、上記のようなリソースマネージャ１５５がプール７０５を定義する方法とは関係なく、リソースマネージャが個別のエラープール７０５ｅ（図示せず）を定義する場合がある。リソースマネージャ１５５は、エラー処理に関連する何らかのＩ／Ｏタスクをエラープールに関連付ける。エラー処理を行なうため、リソースマネージャ１５５は、このエラープール７０５ｅからリソースをそれらのエラー処理Ｉ／Ｏタスクに割り当てる。エラープール７０５ｅからリソースをそれらのエラーを処理するＩ／Ｏタスクに割り当てることによって、リソースマネージャ１５５は、利用可能なシステムリソースをすべて消費しデータアクセス要求に対するストレージシステム１０５の応答速度を極度に低下させるエラーＩ／Ｏタスクが存在しないようにする。エラーが存在するパスに関連しないＩ／Ｏタスクは、すべて迅速に処理できなければならない。リソースマネージャ１５５は、エラープール７０５ｅに対するリソースタイプの割り当てを動的に変更することができる。リソースマネージャは、この動的割り当てを、例えば現在分かっているディスクエラー、統計データ、履歴的使用量などに応じて行なう。他の実施形態では、システム内の各ＲＡＩＤグループについてエラープール７０５が存在する場合もある。この実施形態では、各ＲＡＩＤグループについてのエラー処理Ｉ／Ｏタスクは、各々独自のエラープール７０５に関連付けられる。ＲＡＩＤグループに関して割り当てられるエラー処理Ｉ／Ｏタスクの量を制限することで、システムの全リソースが特定のＲＡＩＤグループに書き込まれるデータ復元にかかりきりになってしまうことが防止される。
【０１２４】
他の実施形態では、グラフ６００（図６）の各リソースグループ（即ち、６０５、６１０、６１５、６２０、６２５、６３０、６３２、６３５、６４０、６４５、６５０、６５５、６６０、６６５、６７０、６８０、６８５及び６９０で識別されるリソース）は、それ独自のリソースプール７０５に関連付けられる場合がある。関連付けされるリソースプールには、その特定グループに必要なリソースタイプが含まれる。例えば、ボリューム書き込みＩ／Ｏリソースグループ６０５がメモリデータ構造リソースタイプ７１５ａを必要とする場合、そのリソースグループ６０５に関連するリソースプール７０５ａは、そのボリューム書き込みＩ／Ｏタスクのインスタンスを保持するのに十分なだけのリソースタイプ７０５ａを保持している必要がある。さらに、グラフ６００においてリソースグループ６０５よりも下にあるリソースグループに関連するリソースプール７０５が上記のような所定比率を用いてサイズ変更された場合、そのリソースプール７０５ａもそれに見合ったサイズにする必要がある。例えば、リソースプール７０５が１０個のボリューム書き込みＩ／Ｏタスクを同時に処理するようなサイズであった場合、リソース７０５ａも、ボリューム書き込みＩ／Ｏタスクの１０個のインスタンスを保持するのに十分なだけのリソースタイプ７０５ａを保持していなければならない。
【０１２５】
均等
本発明は、その思想と本質的特徴から外れることなく、他の形態で実施することもできる。従って、上記の実施形態は、すべて例示的なものであり、本明細書に記載した発明を制限するものではないと考えるべきである。従って、本発明の範囲は、上記の説明ではなく付記した特許請求の範囲に提示されるものであり、特許請求の範囲に記載した発明の均等の意味及び範囲にあたる変更は、すべて本発明に含まれることを意図している。
【図面の簡単な説明】
【図１】本発明に有利に用いられるストレージシステムを含む環境の例示的実施形態を示すブロック図である。
【図２】本発明に有利に用いられるシステムの例示的実施形態の論理表現を示すブロック図である。
【図３】本発明に従って受信したデータの要求された書き込みを実施するために用いられる処理の例示的実施形態を示すフロー図である。
【図４】本発明に従って有利に用いられる分解されたＩ／Ｏタスクの例示的実施形態を示す状態図である。
【図５】本発明に従って要求されたＩ／Ｏタスクを実施するために用いられる他の処理の例示的実施形態を示すフロー図である。
【図６】本発明に従って有利に用いられるリソース割り当ての階層順位の例示的実施形態の論理表現を示すブロック図である。
【図７】本発明に従って有利に用いられる複数のリソースグループの例示的実施形態の論理表現を示すブロック図である。
【図１】
2004038932.tif 000003
【図２】
2004038932.tif 000004
【図３】
2004038932.tif 000005
【図４】
2004038932.tif 000006
【図５】
2004038932.tif 000007
【図６】
2004038932.tif 000008
【図７】
2004038932.tif 000009
【外国語明細書】
2004038932.tif 000010
2004038932.tif 000011
2004038932.tif 000012
2004038932.tif 000013
2004038932.tif 000014
2004038932.tif 000015
2004038932.tif 000016
2004038932.tif 000017
2004038932.tif 000018
2004038932.tif 000019
2004038932.tif 000020
2004038932.tif 000021
2004038932.tif 000022
2004038932.tif 000023
2004038932.tif 000024
2004038932.tif 000025
2004038932.tif 000026
2004038932.tif 000027
2004038932.tif 000028
2004038932.tif 000029
2004038932.tif 000030
2004038932.tif 000031
2004038932.tif 000032
2004038932.tif 000033
2004038932.tif 000034
2004038932.tif 000035
2004038932.tif 000036
2004038932.tif 000037
2004038932.tif 000038
2004038932.tif 000039
2004038932.tif 000040
2004038932.tif 000041
2004038932.tif 000042
2004038932.tif 000043
2004038932.tif 000044
2004038932.tif 000045
2004038932.tif 000046
2004038932.tif 000047
2004038932.tif 000048
2004038932.tif 000049
2004038932.tif 000050
2004038932.tif 000051
2004038932.tif 000052
2004038932.tif 000053
2004038932.tif 000054
2004038932.tif 000055
2004038932.tif 000056
2004038932.tif 000057
2004038932.tif 000058
2004038932.tif 000059
2004038932.tif 000060
2004038932.tif 000061
2004038932.tif 000062
2004038932.tif 000063
2004038932.tif 000064
2004038932.tif 000065
2004038932.tif 000066
2004038932.tif 000067
2004038932.tif 000068
2004038932.tif 000069
2004038932.tif 000070
2004038932.tif 000071
2004038932.tif 000072
2004038932.tif 000073