JP4275504B2 - データ転送方法 - Google Patents

Description

本発明は、ネットワークを介して高信頼かつ高速にデータを転送するためのデータ転送方法と複数の磁気ディスク装置を制御するためのディスク制御装置に関する。

情報通信インフラの高度化に伴い、情報通信システムに求められる処理性能は益々高まってきている。とくに最近では、集積ＬＳＩの微細化が進展した結果、ＬＳＩ間のデータ転送性能が、システム性能を左右する状況となっている。このため、ＩＯシステムの高性能化・多機能化に対する研究が精力的に進められており、転送速度を向上するとともに、多様なトランスポート機能を持った通信プロトコル・エンジンが開発されるようになってきた。

例えば、InfiniBand Architecture Specification Release 1.0aで規定されているInfiniBand転送方式は、送信キュー（ＳＱ）および受信キュー（ＲＱ）で構成されるキューペア（ＱＰ）と、キューペアに積まれたリクエスト処理完了時点で完了ステータスの通知される完了キュー（ＣＱ）とで、アプリケーションプロセスとＩＯシステムとのインターフェースがとられるデータ転送方法となっている。その様子を図4で説明する。

プロセス５１とプロセス５２は、それぞれ２つのキューペアを用いて通信している。プロセス５１は、送信キュー１１と受信キュー２１からなるキューペア４１と送信キュー１２と受信キュー２２からなるキューペア４２を持っている。同様に、プロセス５２は、送信キュー１３と受信キュー２３からなるキューペア４３と送信キュー１４と受信キュー２４からなるキューペア４４を持っている。完了キュー３１には、キューペア４１およびキューペア４２の完了ステータスが格納され、完了キュー３２には、キューペア４３およびキューペア４４の完了ステータスが格納される。

送信キューの各エントリには、転送リクエストがおかれる。この転送リクエストにより転送されるデータの単位を論理レコードと呼ぶ。受信キューの各エントリには、受信バッファへのポインタが格納される。送信キュー１２の転送リクエストは、プロセスバッファ７１内のレコードバッファ８１へのポインタを有し、送信キュー１４の転送リクエストは、プロセスバッファ７２内のレコードバッファ８２へのポインタを有している。同様に、受信キュー２２、２４は、レコードバッファ８１、８２へのポインタが格納されている。

通信を行う２つのキューペア間では、送信キューと受信キュー間で接続が張られる。送信キュー１２は受信キュー２４と、送信キュー１４は受信キュー２２と接続がなされている。このとき、送信キュー１２に積まれた転送リクエストが処理されると、レコードバッファ８１に格納されていた論理レコードが受信キュー２４で指定されているレコードバッファ８２へ転送される。正常な転送が完了した時点で、受信キュー２４からは完了キュー３２に完了ステータスが通知され、送信キュー１２からは完了キュー３１へ完了ステータスが通知される。

これらのキューペアや完了キューの処理は、ホストチャネルアダプタ（ＨＣＡ）とよばれるハードウェアで実行される。その構成例を図５に示した。ＨＣＡは、受信ポート６１３と送信ポート６２３、受信側のリンク層論理６３１、トランスポート層論理６３２、プロセッサ６３３、送信側のリンク層論理６４１、トランスポート層論理６４２、プロセッサ６４３、メモリ６５０、および、接続インターフェース６６０を有している。ＨＣＡとアプリケーションプロセスとの通信は、接続インターフェース、および、メモリを介して行われる。受信側と送信側は、並行して動作することができ、各プロセッサと、リンク層・トランスポート層論理で、高機能プロトコル処理を高速に実行することができるようになっている。

２つのＨＣＡ間で単純転送リクエストが処理される様子を図６で説明する。ＨＣＡ１側のプロセスバッファ７３内のレコードバッファ８３をＨＣＡ２側のプロセスバッファ７４内のレコードバッファ８４に転送する場合を考える。ＨＣＡ１では、レコードバッファ８３を送信に適したサイズに分解し、それぞれ適当なヘッダとエラーチェックコード（ＣＲＣ）を付加してパケット４０１−４０３として転送する。ＨＣＡ２では、受信パケットにエラーがないかＣＲＣで確認し、エラーを検出した場合、ＨＣＡ１にその旨ＮＡＫ（Negative AcKnowledgement）で通知する。ＨＣＡ１では、ＮＡＫが返されたパケットについては再送を行う。ＨＣＡ２では、すべてのパケットが正常に受け取れた時点で、論理レコードの再構築を行い、レコードバッファ８４に格納して、完了キュー３４に完了ステータスを通知するとともに、ＨＣＡ１に受信完了を知らせる。ＨＣＡ１では、ＨＣＡ２の受信完了通知を受けて、完了キュー３３に転送完了ステータスを通知することで、一連の転送リクエスト処理が完了する。

別の例として、２つのＨＣＡ間でのＲＤＭＡ転送リクエストが処理される様子を図７で説明する。ＲＤＭＡ転送では、イニシエータのアプリケーションメモリ空間７５内のＲＤＭＡ転送空間８５をターゲットのアプリケーションメモリ空間７６内のＲＤＭＡ転送空間８６に転送する。ＲＤＭＡ転送では、転送先のアプリケーションメモリ空間内に直接転送を行うので、転送先のメモリアドレス情報を付加する必要がある。それ以外は、単純転送リクエストと同様の動作をする。ＨＣＡ１ではＲＤＭＡ転送空間８５を適当なサイズでパケットに構成し、順次ＨＣＡ２に転送する。ＨＣＡ２では、受信パケットをＲＤＭＡ転送空間８６内の決められた場所に格納し、必要ならパケットの再送処理をして、空間全体の再構築を行う。ＨＣＡ２では、すべてのパケットを正常に受け取った時点で、完了キュー３６に完了ステータスを通知するとともに、ＨＣＡ１に受信完了を知らせる。ＨＣＡ１では、ＨＣＡ２の受信完了通知を受けて、完了キュー３５に転送完了ステータスを通知することで、一連の転送リクエスト処理が完了する。

ここまで説明したデータ転送方法は、転送エラーの無いことを保証するリライアブルデータ転送方法であり、広く一般的に使われている基本的なものである。従来のリライアブルデータ転送方法には、以下の２つの特徴がある。
１． ターゲットでは、転送リクエスト単位である論理レコード全体にエラーの無いことを確認してから完了ステータスを通知する。
２． イニシエータでは、ターゲットからの論理レコード全体の正常転送完了ステータス通知を確認してから次の論理レコードの転送を開始する。

上記特徴について、図２、および、図３を用いて説明する。図２では、ＨＣＡ１側のアプリケーション（ＡＰ）１から転送リクエスト１２１によって論理レコード２２１の転送を開始している。ＨＣＡ２で転送エラーを検出した場合には再送を行う。ＨＣＡ２は、正常に論理レコードの受信を完了した時点で、アプリケーション２の完了キューに完了ステータス３２１を通知する。完了ステータス３２１を受けて、アプリケーション２は、論理レコード２２１を使った処理７２１を開始することができる。論理レコード２２１の正常受信を完了したＨＣＡ２は、受信完了をＨＣＡ１に知らせ、ＨＣＡ１はアプリケーション１の完了キューに転送完了ステータス３６１を通知する。この例で明らかなように、ターゲット側のアプリケーション２は、論理レコード２２１全体の受信が完了してから完了ステータス３２１を受け取る。また、イニシエータ側のアプリケーション１は、論理レコード２２１全体の受信がＨＣＡ２で完了した後、次の論理レコードの転送リクエストを開始することができる。

図３では、ＨＣＡ１側のアプリケーション１から転送リクエスト１３１によってＲＤＭＡ転送を開始している。この場合、ＲＤＭＡ転送空間全体がひとつの論理レコードとなる。ＨＣＡ２では、複数に分割されたパケットを受信しながら、必要に応じて再送要求を行う。すべてのパケット転送（論理レコード全体の転送）が正常に終了した時点で、ＨＣＡ２側のアプリケーション２の完了キューに完了ステータス３３１を通知する。完了ステータス３３１を受けて、アプリケーション２は、転送された論理レコードであるＲＤＭＡ転送空間を使った処理７３１を開始することができる。論理レコードの正常受信を完了したＨＣＡ２は、受信完了をＨＣＡ１に知らせ、ＨＣＡ１はアプリケーション１（の完了キュー）に転送完了ステータス３７１を通知する。

この例でも明らかなように、ターゲット側のアプリケーション２は、論理レコード（ＲＤＭＡ転送空間）全体の受信が完了してから完了ステータス３３１を受け取る。また、イニシエータ側のアプリケーション１は、論理レコード（ＲＤＭＡ転送空間）全体の受信がＨＣＡ２で完了した後、次の論理レコードの転送リクエストを開始することができる。

このように従来のリライアブルデータ転送方法では、転送エラーを回避するための仕組みとして、上記２つの基本的な特徴をもつ必要があった。なお、特開平８−１７９９９９に開示されている従来のリライアブルデータ転送方法のように、エラー発生以前の転送データを保証する方式も知られているが、上記２つの特徴を満たす必要のあることに変わりはない。

特開平８−１７９９９９号公報

InfiniBand Architecture Specification Release 1.0a

従来のリライアブルデータ転送方法は、転送エラーを回避するために上記２つの特徴を利用しているのであるが、そのために、以下の課題をもつ。
まず、「イニシエータがターゲットでの論理レコード全体の正常受信完了を確認する必要がある」という特徴のため、イニシエータからターゲットへの論理レコード転送に要する時間以外に、ターゲットからイニシエータに転送完了を通知するための時間がオーバーヘッドとしてかかってしまう。このオーバヘッド時間は、論理レコードのレコード長が短い時に顕著となり、通信路の効率を著しく低下させる。とくに、ＩＯシステムの高機能化に伴ってターゲットでの処理タスクは増加しており、論理レコードの転送完了ステータス通知に要する時間は増大傾向にある。論理レコードの転送時間は、転送速度の向上にしたがって短縮されているので、ターゲットからの転送完了通知によるオーバーヘッドが相対的に増大して転送効率が悪化しており、その改善が課題となっている。

次に、「ターゲットでは、受信した論理レコード全体にエラーの無いことを確認してから完了ステータスを通知する」という特徴のため、たとえ論理レコードの途中まで正常に受信ができたとしても、それをターゲットのアプリケーションで認識して有効に活用することができず、論理レコード全体の受信が完了するまで、受信論理レコードを利用したアプリケーション処理の開始を遅延させる必要がある。この処理開始までの遅延時間は、論理レコードのレコード長が長いときに顕著となり、アプリケーションの処理効率を低下させる。レコード長が長ければ、それだけ転送エラーの発生率が上昇し、転送エラーによる再送処理が行われると、上記遅延時間はさらに増加し、処理効率は低下する。大きなレコード長の転送や、転送エラーの発生時にも、アプリケーションの処理効率を低下させないことが、別の課題となっている。

本発明の目的は、上記従来技術の欠点を改善し、高い転送効率と高いアプリケーション処理効率を同時に実現するデータ転送方法を提供することにある。より具体的には、ターゲットでの受信完了通知に要する時間とイニシエータへの転送完了通知に要する時間を実効的に削減するデータ転送方法およびかかるデータ転送方法を用いたディスク制御装置を提供することにある。

上記目的を達成するため、本発明では、イニシエータからターゲットへのデータ転送の際、ターゲットで受信されたデータの通信エラーの有無をデータに付加されているエラーチェックコードを用いて確認し、通信エラーの有無をターゲットからイニシエータに転送ステータスとして返送し、転送ステータスによりデータ転送の際に転送エラーの発生が判明した場合、イニシエータからターゲットにデータの再送を行うリライアブル転送において、イニシエータとターゲット間のデータ転送単位である論理レコードの転送プロトコルにおいて、論理レコードを複数まとめて一括転送し、イニシエータでは、一括転送の単位で転送ステータスの確認を行い、イニシエータが発行した転送リクエストにより論理レコードの転送がなされ、ターゲットでは、転送リクエストに対応した完了ステータスを予め定められた一括転送条件に合致した論理レコードについて、その正常受信が完了した時点でターゲット内に存在する完了キューに通知するようにした。

また、ターゲットでは、一括転送の途中で論理レコードの転送エラーをエラーチェックコードにより検出した際、一括転送の終了まで、当該論理レコードおよびそれ以降の論理レコードの受信を無視し、前記完了ステータスの通知を抑制するようにした。

さらに、ターゲットでは、一括転送の途中で論理レコードの転送エラーをエラーチェックコードにより検出した際、一括転送の終了まで、当該論理レコード及び、それ以降の論理レコードのうち一括転送条件フィールドで指定されている論理レコードの受信を無視し、完了ステータスの通知を抑制するようにした。

さらにまた、ターゲットでは転送エラーが検出された最初の論理レコードのＩＤを、一括転送の単位ごとに確認の行われる前記転送ステータスの中に含め、イニシエータでは転送ステータスをもとに、転送エラーの発生した論理レコードから再送を開始するようにした。

また、一括転送の途中で、イニシエータ、もしくは、ターゲットからキャンセルリクエストを発行して、一括転送を中止することが可能であるようにした。

さらに、ホストコンピュータとのインターフェースを有する複数のホストインターフェース部と、磁気ディスク装置とのインターフェースを有する複数のディスクインターフェース部とを有し、前記ホストインターフェース部は、前記ホストコンピュータに対しリード／ライトされるデータを一時的に格納するメモリを有し、前記メモリと前記ホストコンピュータとの間でデータ転送を実行し、前記ディスクインターフェース部は前記磁気ディスク装置に対しリード／ライトされるデータを一時的に格納するキャッシュメモリを有し、前記メモリと前記磁気ディスク装置との間でデータ転送を実行するディスク制御装置において、複数のホストインターフェース部と複数のディスクインターフェース部との間の転送、複数のホストインターフェース部間の転送、あるいは 複数のホストインターフェース部もしくは複数のディスクインターフェース部と前記メモリ部との間の転送に上述のデータ転送方法を適用するようにした。

さらにまた、ホストコンピュータとのインターフェースを有する複数のホストインターフェース部と、磁気ディスク装置とのインターフェースを有する複数のディスクインターフェース部と，複数のメモリ部と、複数のプロセッサー部とを有し、前記ホストインターフェース部は、前記プロッセサ部と連携して前記メモリ部と前記ホストコンピュータとの間でデータ転送を実行し、前記ディスクインターフェース部は、前記プロセッサ部と連携して前記メモリ部と前記磁気ディスク装置との間でデータ転送を実行するディスク制御装置において、 前記複数のホストインターフェース部あるいは前記複数のディスクインターフェース部と前記プロセッサー部間の転送、複数のメモリ部とプロセッサー部間の転送、 複数のメモリ部間の転送、あるいは、複数のプロセッサ部間の転送に上述のデータ転送方法を適用するようにした。

以上説明したように、本発明のデータ転送方法では、一括転送中には、各論理レコードの転送リクエストが連続して処理され、イニシエータは、ターゲットからの個別の論理レコード転送完了ステータスを待たない。そのため、個別の論理レコード転送完了通知に要する時間が不要となり、転送効率を大幅に向上させることが可能となる。

本発明によれば、一括転送条件に合致した正常受信の論理レコードについては、当該論理レコードの受信完了時点で完了ステータスがアプリケーションに通知される。そのため、多数の論理レコードを一括で転送した場合でも、一括転送全体が完了するのを待たずに、個別の論理レコードの受信が完了した時点で、対応するアプリケーションの処理を開始することができ、アプリケーションの処理効率を改善することが可能となる。とくに、一括転送中に受信エラーが発生した場合についても、エラー発生以前に正常受信した論理レコードについては、その受信完了時点で、アプリケーションの実行を開始できる。

本発明によれば、一括転送における一括転送条件をさらに詳細に規定することができ、一括転送中に転送エラーが生じた場合でも、データ依存関係がなく、到着順序で問題を生じる可能性の無い論理レコードについては、受信動作を継続することが可能となる。そのため、アプリケーションの処理効率を高めることができ、再送レコード数を減らすことでより効率のよい転送を実現することができる。

本発明に拠れば、再送の必要な論理レコードについてのみ再送処理を行うことで、再送処理に要する時間を最小限に抑えることができる。したがって、再送レコード数を減らすことでより効率のよい転送を実現することができる。

本発明に拠れば、一括転送の途中で転送エラー発生などにより、その後の一括転送の継続が不要になった場合、当該一括転送を途中で中止することが可能となる。そのため、不要な論理レコードの転送を抑制することで、より効率のよい転送を実現することができる。

また、本発明のディスク制御装置では、ホストコンピュータ部とディスクインターフェース部の転送効率を大幅に改善することができる。特に、ディスク制御装置内ネットワークの転送効率の向上と、ホストインターフェース部、および、ディスクインターフェース部からのＩＯリクエストに対するレスポンス時間の短縮が可能となり、ディスク制御装置の処理性能を高めることができる効果を奏する。

以下、本発明の実施例を図面を用いて詳述する。
《実施例１》
図１及び図８に、本発明の一実施例を示す。本発明のデータ転送方法においては、複数の論理レコードをまとめて一括転送を行う。そのため、図８に示すように、イニシエータの送信キューに複数の転送リクエストが連続して格納される。各転送リクエストには、論理レコードの転送ごとに一意に定まる転送ＩＤと、転送リクエストの動作を規定する転送命令コードと、転送レコードバッファの先頭アドレスおよびそのバッファ長を含んでいる。図８では、転送リクエスト１０１がレコードバッファ８９の単純転送、転送リクエスト１０５がＲＤＭＡ転送領域８７のＲＤＭＡ転送を示しており、これらが一括転送リクエストとして定義されている。

また、図８には、論理レコードの受信完了を通知するために用いられるターゲットの完了キュー３９とそこに格納される(論理レコードの)完了ステータス３００の構成も示してある。完了ステータス３００は、論理レコードの転送ＩＤと対応するステータスＩＤと、その完了ステータスコードが含まれている。

この一括転送リクエストが処理される様子の一例を図１に示した。ここでは、アプリケーション１がＨＣＡ１とＨＣＡ２を介してアプリケーション２に転送リクエスト１０１−１０５を発行している。ＨＣＡ１では、転送リクエスト１０１によって、論理レコード２０１の転送を開始する。ＨＣＡ２では、論理レコード２０１の正常受信完了を確認した後、アプリケーション２の完了キューに対して完了ステータス３０１を通知している。アプリケーション２では、完了ステータス３０１を受けて、論理レコード２０１に対する処理動作７０１を開始することができる。

本発明の高速データ転送方法では、従来方式と異なって、論理レコード１０２の転送を開始するのに、ＨＣＡ２からの論理レコード１０１の転送完了ステータス通知を待たない。ＨＣＡ１では論理レコード１０１の転送が終了した後、ただちに論理レコード１０２の転送を開始する。また、ＨＣＡ２では、受信した論理レコード１０２にエラーが含まれていた場合、従来方式のように論理レコード１０２の再送要求処理を行うのではなく、一括転送完了ステータスに論理レコード１０２の受信エラーを記録した後、次の論理レコード１０３の処理に移る。一旦、転送リクエスト１０５までのすべての一括転送リクエストが処理された時点で、ＨＣＡ２はまとめて、一括転送完了ステータス３５１をＨＣＡ１に返送する。これを受けて、ＨＣＡ1では、ＨＣＡ２で正常受信の完了していない論理レコードの再送を行う。ＨＣＡ２では、再送によって正常に受信できたレコード２１２−２１５については、完了キューへの完了ステータス３１２−３１５の通知を行い、アプリケーション２では対応する処理７１２−７１５を開始する。一括転送完了ステータス３５２によって、すべての一括転送リクエストの正常転送完了ステータスが通知されることで、一連の一括転送が終了する。

本実施例によれば、一括転送中には、各論理レコードの転送リクエストが連続して処理され、イニシエータは、ターゲットからの個別の論理レコード転送完了ステータス通知を待たない。そのため、個別の論理レコード転送完了通知に要する時間が不要となり、転送効率を大幅に向上させることが可能となる。
また、本実施例によれば、一括転送条件に合致した正常受信の論理レコードについては、当該論理レコードの受信完了時点で完了ステータスがアプリケーションに通知される。そのため、多数の論理レコードを一括で転送した場合でも、一括転送全体の完了を待たずに、個別の論理レコード受信の完了した時点で、対応するアプリケーション処理を開始することができ、アプリケーション処理効率を改善することが可能となる。とくに、一括転送中に転送エラーの発生した場合についても、エラー発生以前に正常受信した論理レコードについては、その受信完了時点で、アプリケーションの実行を開始することができる。

《実施例２》
本発明のデータ転送方法では、一括転送の論理レコードを受信する際、一括転送条件に合致したものだけを選択的に受信する。これにより、一括転送内の論理レコード間で依存関係があっても、受信レコードの時系列順序を保証することが可能となる。例えば、ある論理レコードに受信エラーが含まれていた場合、一括転送中のそれ以降の論理レコードを無視してしまう方法を実施することができる。この方法により、すべての一括転送リクエストを連続して処理した後に、まとめて再送処理をおこなう本発明の方式では、受信論理レコードの依存関係に問題を生じることがなく、従来方式のようにイニシエータでターゲットからの転送完了通知を待つ必要がないという利点がある。

《実施例３》
本発明のデータ転送方法で用いられる一括転送条件について、図９を用いてさらに詳しい説明をおこなう。図９は、本発明のデータ転送方法で使用されるパケットの構造を示したものである。ルーティングに関する情報をもったルーディングヘッダ４４１と、トランスポート処理に関する情報の入ったトランスポートヘッダ４４２と、論理レコード情報の入るペイロード４４３とエラーチェックコードであるＣＲＣ４４４とからなる。ルーディングヘッダは、イニシエータ・ターゲットの宛先アドレスと、パケットの優先度情報、パケット長を含んでいる。トランスポートヘッダには、転送処理を規定する処理動作コードと宛先のキューペア番号、パケット順序番号と、一括転送の動作を規定する一括転送フラグ４５０、一括転送条件フィールド４５１が含まれている。

一括転送フラグ４５０は、当該パケットが一括転送されていることを示すものであり、このフラグを確認することで、一括転送中なのかどうかを判断することができる。一括転送条件フィールド４５１は、一括転送中の各論理レコードのデータ依存関係を示したものである。各論理レコードに対応するビットフィールドに１がセットされると、その論理レコードが他の論理レコードと依存関係の無いことを示す。一括転送中にエラーが発生した場合でも、この一括転送条件フィールドで１のセットされている論理レコードについては、受信処理を実行してもデータの到着順序で問題の生じることが無い。

また、後に明らかになるように、一括転送フラグの情報や、一括転送条件フィールドの情報をペイロードの中にいれて、あらかじめイニシエータからターゲットに通知しておいてもよい。その場合、各パケット中のトランスポートヘッダに、一括転送フラグや、一括転送条件フィールドがなくてもよい。

本実施例によれば、一括転送における一括転送条件をさらに詳細に規定することができる。したがって、一括転送中に転送エラーが生じた場合でも、データ依存関係がなく、到着順序で問題を生じる可能性の無い論理レコードについては、受信動作を継続することが可能となる。そのため、アプリケーションの処理効率を高めることができ、再送レコード数を減らすことでより効率のよい転送を実現することができる。

《実施例４》
本発明のデータ転送方法の動作フローを、図１０を用いて説明する。ここでは一括転送を開始するにあたり、イニシエータがターゲットに一括転送モード開始リクエストを発行している。これは、上述のように、一括転送条件フィールドなどの一括転送に関する情報を、通常のリライアブル送信パケットのペイロードに含めて送信するものである。ターゲットから当該パケットに対する受信完了通知が届いたら、イニシエータ・ターゲットとも一括転送モードになる。ここで、イニシエータからは、送信キューに格納されている一括転送リクエストの処理を順次開始し、ターゲットでは、それに対応したレスポンス処理を行う。一連の一括転送リクエストの処理が終了した時点で、ターゲットから一括転送モードの終了リクエストを、通常のリライアブル送信パケットとして送信する。

このとき、ターゲットでの一括転送受信記録である一括転送完了ステータスをペイロードの一部に含めて送信する。イニシエータからは、その受信完了通知を返信し、イニシエータ・ターゲットは一括転送モードを解除する。イニシエータと、ターゲットは、一括転送完了ステータスを参照して、必要ならば、再送処理を開始する。すなわち、再送すべき論理レコードが存在すれば、それを順次、上記の手順に従い、一括転送する。一括転送リクエストのすべての論理レコードがターゲットに正常受信されたなら、一括転送を終了する。

本実施例において、ターゲットでは、転送エラーが発生した以降の当該一括転送モード中の論理レコード受信については無視し、アプリケーションの完了キューにも通知しない。そして、上記の一括転送完了ステータスの中に、一括転送モード中で転送エラーの検出された最初の論理レコードの転送ＩＤを含めて返送する。イニシエータでは、一括転送完了ステータスに含まれている、エラーの検出された論理レコードから再送を開始する。

本実施例に拠れば、一括転送中で転送エラーの生じるまでの正常受信が完了した論理レコードに関しては、受信完了後ただちに、対応するアプリケーションの処理を開始することができる。したがって、転送エラーが発生した際にも、アプリケーションの処理効率を高めることができる。

《実施例５》
別の実施例では、上記の一括転送完了ステータスの中に、再送の必要な論理レコードの転送ＩＤリストを含めて返送する。イニシエータでは、ターゲットから通知された前記転送ＩＤリストを参照して再送処理を行う。

本実施例に拠れば、再送の必要な論理レコードについてのみ再送処理を行うことで、再送処理に要する時間を最小限に抑えることができる。したがって、再送レコード数を減らすことでより効率のよい転送を実現することができる。

《実施例６》
本発明のデータ転送方法における動作の詳細について、図１１、図１２を用いて説明を行う。図１１は、図１０内の一括転送モードにおけるＳＥＮＤリクエストの動作フローを示したものである。当該論理レコードが一括転送条件に合致していれば、送信処理１２０１を行い、正常に送信できたかどうか、送信ステータス記録処理１２２１を行う。図１２は、ＳＥＮＤリクエストに対応したレスポンスの動作フローを示している。当該論理レコードが一括転送条件に合致していれば、受信処理１１０１を行い、正常に受信できた場合完了キュー通知１１１０を行って、最後に受信ステータス記録処理１１２１を行う。

ＳＥＮＤリクエスト処理、ＳＥＮＤレスポンス処理とも、一括転送条件に合致しない論理レコードについては、当該レコードをスキップする。その際、相互にキャンセルリクエスト１１１２および１２１２を発行して、当該一括転送を途中で中止することが可能である。キャンセルリクエストを受けたほうは、その応答１１１１もしくは１２１１を返した後、一括転送モードを解除する。キャンセルリクエストを出したほうは、相手からその応答が戻ってきた後、一括転送モードを解除する。

本実施例に拠れば、一括転送の途中で転送エラー発生などにより、その後の一括転送の継続が不要になった場合、当該一括転送を途中で中止することが可能となる。そのため、不要な論理レコードの転送を抑制することで、より効率のよい転送を実現することができる。

《実施例７》
図１３、図１４、図１５に本発明のディスク制御装置に関する一実施例を示す。図１３において、ディスク制御装置５００は、ホストコンピュータ５６０とホストインターフェースネットワーク５０１で接続している複数のホストインターフェース部５１０と、磁気ディスク装置５７０とディスクインターフェースネットワーク５０２で接続している複数のディスクインターフェース部５２０とを有しており、複数のホストインターフェース部５１０と複数のディスクインターフェース部５２０は、ディスク制御装置内ネットワーク５０３で接続されている。

図１４にホストインターフェース部５１０の構成を示す。複数のホストチャネルインターフェース５１１とプロセッサ５１２とメモリ５１３とＨＣＡ６０３を有し、それらがホストハブ５１４を介して接続されている。

図１５にディスクインターフェース部５２０の構成を示す。複数のディスクチャネルインターフェース５２１とプロセッサ５２２とメモリ５２３とＨＣＡ６０４を有し、それらがディスクハブ５２４を介して接続されている。また、ディスクハブ５２４には、キャッシュメモリ５２５も接続している。

各ホストインターフェース部５１０は、ホストコンピュータ５６０とのインターフェースとキャッシュメモリ５２５との間のデータ転送を実行し、各ディスクインターフェース部５２０は、磁気ディスク装置５７０とのインターフェースとキャッシュメモリ５２５との間のデータ転送を実行する。

ホストインターフェース部５１０と、ディスクインターフェース部５２０は、ＨＣＡ６０３とＨＣＡ６０４を介してデータ転送を行う。その際、ホストインターフェース部は、複数のホストチャネルからのコマンドやデータをホストハブでまとめて、ディスクインターフェース部に転送する。その際に、上述のデータ転送方法を用いる。なお、ＨＣＡは、図５に示した機能と同等の機能を有するものであればよく、例えば、その一部の機能をプロセッサ５１２やプロセッサ５２２のソフトウェア処理により実現してもかまわない。

本実施例によると、ホストコンピュータ部とディスクインターフェース部の転送効率を大幅に改善することができる。特に、ディスク制御装置内ネットワーク５０３の転送効率の向上と、ホストインターフェース部、および、ディスクインターフェース部からのＩＯリクエストに対するレスポンス時間の短縮が可能となり、ディスク制御装置の処理性能を高めることができる。

《実施例８》
図１３に示したディスク制御装置は、その信頼性を向上させるため、複数のディスクインターフェース部に内蔵されているキャッシュメモリに、冗長にデータを格納している。そのため、ホストインターフェース部５１０から、ディスクインターフェース部５２０に書き込み要求があった場合、あるディスクインターフェース部内のキャッシュメモリ５２５にデータを格納した後、別のディスクインターフェース部内のキャッシュメモリに対しても、冗長書き込みを実行する。この複数のディスクインターフェース部間での冗長書き込みに、上述のデータ転送方法を使用する。

冗長書き込みは、ディスク制御装置の信頼性向上のために不可欠ではあるが、それによるディスク制御装置内ネットワークへの負荷増加とそれに起因するシステム性能劣化が課題であった。本実施例により、ディスク制御装置内ネットワークの転送効率を向上させて、ディスク制御装置の処理性能を高めることが可能となる。

《実施例９》
図１３に示したディスク制御装置では、仮想化機能実現などのために他のディスク制御装置と連携して動作する場合に、ホストインターフェース部間でデータ転送を行う必要がある。このホストインターフェース部間のデータ転送に、上述のデータ転送方法を適用する。

ホストインターフェース部間転送の場合、複数のディスク制御装置を経由してのデータアクセスとなるので、そのレスポンス時間を、可能な限り短くする必要がある。本実施例によるとホストインターフェース部間でのレスポンス時間の大幅な短縮が可能となり、ディスク制御装置の処理性能が向上する。

《実施例１０》
図１６に示したディスク制御装置では、ディスク制御装置５００が、ホストコンピュータ５６０とホストインターフェースネットワーク５０１で接続している複数のホストインターフェース部６１０と、磁気ディスク装置５７０とディスクインターフェースネットワーク５０２で接続している複数のディスクインターフェース部６２０と、複数のメモリ部５８０と、複数のプロッセサ部５９０を有しており、複数のホストインターフェース部６１０と複数のディスクインターフェース部６２０と、複数のメモリ部５８０と、複数のプロセッサ部５９０とは、ディスク制御装置内ネットワーク５０３で接続されている。

前記複数のホストインターフェース部５０１は、上記複数のプロセッサ５９０と連携して上記メモリ部５８０とデータ転送を実行し、あるいは複数のディスクインターフェース部６２０は上記プロセッサ部５９０と連携して上記磁気ディスク装置５７０と上記メモリ部５８０との間でデータ転送を実行する。このデータ転送に上述の本発明のデータ転送方法を用いる。

本実施例によると、ディスク制御装置内ネットワーク５０３の転送効率の向上と、ホストインターフェース部５０１、および、ディスクインターフェース部６２０からのＩ／Ｏリクエストに対するレスポンス時間の短縮が可能となり、ディスク制御装置の処理性能を高めることができる。

また、上記複数のメモリ部５８０とプロッセサ部５９０間のデータ転送や上記複数のメモリ部５８０間、あるいは、プロッセサ部５９０間のデータ転送にも上述の本発明の高速データ転送方法を用いることができ、同様にディスク制御装置の処理性能を高めることができる。

本発明によるデータ転送方法の動作原理を示す図である。 従来のデータ転送方法の動作原理を示す図である。 従来のデータ転送方法の動作原理を示す図である。 IOシステムの構成を示す図である。 ホストチャネルアダプタ（ＨＣＡ）の構成を示す図である。 従来の単純データ転送方法の動作詳細を示す図である。 従来のRDMAデータ転送方法の動作詳細を示す図である。 本発明のデータ転送方法で使用する転送リクエストと論理レコードの構造を示す図である。 本発明のデータ転送方法で使用するパケット構造を示す図である。 本発明のデータ転送方法の動作フローを示す図である。 本発明のデータ転送方法におけるSENDリクエストの動作フローを示す図である。 本発明のデータ転送方法におけるSENDレスポンスの動作フローを示す図である。 本発明のディスク制御装置の構成を示す図である。 本発明のディスク制御装置で使用されるホストインターフェース部の構成を示す図である。 本発明のディスク制御装置で使用されるディスクインターフェース部の構成を示す図である。 本発明のディスク制御装置の構成を示す図である。 本発明のディスク制御装置で使用されるホストインターフェース部の構成を示す図である。 本発明のディスク制御装置で使用されるディスクインターフェース部の構成を示す図である。

符号の説明

１１、１２、１３、１４、１５、１６、１７、１８、１９…送信キュー、
２１、２２、２３、２４、２５、２６、２７、２８…受信キュー、
３１、３２、３３、３４、３５、３６、３９…完了キュー、
４１、４２、４３、４４、４５、４６、４７、４８…キューペア、
５１、５２、５３、５４…プロセス、
６１、６２…プロセスコード、
７１、７２、７３、７４…プロセスバッファ、
７５、７６…アプリケーションメモリ空間、
８１、８２、８３、８４、８９…レコードバッファ、
８５、８６、８７…ＲＤＭＡ転送空間、
１００、１０１、１０２、１０３、１０５、１２１、１２５、１３１…転送リクエスト、
２０１、２０５、２１２、２１３、２１５、２２１、２２５、２３１、２３５、２３２、２３４…転送データ、
３００、３０１、３１２、３１３、３１５、３２１、３２５、３３１…(論理レコード)完了ステータス、
３５１、３５２…一括転送完了ステータス、
３６１、３６５、３７１…転送完了ステータス、
４０１、４０２、４０３、４０４、４１１、４１３、４１４、４２１、４２２、４２３、４２４、４３１、４３３、４３４、４４０…パケット、
４４１…ルーティングヘッダ、
４４２…トランスポートヘッダ
４４３…ペイロード、
４４４…ＣＲＣ、
４５０…一括転送フラグ、
４５１、４５６…一括転送条件フィールド、
４５５…一括転送レコード数、
５００…ディスク制御装置、
５０１…ホストインターフェースネットワーク、
５０２…ディスクインターフェースネットワーク、
５０３…ディスク制御装置内ネットワーク、
５１０…ホストインターフェース部、
５１１…ホストチャネルインターフェース、
５１２…プロセッサ、
５１３…メモリ、
５１４…ホストハブ、
５２０…ディスクインターフェース部、
５２１…ディスクチャネルインターフェース、
５２２…プロセッサ、
５２３…メモリ、
５２４…ディスクハブ、
５２５…キャッシュメモリ
５６０…ホストコンピュータ、
５７０…磁気ディスク装置、
５８０…メモリ、
５９０…プロセッサ、
６０１、６０２、６０３、６０４…ホストチャネルアダプタ、
６１０…ホストインターフェース部、
６１１、６１２、６１３…受信ポート、
６２０…プロセッサー部、
６２１、６２２、６２３…送信ポート、
６３１…受信リンク論理、
６３２…受信トランスポート論理、
６３３…受信プロセッサ、
６４１…送信リンク論理、
６４２…送信トランスポート論理、
６４３…送信プロセッサ、
６５０…メモリ、
６６０…接続インターフェース、
６７０…内部バス
７０１、７１２、７１３、７１５、７２１、７２５、７３１…処理開始、
１００１…一括送信モード開始リクエスト、
１００２…一括転送モード開始レスポンス、
１０１１…送信リクエスト、
１０１３…ＲＤＭＡ送信リクエスト、
１０１５…送信レスポンス、
１０１７…ＲＤＭＡ送信レスポンス、
１０２１…一括転送モード終了レスポンス、
１０２２…一括転送モード終了リクエスト
１１０１…受信、
１１１０…完了通知、
１１１１…キャンセルレスポンス、
１１１２…キャンセルリクエスト、
１１２１…受信ステータス記録、
１２０１…送信、
１２１１…キャンセルレスポンス、
１２１２…キャンセルリクエスト、
１２２１…送信ステータス記録。

Claims (3)

1. イニシエータからターゲットへのデータ転送の際、前記ターゲットで受信されたデータの転送エラーの有無を前記データに付加されているエラーチェックコードを用いて確認し、前記転送エラーの有無を前記ターゲットから前記イニシエータに転送ステータスとして返送し、前記転送ステータスにより前記データ転送の際に転送エラーの発生が判明した場合、前記イニシエータから前記ターゲットに前記データの再送を行うリライアブル転送における、前記イニシエータと前記ターゲット間の前記データ転送の単位である論理レコードのデータ転送方法であって、
   一括転送される他の前記論理レコードとの依存関係の有無を示すデータを含む複数の前記論理レコードをまとめて一括転送し、
   前記イニシエータが発行した転送リクエストにより前記論理レコードの転送がなされ、前記論理レコードが正常に前記ターゲットに到着した時点で、前記一括転送の中の正常受信した前記論理レコードの前記転送リクエストに対応した完了ステータスを前記ターゲット内に存在する完了キューに通知して、前記一括転送される前記論理レコードの中で正常受信し、かつ他の論理レコードとの依存関係の無い前記論理レコードの処理を開始可能とし、
   前記イニシエータでは、前記一括転送の単位の前記転送ステータスとして前記ターゲットが返送する一括転送完了ステータスの確認を行い、
   前記ターゲットでは、前記一括転送の中の前記論理レコードの転送エラーを前記エラーチェックコードにより検出した際、前記一括転送の終了まで、当該論理レコードおよびそれ以降の論理レコードの受信を無視し、前記完了ステータスの通知を抑制することを特徴とするデータ転送方法。
2. 前記イニシエータと前記ターゲットとの間の前記一括転送において、
   前記ターゲットでは前記転送エラーが検出された最初の前記論理レコードのＩＤを、前記一括転送完了ステータスの中に含め、
   前記イニシエータでは前記一括転送完了ステータスをもとに、前記転送エラーの発生した前記論理レコードから再送を開始することを特徴とする請求項１に記載のデータ転送方法。
3. 前記一括転送の途中で、前記イニシエータにおいて前記論理レコードに送信エラーが発生した場合に前記イニシエータがキャンセルリクエストを発行する、もしくは、前記ターゲットにおいて前記論理レコードに受信エラーが発生した場合に前記ターゲットがキャンセルリクエストを発行することにより、前記一括転送を中止することが可能であることを特徴とする請求項１または２に記載のデータ転送方法。

Images