(57)【特許請求の範囲】
【請求項１】
ディスク装置に複数のユーザがアクセスを必要とし、各ユーザが前記ディスク装置にある割合のアクセスを希望するシステムにおいて、
各ユーザに対して、他のシステム・ユーザとの相関でアクセス時間の割合を割り当てる装置と、
前記ユーザから前記ディスク装置へのアクセス要求を受信する装置と、
前記アクセス要求の発信元のユーザに割り当てられた前記アクセス時間の割合に依存して、前記要求の終了すべき時刻を同じユーザによる前回の要求の終了時刻に従って計算し、該終了すべき時刻に基づいて該要求の開始時刻を決定する装置と、
所与の時間内に存在する複数のユーザ要求の前記開始時刻を順序付ける装置と、
を備える、システム。
【請求項２】
前記要求の開始時刻は、該要求の終了すべき時刻からこの要求の処理に要する時間を引いて求められる、請求項１に記載のシステム。
【請求項３】
前記開始時刻の順序付けにおいてスケジューリングに空きが生じるとき、前記アクセス時間の割り当ての大きいユーザからの要求があれば、この空きに挿入できるようにした、請求項１に記載のシステム。
【請求項４】
システム・ユーザのアクセス割合を調整する装置を更に備える請求項１に記載のシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ストレージ（記憶装置）管理システム及び方法に関し、特に所望のシステムで使用可能なプロトコルに従ってデータの検索を効率的に管理するためのストレージ管理システム及び方法に関する。
【０００２】
【従来の技術】
コンピュータがデータをディスクに保存することは、もちろん周知の事実である。ＣＰＵとコンピュータ・アーキテクチャの他のコンポーネントは年々高速化が進んでおり、前述のディスクのデータ検索速度（帯域幅）も向上してきた。インターリービング、ストライピング、複数ディスクの併用、さまざまな形の「ルックアヘッド」処理を始めとする高速のキャッシングなど、多くの仕組みが採用されてきた。その全てがＣＰＵの処理速度の継続的な向上に対応してきたわけではない。
【０００３】
この問題の解決策の１つであるが限定的な効果しかないものに、ディスクを区分して個々のユーザが事前に割り当てられたディスク領域以外にはアクセスできないようにする方法がある。この解決策では、割り当てた領域は別でもディスクは同一なので、１つのディスクから複数のユーザが同時にデータを取得しようとする複数アクセスの問題が残る。
【０００４】
他に、特定のアクセスにほとんど割り込みベースで「即時の」データ検索を許可するという別の解決策もある。この方法でも、このような検索システムでデータを取得できるのは１度に１つのユーザのみである。この種のシステムでは、ユーザはシステムに対して１秒当たりのバイト数（又は希望するアクセスのその他の基準）を指定し、システムは指定のスループットの値を実現するように動作する。但し、このようなシステムで実現できるのは、いわゆるディスクへの直接アクセスのみについてである。この結果、このグループの要求を満足するまで、他のアプリケーションは記憶装置にアクセスできない。従って、１つのグループのみが優先され、他者は全て待機する。
【０００５】
優先順位の逆転として知られる状況を回避するための注意も必要である。この状況は、システム上の優先順位が非常に低い（例えばＣＰＵの１％しか使用できない）ユーザがディスクに大きな回数アクセスを要求する場合に発生する。ディスクへのアクセス要求が発生するとすぐにＣＰＵの使用が停止し、要求された演算が割り当てのタイムスロットを全て使うわけではないため、逆転が起こる。このような状況では、ユーザはＣＰＵの少ない使用量を補うために高い優先順位を得る。従って、この状況では１％のユーザがシステム全体を事実上停止させる恐れがある。ディスク・データのほとんど又は全てを磁気テープなどの別の記憶媒体に転送するバックアップ操作など大規模なデータ転送が必要な場合、又は特定の操作に大量のデータを要する場合などは問題が複雑になる。このような状況では、データ検索帯域幅が不十分な場合にたびたびエラーが発生する。例えば、ディスクからデータが送信される速度がテープの進む速度に対応しない場合はテープがシャット・ダウンして転送のプロセスが非効率的になる。データを検索するまで待機しなければならないアプリケーションも、たびたびデータ検索帯域幅に合わせるためにシャット・ダウンしたりロードを中止したりする。
【０００６】
更に問題を複雑にするのは、多くのユーザが同一のシステムを共有することが多く、各ユーザが異なる要求を抱えていることである。例えば、さまざまな学部のある大学で同一のシステムを共有するとする。数学科と地質学科が学籍係の事務所と同一のシステムを共有しており、ここには講座スケジューリング・アプリケーションが存在する。従って、上記の１つ又はそれ以上の学科がディスク帯域幅を要求し、同時に他のユーザも帯域幅を要求するという状況が発生し得る（実際にたびたびそうなる）。この状況では、これらのユーザにディスクを割り当てるだけでは、ディスクの使用可能な記憶領域の問題は解決しても、同時のデータ・アクセスの問題は解決しない。また、１人のユーザにディスクへの直接アクセスの権利を付与すると、他のユーザがある期間データにアクセスできなくなる。
【０００７】
更に問題を複雑化するのは、一部のユーザが別のユーザと同等のアクセスを要求したり、他のユーザに対する一定の割合のアクセスを要求したりするという事実である。
【０００８】
【発明が解決しようとする課題】
従って、当技術においては、コンピュータのディスク・ドライブなどのデータ記憶媒体へのアクセス許可を根本的に制御できるシステムが要求される。
【０００９】
更に、当技術においては、特定のユーザが他のユーザに対して選択した割合で確実にアクセスできるように、選択的に対応できる上記システムが必要になる。
【００１０】
更に、当技術においては、システム・ユーザが使用できる見かけのデータ検索帯域幅を最大化するストレージ・アクセス・システムも必要である。
【００１１】
また、当技術においては、競合するユーザ・アプリケーション間に一貫して公正に入出力（Ｉ／Ｏ）を割り当て、それらのユーザ・アプリケーションが個々に割り当てられた使用量を実現できるように調整できるストレージ・アクセス・システムも必要である。
【００１２】
【課題を解決するための手段】
上記およびその他の目的、機能、技術的な利点は、特定のユーザ（又はアプリケーション）に対して記憶装置に関するＩ／Ｏ要求のパーセンテージを割り当てるようにしたシステム及び方法によって達成される。特定のユーザ（アプリケーション）への割り当てを行うと、そのユーザからの個々のデータ要求の全てに因子（ファクタ）を表す数値が関連付けられる。次に、この数値は、ユーザが要求したデータを使用できるようデータ検索の終了時間を計算するのに使われる。それぞれの終了時刻は、その時存在し、しかるべく調整される開始可能時刻を考慮する。
【００１３】
動作としては、ユーザに高いパーセンテージを割り当てるほど、そのユーザの因子の値は小さくなる。従って、異なるユーザから複数のアクセス要求が到着すると、さまざまな終了時刻が計算される。各時刻はそのユーザに対して認められた前回の終了時刻と現在の要求のサイズに利用できる開始時刻のサイズによって決まる。この利用できる開始時刻は、要求が到着した順に計算される。
【００１４】
本システム及び方法を使用すると、７５％の検索可能性を有するユーザは２５％のユーザが１回のストレージ・アクセス要求を認められるごとに３回の要求が認められ、８０％のユーザは任意の検索要求のバッチにおいて１０の要求ごとに８つの要求が認められることになる。
【００１５】
本システムでは、実際には、検索要求をある期間遅らせることで、その他のユーザは割り当てられたパーセンテージに応じて要求待ち行列に入ることができる。従って、ストレージ・アクセスの順序はもはや要求順ではなくなり、個々の要求は、要求のバッチごとの随意の開始時刻に基づいていつデータを検索することができるか決定するため処理される。ユーザの視点からは検索時間の差異は認められず、例えば１秒間などといったある一定の時間以下であれば、ある特定の要求について検索プロセスが人為的に遅らされてもユーザには分からない。
【００１６】
前述の計算を実行した後でも、システムが更に高速に動作するように検索要求の順序を再調整すると有効な場合がある。例えば、ディスク上のデータの物理的な場所によって、最高の検索性能が得られるタイミングが決まる場合がある。このような状況では、該当するデータの要求順序を再調整する。
【００１７】
本発明の技術的な利点の１つは、ストレージ・デバイスへの要求のバッチごとに、各ユーザに割り当てられた使用可能性のパーセンテージに従ってそのユーザの実際のデータ検索開始時刻が調整されることである。
【００１８】
本発明の更なる技術的な利点は、効率的な操作およびデータ検索技法に応じて開始時刻が更に調整されることである。
【００１９】
本発明の更に別の技術的な利点は、データ検索の割り当てが１％のユーザであってもデータ検索を阻止（スターベーション）されないこと、及び割り当てのパーセンテージが低いユーザが検索を何度要求しても、パーセンテージが低いユーザが他のユーザの検索を阻止（逆転）しないことである。
【００２０】
以上に本発明の機能と技術的な利点の概要を大まかに述べてきたが、これは以下の本発明の詳細な説明を理解しやすくするためである。本発明の更なる特徴および利点については、本発明の請求項の形で記載している。また、ここに開示の概念および具体的な実施の形態を基礎として、本発明と同じ目的を達成する他の構成を実現できることは当業者には周知であろう。また、そうした等価な構成が、請求項に示す本発明の精神および範囲から逸脱するものではないことも当業者には明らかであろう。
【００２１】
【発明の実施の形態】
例として、転送速度が１２８マイクロ秒当たり１ＫＢ（キロバイト）、データ要求はそれぞれ８ＫＢと仮定する。従って、要求ごとに１０２４マイクロ秒を要する。この転送速度と転送サイズに関する仮定を使用して、ユーザごとに割り当て済みの検索時間のパーセンテージに基づいて時間の因子を割り当てる。各ユーザには必ず１％以上が割り当てられている。ここで、次式を使用して、図１に示すユーザごとの因子を計算できる。
【００２２】
【数１】
転送速度＊転送サイズ＊１００／割り当てのパーセント  （１）
終了時刻は次式で計算する。
【００２３】
【数２】
因子＋前回の要求の終了時刻  （２）
但し、前回の要求は同じユーザによるものである。更に、次式で開始時刻を計算する。
【００２４】
【数３】
終了時刻−（転送速度＊転送サイズ）  （３）
従って、この例では、「開始時刻」は「終了時刻」−１０２４マイクロ秒に等しい。
【００２５】
上記の仮定と図１に示すさまざまなユーザの因子を使用し、図２に示す要求に基づいて、終了時刻の計算結果を示す図３Ａの表が得られる。但し、ユーザごとの計算は、他のユーザの要求と同時に到着した場合であっても、それぞれ他のユーザの計算結果とは関係なく行う。
【００２６】
各ユーザ要求の開始時刻は、その要求の終了時刻から、転送速度＊転送サイズサイズ（この例では１０２４）を引いたものである。これを図３Ｂに示す。
【００２７】
図４は、開始時刻の計算値を整列したものを示す。学籍係の因子は７０％なので、学籍係からの要求がリストの上位にあり、法学部の因子はわずか２％なのでリストの下位にあることが容易に理解できる。
【００２８】
個々の要求は、計算された開始時刻になるまで検索を開始しないので、特定のバッチのスケジューリングに「空き」ができる。この空き時間によって、実際に使用できるパーセンテージが高いユーザから要求が到着した場合に対応することが可能となり、このユーザに対する開始時刻の計算値の方が早くなる。従って、学籍係や経理から新たな要求があった場合には、図４の挿入（インサート：insert）で示す時刻でそれらの要求を処理することになる。データ・アクセス要求は、図４で示す順に処理される。
【００２９】
さまざまなディスクへのアクセスの処理は、ユーザ要求ごとの開始時刻の計算値によって制御される。但し、開始時刻は、システム管理者が割り当てた因子に基づいて計算する。１マイクロ秒の期間を任意に８つ選択してクラスタとし、それを中心として特定のバッチにおける各時刻の順序付けを行う。「バッチ」の時刻は、ディスクが追加の作業を要求するタイミングで定義する。例えば、ディスクが要求を受け入れる準備が整っている場合は、開始時刻の順に次の要求を処理する。従って、バッチ・サイズ又はサービス速度を決定するのはディスクの可用性である。本方法は、任意の到着パターン又は速度に対して機能する。但し、各要求の終了時刻の計算値は（従って開始時刻の計算値も）要求の到着時刻には本質的に関係ないので、全ての要求が本質的に同じ時刻に到着しても同じ順序付けが行われる。各要求の開始時刻は、それぞれに割り当てた因子及び同じユーザによる前回の要求の終了時刻の計算値に基づいて導かれる。これにより、競合の問題が回避され、全てのユーザがそれぞれに割り当てた因子に近い割合で処理される。
【００３０】
パーセンテージの高いユーザからの未決の要求がない状況で、ディスクが要求を受け入れる準備が整っている場合、開始時刻の順に並んだ未決の要求は、よりパーセンテージの高いユーザから要求が到着する可能性があっても待機する必要はない。
【００３１】
この例では、全てのデータ転送が８ＫＢであると仮定している。前述のように、大規模なデータ転送が要求された場合は、同時に複数の要求が到着したという形をとる。式（１）をそのまま使用し、ショートハンド・ファクタ（便法要素）を使用しなくても、同時に複数のデータ要求がない場合を除き、上の例の計算と同じ結果が得られる。
【００３２】
更に、ここではハードディスク装置及びハードディスク装置へのデータの書込みについて説明するが、本システム及び方法は、データ又は他の情報を効率的に転送するさまざまなデバイスに有効である。例えば、異なるユーザからのデータが通信経路上で時間的に競合する場合、本システム及び方法を使用することでプロトコルに応じた通信機能の使用が保証されるため、さまざまなユーザがさまざまな時刻に送信できる。
【００３３】
また、ここでは単一の記憶装置の例を示したが、複数の記憶装置の一部または全てが互いに共同で動作する場合についてもほとんど同様であることに注意されたい。本システムは、後で詳述するように、これらの全デバイスの状況を把握し、全てのデバイスに渡って開始時刻の順序付けを行う。
【００３４】
ディスク帯域幅に関する最も単純な側面は、ディスクへの実際のユーザ要求に関するものである。このディスクＩＯについて、ユーザはデバイスごとの統計を要求する。プロセス・リソース・マネージャ（ＰＲＭ：Process Resource Manager）の共有が有意義であるためには、ＰＲＭグループで上記の統計を分析する必要がある。あらゆるタイプのデバイスについて上記の統計を一律に収集する理想的な場所は、論理ボリューム・マネージャ（ＬＶＭ：Logical Volume Manager）レイヤ上またはそれに近い場所であり、帯域幅制御と同じ場所である。デバイスごとに収集のオンとオフを切り替えるためのコントロールとユーザ領域からこのデータを収集するためのコールも必要である。このような変更に最もふさわしいインタフェースは、既存のＦＳＳ（Fair Share Scheduler：フェア・シェア・スケジューラ）カーネル・インタフェースである。
【００３５】
仮想メモリ（ＶＭ：Virtual Memory）のページング及びスワッピングなど、一般的なシステム・アクティビティは使用量の測定から除外する。
【００３６】
ディスクへの直接的なトランザクションが、非同期ＩＯ、ローキャラクタ（raw character）デバイス、ＩＯ、およびＶｘＦＳファイル・システムでのある最小サイズ（最初は１２８ＫＢ）を超えるデータ転送において、発生する可能性がある。ディスク直接の読出し又は書込みでは、ディスク・ドライバに渡すために、バッファ・キャッシュを使用するのではなく、メモリ内バッファを割り当てる。
【００３７】
多くのデータベースでは、（性能上の理由で）ネイティブ・ファイル・システムをバイパスし、ローキャラクタ・デバイスを使用してトランザクションを実行する。従って、この種のＩＯについては特に注意して調査する必要がある。目標は、請求および共有の目的で、直接的な全てのＩＯにそれぞれ固有のＰＲＭグループを関連付けることである。
【００３８】
デバイスの統計またはＰＲＭグループによる直接的なブロック統計を表示するには、カーネルの変更が必要である。
【００３９】
論理ボリュームは、図７に示すように、ファイル・システム、スワップ、ローデータ（生データ）を配置できる１つ又はそれ以上の物理ボリュームの集まりである。論理ボリュームは、ファイル・システムと実際のデバイスの間に位置する疑似デバイス・ドライバによって管理される（６４個の主要ドライバが/dev/vgxxに格納されている）。論理ボリュームは、ディスク７０１、７０２、７０３などの複数のデバイスにまたがる場合もあれば（各ディスクのパーティションを含むストライプのように）、１つのデバイスが複数のボリュームの役割を果たす場合もある。
【００４０】
新しいディスク帯域幅制御とデータ収集コードを保持するようにＬＶＭレイヤを選択すると、いくつかの効果が得られる。以下に、考えられるいくつかの場所におけるＬＶＭの主な利点を挙げる。
【００４１】
１）デバイス・ドライバ・レベル：変更はカーネル内の非常に小さな領域に集中し、物理的なディスク・デバイスの非常に大きな領域をサポートする。
【００４２】
２）ファイル・システム・レベル：ローデバイス（raw device）へのアクセスを制御できる。データベース・アプリケーションでは、伝統的にファイル・システムでなくロー・パーティション（raw partitions）を使用する。
【００４３】
論理ボリューム・グループは、同じ物理ディスクにアクセスするＬＶＭディスク・パーティションの集まりである。例えば、２つのディスク・ストライプが同じ物理ディスク上のあるパーティションを使用する場合、この２つのストライプは同じ論理グループに属する。一貫した性能を保証するために、ＰＲＭには論理ディスク・グループ内のパーティションが集合的に構成され、有効化されていることが必要である。
【００４４】
ＬＶＭレイヤにデータ収集コードを追加すると、実際にこのデバイスに到達するバッファ使用のＩＯを全て認識するという効果がある。論理ボリューム・マネージャ（ＬＶＭ）ストラテジ・ルーチンへの変更としてデータ・コレクタを実行するか、又はこのレイヤと実際のデバイス・ストラテジとの間に新しいレイヤを追加するかを選択できる。
【００４５】
必ずしも、全てのＩＯが論理ボリューム・インタフェースを介して行われるわけではない。しかし、ＰＲＭによる制御が必要な全てのパーティションにはＬＶＭを介してアクセスしなければならないという制限が設けられる場合がある。ファイル・システムとスワップ・パーティション（定義された場合）は、実際のデバイスでなく疑似デバイスに指定できる。ロー（raw:生）ＩＯ及びキャラクタ・デバイスについてもこのことが言える。各ブロックのＬＶＭデバイス（/dev/vg00/lvollなど）に対応して、「r」で始まるロー・デバイス（/dev/vg00/rlvoll）が存在する。
【００４６】
背後にあるキャラクタ・デバイスへのアクセスは、制限する必要がある。このようなデバイスに対する許可は、通常、ルート（root）以外のものがベース・デバイスに触れることを禁止する。ルートとして実行するジョブは、すでにリソース管理を破壊していることがある。
【００４７】
大規模なファイル・システムでは、ストライピングやミラリングのためにすでに論理ボリュームを使用している傾向がある。
【００４８】
カーネルは、収集したデータに直接作用するのではなく、フィードバックが提供されるユーザ領域でデータを利用できるようにする。収集したデータは構成可能でなければならない。デバイスごとに収集のオンとオフを切り替えるためのコントロールと、ユーザ領域からこのデータを収集するためのコールとが必要である。指定されたデバイスは、論理ボリューム・グループでなければならない。返されるデータは、有効化してからの総計である。
【００４９】
例として、以下のデータを収集するものとする。それぞれ、ＰＲＭグループごと、ＬＶＭデバイスごとに保存する。
【００５０】
ａ．転送された全データ
ｂ．未決の要求の数
ｃ．このグループに要求されたバイト数
ハードウェア帯域幅が予期したものでない場合には、要求のサイズが小さすぎるか、又は複数のディスクからの要求でコントローラが過負荷になっていることを表している可能性がある。要求のサイズは入手可能な統計から容易に計算できる。サイズが小さすぎる場合は、貴重な性能フィードバックが提供される。コントローラが過負荷の場合、管理者は、ディスクを再設定するかコントローラを買い足すべきであると知る。
【００５１】
ハードウェア帯域幅は適切であるが、個々のユーザが実際に使用できる帯域幅が予期したものでない場合、ディスク待ち行列に費す時間が過剰である。この遅れは、一般に待ち行列で採用する優先順位の体系、又は当該グループにより高いパーセンテージを割り当てる必要があることを表す。性能が問題となるデバイスをスワップ・パーティションによってスラッシング（thrashing）しないよう注意する必要がある。
【００５２】
これらの平均をとる間隔は、ユーザが定義できる。但し、サンプリングが多すぎると性能が低下する。また、１秒当たり数メガバイトの測定値を呈する帯域幅には、１秒未満のサンプル間隔は無意味である。
【００５３】
更に、測定値は１つのプロセスのみでなくＰＲＭグループ全体に関するものである。ＰＲＭグループ内で、他のプロセスのＩＯが多いためにあるプロセスのＩＯが少ない場合がある。ＰＲＭグループを構成する場合は、このことを考慮する必要がある。
【００５４】
スピンドルごと、デバイスごとの測定値は、帯域幅の測定値が意味をもつ最小の単位である。ＲＡＩＤ、ストライプ、及び論理ボリュームでは、複数のスピンドルのデータを組み合わせる必要がある。ファイル・システムが１つのディスク・パーティション上にあると、このディスクを使用する他の全てのファイル・システムの性能に重大な影響を及ぼす可能性がある。更に、帯域幅は伝染性であり、動的である。伝染性があるのは、場合によっては２つのストライプで同一のディスクの一部が重複したり、コントローラがディスクを共有したりするためである。動作中のシステム上でＩＯカードがスワップされたり、拡張ベースのファイル・システムで実行中にボリュームを再配置したりする可能性があるので、この影響の階層は非常に流動的である。同一のコントローラを共有する複数のディスクに対して計３０ＭＢ／秒を超えるデータ転送を試みると、ＳＣＳＩデバイス上で保証される絶対的な帯域幅が無効になる恐れがある。
【００５５】
ディスクＩＯの共有は、ＰＲＭ内の他の限定的なリソースの共有と同等に機能する。割り当ては、現在プロセスが属するＰＲＭグループに基づいて決まる。グループを作成し、使用可能性の割り当てを変更できるのは管理者のみである。管理者は、１日のさまざまな時刻に、あるいはさまざまなイベント・トリガにおいて、この体系の微調整または完全な切り替えを容易に実行できる。
【００５６】
公正さが問題になるのは、リソースの競合が発生する場合のみである。ディスク・リソースの競合がない場合は、競合が発生するまで使用量は最大である。構成を移行する期間は、帯域幅のサービス・レベルは保証されない。システムがスワップする場合、絶対的な保証の全てが適用されるとは限らない。リソースは、優先順位が最も高いジョブの進行に合わせて割り当てられる。
【００５７】
測定コードがボリューム・マネージャ・レイヤにある場合は、同レイヤ内にコントロール・コードを配置することに意味がある。ＬＶＭ内でディスク帯域幅を制御することによって、ストライプの全てのメンバーに対して強制的に同じ帯域幅を割り当てることができる。例えば、あるディスクに８０％を保証し、そのストライプの他のメンバーそれぞれを１０％に制限しても意味がなくなる。
【００５８】
他のものは、大規模なロー（raw）ＩＯブロックのディスク帯域幅制御を実現してきた。ＶｘＦＳなどのファイル・システムがfs_direct_szを超える（現在は１２８ＫＢ）大規模なＩＯ処理を要する場合、バッファ・キャッシュに全体をコピーして自己の疑似バッファを構成するというオーバーヘッドを削減することが多い。これは物理ＩＯとして知られており、ＩＯ帯域幅を保証する方法の１つである。この機能は、アプリケーション又は他のデバイスをビジー状態に保つために最低限のデータ・フローを要するジョブには必須である。ビデオ・ストリームは、文献に最もよく見られる例である。
【００５９】
システム上の物理ＩＯについてのみ注意すればよい場合は、要求ごとに実行する総ＭＢ数と秒数を把握することによって、確実に目標を達成できる。しかし、非常に大量の場合は、システム上の他のユーザに対する公正さが崩れる。帯域幅適合アルゴリズムが有効であるためには、物理ＩＯを小さなサイズに分割する必要があるが、小さすぎるとオーバーヘッドによって物理ＩＯの効果がなくなる。ディスク・キャッシング・メカニズムは１ＭＢ程度なので、最大１ＭＢが提唱されている。ＶｘＦＳではすでに全てのＩＯをこのサイズ（maxtransfer）に分割している。
【００６０】
大規模なＩＯがそれぞれ事前にブロックでソートされていると仮定すれば、ハードウェア・ディスク待ち行列がソートできるサイズより大きい場合でも、既存のブロック順の待ち行列内に大きな要求が入らないので性能が低下するという心配は必要ない。
【００６１】
上記の仮定において、どのような方法で公正に優先順位を指定するのかを以下に述べる。このボリュームへの要求者のグループに対して許容される帯域幅の割り当て（f(g,v)）を指定し、保証を満足しながら完了する時刻を計算する。
【００６２】
【数４】
希望終了デルタ＝(1/f(g,v))＊デバイスの転送速度＊要求サイズ
【００６３】
実際に必要なのはＩＯ終了時刻でなくＩＯ開始時刻のスケジュールなので、ＩＯにかかる時間を引く。
【００６４】
【数５】
希望開始デルタ＝((1/f(g,v))-1)＊デバイスの転送速度＊要求サイズ
【００６５】
但し、ここで必要なのは現在待ち行列を共有している他のグループに基づく相対的な許容量でなく、絶対的な許容量である。これには、２つの理由がある。まず、現在待ち行列上にある全てのグループを追跡するとオーバーヘッドが非常に大きくなる。あるグループがリソースに追加されたり削除されたりすると、新しい相対優先順位では特定のユーザの要求が処理されなくなる恐れがある。
【００６６】
複数のグループから同時に要求が到着した場合は、それらの間で調整される。
この結果、残念ながら優先順位の低いグループが処理されなくなる可能性がある。前述のモデルを拡張するために、同じグループから複数の要求が連続的に到着した場合はこれらを順にスケジューリングすることを考える。最後の要求が過去のある時点で終了した場合は、現在のタイム・スタンプを使用する。
【００６７】
【数６】
希望開始時刻＝max(現在, last_scheduled_completion(g,v))＋((1/f(g,v))-1)＊デバイス転送速度＊要求サイズ
【００６８】
希望開始時刻を計算するごとに、このグループの最新の完了スケジュールを更新する。
【００６９】
これらの帯域幅に関するパーセンテージの目標値は、既存のリソースとほとんど同じ書式でＰＲＭ設定ファイルに記述できる。ＰＲＭでは、新しいｉｏｃｔｌコール又はｆｓｓコールによってこの機能を有効化または無効化できることが必要である。この機能をオンに切り替えるコールには、要素数６４の配列へのポインタがあり、要素ごとに優先順位を指定する。この優先順位の値は上記のアプリケーション・レベルで計算され、上記の式の定数部分を表す。
【００７０】
【数７】
優先順位(g,v) = ((1/f(g,v))-1)＊デバイス転送速度
【００７１】
但し、全ての割り当ての合計は１（１００％）以下である。転送速度をデータ１ＫＢ当たりのマイクロ秒の値で表した場合、０から約２００万までの整数の重みになる。この場合、２ＧＢ／秒未満の転送速度は整数で表される。この速度のメモリ・コピーは、最新の計画および実装によるアーキテクチャではいずれもボトルネックになる。
【００７２】
異なる速度での読出し及び書込みが発生するシステムでは、重み付けのパラメータを追加できる。よって、ディスク待ち行列に入るときに、大規模なＩＯを時間の優先順位でソートできる。
【００７３】
【数８】
開始の優先順位= 優先順位(g,v)＊読出し/書込みの重み＊要求サイズ
【００７４】
サンプリング機能の最小単位を１秒とすると、この時間に１０から１６０の大規模な読出し又は書込みを実行でき、前述の体系ではパーセンテージの目標をほぼ達成する可能性が得られる。このアルゴリズムでは、デバイスが予約されている場合は優先順位の高いジョブの終了が早まる。過負荷の場合にも、同じ重み付けによるパーセンテージで帯域幅が割り当てられる。また、このメカニズムによってスターベーションが回避されるとともに、優先順位が最も低いジョブの開始時刻も保証される。
【００７５】
この優先順位付けの方針は、大規模ＩＯを伴うジョブを優先する方法に比べて、実際に多くの面でシステム全体のスループット向上に有効である。それは、大規模ＩＯを伴うジョブを実行するタスクが貴重なメモリをロックしてこれを解放できなかったり、このＩＯが完了するまでＣＰＵを使用したりするためである。メモリにほとんど余裕がない場合は、大規模な転送の優先順位を上げなければならない場合がある。
【００７６】
上記のリソース間での調整は、より高いレベルで継続する必要がある。開始の目標を達成できなくても、カーネルはより情報に基づいた決定ができるユーザ・レベルに統計を報告する以外は何もしない。なぜ何もしないのかというと、カーネルは、あらゆる状況において適切な方法でリソースの過負荷に対処できるわけではないためである。対処しようとするとＩＯの速度を低下するだけでなく、現在保持しているよりもはるかに高度なカーネルが必要になる。更に、共有における変動の殆どは本来一時的な現象である。過度な対応をしないように、問題が数秒間以上持続する場合にのみ、ディスク待ち行列レベルより上で調整処置を施すことが望ましい。ＰＲＭデーモンはすでにこの間隔でサンプリングしており、適切な応答が何かを事前に認識している顧客への直接的なリンクがあるので、これはコントロールを配置するにふさわしい場所である。
【００７７】
小規模なＩＯ（８ＫＢ以下）は、最も一般的であり、残念ながら非常に複雑なケースである。最大の問題は、待ち行列に大量のブロックを記録できなかったり性能が低下したりして、メタデータが正しい順序で記述されないことである。これを可能にするには、前述の規則を若干変更する必要がある。
【００７８】
小規模ＩＯに関する規則の変更１：同期システム・オペレーションの優先順位を１００％とする。すなわち、この種のオペレーションは直ちに待ち行列の先頭に入る。遅延された書込みと読出しには、ＩＯの完了を待っているアクティブ・ユーザと同レベルの時間の保証はない。システムＩＯの発生頻度は低い。しかし、この優先順位の体系では、システムＩＯが一定のストリームであっても、待機している他の全てのユーザの完了順序を保証する。
【００７９】
小規模ＩＯに関する規則の変更２：短いタイム・クォンタム（time quantum）内で、ディスク・ブロックの順に整列して性能を保証する必要がある。このクォンタムは初めに試験的に設定できる。ハードウェア・ディスク待ち行列内の８つの要求を処理するのにかかる時間の基準はミリ秒なので、この範囲で指定する。数十ミリ秒の期間を設定し、標準のディスク・ソート・ルーチンがこのバケット内に整列できるようにする必要がある。この結果、概観的には優先順位が保持され、微視的には性能が得られる。
【００８０】
多くの場合には、数バイトの書込みでも、ディスク・ブロック全体の書込みと同じだけの時間がかかる。本システムは、ディスク全体の性能を害する非常に小さな要求を直ちに処理するように機能する。ユーザは、小さな要求に起因するサービスの拒否を避けるために、任意のＩＯに最小の重み付けを希望する場合がある。この値は、経験的に決定したデフォルトによって調整することもできる。従って、ソート・ビン（sort bin）の式は次のようになる。
【００８１】
【数９】
sort bin＝優先順位(g,v)＊max(要求サイズ, 最小サイズ)／クォンタム・サイズ
【００８２】
クォンタム・サイズは、個々のビンに配置される要求の数によって動的に大きくしたり小さくしたりする必要があることがある。
【００８３】
上記のアルゴリズムの実際の機能を示すために、いくつかの例を挙げる。以下の例では、３つのディスク帯域幅レコードはＰＲＭ設定ファイルで定義され、グループごとの値は以下のとおりとする。
【００８４】
グループＡ：５０％
グループＢ：２５％
グループＣ：２５％
例として、デバイスの転送速度は８ＫＢの要求を１ミリ秒で完了できるものとする。簡単のために、時間はミリ秒（ｍｓ）単位で０から始まるものとする。
【００８５】
例えば、グループＡ、Ｂ、Ｃから１２８ＫＢの書込み要求が１０回ずつ発生するとする。まず、帯域幅の要件を満足しつつ新しい要求を処理するのにかかる時間をそれぞれ計算する。個々のＩＯがデバイスに到達してからかかる時間は、１２８ＫＢ／（８ＫＢ／ｍｓ）＝１６ｍｓである。グループＡの場合、（１／．５）＊１６ｍｓ＝３２ｍｓ後にＩＯを完了してよい。この目標を達成するため、このＩＯを３２−１６＝１６ｍｓの位置にスケジューリングしなければならない。
【００８６】
時計はグループＢの要求を処理する時刻までわずかに（ここでは１ｍｓ）進んでいる。グループＢのＩＯは、（１／．２５）＊１６＋１ｍｓ＝６５ｍｓ後に終了できる。但し、４９ｍｓの位置で始める必要がある。グループＣでは、再び時計が進んで２ｍｓに達し、６６ｍｓまでに終了すれば良く、従って５０ｍｓの位置までに開始しなければならない。
【００８７】
最初のＩＯが完了する前に１０個の全ての要求が発生すると仮定する。このとき、グループＡの２番目のＩＯはこのグループで最後の終了予定（３２ｍｓ）の直後にスケジューリングされる。希望の帯域幅を保持するために、開始前の最大の遅れ（１６ｍｓ）はそのままで、２番目の要求の開始予定は４８ｍｓ、終了予定は６４ｍｓになる。このロジックを全ての要求に対して次々に適用すると、グループＢとグループＣの間隔は６４ｍｓになる。各グループのスケジュール表は次のようになる。
【００８８】
【表１】
Ａ：１６，４８，８０，１１２，１４４，１７６，２０８，２４０，２７２，３０４
Ｂ：４９，１１３，１７７，２４１，３０５，３６９，４３３，４９７，５６１，６２５
Ｃ：５０，１１４，１７８，２４２，３０６，３７０，４３４，４９８，５６２，６２６
【００８９】
待ち行列への挿入順序として上記を使用すると、要求は以下のような順となる（それぞれ、グループ及び要求番号を表す）。
【００９０】
【表２】
Ａ１，Ａ２，Ｂ１，Ｃ１，Ａ３，Ａ４，Ｂ２，Ｃ２，Ａ５，Ａ６，Ｂ３，Ｃ３，Ａ７，Ａ８，Ｂ４，Ｃ４，Ａ９，Ａ１０，Ｂ５，Ｃ５，Ｂ６，Ｃ６，Ｂ７，Ｃ７，．．．
【００９１】
ここで、グループＡが完了までの時間の正確に５０％を占めており、他の２つの（パーセンテージの等しい）要求が残りの５０％を同等の割合で占めていることに注目されたい。最初の要求は、１６ｍｓにスケジュールされているが、ほぼ即時に開始される。待ち行列全体を完了するのにはわずか４８０ｍｓしかかからない。このことは、多くのＩＯが、帯域幅の利用度が低い場合、スケジュールされた時刻以前に処理を開始することを意味する。すなわち、スケジューリング時刻は、最悪の場合、場所取りにすぎない。後で（例えば２００ｍｓの時点で）Ａから追加の要求が到着すると、タイム・スタンプによって新しい要求を挿入する公正な位置（３６８ｍｓ）が決まる。そして、最後の完了時刻を開始位置として、優先順位の低いグループのスターベーション（窮乏状態）を回避する。
【００９２】
グループＡに、最後の例と同様に１２８ＫＢの書込み要求が１０回ある場合には、スケジュール時刻はそのままとなる。但し、Ｂには８ＫＢの書込み要求が１００回あり、Ｃには書込み要求がないとする。また、グループＢの各トランザクションには１ｍｓかかり、更に開始前に３ｍｓ待機するのが望ましいとする。ここで、大規模なＩＯスケジュールを使用すると次のようになる。
【００９３】
【表３】
Ａ：１６，４８，８０，１１２，１４４，１７６，２０８，２４０，２７２，３０４
Ｂ：３，７，１１，１５，１９，２３，２７，３１，３５，３９，４３，４７，５１，．．．，３９５，３９９，４０３
【００９４】
予定時刻のみでソートすれば、サービス順は次のようになる（それぞれ、ＫＢ｜グループを表す）。
【００９５】
【表４】
３２｜Ｂ，１２８｜Ｂ，１２８｜Ａ，６４｜Ｂ，１２８｜Ａ，６４｜Ｂ，１２８Ａ，．．．，６４｜Ｂ，１２８｜Ａ，１２８｜Ｂ
【００９６】
要求の数が多くなると、２つのグループ間の比率はそれぞれに対応する帯域幅の割り当て（５０：２５）を反映して２：１に近付く。優先順位の高いグループが完了すると、優先順位の低いグループがデバイス全体を占有する。
【００９７】
残念ながら、最適な性能を得るためには、グループＢの要求の小さなブロックをブロック番号順に整列する必要がある。バケツを３２ｍｓとした場合、新しい主キーは次のようになる。
【００９８】
【表５】
Ａ：０，１，２，３，４，５，６，７，８，９
Ｂ：０，０，０，０，０，０，０，０，１，１，１，１，１，１，１，１，２，２，２，２，．．．１１，１２，１２，１２，１２
【００９９】
ビン内のブロック番号の副キーでソートすると、６４｜Ｂ＋１２８｜Ａの１０個のビンはそれぞれ固有の順序ではなく、最後の３つのビンは６４｜Ｂ，６４｜Ｂ，３２｜Ｂとなる。
【０１００】
ビンを使用しても、分割のパターンにも帯域幅の１秒刻みのサンプリングにも大きな相違は見られない。
【０１０１】
ｄｂｃにまだ余裕がある場合でも、管理者が停止し、遅延された書込み及び読出しのトラフィックを優先的に待ち行列に入れるべきではない。その第１の理由は、待ち行列は一定の方針に沿って順序付けすべきだからである。順序がほとんど守られなくても、システムがｄｂｃ外にあればそのような不均衡はないであろう。第２には、この体系によると同期ユーザＩＯによるリソースの占有を回避しやすいからである。第３には、システムはバッファ・キャッシュをブレークしないので、このディスク・チャネルにまだ余裕があることになるからである。現在の限界は１ＧＢのｄｂｃであり、複数のデバイスを許容してなお余裕がある。第４には、ＩＯを阻止された高優先順位のジョブは順序付けによってより迅速に再開できるからである。ビジー・システムでは、バッファ・キャッシュ全体がこのデバイス・レベルの待ち行列になる可能性がある。
【０１０２】
遅延された書込みと不正なバッファの実際のフラッシングとの間の長期の遅れによって、バッファとプロセスの関連付けがなくなる場合がある。その場合、実際にＩＯを行うプロセス（ほとんどはｓｙｎｃｄデーモンとＶｘＳＦデーモン）をチャージするか、所有するプロセスでバッファ・ヘッダに何らかのタグ付けをするかの２つの選択肢がある。ここで、プロセス・ポインタでｆｓｓ ＩＤを取得する必要がある。遅延されたさまざまなＩＯは、すでにプロセス・ポインタでb_Procフィールドにタグを付けている。但し、これだけに頼ることはできない理由が２つある。データ・フラッシングの時刻の前にプロセスが終了する場合があることと、プロセスがグループを変更する場合があることである。致命的な問題となるのは、最初のケースだけである。よって、ｆｓｓ ＩＤ（６ビット）はバッファ・ヘッダの特定のフィールドに置かれる。
【０１０３】
新しいFS_LVM_ADDコマンドは、引数としてデバイス番号とMAX_FSID+１優先順位のリストを受け取る。このコマンドは、デバイス番号の正当性を確認し、ｆｓデバイス情報構造の領域を割り当て、選択したボリュームのデバイスにデバイス番号を関連付ける。
【０１０４】
新しいFS_LVM_DELETEコマンドは、引数としてデバイス番号を受け取る。このコマンドは、領域フラグ及びボリューム・フラグを削除し、デバイス番号を所定のデバイスのモニタに関連付ける。
【０１０５】
新しいFS_LVM_INFOコマンドは、モニタ対象のデバイスの数に関する要求、又はユーザが指定するバッファに現在のデバイス情報をコピーするという要求を処理する。この情報は、全てのＣＰＵについて合計してから復帰の構造に書き込まれる。
【０１０６】
新しいFS_LVM_STARTコマンドは、ディスク帯域幅共有化と事前に設定した全てのデバイスを起動する。
【０１０７】
新しいFS_LVM_STOPコマンドは、ディスク帯域幅共有化と全てのディスク・デバイスを終了する。
【０１０８】
新しいフラグを設定すると、ＰＲＭグループが必要なデバイス統計を収集するようにＩＯ待ち行列の開始および終了コードが変更される。
【０１０９】
getblklルーチンでは、ＦＳＳがアクティブな場合はcache-padフィールドがｆｓｓ ＩＤでタグ付けされていなければならない。getnewbufルーチンもグループＩＤを初期化するように変更が必要な場合がある。
【０１１０】
ＡＰＩは、ユーザ指定の帯域幅のパーセンテージを、待ち行列の優先順位付けに使用する重み付き遅れ乗数のベクトルに変換できなければならない。全てのパーセンテージの合計は１００以下でなければならない。
【０１１１】
図５に、本発明が機能することによってマルチ・ユーザのストレージ・アクセスを改善できる基本的なコンピュータ・システムを示す。このような環境では、本発明をＵＮＩＸオペレーティング・システムと組み合わせて使用するのが一般的である。本発明は任意のオペレーティング・システムで使用できるが、マルチユーザ・ベースであるＵＮＩＸシステムが、考え得る最適な形態である。コンピュータ・システム５０は、通常、ディスプレイ又はスクリーン５０１、なんらかのローカル・メモリ５０４、ＣＰＵ５０２、入力装置５０５、及び少なくとも１つの記憶装置５０３を有する。補助記憶装置５０６、５０７を使用する場合があり、これらの補助記憶装置はコンピュータ５０内やマルチプロセッサ・システム内の他の場所に配置する場合がある。
【０１１２】
図６に、ディスク６０６、６０７、６０８へのさまざまなストレージ・コールを示す。これらのコールは、仮想メモリ・システム６０５、システム・コール６０１、ファイル管理６０２、論理ファイル・マネージャ６０４、キャッシュ６０３の間で送受信できる。
【０１１３】
以下で使用する主なデータ構造は、配列prm_vg_enabled及びall_volumesである。
【０１１４】
char prm_vg_enabled [maxvgs];
上記はボリュームごとに１つの論理値で、そのボリュームにＰＲＭの権限があるかどうかを表す。
【０１１５】
【表６】
0003876100.tif 000002
【０１１６】
上記の構造には、ユーザ定義の権限、バーチャル・クロック、有効な各ボリューム・グループの転送バイト数が含まれる。
以下に示すディスク要求バッファの３つのフィールドも使用する。
【０１１７】
【表７】
int b_prio; /*要求の優先順位*/
int b_bcount; /*ディスク要求サイズ*/
int b_fsid; /*ディスク要求作成元プロセスのフェアシェアＩＤ*/
【０１１８】
ディスク帯域幅マネージャの心臓部は、prm_strategyルーチンである。prm_strategyルーチンはディスク要求が到着するたびにlvm_strategyルーチンから呼び出され、ディスク管理機能が有効になる。
【０１１９】
引数は、ボリューム・インデックス、ボリューム待ち行列の要素数、及び要求バッファである。以下に疑似コードを示す。
【０１２０】
【表８】
ＩＯ開始ルーチン：
入力：ＩＯ要求バッファ
出力：同ＩＯ要求の優先順位フィールドを変更したもの
この要求のボリューム・グループを検出
このボリューム・グループが管理対象外の場合は復帰
この要求が実時間の場合は復帰
ＩＯ要求のリソース・グループＩＤを取得
（待機因子＝１００／このリソース・グループの割り当てパーセンテージ）を計算
ＩＯ要求サイズに基づいてＩＯ時間を計算
（終了時間＝（因子＊ＩＯ時間））を計算
（ボリューム・グループ・キューが空）の場合は
バーチャル・クロック[volume group]をリセット（tzero＝now）
（このリソース・グループの最終予定終了時刻が過去）の場合は
（このリソースグループの最終予定終了時刻＝now）に設定
（時間デルタ（差）＝最終予定終了時刻＋終了時間―入力時間―tzero）を計算
（リソース・グループの新しい最終予定終了時刻＝最終予定終了時刻＋終了時間）を計算
（要求の新しい優先順位＝時間デルタ／（２＾１８））を計算
ＩＯ完了ルーチン
入力：完了したＩＯバッファ
出力：なし
この要求のボリューム・グループを検出
ＩＯ要求のグループＩＤを取得
このリソース・グループの総転送バイト数を増加
このボリューム・グループを管理する場合は
バーチャル・クロック[volume group]を転送バイト数だけ増加
優先順位フィールドをタイム・スタンプに戻す
（完了したＩＯのタイム・スタンプ＞クロック[volume group]）の場合は
クロック[volume group]＝タイム・スタンプ
【０１２１】
以上の説明および例は読出しのシステムを中心に展開したが、この好ましい実施形態において本発明は読出しと書込みの両方の要求に対して有効であることに注意されたい。
【０１２２】
なお、ユーザという用語は、個々のログイン又は特定業務向けのコンピュータ・アプリケーションを実行する個人、あるいは管理者が定義したその他のグループを表すものである。
【０１２３】
以上、本発明およびその効果について詳細に説明したが、添付の請求項に定義する本発明の精神および範囲を逸脱せずにさまざまな変更、代用、代替が可能であることは言うまでもない。
【０１２４】
この発明は、例として次の実施形態を含む。
１．帯域幅に制限のあるデバイスに複数のユーザが時折アクセスを必要とし、各ユーザが前記デバイスに特定のパーセンテージでアクセスを希望するシステム（５０）であって、
各ユーザに対して、他のシステム・ユーザに関連してアクセス時間のパーセンテージを割り当てる装置と、
前記ユーザから前記デバイスへのアクセスに関する要求を受信するために時折動作する装置と、
前記要求の発信元のユーザに割り当てたアクセスのパーセンテージに従って前記要求の開始時刻を要求ごとに決定する装置と
を備えるシステム。
【０１２５】
２．上記１に記載のシステム（５０）において、
所定の期間内に存在する複数のユーザ要求の開始時刻を順序付ける装置
を更に備えるシステム。
【０１２６】
３．上記２に記載のシステム（５０）において、
開始時刻の順に、前記順序付けられた要求を処理する装置
を更に備えることを特徴とするシステム。
【０１２７】
４．上記１に記載のシステム（５０）において、
前記の開始時刻を決定する装置が、各ユーザの開始時刻を前記同一ユーザによる前回の要求の終了時刻に従って計算する装置を備える
ことを特徴とするシステム。
【０１２８】
５．上記１に記載のシステム（５０）において、アクセス要求を受信してからある固有の時間内に前記要求を処理することを特徴とするシステム。
【０１２９】
６．上記５に記載のシステム（５０）において、新たなユーザ要求が到着し、その開始時刻の計算値が他の順序付けられた開始時刻よりも早い場合は、前記固有の時間内にその要求を処理することを特徴とするシステム。
【０１３０】
７．上記１に記載のシステム（５０）において、
システム・ユーザのアクセス・パーセンテージを調整する装置
を更に備えることを特徴とするシステム。
【０１３１】
８．上記１に記載のシステム（５０）において、
前記システムは、前記ユーザによる複数のアプリケーションを管理することが可能であり、
且つ前記システムが、ユーザが制御する任意のアプリケーションからの全ての要求に前記ユーザのアクセス・パーセンテージの情報を関連付ける装置を備える
ことを特徴とするシステム。
【０１３２】
９．上記２に記載のシステム（５０）において、
操作可能なシステム・パラメータの制御の下で、前記システム・パラメータに従って要求の効果的な開始時刻を再度順序付けする装置
を更に備えることを特徴とするシステム。
【０１３３】
１０．帯域幅に制限のあるデバイスに複数のユーザが時折アクセスを必要とし、各ユーザが前記デバイスに特定のパーセンテージでアクセスを希望するシステム（５０）を操作する方法であって、
各ユーザに対して他のシステム・ユーザに関連してアクセス時間のパーセンテージを事前に割り当てるステップと、
前記ユーザから前記デバイスへのアクセス要求を時折受信するステップと、
前記要求の発信元のユーザに割り当てたアクセスのパーセンテージに従って前記要求の開始時刻を要求ごとに決定するステップと
を備えることを特徴とする方法。
【０１３４】
【発明の効果】
本発明によると、コンピュータのディスク・ドライブなどのデータ記憶媒体へのアクセス許可を根本的に制御できるシステムが提供される。また、特定のユーザが他のユーザに対して選択した割合で確実にアクセスできるように、選択的に対応できるシステムが提供される。更に、システム・ユーザが使用できる見かけのデータ検索帯域幅を最大化するストレージ・アクセス・システムが提供される。更に又、競合するユーザ・アプリケーション間に一貫して公正に入出力（Ｉ／Ｏ）を割り当て、それらのユーザ・アプリケーションが個々に割り当てられた使用量を実現できるように調整できるストレージ・アクセス・システムが提供される。
【図面の簡単な説明】
【図１】図１は、ストレージ・アクセス全体を複数のユーザに割り当てたパーセンテージの例を示す表である。
【図２】図２は、８つの期間にわたるアクセス要求の総数を集計した例を示す表である。
【図３】図３Ａは、図２に示す各要求に関して計算した終了時刻を示す表であり、図３Ｂは、図２に示す各要求に関して計算した開始時刻を示す表である。
【図４】図４は、図３Ｂの開始時刻を、開始時刻に従って処理する順に並べた表である。
【図５】図５は、本発明によってストレージ・アクセスを制御できる汎用コンピュータを示す図である。
【図６】図６は、さまざまな種類のディスク・アクセスを示す図である。
【図７】図７は、３つの記憶用ディスクで構成する論理ボリュームの例を示す図である。
【符号の説明】
５０    コンピュータ・システム        ５０２  ＣＰＵ
５０３  記憶装置                      ５０４  ローカル・メモリ
５０６，５０７  補助記憶装置
６０１  読出し／書込みのシステム・コール
６０２  ファイル・システム            ６０３  バッファ・キャッシュ
６０４  論理ボリューム・マネージャ    ６０６，６０７，６０８  ディスク
【図１】
0003876100.tif 000003
【図２】
0003876100.tif 000004
【図３】
0003876100.tif 000005
【図４】
0003876100.tif 000006
【図５】
0003876100.tif 000007
【図６】
0003876100.tif 000008
【図７】
0003876100.tif 000009