(57)【特許請求の範囲】
【請求項１】
ホストデバイスのチャネルにより、データ転送コマンドを、ストレージ・コントローラ内に含まれる制御ユニットに送ることと、
前記ホストデバイスの前記チャネルが、前記制御ユニットとの通信のために、前記制御ユニットからある数のバッファ・クレジットを受信することであって、前記受信したバッファ・クレジットの数は、前記制御ユニットが、前記チャネルを含む複数のチャネルと通信しながら監視期間中に監視する転送準備動作の数及びリトライ動作の数に基づいて調整される、受信することと、
を含み、
前記制御ユニットが、前記監視期間中、転送準備動作の使用はあるがリトライ動作の使用はないと判断し、かつ、転送準備動作の前記数が転送準備閾値を上回ると判断することに応答して、前記チャネルは、増加した数のバッファ・クレジットを受信することをさらに含む、方法。
【請求項２】
前記バッファ・クレジットの数は、前記チャネルが利用可能なバッファの数であり、
前記複数のチャネルの各々は、前記制御ユニットから同一の数のバッファ・クレジットを受信することをさらに含む、請求項１に記載の方法。
【請求項３】
前記制御ユニットが、前記監視期間中、リトライ動作の使用はあるが転送準備動作の使用はないと判断し、かつ、リトライ動作の前記数がリトライ低閾値を上回ると判断することに応答して、前記チャネルは、減少した数のバッファ・クレジットを受信することをさらに含む、請求項１に記載の方法。
【請求項４】
前記制御ユニットが、前記監視期間中、転送準備動作及びリトライ動作の両方の使用があると判断し、かつ、リトライ動作の前記数がリトライ高閾値を上回ると判断することに応答して、前記チャネルは、減少した数のバッファ・クレジットを受信することをさらに含む、請求項１に記載の方法。
【請求項５】
前記複数のチャネルの各々は、前記複数のチャネルと前記制御ユニットとの間の通信の始動段階の開始時に、バッファ・クレジットの前記数を受信することであって、前記受信したバッファ・クレジットの数は、データの転送に用いられるとき、転送準備動作を発生させるが、リトライ動作を発生させない、受信することと、
前記複数のチャネルの各々は、前記始動段階の前記開始から所定の時間内に、転送準備動作を排除する又はリトライ動作を発生させるためのバッファ・クレジットの数を繰り返し受信することと、
をさらに含む、請求項１に記載の方法。
【請求項６】
前記始動段階の前記開始は、前記複数のチャネルが前記制御ユニットにログオンしたときに起こる、請求項５に記載の方法。
【請求項７】
ストレージ・コントローラと通信するホストデバイスであって、前記ホストデバイスは、
メモリと、
前記メモリに結合されたプロセッサと、
を備え、前記プロセッサは、
前記ホストデバイスのチャネルにより、データ転送コマンドを、ストレージ・コントローラ内に含まれる制御ユニットに送ることと、
前記ホストデバイスの前記チャネルによって、前記制御ユニットとの通信のために、前記制御ユニットからある数のバッファ・クレジットを受信することであって、前記受信したバッファ・クレジットの数は、前記制御ユニットが、前記チャネルを含む複数のチャネルと通信しながら監視期間中に監視する転送準備動作の数及びリトライ動作の数に基づいて調整される、受信することと、
を実行し、
前記制御ユニットが、前記監視期間中、転送準備動作の使用はあるがリトライ動作の使用はないと判断し、かつ、転送準備動作の前記数が転送準備閾値を上回ると判断することに応答して、前記チャネルによって、増加した数のバッファ・クレジットを受信することをさらに実行する、ホストデバイス。
【請求項８】
プロセッサに、
ホストデバイスのチャネルにより、データ転送コマンドを、ストレージ・コントローラ内に含まれる制御ユニットに送ること、
前記ホストデバイスの前記チャネルが、前記制御ユニットとの通信のために、前記制御ユニットからある数のバッファ・クレジットを受信することであって、前記受信したバッファ・クレジットの数は、前記制御ユニットが、前記チャネルを含む複数のチャネルと通信しながら監視期間中に監視する転送準備動作の数及びリトライ動作の数に基づいて調整される、受信すること、
前記制御ユニットが、前記監視期間中、転送準備動作の使用はあるがリトライ動作の使用はないと判断し、かつ、転送準備動作の前記数が転送準備閾値を上回ると判断することに応答して、前記チャネルが、増加した数のバッファ・クレジットを受信すること、
を実行させるためのコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
実施形態は、制御ユニットにデータを伝送するために、１つ又は複数のホスト計算デバイス（host computational device: 単にホスト又はホストデバイスと呼ぶ場合がある）の複数のチャネルにより、バッファ・クレジットを受信することに関する。
【背景技術】
【０００２】
入力／出力（Ｉ／Ｏ）動作は、Ｉ／Ｏ処理システムのメモリとＩ／Ｏデバイスとの間でデータを転送するために用いることができる。例えば、入力／出力動作を実行することにより、データをメモリから１つ又は複数のＩ／Ｏデバイスに書き込むこと、又は、データを１つ又は複数のＩ／Ｏデバイスからメモリに読み取ることができる。Ｉ／Ｏ動作の処理を促進するために、Ｉ／Ｏ処理システムのＩ／Ｏサブシステムを用いることができる。Ｉ／Ｏサブシステムは、Ｉ／Ｏ処理システムの主メモリ及びＩ／Ｏデバイスに結合され、メモリとＩ／Ｏデバイスとの間の情報の流れを方向付ける。Ｉ／Ｏサブシステムの一例は、チャネル・サブシステムである。チャネル・サブシステムは、チャネル経路を通信媒体として使用する。各チャネル経路は、制御ユニットに結合されたチャネルを含み、この制御ユニットは１つ又は複数のＩ／Ｏデバイスにさらに結合される。
【０００３】
特定の機構において、チャネル・サブシステム及びＩ／Ｏデバイスは、Ｉ／Ｏデバイスとメモリとの間でデータを転送するための１つ又は複数のコマンド制御ブロックの転送をサポートする、トランスポート・モードで動作することができる。トランスポート制御ワード（ＴＣＷ：ｔｒａｎｓｐｏｒｔ  ｃｏｎｔｒｏｌ  ｗｏｒｄ）は、実行すべき１つ又は複数のＩ／Ｏコマンドを指定することができる。特定のＩ／Ｏ動作を開始するコマンドについては、ＴＣＷは、この動作と関連付けられたメモリ領域、この領域との間の転送が完了するたびに取るべきアクション及び他のオプションを指定することができる。
【０００４】
幾つかの状況では、制御ユニットは、ストレージ・デバイス内に含ませることができる。他の状況では、制御ユニットは、ストレージ・コントローラ内に含ませることができ、そこでは、ストレージ・コントローラ内で実行されるストレージ管理アプリケーションが、ストレージ・コントローラに結合される、ディスクドライブ、テープドライブ、フラッシュドライブ等のような複数のストレージ・デバイスを管理することができる。制御ユニットと通信するためのチャネルは、ストレージ・デバイス内に格納されるデータにアクセスできる複数のホストにより、使用することができる。
【０００５】
ファイバ・チャネルとは、米国規格協会（American National Standards Institute）により開発されたデータ転送用アーキテクチャ規格の統合セットを指す。ファイバ接続（ＦＩＣＯＮ）は、ファイバ・チャネル・アーキテクチャのプロトコルであり、ＦＣ−ＳＢ５の形式的名称で呼ぶこともできる。ＦＣ−ＳＢ５の詳細については、非特許文献１に記載されている。
【０００６】
チャネルとは、通信デバイス間の直接又は交換ポイント・ツー・ポイント接続（switched point-to-point connection）である。ファイバ・チャネル・アーキテクチャでは、ＦＩＣＯＮチャネルは、ＦＣ−ＳＢ５によって指定された機能を実行して、制御ユニット又はエミュレートされた制御ユニットにより入力／出力（Ｉ／Ｏ）デバイスへのアクセスを可能にすることができる。ＦＩＣＯＮチャネルは、通信デバイス間でデータを転送するためにパケット交換に依存し得る。
【０００７】
特定の状況では、データを処理するために、制御ユニットの能力を超える速度でデータが転送される場合、Ｉ／Ｏデバイスに送られたデータ転送が、それぞれの制御ユニットでデータ・オーバーフローをもたらすことがある。
【０００８】
特定の機構は、制御ユニットは、チャネルに利用可能な第１の転送バッファの数及び／又はサイズの指定を可能にするデータ転送制御フィーチャを提供する。特定の状況では、データ転送制御フィーチャは、制御ユニットにより指定される第１の転送バッファ・サイズ（ＦＴＢＳ：first-transfer-buffer size）値と、第１の転送バッファ・クレジット（ＦＴＢＣ：first-transfer-buffer credit）値とを定める。ＦＴＢＣは、バッファ・クレジットと呼ばれることもある。ＦＴＢＳ及びＦＴＢＣは、チャネル内に格納され、これらを用いて、第１のデータ転送メッセージにおいて制御ユニットに転送できるデータの量を制限する。他の状況では、制御ユニットは、（単数又は複数の）Ｉ／Ｏコマンドの受信及び／又はＩ／Ｏ動作の実行に応答してチャネルに送られる応答メッセージを介して、ＦＴＢＣを指定する又は動的に修正することができる。チャネルと制御ユニットとの間のリンクの初期化（例えば、プロセス・ログイン要求及び応答メッセージ内に示される）中、データ転送制御フィーチャへのサポートを確立することができる。
【０００９】
高性能ＦＩＣＯＮ（ｚＨＰＦ）Ｅｘｔｅｎｄｅｄ  Ｄｉｓｔａｎｃｅ  ＩＩは、長距離の第１のバースト・サイズ（例えば、６４ＫＢ）より大きいＦＩＣＯＮトランスポート・モード書き込みの性能を改善し、かつ、ストレージ・コントローラ・ポートにおける低バッファ状態がストレージ・エリア・ネットワーク（ＳＡＮ）のコンジェスチョンをもたらすのを防止するための、強化されたバッファ管理機能である。これは、ディスエーブルにされた第１の転送準備（ｄｉｓａｂｌｅｄ  ｆｉｒｓｔ  ｔｒａｎｓｆｅｒ  ｒｅａｄｙ）へのサポートを提供したｚＨＰＦ  Ｅｘｔｅｎｄｅｄ  Ｄｉｓｔａｎｃｅに優る改善点である。
【００１０】
特許文献１は、制御ユニットと通信するように構成されたホスト・コンピュータ・システムにおいてＩ／Ｏ動作を実行するための機構を記載する。トランスポート・モード・コマンド・メッセージは、チャネル・サブシステムから制御ユニットへ送られ、コマンド・メッセージは、制御ユニットにより制御されるＩ／Ｏデバイスに転送されるデータ用のコマンドを含む。データ転送メッセージは制御ユニットに送られ、データ転送メッセージは、最大データ量より少ない又はそれと等しい、転送されるデータ量を有し、最大データ量は、制御ユニットと関連付けられたバッファの数、及びバッファの数の各々のサイズに対応し、その数及びサイズは、ホスト・コンピュータ・システム内に保持される値により示される。特定の機構において、チャネルは、ローカル・チャネル内に、チャネルが接続される制御ユニットと関連付けられた利用可能なバッファのサイズに関する情報を含む。チャネルはまた、制御ユニットについての利用可能なバッファ・クレジットに関する情報を含むこともできる。例えば、ログイン又は初期化プロセス中などＩ／Ｏ動作を開始する前に、制御ユニットは、バッファ・サイズ及び／又はバッファ・クレジット情報をチャネルに送る。
【００１１】
特許文献２は、制御ユニットと通信するように構成されたホスト・コンピュータ・システムにおいて、Ｉ／Ｏ動作命令により開始される入力／出力(Ｉ／Ｏ)動作を実行するための機構を記載する。制御ユニットは、ホスト・コンピュータ・システムのチャネル・サブシステムから、トランスポート・モード・コマンド・メッセージを受信し、そこで、コマンド・メッセージは、ホスト・コンピュータ・システムと制御ユニットにより制御されるＩ／Ｏデバイスとの間でデータを転送するためのコマンドを含む。コマンドリトライ（command retry）メッセージは、チャネル・サブシステムに送られ、このコマンドリトライメッセージは、コマンド・メッセージを制御ユニットに再送信する要求と、その要求の理由を示す理由コードとを含む。
【００１２】
従って、特許文献２及び特許文献１は、ＦＩＣＯＮの特定のバージョンにおいて実装することができるようなコマンドリトライ及び転送バッファ・クレジットの詳細を提供する。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】米国特許公開第２０１４／０３５９，１６８号明細書
【特許文献２】米国特許第８９１８５４２号明細書
【非特許文献】
【００１４】
【非特許文献１】「ＦＩＢＲＥ  ＣＨＡＮＮＥＬ  Ｓｉｎｇｌｅ−Ｂｙｔｅ  Ｃｏｍｍａｎｄ  Ｃｏｄｅ  Ｓｅｔｓ  Ｍａｐｐｉｎｇ  Ｐｒｏｔｏｃｏｌ−５（ＦＣ−ＳＢ−５）」、Ｒｅｖ．２．０、Ａｍｅｒｉｃａｎ  Ｎａｔｉｏｎａｌ  Ｓｔａｎｄａｒｄｓ  Ｉｎｓｔｉｔｕｔｅ発行、２０１３年３月２６日
【発明の概要】
【発明が解決しようとする課題】
【００１５】
制御ユニットにデータを伝送するために１つ又は複数のホスト計算デバイスの複数のチャネルによりバッファ・クレジットを受信する方法、システム及びコンピュータ・プログラムを提供する。
【課題を解決するための手段】
【００１６】
ホスト計算デバイスのチャネルが、データ転送コマンドを、ストレージ・コントローラ内に含まれる制御ユニットに送る、方法、システム及びコンピュータ・プログラム製品が提供される。ホスト計算デバイスのチャネルは、制御ユニットとの通信のために、制御ユニットから、ある数のバッファ・クレジットを受信し、受信したバッファ・クレジットの数は、制御ユニットが、チャネルを含む複数のチャネルと通信する間、監視期間中、転送準備動作(transfer ready operation)の数及びリトライ動作の数を監視することに基づく。
【００１７】
チャネルが、制御ユニットへのデータ伝送のために受信したバッファ・クレジットの数を用いるとき、高いデータ転送速度が維持されることが好ましい。
【００１８】
特定の実施形態において、複数のチャネルの各々は、制御ユニットから同一の数のバッファ・クレジットを受信する。その結果、全てのチャネルは、バッファ・クレジットの数割り当てに関して、制御ユニットから同じ優先順位を受け取る。
【００１９】
更に別の実施形態において、制御ユニットが、前記監視期間中、転送準備動作の使用はあるが、リトライ動作の使用はないと判断すること、及び、制御ユニットが、転送準備動作の数が転送準備閾値より大きいと判断することに応答して、チャネルは、増加した数のバッファ・クレジットを受信する。バッファ・クレジットの数の増加のため、伝送の際、チャネルは、より多くのデータを送ることができる。
【００２０】
更に別の実施形態において、制御ユニットが、監視期間中、転送準備動作の使用はあるが、リトライ動作の使用はないと判断すること、及び、制御ユニットが、リトライ動作の前記数がリトライ低閾値（ｒｅｔｒｙ  ｌｏｗ  ｔｈｒｅｓｈｏｌｄ）を上回ると判断することに応答して、チャネルは、減少した数のバッファ・クレジットを受信する。その結果、チャネルが、制御ユニット内のバッファ空間を使い過ぎることはない。
【００２１】
付加的な実施形態において、制御ユニットが、記監視期間中、転送準備動作及びリトライ動作の両方の使用があると判断すること、及び、制御ユニットが、リトライ動作の数がリトライ高閾値（ｒｅｔｒｙ  ｈｉｇｈ  ｔｈｒｅｓｈｏｌｄ）を上回ると判断することに応答して、チャネルは、減少した数のバッファ・クレジットを受信する。その結果、チャネルが、制御ユニット内のバッファ空間を使い過ぎることはない。
【００２２】
特定の実施形態において、複数のチャネルの各々は、複数のチャネルと制御ユニットとの間の通信の始動段階（startupphase）の開始時に、バッファ・クレジットの数を受信し、受信されるバッファ・クレジットの数は、データの転送に用いられるとき、転送準備動作を発生させるが、リトライ動作を発生させない。複数のチャネルの各々は、始動段階の開始から所定の時間内に、あらゆる転送準備動作を排除する又はリトライ動作を発生させるのに十分に大きい増加した数のバッファ・クレジットを繰り返し受信する。その結果、チャネルは、制御ユニットとのデータ通信のための動作の定常状態に迅速に達し、動作の定常状態において、データ転送は、最適な数の転送準備及びリトライによって効率的に実行される。
【００２３】
更に別の実施形態において、始動段階の開始は、複数のチャネルが制御ユニットにログオンしたときにもたらされる。
【００２４】
さらに、ストレージ・コントローラと通信し、かつメモリと、メモリに結合されたプロセッサとを備えるホスト計算デバイスが提供され、プロセッサは動作を実行し、その動作は、ホスト計算デバイスのチャネルにより、データ転送コマンドを、ストレージ・コントローラ内に含まれる制御ユニットに送ることと、ホスト計算デバイスのチャネルにより、制御ユニットとの通信のために、制御ユニットから、ある数のバッファ・クレジットを受信することであって、受信したバッファ・クレジットの数は、制御ユニットが、チャネルを含む複数のチャネルと通信する間、監視期間中、転送準備動作の数及びリトライ動作の数を監視することに基づく、受信することとを含む。
【００２５】
ここで、全体にわたって同様の参照番号が対応する部品を表す以下の図面を参照して、単なる例証として、本発明の好ましい実施形態を説明する。
【図面の簡単な説明】
【００２６】
【図１】特定の実施形態による、制御ユニットとすることができるターゲットと、複数のチャネルとすることができる複数のイニシエータとを含むコンピューティング環境のブロック図を示す。
【図２】特定の実施形態による、バッファ・クレジットの利用についてのブロック図を示す。
【図３】特定の実施形態による、コマンドのリトライを示すブロック図を示す。
【図４】特定の実施形態による、バッファ・クレジット調整プロセスの動作を示すブロック図を示す。
【図５】特定の実施形態による、転送準備及びリトライを最適化するための制御ユニットの動作を示す第１のフローチャートを示す。
【図６】特定の実施形態による、リトライと転送準備がどのようにバランスされるかを示すブロック図を示す。
【図７】特定の実施形態による、リトライ及び転送準備の数を最適化するために、バッファ・クレジットがどのように調整されるかを示す第２のフローチャートを示す。
【図８】特定の実施形態による、リトライ及び転送準備の数を最適化するために、バッファ・クレジットがどのように調整されるかを示す第３のフローチャートを示す。
【図９】特定の実施形態による、リトライ及び転送準備の数を最適化するために、バッファ・クレジットがどのように調整されるかを示す第４のフローチャートを示す。
【図１０】特定の実施形態による、始動段階におけるバッファ・クレジットの調整を示すブロック図を示す。
【図１１】特定の実施形態による、始動段階及び始動後段階（post-startup phase）中に実行される動作を示す第５のフローチャートを示す。
【図１２】特定の実施形態による、始動後段階中に調整される特定の付加的なパラメータを示すブロック図を示す。
【図１３】特定の実施形態による、始動後段階における監視及び監視ラウンド間の待機のための動作を示す第６のフローチャートを示す。
【図１４】特定の実施形態による、リトライ及び転送準備の数に基づいたバッファ・クレジットの調整を示す第７のフローチャートを示す。
【図１５】特定の実施形態による、始動後段階における監視期間、及び監視の連続ラウンド間の待機時間の影響を示すブロック図を示す。
【図１６】特定の実施形態による、始動段階においてバッファ・クレジットを増加させるための動作を示す第８のフローチャートを示す。
【図１７】特定の実施形態による、始動段階においてバッファ・クレジットを増加させるための動作、並びに始動段階及び始動後段階において他のパラメータを調整するための動作を示す第９のフローチャートを示す。
【図１８】特定の実施形態による、１つ又は複数のスイッチを介するストレージ・コントローラの制御ユニットと通信する複数のチャネルを含む複数のホストのブロック図を示す。
【図１９】特定の実施形態による、チャネルがデータ転送コマンドを制御ユニットに送り、チャネルが制御ユニットからある数のバッファ・クレジットを受信する、ブロック図を示す。
【図２０】特定の実施形態による、制御ユニットと通信する間、転送準備動作及びリトライ動作を実行し、制御ユニットによる転送準備動作の数及びリトライ動作の数の分析に基づいて、制御ユニットからある数のバッファ・クレジットを受信するチャネルのブロック図を示す。
【図２１】特定の実施形態による、１つ又は複数のホストに含まれる複数のチャネルの１つ又は複数のチャネルにより実行される動作を示す第１０のフローチャートを示す。
【図２２】特定の実施形態による、１つ又は複数のホストに含まれる複数のチャネルの１つ又は複数のチャネルにより実行される動作を示す第１１のフローチャートを示す。
【図２３】特定の実施形態による、クラウド・コンピューティング環境のブロック図を示す。
【図２４】特定の実施形態による、図２３のクラウド・コンピューティング環境のさらなる詳細のブロック図を示す。
【図２５】特定の実施形態による、図１、図１８、図１９、図２０に示されるストレージ・コントローラ又はホスト内に含ませることができる特定の要素を示す計算システムのブロック図を示す。
【発明を実施するための形態】
【００２７】
以下の説明において、その一部を形成し、幾つかの実施形態を示す添付図面を参照する。他の実施形態を用い得ること、及び、動作の変更をなし得ることが理解される。
【００２８】
制御ユニット（ターゲットとも呼ばれる）が、複数のチャネルから制御ユニットへのデータ転送の性能を改善するために、ある期間、転送準備及びリトライの数に基づいてバッファ・クレジットの数を調整する、特定の実施形態が提供される。バッファ・クレジットの数は、利用可能なバッファの数が使い尽くされず、高いデータ転送速度が維持されるように調整される。
【００２９】
特定の状況では、ＦＣＰ（ファイバ・チャネル・プロトコル）又はＦＩＣＯＮ規格によると、転送準備がディスエーブルにされると、データ転送用の転送準備の使用は、１つの第１のバースト・バッファに固定される。ストレージ・ポートが受信バッファを使い切ると、ストレージ・エリア・ネットワーク（ＳＡＮ）のバッファ・クレジットが不足してファブリックコンジェスチョンを引き起こすことがある。
【００３０】
特定の実施形態は、第１の転送バッファ・クレジット及びトランスポート・モード・コマンドリトライフィーチャを用いて、ホスト・アダプタ内の受信バッファを管理するための機構を提供する。これは、低速のドレイン・ポートにより引き起こされるファブリックコンジェスチョンの緩和をもたらし、受信バッファが供給不足状態のとき、転送準備を用いて動作をリトライする能力を利用する。
【００３１】
特定の実施形態は、ストレージ・デバイスにおける第１の転送バッファを管理するための機構を提供する。特定の実施形態において、制御ユニット（ターゲット）にバッファがないか又はバッファが少ないとき、トランスポート・コマンドリトライ要求がチャネルに送られ、このリトライ要求は、データを確実に制御ユニットに転送するトランスポート・コマンドリトライを行うよう、（転送準備ハンドシェイクを介して）チャネルに求める。特定の実施形態において、制御ユニットは、利用可能である可能性が高いクレジットの表示を提供するので、事前のハンドシェイクを必要としない。幾つのリトライが発生しているか、又は幾つの転送準備ハンドシェイクが発生しているかに基づいて、チャネルのためのバッファ・クレジットを調整するための機構が提供される。
【００３２】
特定の実施形態において、バッファの不足により引き起こされるコンジェスチョンを防止し、最小限の再伝送で転送準備と共にリトライするための機構を提供するために、特許文献２及び特許文献１に記載されるようなＦＩＣＯＮアーキテクチャの改善点を利用するように、制御システムが提供され、実施形態は、データ・バッファがなくなって、バッファ・クレジットをチャネルに提供するとき、及び、プロセスがバッファ・クレジットの数を最適化しようと試みる間、リトライを提供する。
【００３３】
特定の実施形態は、最小数のターンアラウンドで大容量のバッファを可能にする。理想的には、あらゆるコマンドは、同時ワークロード及びバッファ可用性を条件として１又は２回のターンアラウンドで実行することができる。特定の実施形態は、書き込みワークロードが最大同時処理を超え、そして利用可能なデータ・バッファ・リソースを効率的に使用するときに必要とされる再伝送の数を大きく減少させる。
【００３４】
特定の実施形態は、ディスエーブルにされる／必要とされる第１の転送準備の動的使用、及び、第１のバースト・データの動的長さを可能にするリンク・アーキテクチャを採用する。ＦＩＣＯＮチャネルは、動作（開始）ベースで、第１のバースト・データのために転送準備をディスエーブルにするか又は必要とするか判断することができ、転送準備をディスエーブルにするとき、制御ユニットからのクレジット・ヒントに基づいて、任意のデータ量を送る。さらに、制御ユニット・ポートは、大容量の（例えば、６４Ｋより大きい）第１のバースト・データ情報ユニット（ＩＵ）シーケンスを、複数の「第１のバースト」受信データ・バッファ内に受信する能力を提供する。
【００３５】
例示的な実施形態
図１は、特定の実施形態による、制御ユニットとすることができるターゲット１０２と、複数のチャネルとすることができる複数のイニシエータ１０４、１０６、．．．１０８とを含むコンピューティング環境１００のブロック図を示す。制御ユニット１０２は、複数のチャネル１０４、１０６、．．．１０８からのデータ転送を管理するストレージ・コントローラ又はストレージ・デバイス１０１内に含まれ得る。複数のチャネル１０４、１０６、．．．１０８は、１つ又は複数のホスト１１０内に含まれ得る。
【００３６】
制御ユニット１０２を含み、ストレージ・デバイスを制御するストレージ・コントローラ１０１、及びホスト１１０は、パーソナル・コンピュータ、ワークステーション、サーバ、メインフレーム、手持ち式コンピュータ、パームトップ・コンピュータ、テレフォニー・デバイス、ネットワーク・アプライアンス、ブレード・コンピュータ、処理デバイス等のような、当技術分野において現在周知のものを含む任意の適切な計算デバイスを含むことができる。ストレージ・コントローラ１０１及びホスト１１０は、ストレージ・エリア・ネットワーク、広域ネットワーク、インターネット、イントラネットのような任意の適切なネットワーク内の要素とすることができる。特定の実施形態において、ストレージ・コントローラ１０１及びホスト１１０は、クラウド・コンピューティング環境内の要素とすることができる。
【００３７】
複数のチャネル１０４、１０６、．．．１０８及び制御ユニット１０２は、ファイバ・チャネル・プロトコル（ＦＣＰ）、ＦＩＣＯＮ、又は他のいずれかの適切なプロトコルによって、図１に示されるようなスイッチ１１２を介して通信する。
【００３８】
制御ユニット１０２は、制御ユニット１０２とチャネル１０４、１０６、．．．１０８との間のデータ転送の性能を改善するために、転送準備動作及びリトライ動作の数を最適化するための制御ユニット・アプリケーション１１４を含む。制御ユニット・アプリケーション１１４は、ソフトウェア、ハードウェア、ファームウェア、又はそのいずれかの組み合わせで実装することができる。
【００３９】
制御ユニット１０２は、制御ユニット１０２によってチャネル１０４、１０６、．．．１０８から受信したデータを格納するために共有される複数のバッファ１１６、１１８、．．．１２０を制御する。特定の実施形態において、バッファ１１６、１１８、．．．１２０は、受信バッファと呼ばれる。特定の実施形態において、各バッファのサイズは、６４キロバイトとすることができ、２０００個のバッファが存在し得る。
【００４０】
制御ユニット・アプリケーション１１４は、バッファ・クレジット１２２、転送準備カウンタ１２３、リトライカウンタ１２４、転送準備閾値１２６、リトライ低閾値１２８及びリトライ高閾値１３０に対応するデータ構造を用いて、データをチャネル１０４、１０６、．．．１０８から制御ユニット１０２のバッファ１１６、１１８、．．．１２０へ転送するために転送準備動作及びリトライ動作の数を最適化する。転送準備カウンタ１２３は、転送準備動作の数を格納し、リトライカウンタ１２４は、リトライ動作の数を格納する。特定の実施形態において、動作数は、転送準備を、オーバーラン動作をリトライする要求の結果として用いることができるので、特定の実施形態において、十分でないバッファ・クレジットに起因して転送準備を用いる動作数は、転送準備動作の総数からリトライ動作の数を減算することによって近似値が求められ、転送準備カウンタ１２３は、そうした実施形態において、この近似値に対応し得る。
【００４１】
従って、図１は、制御ユニット・アプリケーション１１４が、ＦＣＰ及びＦＩＣＯＮ、並びに他の通信又はトランスポート・プロトコルに従ってチャネル１０４．．．１０８に対して割り当てられたバッファ・クレジット１２２を調整することによって、転送準備動作及びリトライ動作の数を最適化する、特定の実施形態を示す。
【００４２】
図２は、特定の実施形態による、バッファ・クレジットの利用についてのブロック図２００を示す。
【００４３】
初期化の際、制御ユニット１０２は、バッファ・クレジットをチャネル１０４に提供することができる（参照番号２０２により示されるように）。特定の実施形態において、バッファ・クレジットは、ＦＩＣＯＮ規格における第１の転送バッファ・クレジット（ＦＴＢＣ）値に対応し得る。
【００４４】
バッファ・クレジットがチャネル１０４に提供されると、データの送信の間、チャネル１０４は、第１のバースト・データが最大バッファ・クレジットの量までのデータを含むように、第１のバースト・データを制御ユニット１０２に送る（参照番号２０４により示されるように）。例えば、バッファ・クレジットにより、チャネルが、複数のバッファ１１６、１１８、．．．１２０の最大８つまでのバッファ（例えば、バッファ・クレジットは８である）内に格納することができるデータを送ることが可能になる場合、チャネル１０４から制御ユニット１０２へのデータの第１のバーストの間、少なくとも、最大８つのバッファ内に格納することができるデータを送ることができる。チャネル１０４は、バッファ・クレジットの数を認識しているので、いずれのバッファ・クレジットもなしに第１のバーストにおいて他の方法で送ることができる何らかのデータに加えて、第１のバーストにおいて制御ユニット１０２に転送することができるデータの量を知っている。
【００４５】
図３は、特定の実施形態による、コマンドのリトライを示すブロック図３００を示す。チャネル１０４は、バッファ・クレジットがチャネル１０４に提供されたとき、第１のバースト・データを制御ユニット１０２に送るための動作を実行する（参照番号３０２）。
【００４６】
複数のチャネル１０４、１０６、．．．１０８は、データを制御ユニット１０２に転送することができるので、制御ユニット１０２は、複数のバッファ１１６、１１８、．．．１２０内に、チャネル１０４により転送されるデータを格納するための空きスペースがないことに気付くことができる。制御ユニット１０２が、チャネル１０４により送られるデータを格納するための利用可能なバッファがないと判断する場合、制御ユニット１０２は、転送準備動作を用いて動作をリトライするよう、チャネル１０４に要求する（参照番号３０４）。
【００４７】
制御ユニット１０２は、バッファが利用可能になるのを待つ必要がない。転送準備（低速動作）を用いてリトライが行われると、制御ユニット１０２により、リトライ済みコマンドが受信され、次に、データを受信するのに利用可能なバッファがある場合、制御ユニット１０２は、転送準備をチャネルに送ってデータを要求する。
【００４８】
特定の代替的な実施形態においては、制御ユニット１０２は、バッファが利用可能になるのを待ち、次に、転送準備を用いずに（第１のバースト・データを用いて）リトライを要求するが、データが最終的に到達したときにバッファが依然として利用可能であるという保証はなく、システムは、第１のリトライで動作が成功するという保証を失うことがある（特定の動作のためにデータ・バッファが予約されていない限り）。制御ユニット１０２は、リトライのために使用する理由コードに基づき、転送準備を用いてリトライするかどうかをチャネル１０４、１０６、．．．１０８に示す能力を有する。
【００４９】
転送準備動作のために、少なくとも１回の付加的なラウンドトリップが必要とされるので、転送準備動作は、データをチャネル１０４から制御ユニット１０２に転送するための比較的低速の機構である。光の速さにより、Ｉ／Ｏ動作は、各片道トリップについて１キロメートル当たり５マイクロ秒だけ遅延する。高性能ＦＩＣＯＮにおける読み取り動作は、通常、単一回のラウンドトリップ、すなわち１キロメートル当たり１０マイクロ秒を要する。書き込み動作は、一般に、転送準備がディスエーブルにされるとき、単一回のラウンドトリップを必要とし、転送準備が必要とされるとき、少なくとも２回のラウンドトリップを必要とする。各々の付加的な転送準備は、付加的なラウンドトリップを必要とすることがある。書き込みにおいても読み取りにおいても、１キロメートル当たり５マイクロ秒の付加的な片道トリップが付加されることが確認されている。顧客は、多くの場合１０〜２０キロメートルの距離だけ離れた２つの処理センターを有する高可用性（ＨＡ）構成を使用するので、合理化した動作は特に重要である。プロセッサの故障が発生した場合、又はアクティブ・アクティブ構成においては、Ｉ／Ｏは、遠隔ホスト・プロセッサから受信される。多くの場合、最大１００キロメートルまでの距離がサポートされる。チャネル延長技術の使用により、より遠い距離が可能となる。転送準備動作は少なくとも２回のラウンドトリップを必要とするので、これは、ディスエーブルにされた転送準備を用いる機構よりもかなり低速であり得る。
【００５０】
転送準備動作を用いてリトライが実行されることが、チャネルに通知されることに応答して、チャネル１０４は、転送準備動作を用いてデータを制御ユニット１０２に送る（参照番号３０６）。
【００５１】
従って、複数のバッファ１１６、１１８、．．．１２０における利用可能なスペースが、指示されるバッファ・クレジットにより、転送準備ディスエーブル・モードでチャネル１０４、１０６．．．１０８により送られるデータを収容することができないとき、制御ユニット１０２は、比較的低速の転送準備動作によって動作をリトライすべきであると、データが収容されなかったチャネルに指示することができる。
【００５２】
図４は、特定の実施形態による、バッファ・クレジット調整プロセスの動作を示すブロック図４００を示す。図４において、ブロック４０２において、チャネルの１つ（例えば、チャネル１０４）は、制御ユニット１０２に与えられるバッファ・クレジット１２２を変更させる条件をもたらす。例えば、多すぎるバッファ・クレジットが与えられた場合、バッファ１１６、１１８、．．．１２０はあまりにも迅速に満杯になり、比較的低速の転送準備でフォールバックするリトライを使用しなければならない。こうした状況では、バッファ・クレジット１２２の数を減少させることが望ましい場合がある。
【００５３】
バッファ・クレジットの数を減少させる（例えば、リトライが多すぎる場合）又は増加させる（例えば、転送準備を用いる多くの動作がある場合）ための判断を制御ユニット１０２により行うとき、制御ユニット１０２は、等しい数のバッファ・クレジットを複数のチャネル１０４、１０６、．．．１０８の各チャネル供与する（ブロック４０４に示されるように）。チャネルを等しく処理することにより、制御ユニット１０２は、いずれかの単一のチャネルが、他のチャネルを犠牲にして、バッファ１１６、１１８、．．．１２０内の圧倒的な量のスペースを獲得することを防止する。代替的な実施形態においては、その履歴データ転送の必要性又は他の要件に基づいて、異なる数のクレジットを異なるチャネルに提供することも可能である。
【００５４】
図５は、特定の実施形態による、転送準備及びリトライを最適化するための制御ユニットの動作を示すフローチャート５００を示す。図５に示される動作は、制御ユニット１０２において実装することができ、制御ユニット・アプリケーション１１４により実行することができる。
【００５５】
制御は、制御ユニット１０２が、一定期間にわたり、複数のチャネル１０４、１０６、．．．１０８からの通信に対して行われたリトライ及び転送準備（すなわち、転送準備動作）の数を判断する、ブロック５０２で開始する。制御ユニットは、ブロック５０２から、並行してブロック５０４、５０６に進む。
【００５６】
ブロック５０４において、制御ユニット１０２は、多すぎるリトライ（すなわち、リトライ動作）が発生したかどうかを判断する。多すぎるリトライが発生した場合（「イエス」分岐５０８）、多すぎるバッファ・クレジットが各チャネルに割り当てられ、ブロック５１０において、制御ユニット１０２は、各チャネルについてのバッファ・クレジットの数を減少させる。多すぎるリトライが発生しなかった場合（「ノー」分岐５０５）、制御はブロック５０２に戻る。
【００５７】
ブロック５０６において、制御ユニット１０２は、多すぎる転送準備が行われたかどうかを判断する。多すぎる転送準備が行われた場合（「イエス」分岐５１２）、バッファ・クレジットが増加されれば、システム性能が改善可能であり、制御ユニットは、バッファ・クレジットの数を増加させる（ブロック５１４において）。多すぎる転送準備が行われなかった場合（「ノー」分岐５０７）、制御ユニットは、ブロック５０２に戻る。
【００５８】
従って、図５は、リトライ及び／又は転送準備の数に基づいてバッファ・クレジットの数が調整される、１つの実施形態を示す。
【００５９】
図６は、特定の実施形態による、リトライと転送準備のバランスをどのようにとるかを示すブロック図６００を示す。参照番号６０２は、紙面の右に向かう矢印の方向に増加するバッファ・クレジットの数を示す。バッファ・クレジットの数が大きい場合、バッファ１１６、１１８、．．．１２０は、チャネルからの全てのデータを収容することができ、リトライを必要とし得る（参照番号６０４により示される）。バッファ・クレジットの数が小さい場合、データを転送するために、低速プロセスの転送準備を必要とし得る（参照番号６０６により示される）。制御ユニット・アプリケーション１１４は、バッファ・クレジットの数を調整しようと試みるので（参照番号６０８）、システムは、望ましい動作範囲にあり、ここで、望ましい動作範囲は、所定の動作範囲とすることができる。例えば、予め定められる望ましい動作範囲は、最後の３０秒においてリトライされる動作が０．５％を超えず、最後の３０秒において転送準備である動作が０．５％を超えないものであり得る（参照番号６１０により示されるように）。最適な動作条件は、最後の３０秒において、０．１％未満の動作がリトライであり、転送準備は要求されない。参照番号６１２及び６１４は、多すぎる転送準備（例えば、最後の３０秒間に０．５％より多い動作）又は多すぎるリトライ（例えば、最後の３０秒間に０．５％より多い動作）がある、望ましくない動作範囲を示す。
【００６０】
図７は、特定の実施形態による、リトライ及び転送準備の数を最適化するために、バッファ・クレジットがどのように調整されるかを示すフローチャート７００を示す。図７に示される動作は、制御ユニット１０２において実装することができ、制御ユニット・アプリケーション１１４により実行することができる。
【００６１】
制御は、制御ユニット１０２が、ある監視期間、転送準備動作及びリトライ動作を監視する、ブロック７０２で開始する。特定の実施形態において、監視期間は、３０秒とすることができる。
【００６２】
制御は、制御ユニット１０２が、監視期間中、転送準備又はリトライのいずれかの使用があるかどうかを判断する、ブロック７０４に進む。転送準備の使用のみがある（すなわち、リトライはない）場合（分岐７０６）、制御はブロック７１２に進む。リトライの使用だけがある（すなわち、転送準備の使用はない）場合（分岐７０８）、制御はブロック７１４に進む。転送準備及びリトライの両方の使用がある場合（分岐７１０）、制御はブロック７１６に進む。（ブロック７０４において）監視期間中、転送準備又はリトライの使用がない場合、制御は「ノー」分岐７１８を介してブロック７０２に進む。
【００６３】
ブロック７１２において、転送準備の使用が転送準備閾値１２６を上回るかどうかの判断がなされる。転送準備閾値は低閾値（例えば、動作の０．２％）であり、予め定められている。転送準備の使用が転送準備閾値１２６を上回る場合（「イエス」分岐７２０）、制御はブロック７２２に進み、そこで、バッファ・クレジットが増加される。転送準備の使用が転送準備閾値１２６を上回らない場合（「ノー」分岐７２４）、制御はブロック７０２に戻る。
【００６４】
ブロック７１４において、リトライの使用が「リトライ低閾値（ｒｅｔｒｙ  ｌｏｗ  ｔｈｒｅｓｈｏｌｄ」１２８を上回るかどうかの判断がなされる。例えば、リトライ低閾値は、動作の０．１％とすることができる。リトライの使用がリトライ低閾値１２８を上回る場合（「イエス」分岐７２６）、バッファ・クレジットは減少される（ブロック７２８において）。リトライの使用がリトライ低閾値１２８を上回らない場合（「ノー」分岐７３０）、制御はブロック７０２に戻る。
【００６５】
転送準備及びリトライの両方の使用があるとき、制御はブロック７１６に達する。転送準備及びリトライの両方が使用される場合、考慮すべき４つのケースがある。この４つのケースは、以下のとおりである。
ケース１：転送準備の数が転送準備閾値を下回り、リトライの数がリトライ高閾値を下回る場合、制御ユニット１０２は、転送準備及びリトライの監視を続行する。
ケース２：転送準備の数が転送準備閾値を下回り、リトライの数がリトライ高閾値を上回る場合、制御ユニット１０２は、バッファ・クレジットの数を減少させる。
ケース３：転送準備の数が転送準備閾値を上回り、リトライの数がリトライ高閾値を下回る場合、特定の実施形態において、制御ユニット１０２は、バッファ・クレジットを増加させるように選択することができ、他の実施形態においては、制御ユニット１０２は、転送準備及びリトライの監視の続行することを選択することができる。制御ユニット１０２がバッファ・クレジットを増加させることを選択する実施形態において、システムは、バッファ・クレジットを減少させる必要がある以下のケース４に示される状況に達することができる。バッファ・クレジットを繰り返し増加及び減少させることによる、変動するスラッシングを回避するために、特定の実施形態においては、簡単にするために、バッファ・クレジットを増加させる代わりに、転送準備及びリトライの監視を続行することが適切な場合がある。バッファ・クレジットが増加される実施形態において、制御ユニット１０２は、バッファ・クレジットの増加が既に一度行われていることを追跡することができ、スラッシング（すなわち、バッファ・クレジットが増加した後に、バッファ・クレジットが減少した）の発生時には、バッファ・クレジットは再度増加しない。
ケース４：転送準備の数が転送準備閾値を上回り、リトライの数がリトライ高閾値を上回る場合（例えば、動作の０．５％がリトライであるのは、リトライ高閾値であり得る）、制御ユニット１０２は、バッファ・クレジットを減少させる。
【００６６】
上記に示されるケース１〜４を鑑みて、特定の実施形態では、リトライカウントがリトライ高閾値を上回る場合はつねに、制御ユニット１０２は、転送準備の数に関係なく、バッファ・クレジットを減少させ、他の場合には、転送準備及びリトライの監視を続行する。こうした実施形態が図７に示され、ブロック７１６において、リトライの使用が「リトライ高閾値」１３０を上回るかどうかについての判断がなされる。リトライの使用が「リトライ高閾値」１３０を上回る場合（「イエス」分岐７３２）、制御はブロック７３４に進み、そこでバッファ・クレジットが減少される。リトライの使用が「リトライ高閾値」１３０を上回らない場合（「ノー」分岐７３６）、制御はブロック７０２に進む。
【００６７】
バッファ・クレジットに対する調整がなされるブロック７２２、７２８、７３４から、制御ユニット１０２は、監視期間中、転送準備動作及びリトライ動作を再度監視する前に、システムが変更する特定の期間（例えば、参照番号７３５により示されるような２秒間）を待つ（ブロック７０２において）。
【００６８】
従って、図７は、監視期間中、転送準備及びリトライの使用量に基づき、バッファ・クレジットの調整を行ってデータ転送の性能を改善する、特定の実施形態を示す。
【００６９】
図８は、特定の実施形態による、リトライ及び転送準備の数を最適化するために、バッファ・クレジットをどのように調整するかを示すフローチャート８００を示す。図８に示される動作は、制御ユニット１０２において実装することができ、制御ユニット・アプリケーション１１４により実行することができる。
【００７０】
制御は、制御ユニット１０２が、複数のチャネル１０４、１０６、．．．１０８との通信の間に、ある監視期間中、転送準備動作の数及びリトライ動作の数を監視する、ブロック８０２で開始する。監視に基づいて、複数のチャネル１０４、１０６、．．．１０８との通信のために、バッファ・クレジット１２２の数を調整する（ブロック８０４において）。
【００７１】
図９は、特定の実施形態による、リトライ及び転送準備の数を最適化するために、どのようにバッファ・クレジットを調整するかを示すフローチャート９００を示す。図９に示される動作は、制御ユニット１０２において実装することができ、制御ユニット・アプリケーション１１４により実行することができる。
【００７２】
制御は、制御ユニット１０２が、複数のチャネル１０４、１０６、．．．１０８との通信の間に、ある監視期間中、転送準備動作の数及びリトライ動作の数を監視する、ブロック９０２で開始する。
【００７３】
制御はブロック９０２からブロック９０４に進み、そこで、監視期間中、転送準備動作の使用はあるが、リトライ動作の使用はないと判断すること、及び、転送準備動作の数が転送準備閾値を上回ると判断することに応答して、バッファ・クレジットの数を増加させる。
【００７４】
ブロック９０４から、制御はブロック９０６に進み、そこで、監視期間中、リトライ動作の使用はあるが、転送準備動作の使用はないと判断すること、及び、リトライ動作の数がリトライ低閾値を上回ると判断することに応答して、バッファ・クレジットの数を減少させる。
【００７５】
制御はブロック９０６からブロック９０８に進み、そこで、監視期間中、転送準備動作及びリトライ動作の両方の使用があると判断すること、及び、リトライ動作の数がリトライ高閾値を上回ると判断することに応答して、バッファ・クレジットの数を減少させる。
【００７６】
従って、図１〜図９は、制御ユニット１０２（ターゲットとも呼ばれる）が、複数のチャネル１０４、１０６、．．．１０８から制御ユニットへのデータ転送の性能を改善するために、ある期間中、転送準備及びリトライの数に基づいて、バッファ・クレジットの数を調整する、特定の実施形態を示す。バッファ・クレジットの数は、利用可能なバッファの数が使い尽くされず、高いデータ転送速度が維持されるように調整される。
【００７７】
始動段階（ｓｔａｒｔｕｐ  ｐｈａｓｅ）におけるバッファ・クレジット及び他のパラメータの調整
特定の実施形態において、初めに、チャネル１０４、１０６、．．．１０８に、制御ユニット１０２において利用可能なバッファの数（例えば、２０００）よりずっと少ないバッファ・クレジット（例えば、１６）を与えることができる。チャネル１０４．．．１０８は、第１のＩ／Ｏに対してバッファ・クレジットを使用し、次に、残りのＩ／Ｏに対して転送準備動作の要求を開始する。リトライ動作は必要とされない。リトライ動作は、転送準備動作と比べてかなり時間がかかることに留意されたい。可能であれば、いずれのリトライ動作も発生させることなく、転送準備動作を必要としない点に達し、さらに、その点に比較的迅速に達することが望ましい。
【００７８】
いかなるリトライ動作も見出すことなく転送準備動作が用いられるときには機会の損失があり、リトライ動作が転送準備を使用し始めるとデータ速度が自動的に遅くなるので、リトライのために転送準備を用いる動作がありすぎて失敗するが、リトライが発生しない位置まで後退する方がよい。従って、特定の実施形態において、バッファ・クレジットは、これが減少するよりも速いペースで増加する。言い換えれば、リトライが発生する状況又はそれ以上の転送準備が使用されない状況をもたらすまで、バッファ・クレジットへのインクリメントが迅速に行われ、始動段階中に行われるインクリメントのペースより遅いペースでデクリメントされる。
【００７９】
特定の実施形態において、ワークロード始動の５分以内にリトライ点（すなわち、それ以上の転送準備がない）に達するように、システムを設定することが望ましい。必要とされるリトライ点から、更に３〜５分以内に安定点に達することができる。
【００８０】
図１０は、特定の実施形態による、始動段階におけるバッファ・クレジットの調整を示すブロック図１０００を示す。
【００８１】
制御ユニット１０２は、図１及び他の図に示される要素に加えて、始動段階の始めに、バッファ・クレジットのデフォルト数（参照番号１００２）の表示、始動段階中のバッファ・クレジットのインクリメント又は乗数値（参照番号１００４）、始動段階における監視期間（参照番号１００６）、及び監視の連続ラウンド間の待機時間（参照番号１００８）を含むことができる。
【００８２】
制御ユニット１０２によりチャネル１０４〜１０８の各々に与えられるバッファ・クレジットのデフォルト数は１６とすることができ、これは、２０００とすることができる利用可能なバッファ１１６．．．１２０の数よりかなり少ない。１６のデフォルト値は、チャネル１０４．．．１０８がログオン動作（参照番号１０１０により示される）を行って、スイッチ１１２を介して制御ユニット１０２に接続するときに提供され得る。ログオン動作は、始動段階の開始とみなすことができる。
【００８３】
始動段階中のバッファ・クレジットのインクリメント値１００４は、１６に設定することができる。こうした実施形態において、始動段階中、バッファ・クレジットは、待機時間１００８だけ待った後、各監視期間１００６後に、１６のインクリメントだけ増加される。例えば、監視期間が３秒であり、待機時間が２秒である場合、最初に、バッファ・クレジットの数は１６（デフォルト値）に設定され、３秒の第１の監視時間及び２秒の待機時間の後、バッファ・クレジットの数は１６だけインクリメントされ、必要に応じて３２になる。その後、３秒の第２の監視期間及び２秒の待機時間の後、バッファ・クレジットの数は、１６だけインクリメントされ、４８になる。バッファ・クレジットを増加させるために、インクリメント値の代わりに、バッファ・クレジットの乗数を用いてもよい。例えば、２の乗数を用いて、バッファ・クレジットは、１６から３２に増加し、次に６４、そして１２８に増加することができる。
【００８４】
図１１は、特定の実施形態による、始動段階及び始動後段階（ｐｏｓｔ−ｓｔａｒｔｕｐ  ｐｈａｓｅ）中に実行される動作を示す第５のフローチャート１１００を示す。図１１に示される動作は、制御ユニット１０２において実装することができ、制御ユニット・アプリケーション１１４により実行することができる。
【００８５】
制御は、始動段階が始まるブロック１１０２で開始する。例えば、特定の実施形態において、始動段階は、スイッチ１１２が停止し、再び復帰した場合に始まることができる。１つ又は複数のポートがオンラインになり、複数のチャネル（例えば、チャネル１０４．．．１０８のような１０個のチャネル）が制御ユニット１０２にログオンすると、制御はブロック１１０４に進む。
【００８６】
制御は、ブロック１１０６に進み、そこで、制御ユニット１０２は、各チャネルにデフォルト数（例えば、１６）のバッファ・クレジットを与える。転送準備はリトライと比べてあまり破壊的ではないので、バッファ・クレジットのデフォルト数は比較的小さい。バッファ・クレジットが初めに非常に高い値に設定された場合、初めに多数のリトライがあることになり、これによりシステムが減速されることがある。
【００８７】
制御はブロック１１０８に進み、そこで、Ｉ／Ｏが実行され、制御ユニット１０２は、３秒といった短い時間、転送準備動作及びリトライ動作を監視する。監視期間（すなわち、サンプリング期間）は、バッファ・クレジットを比較的迅速に変更することによる、システムの迅速な調整のために、比較的少ない。例えば、バッファ・クレジットは、３秒の監視期間と２秒の連続する監視間の待機時間の５秒ごとに、インクリメント値又は乗数だけインクリメントされる。
【００８８】
ブロック１１０８から、制御はブロック１１１０に進み、そこで、監視中、全ての転送準備が排除されたと判断された、又はリトライ動作が発生したかどうかについての判断がなされる。全ての転送準備が排除された又はいずれかのリトライ動作が発生した場合、始動段階は終わり（参照番号１１１８は始動段階を示す）、制御は分岐１１１１を介してブロック１１１２に進む。
【００８９】
ブロック１１１２において、Ｉ／Ｏが引き続き実行され、転送準備動作及びリトライ動作の監視は、監視の連続ラウンド間の待機時間（例えば、２秒）を有する始動段階（例えば、３０秒）と比べると長い時間実行される。始動時間が終わり、バッファ・クレジットの適正値が割り当てられた後、参照番号１１２０により示される始動後段階において、バッファ・クレジットをあまりにも頻繁に変更する必要性はない。
【００９０】
ブロック１１１２から、制御はブロック１１１４に進み、そこで、必要に応じて、バッファ・クレジットを少量だけ調整する。例えば、バッファ・クレジットは、最大２の値だけインクリメント又はデクリメントすることができ、制御はブロック１１１２に戻る。ブロック１１１２及び１１１４により形成されるループが、図７に示される実施形態の他の態様に関して幾らか詳細に説明された。
【００９１】
ブロック１１１０において、監視期間中、リトライ動作が発生せず、転送準備が排除されなかったと判断される場合（分岐１１１５）、制御はブロック１１１６に進み、そこで、バッファ・クレジットを、固定値若しくは乗数により又は他の何らかの機構により大量に（例えば、１６又は３２）インクリメントする。バッファ・クレジットは迅速に増加され、そうでない場合、システムを最適化するのに時間がかかりすぎる。その後、制御はブロック１１０８に戻る。
【００９２】
始動段階１１１８は、特定の実施形態において、５分以内に終わり、このことは、システムにより望まれることがある。これを達成するために、バッファ・クレジットは比較的迅速に増加される。
【００９３】
図１２は、特定の実施形態による、始動後段階中に調整される特定の付加的なパラメータを示すブロック図１２００を示す。
【００９４】
始動後段階において、制御ユニット１０２は、始動後段階における監視期間（参照番号１２０２）と、監視の連続ラウンド間の待機時間（参照番号１２０４）とを示す付加的なインジケータを含むことができる。例えば、特定の実施形態において、監視期間１２０２は３０秒とすることができ、待機時間１２０４は２秒とすることができる。バッファ・クレジットがデフォルト値から迅速に増加される始動段階におけるのと同じくらい迅速にバッファ・クレジットを変更する必要性がないので、始動後段階における監視期間は、始動段階における監視期間と比べてかなり長くすることができる。
【００９５】
図１３は、特定の実施形態による、監視と始動後段階における監視ラウンド間の待機についての動作を示す第６のフローチャート１３００を示す。図１３に示される動作は、制御ユニット１０２において実装することができ、制御ユニット・アプリケーション１１４により実行することができる。
【００９６】
制御は、制御ユニット１０２が、一定時間（例えば、３０秒）転送準備動作及びリトライ動作を監視するブロック１３０２で開始する。制御は１３０４に進み、そこで、（少なくとも図７に示される動作により示されるように）システムの性能を改善するために、バッファ・クレジットの調整が必要とされるかどうかについての判断がなされる。バッファ・クレジットの調整が必要とされる場合（「イエス」分岐：参照番号１３０６）、制御はブロック１３０８に進み、そこで、バッファ・クレジットが調整される。バッファ・クレジットの調整が必要とされない場合（「ノー」分岐：参照番号１３１２）、制御はブロック１３０２に戻り、監視を続行する。
【００９７】
ブロック１３０８から、制御はブロック１３１０に進み、そこで、イン・フライト（in flight）状態のＩ／Ｏ動作を完了しなければならないので、監視の次のラウンドの前に待機が行われる。例えば、特定の実施形態において、２秒の待機後、制御は、監視の次のラウンドのためにブロック１３０２に戻る。
【００９８】
特定の実施形態では、始動後段階において、バッファ・クレジットを、１６のような固定数だけ増加又は減少させることができる。しかしながら、代替的な実施形態では、始動後段階において、バッファ・クレジットを変数により調整することができる、１つのそうした実施形態が、図１４に与えられる。
【００９９】
図１４は、特定の実施形態による、書き込みの百分率としてのリトライ及び転送準備の数に基づくバッファ・クレジットの調整を示す第７のフローチャート１４００を示す。
【０１００】
制御は、制御ユニット１０２が監視期間における書き込みの数を判断するブロック１４０２で開始し、監視期間におけるリトライ及び転送準備の数も判断する（ブロック１４０４において）。監視期間中の書き込みの百分率としてのリトライ及び転送準備の関数に基づいて、バッファ・クレジットの調整（すなわち、増加又は減少）を行う（ブロック１４０６において）。クレジットの調整は、リトライ又は転送準備の数だけに基づくのではなく、監視期間において発生した書き込みの総数を考慮に入れることに留意されたい。クレジットの調整は、これは百分率に基づいており、リトライ又は転送準備の絶対カウントに基づくのではない。このように、クレジットの調整は、サンプル・サイズに影響されない。
【０１０１】
図１５は、特定の実施形態による、始動後段階における、監視期間（参照番号１５０２）及び監視の連続ラウンド間の待機時間（参照番号１５１２）の影響を示すブロック図１５００を示す。
【０１０２】
監視のために用いられる時間が長い（ｈｉｇｈ）（参照番号１５０４）場合、これは、ワークロードにおけるより良好な読み取りを提供できるより大きいサンプル時間が与えられるが、バッファ・クレジットを調整するのにより長い時間がかかり得る（参照番号１５０６により示される）。特定の実施形態において、バッファ・クレジットの調整は、現在のバッファ・クレジットの固定したインクリメント又はデクリメント(例えば、１６）である。先の図１４に示されるような他の実施形態において、バッファ・クレジットのインクリメント又はデクリメントのサイズは、書き込みの百分率としての転送準備及びリトライの数に依存する。転送準備又はリトライのカウントは、監視時間に関係なく全てのＩ／Ｏで発生するので、監視時間が長くても、監視のためにより多くのリソースを要しないことに留意されたい。
【０１０３】
短すぎる監視期間（すなわち、監視期間が短い（ｌｏｗ）１５０８）は、システムの定常状態を表さないサンプルをもたらすことがあり、バッファ・クレジットの変動するスラッシングが発生し得る。また、更新が頻繁すぎると、バッファ・クレジットをチャネルに通信するのに、システムへの影響がより多くなる（参照番号１５１０により示されるように）。
【０１０４】
待機時間の影響が、待機が長すぎる（ｔｏｏ  ｈｉｇｈ）と（参照番号１５１４）、現在のワークロードの調整が遅延し、システムのサンプルの不足をもたらすことがある（参照番号１５１６）。待機が短すぎると（参照番号１５１８）、アクティブＩ／Ｏが完了し、システムが更新されたバッファ・クレジットに調整するのに十分な時間を与えることができない（参照番号１５２０）。
【０１０５】
図１６は、特定の実施形態による、始動段階においてバッファ・クレジットを増加させるための動作を示す第８のフローチャート１６００を示す。図１６に示される動作は、制御ユニット１０２において実装することができ、制御ユニット・アプリケーション１１４により実行することができる。
【０１０６】
制御はブロック１６０２で開始し、そこで、制御ユニット１０２は、１つ又は複数のチャネル１０４、１０６、．．．１０８と制御ユニット１０２との間の通信の始動段階の開始に応答して、ある数のバッファ・クレジット（例えば、１６）を１つ又は複数のチャネル１０４、１０６、．．．１０８に提供し、提供されるバッファ・クレジットの数は、データの転送に用いられるとき、転送準備動作を発生させるが、リトライ動作を発生させない。制御ユニット１０２は、始動段階の開始から所定の時間（例えば、５分）内に、あらゆる転送準備動作を排除する又はリトライ動作を発生させるのに十分に大きい量（例えば、１６又は３２の増加又は乗数による増加）だけバッファ・クレジットの数を繰り返し増加させる（ブロック１６０４において）。その結果、所定の時間内に、最適な数のバッファ・クレジットが、所定の時間内に達成され、例えば、通信の始動段階の開始から５分内に、最適な数のバッファ・クレジットに達することができる。
【０１０７】
図１７は、特定の実施形態による、始動段階においてバッファ・クレジットを増加させ、始動段階及び始動後段階における他のパラメータを調整するための動作を示す第９のフローチャート１７００を示す。図１７に示される動作は、制御ユニット１０２において実装することができ、制御ユニット・アプリケーション１１４により実行することができる。
【０１０８】
制御は、１つ又は複数のチャネル１０４．．．１０８が制御ユニット１０２にログオンしたときに始動段階を開始させるブロック１７０２で開始する。制御はブロック１７０４に進み、そこで、制御ユニット１０２は、１つ又は複数のチャネルと制御ユニット１０２との間の通信の始動段階の開始に応答して、ある数のバッファ・クレジットを１つ又は複数のチャネル１０４．．．１０８に提供し、提供された数のバッファ・クレジットは、データの転送に用いられるとき、転送準備動作を発生させるが、リトライ動作を発生させない。
【０１０９】
その数のバッファ・クレジットを提供した後、制御ユニット１０２は、リトライ動作の数及び転送準備動作の数を判断するために、ある期間、通信を監視する（ブロック１７０６において）。その結果、制御ユニット１０２は、システムがどれだけ効率的にＩ／Ｏ動作を行っているかを判断することができる。
【０１１０】
ブロック１７０６から、制御はブロック１７０８及び１７１０に並行して進む。
【０１１１】
ブロック１７０８において、監視に続いて、制御ユニット１０２は、転送準備動作が発生し、リトライ動作は発生しなかったと判断することに応答して、ある量だけ（一定のインクリメント若しくは乗数により、又は他の何らかの機構により）バッファ・クレジットの数を増加させ、ここで、各監視期間の間の待機時間は、イン・フライト状態のＩ／Ｏ動作が完了するのを可能にするのに適切なものである。
【０１１２】
ブロック１７１０において、監視に続いて、転送準備動作が排除された又はリトライ動作が発生したと判断することに応答して、始動段階を終了する。その結果、始動段階は、所定の時間内に終了し、バッファ・クレジットは、動作の始動後段階のための十分に高い値に設定される。
【０１１３】
ブロック１７１２において、始動段階の終了に応答して、始動後段階におけるバッファ・クレジットの数を増加させ、減少させ、又は変わらないままにするために、監視のための期間を増大させ、リトライ動作の数及び転送準備動作の数を決定する。その結果、始動後段階において、監視期間が増大し、バッファ・クレジットの変更は、始動期間におけるよりも少ない頻度でなされる。
【０１１４】
従って、図１０〜図１７は、始動段階中、バッファ・クレジットが所定の値で開始し、比較的大きいインクリメントで迅速に増加され、その結果、始動段階が約５分以内に迅速に終了する、特定の実施形態を示す。その後、始動後段階において、バッファ・クレジットは、比較的ゆっくりと変更され、その変更は、始動段階と比べると少ないインクリメント又はデクリメントである。
【０１１５】
データの転送のためにチャネルによりバッファ・クレジットを受信する
始動段階及び始動後段階の両方の間、及び、バッファ・クレジットの調整を決定する間、制御ユニット１０２がバッファ・クレジットの調整を決定する間、制御ユニット１０２と通信するチャネルは、少なくとも制御ユニット１０２から受け取ったバッファ・クレジットに基づいて、制御ユニット１０２と通信するための動作を行う。図１８〜図２２は、少なくとも、制御ユニット１０２と通信するホスト計算デバイス内に含まれるチャネルによって行われる特定の動作を説明する。
【０１１６】
図１８は、特定の実施形態による、１つ又は複数のスイッチ１１２を介してストレージ・コントローラ１０１の制御ユニット１０２との通信する複数のチャネル１０４、１０６、．．．１０８を含む、複数のホスト１１０．．．１８０２のブロック図１８００を示す。複数のホストの各ホストは、ホスト計算デバイスとも呼ばれる。
【０１１７】
制御ユニット１０２内に含まれる要素は、図１〜図１８及び図１〜図１８の説明において先に説明されている。
【０１１８】
複数のホスト１１０．．．１８０２は、パーソナル・コンピュータ、ワークステーション、サーバ、メインフレーム、手持ち式コンピュータ、パームトップ・コンピュータ、テレフォニー・デバイス、ネットワーク・アプライアンス、ブレード・コンピュータ、処理デバイス等のような、当技術分野において現在周知のものを含む任意の適切な計算デバイスを含むことができる。
【０１１９】
複数のホスト１１０．．．１８０２の各ホストは、１つ又は複数のスイッチ１１２上で１つ又は複数のチャネルを介して、ストレージ・コントローラ１０１の制御ユニット１０２と通信することができる（ここで、ストレージ・コントローラ１０１は、ストレージ・デバイス若しくは計算デバイス、又は他のいずれかのデバイスとすることができる）。例えば、特定の実施形態において、ホスト１１０は、参照番号１０４、１０６、．．．１０８で示される複数のチャネルを含むことができ、ホスト１８０２は、参照番号１８０４で示される複数のチャネルを含むことができる。
【０１２０】
複数のホスト１１０．．．１８０２の各ホストはまた、ソフトウェア、ハードウェア、ファームウェア、又はそのいずれかの組み合わせで実装されるホスト計算デバイス・アプリケーション（例えば、１８０６、１８０８）も含む。ホスト計算デバイス・アプリケーション１８０６、１８０８は、制御ユニット１０２へのチャネル１０４、１０６、．．．１０８、１８０４の通信を制御する。
【０１２１】
図１９は、特定の実施形態による、データ転送コマンドを、制御ユニット１０２及び制御ユニット１０２からある数のバッファ・クレジットを受信するチャネル１０４、１０６、．．．１０８に送るチャネル１０４、１０６、．．．１０８を示す、ブロック図１９００を示す。
【０１２２】
ホスト１１０のホスト計算デバイス・アプリケーション１８０６は、ストレージ・コントローラ１０１の制御ユニット１０２へのチャネル１０４、１０６、．．．１０８の通信を制御する。チャネル１０４、１０６、．．．１０８の１つ又は複数は、データ転送コマンドを制御ユニット１０２に送る（参照番号１９０２に示されるように）。これに応答して、チャネル１０４、１０６、．．．１０８は、制御ユニット１０２への後のデータ転送に用いるためにある数のバッファ・クレジットを制御ユニット１０２から定期的に受け取る（参照番号１９０４により示されるように）。
【０１２３】
図２０は、特定の実施形態による、制御ユニット１０２と通信する間、転送準備動作２００２及びリトライ動作２００４を実行し、そこで、チャネル１０４．．．．１０８は、ある期間中の転送準備動作の数及びリトライ動作の数の制御ユニット１０２による分析に基づいて、制御ユニット１０２からある数のバッファ・クレジット２００６．．．２００８を受信する、チャネル１０４．．．１０８のブロック図２０００を示す。提供すべきバッファ・クレジットの数を決定するために制御ユニット１０２により行われる分析は、図１〜図１７において先に説明された。
【０１２４】
制御ユニット１０２は、図１０の参照番号１００６及び図１２の参照番号１２０２により先に示されるような、始動段階及び始動後段階において異なり得る監視期間２０１０を含む。監視期間２０１０の間、制御ユニット１０２は、バッファ・クレジットの数を決定し、チャネル１０４．．．１０８の各々に示すために、転送準備動作及びリトライ動作を監視する。
【０１２５】
図２１は、特定の実施形態による、１つ又は複数のホスト１１０．．．１８０２内に含まれる複数のチャネル１０４．．．１０８、１８０４の１つ又は複数により実行される動作を示す、第１０のフローチャート２１００を示す。図２１に示される動作は、ホスト計算デバイス・アプリケーション１８０６．．．１８０８及び／又はチャネル１０４．．．１０８、１８０４を介して、１つ又は複数のホスト１１０．．．１８０２において実行することができる。
【０１２６】
制御は、ホスト計算デバイス１１０のチャネル（例えば、チャネル１０４）が、データ転送コマンドを、ストレージ・コントローラ１０１内に含まれる制御ユニット１０２に送る、ブロック２１０２で開始する。
【０１２７】
制御はブロック２１０４に進み、そこで、ホスト計算デバイス１１０のチャネル１０４は、制御ユニット１０２との通信のためにある数のバッファ・クレジット２００６を制御ユニット１０２から受信し、受信するバッファ・クレジット２００６の数は、チャネル１０４を含む複数のチャネル１０４．．．１０８、１８０４と通信する間、監視期間２０１０中、制御ユニット１０２が、転送準備動作２００２の数及びリトライ動作２００４の数を監視することに基づく。特定の実施形態において、複数のチャネル１０４．．．１０８、１８０４の各々は、同一の数のバッファ・クレジットを制御ユニット１０２から受信する。
【０１２８】
ブロック２１０４から、制御はブロック２１０６、２１０８及び２１１０に並行して進むことができる。ブロック２１０６において、制御ユニット１０２が、監視期間中、転送準備動作の使用はあるが、リトライ動作の使用はないと判断すること、及び、制御ユニット１０２が、転送準備動作の数が転送準備閾値１２６を上回ると判断することに応答して、チャネル１０４は、増加した数のバッファ・クレジットを受信する。
【０１２９】
ブロック２１０８において、制御ユニット１０２が、監視期間中、リトライ動作の使用はあるが、転送準備動作の使用はないと判断すること、及び、制御ユニット１０２が、リトライ動作の数はリトライ低閾値１２８を上回ると判断することに応答して、チャネル１０４は、減少した数のバッファ・クレジットを受信する。
【０１３０】
ブロック２１１０において、制御ユニット１０２が、監視期間中、転送準備動作及びリトライ動作の両方の使用があると判断すること、及び、制御ユニット１０２が、リトライ動作の数はリトライ高閾値１３０より大きいと判断することに応答して、チャネル１０４は、減少した数のバッファ・クレジットを受信する。
【０１３１】
ブロック２１０６、２１０８、２１１０から、チャネル１０４（又は、複数のチャネル１０４．．．１０８、１８０４の各々）が増加した数又は減少した数のバッファ・クレジットを受信した後、チャネルは、受信したバッファ・クレジットの数を格納し（参照番号２１１２により示されるように）、制御は、制御ユニット１０２へコマンドをさらに送信するために、チャネル１０４．．．１０８、１８０４からブロック２１０２へ進む。
【０１３２】
従って、図２１は、チャネル１０４．．．１０８、１８０４が制御ユニット１０２から受信する受信したバッファ・クレジットの数に基づいて、チャネル１０４．．．１０８、１８０４がデータを制御ユニット１０２に通信する、特定の実施形態を示す。
【０１３３】
図２２は、特定の実施形態による、制御ユニット１０２との通信の始動段階中、１つ又は複数のホスト１１０．．．１８０２内に含まれる複数のチャネル１０４．．．１０８、１８０４の１つ又は複数により実行される動作を示す、第１１のフローチャートを示す。図２２に示される動作は、ホスト計算デバイス・アプリケーション１８０６．．．１８０８及び／又はチャネル１０４．．．１０８、１８０４を介して、１つ又は複数のホスト１１０．．．１８０２において実施することができる。
【０１３４】
制御は、複数のチャネル１０４．．．１０８、１８０４が制御ユニット１０２にログオンして始動段階を開始する、ブロック２２０２で開始する
【０１３５】
制御はブロック２２０４に進み、そこで、複数のチャネル１０４．．．１０８、１８０４の各々は、複数のチャネル１０４．．．１０８、１８０４と制御ユニット１０２との間の通信の始動段階の開始時に、ある数のバッファ・クレジット受信し、受信したバッファ・クレジットの数は、データの転送に使用されるとき、転送準備動作を発生させるが、リトライ動作を発生させない。
【０１３６】
制御はブロック２２０６に進み、そこで、複数のチャネル１０４．．．１０８、１８０４の各々は、始動段階の開始から所定の時間（例えば、５分）内に、あらゆる転送準備動作を排除する又はリトライ動作を発生させるのに十分に大きい増加した数のバッファ・クレジットを繰り返し受信する。
【０１３７】
従って、図１８〜図２２は、少なくとも、ホスト計算デバイス内に含まれる１つ又は複数のチャネルにおいて実行される動作を示す。動作は、制御ユニットからの受信したバッファ・クレジットの表示に基づいて、データを制御ユニットに転送することを含む。
【０１３８】
実施例
第１の組の実施形態の第１の実施形態において、制御ユニットは、複数のチャネルと通信する間、監視期間中、転送準備動作の数及びリトライ動作の数を監視する。監視に基づいて、複数のチャネルと通信するためにバッファ・クレジットの数を調整する。
【０１３９】
第１の組の実施形態の第２の実施形態において、第１の実施形態の主題は、所定の動作範囲内に書き込み動作の数に対して転送準備動作及びリトライ動作の数を定めるようにバッファ・クレジットの数の調整を行うことを含むことができる。その結果、システムは、多すぎるリトライ又は転送準備の実行を回避する。
【０１４０】
第１の組の実施形態の第３の実施形態において、第１の実施形態又は第２の実施形態の主題は、調整された転送準備動作の数は、転送準備動作の総数から、リトライされるように要求される動作の数を減算することによって、バッファ・クレジットの数を調整するように決定されることを含むことができる。その結果、リトライの結果発生した転送準備動作が、明らかになる。
【０１４１】
第１の組の実施形態の第４の実施形態において、第１の実施形態の主題は、監視期間中、転送準備動作の使用があるが、リトライ動作の使用はないと判断すること、及び、転送準備動作の数は転送準備閾値を上回ると判断することに応答して、バッファ・クレジットの数を増加させることを含むことができる。転送準備動作の数が転送準備閾値を上回らないと判断することに応答して、制御ユニットは、複数のチャネルと通信する間、付加的な監視期間中、転送準備動作の数及びリトライ動作の数を監視し続ける。
【０１４２】
第１の組の実施形態の第５の実施形態において、第１の実施形態の主題は、監視期間中、リトライ動作の使用はあるが、転送準備動作の使用はないと判断すること、及び、リトライ動作の数がリトライ低閾値を上回ると判断することに応答して、バッファ・クレジットの数を減少させることを含むことができる。リトライ動作の数がリトライ低閾値を上回らないと判断することに応答して、制御ユニットは、複数のチャネルと通信する間、付加的な監視期間中、転送準備動作の数及びリトライ動作の数を監視し続ける。
【０１４３】
第１の組の実施形態の第６の実施形態において、第１の実施形態の主題は、監視期間中、転送準備動作及びリトライ動作の両方の使用があると判断すること、及び、リトライ動作の数がリトライ高閾値を上回ると判断することに応答して、バッファ・クレジットの数を減少させる。
【０１４４】
第１の組の実施形態の第７の実施形態において、第６の実施形態の主題は、リトライ動作の数がリトライ高閾値を上回らないと判断することに応答して、制御ユニットは、複数のチャネルと通信する間、付加的な監視期間中、転送準備動作の数及びリトライ動作の数を監視し続けることを含むことができる。
【０１４５】
第１の組の実施形態の第８の実施形態において、第１の実施形態の主題は、監視期間中、転送準備動作の使用があるが、リトライ動作の使用はないと判断すること、及び、転送準備動作の数が転送準備閾値を上回ると判断することに応答して、バッファ・クレジットの数を増加させることを含むことができる。付加的に、監視期間中、リトライ動作の使用はあるが、転送準備動作の使用はないと判断すること、及び、リトライ動作の数がリトライ低閾値を上回ると判断することに応答して、バッファ・クレジットの数を減少させる。さらに、監視期間中、転送準備動作及びリトライ動作の両方の使用があると判断すること、及び、リトライ動作の数がリトライ高閾値を上回ると判断することに応答して、バッファ・クレジットの数を減少させる
【０１４６】
第１の組の実施形態の第９の実施形態において、ストレージ・コントローラは、１つ又は複数のホストと通信し、かつ、メモリと、メモリに結合されたプロセッサとを含み、プロセッサは動作を実行し、この動作は、ストレージ・コントローラの制御ユニットにより、１つ又は複数のホストの複数のチャネルとの通信する間、監視期間中、転送準備動作の数及びリトライ動作の数を監視することと、監視に基づいて、１つ又は複数のホストの複数のチャネルと通信するために、ある数のバッファ・クレジットを調整することとを含む。
【０１４７】
第２の組の実施形態の第１の実施形態において、制御ユニットは、１つ又は複数のチャネルと制御ユニットとの間の通信の始動段階の開始に応答して、ある数のバッファ・クレジットを１つ又は複数のチャネルに提供し、提供されるバッファ・クレジットの数は、データの転送に用いられるとき、転送準備動作を発生させるが、リトライ動作を発生させない。制御ユニットは、始動段階の開始から所定の時間内に、あらゆる転送準備動作を排除する又はリトライ動作を発生させるのに十分に大きい量だけバッファ・クレジットの数を繰り返し増加させる。その結果、所定の時間内に最適なバッファ・クレジットの数に達することが可能であり、例えば通信の始動段階の開始から５分で最適なバッファ・クレジットの数に達することができる。
【０１４８】
第２の組の実施形態の第２の実施形態において、第１の実施形態の主題は、１つ又は複数のチャネルが制御ユニットにログオンしたとき、始動段階の開始がもたらされることを含むことができる。
【０１４９】
第２の組の実施形態の第３の実施形態において、第１の実施形態の主題は、そのバッファ・クレジットの数を提供した後、制御ユニットは、ある期間通信を監視し、リトライ動作の数と転送準備の数を決定することを含むことができる。その結果、制御ユニットは、システムが入力／出力（Ｉ／Ｏ）動作をどのように効率的に行っているかを判断することができる。
【０１５０】
第２の組の実施形態の第４の実施形態において、第３の実施形態の主題は、監視の後、制御ユニットは、転送準備動作が発生し、リトライ動作が発生しなかったと判断することに応答して、所定の量だけバッファ・クレジットの数を増加させる。
【０１５１】
第２の組の実施形態の第５の実施形態において、第４の実施形態の主題は、監視の後、転送準備動作が排除された又はリトライ動作が発生したと判断することに応答して、始動段階が終了する。その結果、所定の時間内に始動段階が終了し、バッファ・クレジットは、動作の始動後段階のための十分に高い値に設定される。
【０１５２】
第２の組の実施形態の第６の実施形態において、第５の実施形態の主題は、始動段階の終了に応答して、監視のための期間の増大を行って、リトライ動作の数及び転送準備動作の数を決定し、始動後段階においてバッファ・クレジットの数を増加させ、減少させ、又は変化しないままにする。その結果、始動後段階において、監視期間が増大し、バッファ・クレジットは、始動段階におけるよりも頻繁に変更されない。
【０１５３】
第２の組の実施形態の第７の実施形態において、第６の実施形態の主題は、監視のための期間が比較的長い場合、ワークロードにおける良好な読み取りが決定されるが、バッファ・クレジットの調整のための時間が増加し、監視時間が比較的短い所定の時間を下回る場合には、バッファ・クレジットの変動するスラッシングが頻繁に発生し、バッファ・クレジットの頻繁な更新を１つ又は複数のチャネルに送らなければならない。
【０１５４】
第２の組の実施形態の第８の実施形態において、第３の実施形態の主題は、各々の監視の間の待機時間は、イン・フライト状態の入力／出力（Ｉ／Ｏ）動作が完了するのを可能にするのに適切であることを含むことができる。
【０１５５】
第２の組の実施形態の第９の実施形態において、ストレージ・コントローラは、１つ又は複数のホストと通信し、かつ、メモリと、メモリに結合されたプロセッサとを含み、プロセッサは動作を実行し、この動作は、ストレージ・コントローラの制御ユニットにより、１つ又は複数のチャネルと制御ユニットとの間の通信の始動段階の開始に応答して、ある数のバッファ・クレジットを１つ又は複数のチャネルに提供することであって、提供されるバッファ・クレジットの数は、データの転送に用いられるとき、転送準備動作を発生させるが、リトライ動作は発生させない、提供することと、ストレージ・コントローラの制御ユニットにより、始動段階の開始から所定の時間内に、あらゆる転送準備動作を排除する又はリトライ動作を発生させるのに十分に大きい量だけバッファ・クレジットの数を繰り返し増加させることとを含む。
【０１５６】
第３の組の実施形態の第１の実施形態において、ホスト計算デバイスのチャネルは、データ転送コマンドを、ストレージ・コントローラ内に含まれる制御ユニットに送る。ホスト計算デバイスのチャネルは、制御ユニットとの通信のために、制御ユニットからある数のバッファ・クレジットを受信し、受信するバッファ・クレジットの数は、制御ユニットが、チャネルを含む複数のチャネルと通信する間、監視期間中、転送準備動作の数とリトライ動作の数を監視することに基づく。
【０１５７】
第３の組の実施形態の第２の実施形態において、第１の実施形態の主題は、複数のチャネルの各々は、制御ユニットから同一の数のバッファ・クレジットを受信することを含むことができる。
【０１５８】
第３の組の実施形態の第３の実施形態において、第１又は第２の実施形態の主題は、制御ユニットが、監視期間中、転送準備動作の使用はあるが、リトライ動作の使用はないと判断すること、及び、制御ユニットが、転送準備動作の数が転送準備閾値を上回ると判断することに応答して、チャネルが増加した数のバッファ・クレジットを受信することを含むことができる。
【０１５９】
第３の組の実施形態の第４の実施形態において、第１、第２又は第３の実施形態の主題は、監視期間中、リトライ動作の使用はあるが、転送準備動作の使用はないと判断すること、及び、制御ユニットが、リトライ動作の数はリトライ低閾値を上回ると判断することに応答して、チャネルが減少した数のバッファ・クレジットを受信することを含むことができる。
【０１６０】
第３の組の実施形態の第５の実施形態において、第１、第２、第３又は第４の実施形態の主題は、制御ユニットが、監視期間中、転送準備動作及びリトライ動作の両方の使用があると判断すること、及び、制御ユニットが、リトライ動作の数はリトライ高閾値を上回ると判断することに応答して、チャネルが減少した数のバッファ・クレジットを受信することを含むことができる。
【０１６１】
第３の組の実施形態の第６の実施形態において、第１、第２、第３、第４又は第５の実施形態の主題は、複数のチャネルの各々は、複数のチャネルと制御ユニットとの間の通信の始動段階の開始時に、ある数のバッファ・クレジットを受信し、受信したバッファ・クレジットの数は、データの転送に用いられるとき、転送準備動作を発生させるが、リトライ動作を発生させないことを含むことができる。複数のチャネルの各々は、リトライ動作を始動段階の開始から所定の時間（例えば、５分）内に、あらゆる転送準備動作を排除する又はリトライ動作を発生させるのに十分に大きい増加した数のバッファ・クレジットを繰り返し受信する。
【０１６２】
第３の組の実施形態の第７の実施形態において、第１、第２、第３、第４、第５又は第６の実施形態の主題は、複数のチャネルが制御ユニットにログオンしたとき、始動段階の開始がもたらされることを含むことができる。
【０１６３】
第３の組の実施形態の第８の実施形態において、ホスト計算デバイスは、ストレージ・コントローラと通信し、かつ、メモリと、メモリに結合されたプロセッサとを含み、プロセッサは動作を実行し、この動作は、ホスト計算デバイスのチャネルにより、データ転送コマンドを、ストレージ・コントローラ内に含まれる制御ユニットに送ることと、ホスト計算デバイスのチャネルにより、制御ユニットとの通信のために、制御ユニットからある数のバッファ・クレジットを受信することとを含み、受信したバッファ・クレジットの数は、チャネルを含む複数のチャネルと通信する間、監視期間中、制御ユニットが、転送準備動作の数及びリトライ動作の数を監視することに基づく。
【０１６４】
特定の付加的な実施形態
特定の付加的な実施形態において、制御ユニットは、チャネルによりどれだけのデータが伝送されるか、及び、制御ユニットがファイバ・チャネル通信におけるシーケンス・イニシアチブを受信するときに付加的な転送準備が必要とされるかどうかを判断する。調整の間、転送準備を使用するために複数の動作を必要とする少なすぎるクレジット（すなわち、バッファ・クレジット）と複数の動作をリトライしなければならない多すぎるクレジットとの間を行き来するのを回避するために、注意を払う必要がある。
【０１６５】
実施形態は、以下の機構を用いることができる。
（ａ）制御ユニットは、利用可能なバッファを有していないために動作をリトライしなければならない場合、多すぎるクレジットを放出したと判断することができる。
（ｂ）制御ユニットは、該制御ユニットによりリトライが要求されるときに転送準備を必要とする動作を受け取った場合、チャネルが不十分なクレジットを有すると判断することができる。
（ｃ）制御ユニットは、リトライを必要とするいずれの動作も又は転送準備を必要とする動作も認めない場合、チャネルが理想的なクレジットを有すると判断することができる。
（ｄ）ポートに対してバッファ不足が存在するとき、データが削除され、リトライが発生することがある。リトライされる動作は、長距離でデータ・レート・ドループ（data rate droop）が発生すること、バッファが利用可能になるまでチャネル内にデータを保持することに起因して、本質的にリンク・データ速度を遅くすることがある転送準備を用いて実行することができ、転送準備を受信する。このことは、リトライの数を減らし、安定した動作をもたらし得る。
（ｅ）制御ユニットにおけるデータの削除及びリトライの実行は、制御ユニットのリソースを消費しないので、制御ユニットのポートに損害を与えない。そのことは、再送信のためのリンク速度に影響を及ぼす（多くとも１回の再伝送が行われ得るので、３０％のリトライは、３０％多い利用可能な帯域幅の使用をもたらす。付加的な帯域幅が利用可能な場合、それは問題ではないが、高価な長距離の複製リンクにおいてその帯域幅は高価である）。リトライはまた、データの再伝送のためのメモリ帯域幅を消費するという点で、送信者にも影響を及ぼす。
（ｆ）バッファ不足が存在するとき、リトライされる動作は、利用可能なバッファがゼロであるときにデータが受信されるものである。統計的に、このことは、リトライが発生する全てのチャネルにおいて均一なリトライの分布をもたらすことができる。従って、リトライが発生した場合、特定の実施形態においては、そのチャネル上でリトライが発生したときに単一のチャネルについてのクレジットを減少させるのではなく、全てのチャネルについてのクレジットを同時に減少させることが望ましい。
（ｇ）複数のバッファを消費する大容量の転送は、単一のバッファ動作よりもリトライになりやすいが、データ転送時間と処理時間との比に起因して、より小さい動作に対する応答時間への影響はより大きくなる。
（ｈ）必要としない又は使用しない多すぎるクレジットをチャネルに提供しても、システムにとってあまり問題を引き起こさない。
（ｉ）少なすぎるクレジットをチャネルに提供することは、転送準備の使用をもたらすことがある。制御ユニットにおいて利用可能な十分なバッファがある場合、転送準備の使用は機会損失を招く。
（ｊ）制御ユニットにおいてバッファ不足があるとき、制御ユニットは、いずれにしても、リンク速度に追いつくことができないので、チャネルにおける少なすぎるクレジットに起因する転送準備の使用は望ましい。次に、バッファが利用可能になるまで、データをチャネル内に保持し、ストレージ・エリア・ネットワークにおけるコンジェスチョンを減らし、十分に活用することができない他のリンクを使用するために、ホストにおける経路選択のための機会を提供する。
【０１６６】
その結果、特定の実施形態において、クレジットは、ポートごとに制御ユニット内に保持される。制御ユニット・クレジット機構のための基本的スキームは、ポートにログインしたチャネルが付加的なクレジットを必要とする場合、クレジットをインクリメントし、チャネルがコマンドのリトライを開始した場合、クレジットをデクリメントすることである。上述のように、カウントを過剰にインクリメント及びデクリメントしないよう、注意を払う必要がある。実施形態は、Ｉ／Ｏのバーストを考慮に入れる。制御ユニットは、各チャネルについての状況を送るためにトランスポート・モード動作を有する必要があり、現行の動作はイン・フライト状態にあるので、クレジットのいかなる変更も、効果を生じるのにしばらく時間がかかり得る。
【０１６７】
初めに、チャネルは、存在する利用可能なバッファよりも少ないクレジット（１６個）を有し得る。チャネルは、それを第１のＩ／Ｏに対して使用し、次に、残りに対する転送準備の要求を開始する。リトライをもたらすべきではない。可能であれば、リトライを発生させずに、転送準備が必要とされない点に達すること、及び、その点に比較的迅速に達することが望ましい。いずれのリトライも見出すことなく、転送準備が使用されるときに機会損失があり、リトライが転送準備を使用し始めるとデータ速度が自動的に遅くなるので、リトライのために転送準備を用いる動作がありすぎて失敗するが、リトライが発生しない位置まで後退する方がよい。従って、バッファ・クレジットは、これが減少されるよりも速いペースで増加させることができる。
【０１６８】
ワークロードの始動から５分以内にリトライ点（すなわち、それ以上の転送準備がない）に達するように目的が設定される。必要とされるリトライ点から、更に３〜５分以内に安定点に達するはずである。クレジットは、ポート毎に保持され、ポートにログインされる全ての遠隔ポートに、同じ量のクレジットが与えられる。各々の遠隔ポートは、そのチャネルについて、Ｉ／Ｏ完了として更新され、通信される最後のクレジットは、所望のクレジットとは異なる。
【０１６９】
特定の付加的な実施形態において、任意のポートについてのクレジットは、最大値を超えてインクリメントされず、最小値（例えば、１６）より低くもデクリメントされない。最大値は、制御ユニット・ポートが利用可能なバッファ空間、ログインされる予想チャネル数、及び予想されるワークロードのタイプに基づいて選択される。
【０１７０】
特定の実施形態において、ソフトウェアにフィーチャ・ビットを提供し、制御ユニットにおいて、これらの実施形態において説明されるフィーチャがイネーブルにされることを検出する。これは、これらの実施形態において説明されるフィーチャが利用可能であるとき、ソフトウェアにより使用されて、大容量の書き込みのためにＦＩＣＯＮの使用からｚＨＰＦの使用に切り換える。
【０１７１】
クラウド・コンピューティング環境
クラウド・コンピューティング環境は、最小限の管理努力又はサービス・プロバイダとの対話で迅速にプロビジョニング及び解放することができる構成変更可能なコンピューティング・リソース（例えば、ネットワーク、サーバ、ストレージ、アプリケーション、及びサービス）の共有プールに対するオンデマンドの便利なネットワーク・アクセスを可能にするためのモデルである。
【０１７２】
ここで図２３を参照すると、例証となるクラウド・コンピューティング環境５０が示される。示されるように、クラウド・コンピューティング環境５０は、例えば、携帯情報端末（ＰＤＡ）又は携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、及び／又は自動車コンピュータ・システム５４Ｎなどの、クラウド・コンシューマにより使用されるローカル・コンピューティング・デバイスが通信できる１つ又は複数のクラウド・コンピューティング・ノード１０を含む。ノード１０は、互いに通信することができる。これらのノードは、上述したようなプライベート・クラウド、コミュニティ・クラウド、パブリック・クラウド、又はハイブリッド・クラウド、又はそれらの組み合わせのような１つ又は複数のネットワークに物理的又は仮想的にグループ化することができる（図示せず）。これにより、クラウド・コンピューティング環境５０は、クラウド・コンシューマがローカル・コンピューティング・デバイス上にリソースを保持する必要のない、ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  ａｓ  ｓｅｒｖｉｃｅ、ｐｌａｔｆｏｒｍ  ａｓ  ｓｅｒｖｉｃｅ、及び／又はｓｏｆｔｗａｒｅ  ａｓ  ｓｅｒｖｉｃｅを提供することが可能になる。図２３に示されるコンピューティング・デバイス５４Ａ〜Ｎのタイプは単なる例証であるように意図されていること、並びに、コンピューティング・ノード１０及びクラウド・コンピューティング環境５０は、任意のタイプのネットワーク及び／又はネットワーク・アドレス指定可能接続によって（例えば、ウェブ・ブラウザを用いて）任意のタイプのコンピュータ化されたデバイスと通信できることを理解されたい。
【０１７３】
ここで図２４を参照すると、クラウド・コンピューティング環境５０（図２３）によって提供される機能抽象化層の組が示される。図２４に示されるコンポーネント、層、及び機能は単なる例証であるように意図されており、本発明の実施形態はそれらに限定されないことを予め理解されたい。
【０１７４】
ハードウェア及びソフトウェア層６０は、ハードウェア及びソフトウェアのコンポーネントを含む。ハードウェア・コンポーネントの例として、ＩＢＭ  ｚＳｅｒｉｅｓ（登録商標）システムを一例とするメインフレームと、ＩＢＭ  ｐＳｅｒｉｅｓ（登録商標）システムを一例とするＲＩＳＣ（縮小命令セット・コンピュータ）アーキテクチャ・ベースのサーバと、ＩＢＭ  ｘＳｅｒｉｅｓ（登録商標）システムと、ＩＢＭ  ＢｌａｄｅＣｅｎｔｅｒ（登録商標）システムと、ストレージ・デバイスと、ネットワーク及びネットワーク・コンポーネントと、が挙げられる。ソフトウェア・コンポーネントの例として、ＩＢＭ  ＷｅｂＳｐｈｅｒｅ（登録商標）アプリケーション・サーバ・ソフトウェアを一例とするネットワーク・アプリケーション・サーバ・ソフトウェアと、ＩＢＭ  ＤＢ２（登録商標）データベース・ソフトウェアを一例とするデータベース・ソフトウェアとが挙げられる。
【０１７５】
仮想化層６２は、仮想エンティティの以下の例、即ち、仮想サーバ、仮想ストレージ、仮想プライベート・ネットワークを含む仮想ネットワーク、仮想アプリケーション及びオペレーティング・システム、並びに仮想クライアントを提供することができる、抽象化層を提供する。
【０１７６】
一例においては、管理層６４は、以下で説明される機能を提供することができる。リソース・プロビジョニングは、クラウド・コンピューティング環境内でタスクを行うのに利用されるコンピューティング・リソース及び他のリソースの動的な調達を提供する。計量及び価格設定は、クラウド・コンピューティング環境内でリソースが用いられる際のコスト追跡と、これらのリソースの消費にかかる課金又は請求とを提供する。１つの例においては、これらのリソースは、アプリケーション・ソフトウェア・ライセンスを含むことができる。セキュリティは、クラウド・コンシューマ及びタスクについての識別情報の検証と、データ及び他のリソースの保護とを提供する。ユーザ・ポータルは、コンシューマ及びシステム管理者のために、クラウド・コンピューティング環境へのアクセスを提供する。サービス・レベル管理は、必要なサービス・レベルが満たされるように、クラウド・コンピューティング・リソースの割り当て及び管理を提供する。サービス・レベル・アグリーメント（ＳＬＡ）の計画及び履行は、ＳＬＡによって将来の必要性が予測されるクラウド・コンピューティング・リソースの事前配置及び調達を提供する。
【０１７７】
ワークロード層６６は、クラウド・コンピューティング環境を利用することができる機能の例を提供する。この層から提供することができるワークロード及び機能の例には、マッピング及びナビゲーション、ソフトウェア開発及びライフサイクル管理、仮想教室教育配信、データ分析処理、トランザクション処理、及び図１〜図２３に示されるようなバッファ・クレジット６８（例えば、制御ユニットユニット・アプリケーション１１４における）の調整又はバッファ・クレジット６８の受領が含まれる。
【０１７８】
付加的な実施形態の詳細
説明した動作は、ソフトウェア、ファームウェア、ハードウェア、又はこれらの任意の組み合わせを作成するための標準的プログラミング及び／又はエンジニアリング技法を用いて、方法、装置又はコンピュータ・プログラム製品として実装することができる。従って、実施形態の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、又はソフトウェア態様とハードウェア態様とを組み合せた実施形態の形をとることができ、これらは、本明細書において全て一般的に「回路」、「モジュール」又は「システム」と呼ぶことができる。さらに、実施形態の態様は、コンピュータ・プログラム製品の形をとることができる。コンピュータ・プログラム製品は、プロセッサに本実施形態の態様を実施させるためのコンピュータ可読プログラム命令をその上に有するコンピュータ可読ストレージ媒体（単数又は複数）を含むことができる。
【０１７９】
コンピュータ可読ストレージ媒体は、命令実行デバイスにより使用される命令を保持及び格納することができる有形デバイスとすることができる。コンピュータ可読ストレージ媒体は、例えば、これらに限定されるものではないが、電子記憶装置、磁気記憶装置、光学記憶装置、電磁気記憶装置、半導体記憶装置、又は上記のいずれかの適切な組み合わせとすることができる。コンピュータ可読ストレージ媒体のより具体的な例の非網羅的なリストとして、以下のもの：即ち、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭ又はフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ポータブル・コンパクト・ディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、メモリ・スティック、フロッピー・ディスク、パンチカード若しくは命令がそこに記録された溝内の隆起構造のような機械的にエンコードされたデバイス、及び上記のいずれかの適切な組み合わせが挙げられる。本明細書で使用される場合、コンピュータ可読ストレージ媒体は、電波、又は他の自由に伝搬する電磁波、導波管若しくは他の伝送媒体を通じて伝搬する電磁波（例えば、光ファイバ・ケーブルを通る光パルス）、又はワイヤを通って送られる電気信号などの、一時的信号自体として解釈されない。
【０１８０】
本明細書で説明されるコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体からそれぞれのコンピューティング／処理デバイスに、又は、例えばインターネット、ローカル・エリア・ネットワーク、広域ネットワーク、及び／又は無線ネットワークなどのネットワークを介して外部コンピュータ又は外部ストレージ・デバイスにダウンロードすることができる。ネットワークは、銅伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、及び／又はエッジ・サーバを含むことができる。各コンピューティング／処理デバイスにおけるネットワーク・アダプタ・カード又はネットワーク・インターフェースは、ネットワークからコンピュータ可読プログラム命令を受け取り、コンピュータ可読プログラム命令を転送して、それぞれのコンピューティング／処理デバイス内のコンピュータ可読ストレージ媒体内に格納する。
【０１８１】
本実施形態の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、ファームウェア命令、状態設定データ、又は、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語、又は、「Ｃ」プログラミング言語若しくは類似のプログラミング言語などの通常の手続き型プログラミング言語を含む１つ又は複数のプログラミング言語の任意の組み合わせで記述することができる。コンピュータ可読プログラム命令は、完全にユーザのコンピュータ上で実行される場合もあり、一部がユーザのコンピュータ上で、独立型ソフトウェア・パッケージとして実行される場合もあり、一部がユーザのコンピュータ上で実行され、一部が遠隔コンピュータ上で実行される場合もあり、又は完全に遠隔コンピュータ若しくはサーバ上で実行される場合もある。最後のシナリオにおいて、遠隔コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）若しくは広域ネットワーク（ＷＡＮ）を含むいずれかのタイプのネットワークを通じてユーザのコンピュータに接続される場合もあり、又は外部コンピュータへの接続がなされる場合もある（例えば、インターネット・サービス・プロバイダを用いたインターネットを通じて）。幾つかの実施形態において、例えば、プログラム可能論理回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、又はプログラム可能論理アレイ（ＰＬＡ）を含む電子回路は、コンピュータ可読プログラム命令の状態情報を用いて、電子回路を個人化することによりコンピュータ可読プログラム命令を実行し、本実施形態の態様を実施することができる。
【０１８２】
本実施形態の態様は、本発明の実施形態による方法、装置（システム）及びコンピュータ・プログラム製品のフローチャート図及び／又はブロック図を参照して説明される。フローチャート図及び／又はブロック図の各ブロック、並びにフローチャート図及び／又はブロック図内のブロックの組み合わせは、コンピュータ可読プログラム命令によって実装できることが理解されるであろう。
【０１８３】
これらのコンピュータ可読プログラム命令を、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置のプロセッサに与えてマシンを製造し、それにより、コンピュータ又は他のプログラム可能データ処理装置のプロセッサによって実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロック内で指定された機能／動作を実施するための手段を作り出すようにすることができる。これらのコンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、又は他のデバイスを特定の方式で機能させるように指示することができるコンピュータ可読媒体内に格納し、それにより、そのコンピュータ可読媒体内に格納された命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実施する命令を含む製品を製造するようにすることもできる。
【０１８４】
コンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、又は他のデバイス上にロードして、一連の動作ステップをコンピュータ、他のプログラム可能データ処理装置、又は他のデバイス上で行わせてコンピュータ実施のプロセスを生成し、それにより、コンピュータ又は他のプログラム可能装置上で実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実行するためのプロセスを提供するようにすることもできる。
【０１８５】
図面内のフローチャート及びブロック図は、本発明の種々の実施形態による、システム、方法、及びコンピュータ・プログラム製品の可能な実装の、アーキテクチャ、機能及び動作を示す。この点に関して、フローチャート内の各ブロックは、指定された論理機能を実装するための１つ又は複数の実行可能命令を含む、モジュール、セグメント、又はコードの一部を表すことができる。幾つかの代替的な実装において、ブロック内に示される機能は、図に示される順序とは異なる順序で生じることがある。例えば、連続して示される２つのブロックは、関与する機能に応じて、実際には実質的に同時に実行されることもあり、又はこれらのブロックはときとして逆順で実行されることもある。ブロック図及び／又はフローチャート図の各ブロック、及びブロック図及び／又はフローチャート図内のブロックの組み合わせは、指定された機能又は動作を実行する、又は専用のハードウェアとコンピュータ命令との組み合わせを実行する、専用ハードウェア・ベースのシステムによって実装できることにも留意されたい。
【０１８６】
図２５は、特定の実施形態による、ホスト１１０、１８０２のストレージ・コントローラ若しくはストレージ・デバイス１０１、制御ユニット１０２、チャネル１０４、１０６、．．．１０８、１８０４デバイス、又は他の計算デバイス内に含ませることができる特定の要素を示すブロック図を示す。システム２５００は、特定の実施形態において、少なくとも１つのプロセッサ２５０４を含むことができる回路２５０２を含むことができる。システム２５００はまた、メモリ２５０６（例えば、揮発性メモリ・デバイス）及びストレージ２５０８を含むこともできる。ストレージ２５０８は、不揮発性メモリ・デバイス（例えば、ＥＥＰＲＯＭ、ＲＯＭ、ＰＲＯＭ、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭ、フラッシュ、ファームウェア、プログラム可能論理理等）、磁気ディスクドライブ、光ディスクドライブ等を含むことができる。ストレージ２５０８は、内部ストレージ・デバイス、アタッチト・ストレージ・デバイス、及び／又はネットワーク・アクセス可能ストレージ・デバイスを含むことができる。システム２５００は、メモリ２５０６内にロードし、プロセッサ２５０４若しくは回路２５０２により実行することができるコード２５１２を含むプログラム論理２５１０を含むことができる。特定の実施形態において、コード２５１２を含むプログラム論理２５１０は、ストレージ２５０８内に格納することができる。特定の他の実施形態において、プログラム論理２５１０は、回路２５０２内に実装することができる。従って、図２５は、プログラム論理２５１０を他の要素とは別に示すが、プログラム論理２５１０は、メモリ２５０６及び／又は回路２５０２内に実装することができる。
【０１８７】
特定の実施形態は、人により、又はコンピュータ可読コードをコンピューティング・システムに統合する自動処理により、コンピューティング命令をデプロイするための方法に向けられ、コードは、コンピューティング・システムと共に、説明される実施形態の動作を実施するようにイネーブルにされる。
【０１８８】
「１つの実施形態」、「実施形態」、「（複数の）実施形態」、「その実施形態」、「（複数の）その実施形態」、「１つ又は複数の実施形態」、「幾つかの実施形態」及び「一実施形態」という用語は、特に明示的に断らない限り、本発明の１つ又は複数の（しかし、全てではない）実施形態を意味する。
【０１８９】
「含んでいる（ｉｎｃｌｕｄｉｎｇ）」、「備えている（ｃｏｍｐｒｉｓｉｎｇ）」、「有している（ｈａｖｉｎｇ）」という用語及びその変形は、特に明示的に断らない限り、「含むが、それらに限定されない」ことを意味する。
【０１９０】
項目の列挙リストは、特に明示的に断らない限り、項目のいずれか又は全てが相互排除的であることを意味しない。
【０１９１】
「１つの（ａ）」、「１つの（ａｎ）」及び「その（ｔｈｅ）」という用語は、特に明示的に断らない限り、「１つ又は複数（ｏｎｅ  ｏｒ  ｍｏｒｅ）」を指す。
【０１９２】
互いに通信するデバイスは、特に明示的に断りのない限り、互いに連続的に通信する必要はない。さらに、互いに通信するデバイスは、直接的に、又は１つ又は複数の中間物を介して間接的に通信することもある。
【０１９３】
互いに通信する幾つかのコンポーネントを用いる１つの実施形態の説明は、全てのこうしたコンポーネントが必要であることを意味するものではない。これに反して、本発明の種々の可能な実施形態を示すために、様々な随意のコンポーネントが説明される。
【０１９４】
さらに、プロセス・ステップ、方法ステップ又はアルゴリズムなどは、順番に説明されていることがあるが、そうしたプロセス、方法及びアルゴリズムは別の順番で動作するように構成することができる。換言すれば、説明され得るステップの何れの順序又は順番も、必ずしも、ステップがその順番で実行されることの必要性を示すものではない。本明細書で説明されるプロセスのステップは、実際には任意の順番で実行することができる。さらに、幾つかのステップは同時に実行することができる。
【０１９５】
本明細書において単一のデバイス又は物品が説明されている場合、単一のデバイス／物品の代わりに１つより多くのデバイス／物品（それらが協働してもしなくとも）を使用できることが容易に明らかになるであろう。同様に、本明細書で１つより多くのデバイス又は物品（それらが協働してもしなくとも）が説明されている場合、１つより多くのデバイス又は物品の代わりに単一のデバイス／物品を使用することができ、又は、示される数のデバイス又はプログラムの代わりに異なる数のデバイス／物品を使用することができることが容易に明らかであろう。デバイスの機能及び／又は特徴は、それら機能／特徴を有するように明示的に説明されていない１つ又は複数の他のデバイスによって代替的に具体化することができる。従って、本発明の他の実施形態は、そのデバイス自体を含む必要はない。
【０１９６】
図に示されている少なくとも特定の動作は、特定のイベントが特定の順番で行われることを示す。代替的な実施形態においては、特定の動作は異なる順番で実行することができ、又は修正若しくは除去することができる。さらに、上述の論理にステップを付け加えて、それでもなお説明される実施形態に適合させることができる。さらに、本明細書で説明される動作は順次に行うことができ、又は特定の動作は並列して処理することができる。さらにまた、動作は単一の処理ユニットにより、又は分散処理ユニットによって実行することができる。
【０１９７】
本発明の種々の実施形態の上記の説明は、例証及び説明のために提示されたものである。これは網羅的であること、又は本発明を開示された通りの形態に限定することを意図したものではない。上記の教示を考慮すれば、多くの修正及び変形が可能となる。本発明の範囲は、この詳細な説明ではなく、添付の特許請求の範囲によって限定されることが意図されている。上記の詳細な説明、実施例及びデータは、本発明の構成の製造及び使用の完全な説明を与える。本発明の範囲から逸脱することなく、本発明の多くの実施形態を作成することができるので、本発明は、添付の特許請求の範囲の中に存在する。
※ＯＢＭ、ＷｅｂＳｐｈｅｒｅ及びＤＢ２は、世界中の多数の管轄区域において登録されているインターナショナル・ビジネス・マシーンズ・コーポレーションの商標である。
【符号の説明】
【０１９８】
１０１：ストレージ・コントローラ又はストレージ・デバイス
１０２：制御ユニット（ターゲット）
１０４、１０６、１０８、１８０４：複数のチャネル
１１０、１８０２：ホスト
１１２：スイッチ
１１４：制御ユニット・アプリケーション
１１６、１１８、．．．１２０：複数のバッファ
１２２、２００６．．．２００８：バッファ・クレジット
１２３：転送準備カウンタ
１２４：リトライカウンタ
１２６：転送準備閾値
１２８：リトライ低閾値
１３０：リトライ高閾値
２５０２：回路
２５０４：プロセッサ
２５０６：メモリ
２５０８：ストレージ
２５１０：プログラム論理
２５１２：コード
【図１】
0006714614.tif 000002
【図２】
0006714614.tif 000003
【図３】
0006714614.tif 000004
【図４】
0006714614.tif 000005
【図５】
0006714614.tif 000006
【図６】
0006714614.tif 000007
【図７】
0006714614.tif 000008
【図８】
0006714614.tif 000009
【図９】
0006714614.tif 000010
【図１０】
0006714614.tif 000011
【図１１】
0006714614.tif 000012
【図１２】
0006714614.tif 000013
【図１３】
0006714614.tif 000014
【図１４】
0006714614.tif 000015
【図１５】
0006714614.tif 000016
【図１６】
0006714614.tif 000017
【図１７】
0006714614.tif 000018
【図１８】
0006714614.tif 000019
【図１９】
0006714614.tif 000020
【図２０】
0006714614.tif 000021
【図２１】
0006714614.tif 000022
【図２２】
0006714614.tif 000023
【図２３】
0006714614.tif 000024
【図２４】
0006714614.tif 000025
【図２５】
0006714614.tif 000026