JP5611889B2 - データ転送装置、データ送信システムおよびデータ送信方法 - Google Patents

Description

本発明の実施形態は、プロセッサに代行して通信プロトコル処理を行うデータ転送装置、データ送信システムおよびデータ送信方法に関する。

コンピュータに直接接続されたＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）はＤＡＳ（Ｄｉｒｅｃｔ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）と呼ばれているが、これらのストレージをネットワーク経由で接続するネットワークストレージが普及しつつある。ネットワークストレージは、大きく分けるとＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）とＮＡＳ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）に分類できる。ＳＡＮはｉＳＣＳＩやＦｉｂｒｅ Ｃｈａｎｎｅｌ等が知られており、ストレージ装置はブロックデバイスとしてネットワーク経由でホストマシン（ストレージを利用する側のマシン）と接続して、ホストマシン側にファイルシステムを持っている。一方、ＮＡＳはＮＦＳ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ）等が知られており、ストレージ装置側にファイルシステムまでを組み込んでおり、ホスト装置はファイルシステムの上位からストレージにアクセスできる。これにより、ホストマシンの負荷を軽減できるだけでなく、複数台のホストマシンでストレージ上のファイルシステムを共有できる等のメリットがある。

これらのネットワークストレージでは、その通信手段に主にイーサネット(登録商標)が使われ、また通信プロトコルにはインターネット等で広く使われているＴＣＰ／ＩＰやＵＤＰ／ＩＰ等が使われる。これらの広く普及した汎用技術によりネットワークストレージの利用が容易となり、ネットワークストレージは従来のＤＡＳに比べ、ストレージとしての拡張性や保守性等の利便性が向上した。

また、昨今では映像のストリーミング配信が普及しつつある。例えばＶＯＤ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）サーバと呼ばれるコンテンツ配信サーバによってストリーミング配信が行われるが、このようなコンテンツ配信サーバも、自身がもつストレージ装置から映像コンテンツを読み出し、ネットワーク接続されたユーザの端末に送信する処理を行う。Ｗｅｂサーバも同様にストレージ上のコンテンツをユーザの端末に送信する。通信プロトコルは、ＴＣＰ／ＩＰベースのＨＴＴＰや、リアルタイム通信向けのＵＤＰ／ＩＰベースのＲＴＰ等が使われる。また、ＲＴＰの場合は誤り訂正にＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）等が使われる。

このようなネットワークストレージ、ＶＯＤサーバ、Ｗｅｂサーバに用いられるストレージやネットワーク等のデバイスの高速化は著しく進んでいる。イーサネットは現在１Ｇｂｐｓが主流になりつつあり、データセンター等では１０Ｇｂｐｓが使われ始めている。また、次世代の４０Ｇｂｐｓ／１００Ｇｂｐｓイーサネットの仕様策定も完了し、これらについても今後着実に普及していくものと思われる。また、ストレージに関してはＨＤＤのＲＡＩＤのストライピング処理（並列化）による高速化に加えて、昨今のＳＳＤの転送性能の向上は著しく、現行製品でも単体で２Ｇｂｐｓ超の読み出しレートを出すものがある。ストレージ装置のＩ／Ｆ規格のＳＡＴＡに関しても、バンド幅６ＧｂｐｓのＳＡＴＡ３．０が既に普及している状況である。これらを鑑みるとネットワークストレージに関しても、近い将来に１０Ｇｂｐｓクラスの帯域になるものと予想される。

このようなネットワークストレージの性能向上に伴って、それを制御するホストＣＰＵの処理負荷も増大していく。従来はＴＣＰ／ＩＰオフロードエンジン（以下、ＴＯＥ）という技術により、その解決が試みられてきた。ＴＯＥは、ホストＣＰＵに代行して、前述のＴＣＰ／ＩＰの処理を行う専用プロセッサや専用回路を設けたものであり、ホストＣＰＵからＴＣＰ／ＩＰ処理負荷をオフロードするものである。このＴＯＥを用いることによって、従来のソフトウェアによる通信プロトコル処理よりも高速にＴＣＰ／ＩＰ処理を行うことが可能となり、ネットワークストレージの性能向上に貢献できる。

ストレージ装置やＴＯＥは、それぞれホストＣＰＵによって制御され、データはメインメモリを介して入出力することが想定されている。よって、ストレージ上のデータをネットワークに入出力する際、ストレージ装置（ＳＳＤ、ＨＤＤ等）とＴＯＥの間のデータ転送は、必ずメインメモリを介して行われる（特許文献１参照）。

また、ホストＣＰＵ上で動作する、これらの間をブリッジするアプリケーションソフトウェア、あるいは、ＯＳのカーネル空間とユーザ空間のデータの受け渡し処理等により、メインメモリ上で何回分か転送データのコピーが発生する場合もある。さらにファイルシステム処理も必要であり、通常のファイルシステムの実装では、ストレージから固定バイト長のセクタ単位で読み書きしたデータを、任意バイト長のファイルとして整形するため、ここでもデータのコピーが発生する。

特開２００５−３１６６２９号公報

このように、ストレージ装置とＴＯＥの間でデータ転送を行う場合は、ホストＣＰＵのソフトウェア処理が介在することから、少なくとも一回はメインメモリへの読み書きが必要となり、また、ＯＳやアプリケーション、ファイルシステムの処理により、メインメモリ上で場合によっては複数回分のメモリコピーが発生することになり、メインメモリの負荷が大幅に増大してしまう。

このようなメモリ負荷に対し、従来は十分な処理性能を持つホストＣＰＵと高速のメインメモリを用意して対応していたが、昨今のネットワークストレージの１０Ｇｂｐｓに迫る転送レートの向上を鑑みると、少なからず問題となってきた。特に、メインメモリの性能を上げるためには、一般にホストＣＰＵのグレードアップも伴い、ＰＣやサーバ等の場合は、付随するチップセットのグレードアップも必要となる。これにより、コストや消費電力の問題が特に顕著となる。

本発明の一側面は、このようなホストＣＰＵの処理負担を軽減させて、効率的にデータ転送を行うことができるデータ転送装置、データ送信システムおよびデータ送信方法を提供するものである。

本発明の一実施形態としてのデータ転送装置は、ブロック単位でデータを管理するストレージ装置に記憶されているファイルのデータをネットワークに転送するデータ転送装置であって、第一発行部と、第二発行部と、送信データ抽出部と、通信処理部とを備える。

前記第一発行部は、外部のホストＣＰＵからの要求を受けて、第一ファイルのデータが前記ストレージ装置上のどの位置に記憶されているかを示す第一マップ情報を含むメタデータの読み出しコマンドを生成し、前記読み出しコマンドを前記ストレージ装置に送る。

前記第二発行部は、前記ストレージ装置から返される前記メタデータを取得した前記外部のホストＣＰＵから、前記第一ファイルのデータの読み出し指示を受け、前記第一ファイルのデータを格納したブロックの読み出しコマンドを生成し、前記読み出しコマンドを前記ストレージ装置に送る。

前記送信データ抽出部は、前記読み出しコマンドに応じて前記ストレージ装置から読み出されるブロックデータを受け取り、前記外部のホストＣＰＵから前記第一マップ情報を受け取り、前記第一マップ情報に基づき、前記ブロックデータから前記第一ファイルのデータを抽出する。

前記通信処理部は、前記送信データ抽出部により抽出された前記第一ファイルのデータを、前記ネットワークに送信する。

第１の実施形態に係るデータ送信システムの概略構成を示すブロック図である。 ストレージ装置に格納されたデータの一例を示す図である。 コマンドごとに送信データ抽出部のアドレス領域を対応づけたことを示す図である。 第1の実施形態に係るデータ送信システムの他の例を示す図である。 第２の実施形態に係るデータ送信システムの概略構成を示すブロック図である。 ストレージ装置に格納されたデータの他の例を示す図である。 第２の実施形態に係るデータ送信システムの他の構成例を示す図である。

以下、図面を参照しながら、本発明の実施形態を説明する。

（第１の実施形態）
図１は第１の実施形態に係るデータ送信システムの概略構成を示すブロック図である。点線矢印は制御の流れ、実線矢印はストレージから読み出したデータの流れ、太線矢印はそのうちの送信データの流れを示す。

図１のデータ送信システムは、データ転送装置１１と、ホストＣＰＵ（プロセッサ）１２と、ストレージ装置１３と、を備えている。ホストＣＰＵ１２の制御に基づき、データ転送装置１１がデータをストレージ装置１３から読み出し、ネットワーク１４に送信する。

図１のデータ送信システムの具体的な製品形態としては、ＰＣ、サーバ装置、専用ＬＳＩ、またはＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）等のネットワークストレージ、あるいはＶＯＤ（Ｖｉｄｅｏ Ｏｎ Ｄｅｍａｎｄ）サーバ、Ｗｅｂサーバなどが想定されるが、これらに限定されるものではない。

ホストＣＰＵ１２は、システム全体の制御を行う。ホストＣＰＵ１２は、ソフトウェアで実行する主な処理部として、データ送信アプリケーション処理を行う第一アプリ処理部２０１と、ストレージ装置１３のメタデータの読み出しを指示するメタデータ読み出し指示部２０２と、読み出したメタデータを解析してエクステントマップ情報を取得するエクステントマップ取得部２０３と、データ転送装置１１にデータの読み出し及びデータ送信指示を行う送信データ読み出し指示部２０４とを有する。もちろんホストＣＰＵ１２は、その他の種々の処理を行うことが可能である。

ストレージ装置１３には送信するデータが格納されている。ストレージ装置１３の具体的な実装形態は、例えばＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＤメモリカード等が想定されるが、その限りではない。

データ転送装置１１は、ホストＣＰＵ１２に代行し、ストレージ装置１３からデータを読み出し、さらに、通信処理を行い、読み出したデータをネットワーク１４に送信する。
データ転送装置１１は、ストレージ装置１３に対してコマンドを発行するコマンド発行部１０１（第一発行部、第二発行部）、発行したコマンドの応答通知を受け取り、ホストＣＰＵ内の該当構成要素（図１の構成例ではメタデータ読み出し指示部２０２、送信データ読み出し指示部２０４）に振り分ける通知振り分け部１０２、ストレージ装置１３から読み出されたデータを受け取り必要なデータを抽出する送信データ抽出部１０３、抽出されたデータをネットワーク１４に送信する通信処理部１０４を有する。通信処理部１０４は、前述したＴＯＥに相当する。データ転送装置１１の具体的な実装の形態としては、ＦＰＧＡ、専用ＬＳＩなどが想定され、ＰＣＩカード等の通信カードとして実装してもよいが、その限りではない。

ストレージ装置１３にはＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）機能を備えてもよいし、あるいは、データ転送装置１１内のストレージ装置１３とのＩ／ＦにＲＡＩＤ機能を備えてもよい。いずれの場合も本発明の本質とは関係ないので説明では割愛する。

ネットワーク１４は、イーサネット、無線ＬＡＮ、あるいは、その他のあらゆる無線通信、有線通信を含む。

ホストＣＰＵ１２とデータ転送装置１１は、本装置がＰＣやサーバ装置などの場合は例えばチップセット等で接続され、ＳｏＣなどの場合は例えば専用のバスなどで接続されてもよい。ストレージ装置１３とデータ転送装置１１は例えばＳＡＴＡ、ＳＡＳ、ＳＣＳＩ、ＳＤメモリカード規格などで接続される。以上はほんの一例であり、この限りではない。

データ転送装置１１は、ハードウェアとソフトウェアのどちらで構成してもよく、実装の形態は問わないが、処理効率の観点からハードウェアベースで構成することが望ましい。また、通信処理部１０４が処理する通信処理はなんでもよく、例えばＴＣＰ／ＩＰベースのプロトコル処理、ＵＤＰ／ＩＰベースのプロトコル処理、イーサネット処理、無線処理などが挙げられる。なお、ＴＣＰのような対向装置とコネクションを張るようなプロトコルの場合、以下の動作説明は、相手とコネクションを張った後のデータ転送の段階での動作になる。

ストレージ装置１３は、データをたとえばセクタと呼ばれる単位で管理する。ここでは抽象化してブロックと呼ぶ。ユーザが扱うデータはブロック単位ではないため、ストレージ装置１３は通常ファイルシステムによりアクセスされる。ファイルシステムは、バイト単位のファイルデータをブロック単位のストレージ装置１３の記録領域にマッピングする仕組みである。ファイルシステムは、公知のものを利用するため詳細は割愛するが、簡単に説明すると、ストレージ上のある領域に、そのマッピング情報を含むメタデータ（メタデータ自体はその他諸々の情報を含む）を、データと併せて記憶する。ストレージからファイルデータを読み出す際は、まずこのメタデータを読み出し、それを解析し、所望のファイルデータが実際にどのブロックに記憶されているかを表す情報（第一マップ情報）、すなわちエクステントマップを得る。そして、そのエクステントマップ情報に従ってブロックデータを読み出し、必要部分だけを抽出して所望のデータを得る。エクステントマップは具体的には図２のようになる。

図２は１ブロックが５１２バイトで、ブロック２３５〜２３８に所望のファイルのとある部分のデータが格納されている様子を示している。データはブロック２３５の１２４バイト目から始まっているので、オフセット１２４バイト、長さは１４５８バイト、などと表わされる。

このように、エクステントマップは、データが格納されているブロック位置情報、そのうちの有効データが格納されている有効データ位置情報で構成され、つまりはストレージのどこに所望のデータが格納されているかが特定できる情報である。

この例ではデータが格納されているバイト位置をオフセットと長さで示しているが、始端バイト位置と終端バイト位置等で表してもよく、有効データの位置が特定できれば表現形式は問わない。

また、この例では１４５８バイトの一つのデータ列の例を示したが、エクステントマップ情報は離散的な複数のデータ列を表わしていてもよい。すなわち、一つのエクステントマップ情報に、例えばブロック２３５〜２３８のうちの１４５８バイトを示す情報と、ブロック３４６〜２５０のうちの２０００バイトを示す情報の二つのデータ列を含んでいてもよい。

なお、以上のエクステントベースのファイルシステムの場合に当てはまるが、本発明はブロック（クラスタ）ベースのファイルシステムも含む。ブロック（クラスタ）ベースのファイルシステムの場合は、エクステントの代わりにブロック（クラスタ）のリストになるが、これもエクステントの特殊な場合（一つのエクステントの長さを５１２バイトに固定したもの）とみなせば同様に考えることが可能である。以降はエクステントの用語を用いて説明し、これら両方を含むものとする。

公知の技術では、通常、ホストＣＰＵ１２はアプリケーションのファイルデータ読み出し要求に基づき、デバイスドライバやファイルシステムソフトウェア等の制御ソフトウェアを実行することで、このエクステントマップの取得を行い、それに従って所望のデータストレージから読み出し、アプリケーションに読み出したデータを返す。それに対して本実施形態では、そのうち一部の処理をデータ転送装置１１が代行し、ストレージから読み出されたデータをホストＣＰＵ１２に返すことなく、そのままネットワーク１４にデータを送信する。具体的な処理の流れは次のようになる。

まず、第一アプリ処理部２０１が何らかのアプリケーションソフトウェアの処理によって、送信するファイル（第一ファイル）、及び、必要に応じてそのファイルの中のデータ位置を特定する。典型的な例としては、ネットワーク１４に接続された他の機器からの要求に基づき、ファイルを特定する。そして、メタデータ読み出し指示部２０２に、当該ファイルの送信指示とともに、ファイル情報（ファイル識別子、および必要に応じてファイルの中のデータ位置）を送る。

メタデータ読み出し指示部２０２は、渡された情報に基づき、ストレージ装置１３からファイルシステムのメタデータを読み出すべく、データ転送装置１１のコマンド発行部１０１にコマンド発行の指示を行う。コマンド発行の指示は、ファイル識別子および必要に応じてデータ位置を含む。コマンド発行部１０１は、メタデータの読み出しコマンド（第一コマンド）を発行し、ストレージ装置１３に送る。コマンド発行部１０１が備える機能のうち、第一コマンドを発行する機能は、第一発行部に相当する。

ストレージ装置１３はこのコマンドに基づき、該当メタデータを読み出してエクステントマップ取得部２０３に渡す。

エクステントマップ取得部２０３は、このメタデータ情報を解析し、読み出したいファイルのデータのエクステントマップを取得する。なおエクステントマップ情報の取得は、予めキャッシュしていたものを参照して取得する形態でもよいが、同様の手順で予め読み出しておく必要がある。

そして取得したエクステントマップ情報を、送信データ読み出し指示部２０４がデータ転送装置１１に渡し、データ転送装置１１に対してそのデータの読み出しと送信の指示を行う。

データ転送装置１１では、コマンド発行部１０１がそのエクステントマップ情報を受け取り、その情報を元に、送信したいデータを格納したブロックを読み出すべく、ブロックの読み出しコマンド（第二コマンド）の発行を行う。コマンド発行部１０１が備える機能のうち、第二コマンドを発行する機能は、第二発行部に相当する。コマンドはストレージ装置１３側のＩ／Ｆ仕様に従ったものになるが、通常、一度に指定できる読み出しブロック数に限りがあったり、離散的なブロックは同時に指定できなかったり等制限がある場合があるので、一つのエクステントマップ情報が複数のコマンド群に分割される場合もあるので、その分割処理も行う。

そしてコマンド発行部１０１がそのコマンドを順次ストレージ装置１３に対して発行すると、ほどなくストレージ装置１３からその応答としてデータが含まれたブロックが返ってくるので、送信データ抽出部１０３がそのブロックデータを受け取る。

一方、送信データ読み出し指示部２０４がコマンド発行部１０１に指示を出すときに、送信データ抽出部１０３に、個々のコマンドに対応するブロックのどの部分に送信したいデータが含まれているかの情報を渡す。すなわち、前述の図２の例だと、送信データ読み出し指示部２０４は、ブロック２３５〜２３８というブロック位置情報をコマンド発行部１０１に渡し、オフセット１２４バイト・長さ１４５８バイトという有効データ位置情報を送信データ抽出部１０３に渡す。

送信データ抽出部１０３は受け取ったブロックデータからこの情報をもとに所望の１４５８バイトのデータ列を抽出し、通信処理部１０４に渡す。

そして通信処理部１０４は必要に応じて対向装置と制御情報をやりとりしながら、ネットワーク１４上にそのデータを送信する。

ストレージ装置１３とのＩ／Ｆ処理についてより詳しく説明する。まず、ストレージ装置１３が典型的なＳＳＤやＨＤＤなどのＳＡＴＡ Ｉ／Ｆを備え、さらにバスマスターとしての機能（ＤＭＡ機能）を備える場合、ストレージ装置１３へのコマンドはデスクリプタと呼ばれるコマンドを記述したデータを、所定のメモリ上に用意しておき、ストレージ装置１３がそれを読み出すことでコマンドがストレージ装置１３に受け渡される。前述のコマンド発行部１０１はこのような処理を行う。

デスクリブタは通常リングバッファ形式になっており、典型的な公知の技術ではホストＣＰＵ１２が使用するメインメモリ（主記憶装置、不図示）上に置かれる。本実施形態でも同じ形態をとってもよいが、データ転送装置１１内のメモリ、あるいは、データ転送装置１１に直接接続されるメモリを用いることが、メインメモリやホストＣＰＵ１２に負荷を与えないという点で望ましい。

また、ストレージ装置１３が読み出したブロックデータをＤＭＡで書き込む宛先アドレスも、このそれぞれのデスクリブタにあらかじめ指定するが、読み出したメタデータはホストＣＰＵ１２に渡し、送信データは通信処理部１０４に渡すといった振り分けは、このアドレス指定によって実現する。すなわち、メタデータをホストＣＰＵ１２に渡す場合は、通常はメインメモリを介して行うので、デスクリプタに記載する宛先アドレスにメインメモリのアドレスを記載する。送信データを通信処理部１０４に渡す場合は、宛先アドレスに通信処理部１０４のアドレスを記載する。これによって、ストレージ装置１３がデスクリプタによって指定された宛先アドレスに読み出したデータを書き込むだけで、読み出したデータをそれぞれに振り分けることができる。

また、ストレージ装置１３はコマンドを実行してデータを読み出した後にコマンド完了通知（応答通知）を行うが、これは割り込みなどによってその通知が行われ、どこまでコマンドを処理したか、すなわち、リングバッファのデスクリプタ群のどのデスクリプタまで処理したかを、各デスクリプタの処理完了を示すＤＯＮＥビットをセットするなどして通知する。つまり、ホストＣＰＵ１２は割り込み通知を受けると、このＤＯＮＥビットが書かれているデスクリプタを順次読み出し（読み出した後はビットをリセットする）、そこまで処理が完了していることを判断できる。これは一度に複数のデスクリプタの処理が完了している場合もあり得る。

通知振り分け部１０２は、これによって完了と判断されたデスクリプタがメタデータ読み出しのものであった場合はメタデータ読み出し指示部２０２に、送信データ読み出しのものであった場合は送信データ読み出し指示部２０４に通知する形で、完了通知をそれぞれに振り分ける。

メタデータ読み出し指示部２０２はこの通知を受けるとメタデータの読み出しが完了したと判断し、エクステントマップ取得部２０３にエクステントマップの取得を指示する。

また、ストレージ装置１３によるブロックデータの転送は、通常は一定のレイテンシがあるため、ホストＣＰＵ１２は転送指示に対するストレージ装置１３からの実行完了を毎回待たずに、複数のブロックの読み出しコマンドをストレージ装置１３に対してまとめて発行する場合がある。その場合、そのままでは送信データ読み出し指示部２０４（及びメタデータ読み出し指示部２０２）とストレージ装置１３と送信データ抽出部１０３の三者の間で同期が取られなくなるので、例えば以下の手法により同期を行う。

一つ目の手法は、ストレージ装置１３がコマンドを受けた順番と必ず同じ順番で読み出しを実行する場合に有効な手法で、送信データ読み出し指示部２０４がストレージ装置１３に複数のコマンドの読み出し指示を行うとき、その指示を行うのと同じ順番で、対応するブロックの中の有効データ位置情報を送信データ抽出部１０３に通知する手法である。送信データ抽出部１０３は、受け取った有効データ位置情報を例えばキューイングしておき、ストレージ装置１３からブロックデータを受け取った際、キューイングした有効データ位置情報をキューイングした順番に一つずつ取り出せば、ブロックデータとの対応付けが出来る。

二つ目の手法は、ストレージ装置１３が、内部処理の効率等を優先する場合等で、コマンドを受けた順番とは異なる順番で読み出しを実行し得る場合の手法である。この場合は、例えば各ブロックの宛先アドレスとして異なるアドレスを指定する等が考えられる。つまり、例えば４つの読み出しコマンドをストレージ装置１３にまとめて指示する場合、その４個に異なる転送先アドレスを指定しておく。本実施形態では、転送先のアドレスに送信データ抽出部１０３のアドレスを指定するが、この仕組みを利用する場合は、例えば１つのコマンドで最大４つのブロックの読み出し指示を出す場合、各コマンドに対応する転送先アドレスに、それぞれ送信データ抽出部１０３のアドレス領域のうちの異なるアドレス領域を指定しておく。

例えば送信データ抽出部１０３のアドレス領域が０ｘ２０２０００００〜０ｘ２０２ｆｆｆｆｆの場合、図３のように、０ｘ２０２０００００〜０ｘ２０２００７ｆｆの５１２×４バイト領域がコマンド０に対応し、０ｘ２０２００８００〜０ｘ２０２００ｆｆｆの５１２×４バイト領域がコマンド１に対応し、０ｘ２０２０１０００〜０ｘ２０２０１７ｆｆの５１２×４バイト領域がコマンド２に対応し、・・・という具合に予め対応付けておき、送信データ読み出し指示部２０４は各コマンドにこれらのアドレス領域の先頭を指定するようにコマンド発行部１０１に指示を出す。すると、転送されたブロックデータはあくまで送信データ抽出部１０３に転送されるが、それぞれ送信データ抽出部１０３の中の異なるアドレス領域に転送されるため、データを受けた送信データ抽出部１０３は、受けたブロックデータが例えば０ｘ２０２０１２００から始まるアドレスに書き込まれたデータであれば、それはコマンド２の先頭から２番目のブロックデータであることが特定できる。このコマンド２の有効データ位置情報が図２のような場合、このブロックデータは有効データの３８９バイト目から９００バイト目のデータであることが分かる。

一方、送信データ読み出し指示部２０４は、送信データ抽出部１０３に対して有効データ位置情報を８つ通知するが、その際に、コマンド０に対応する有効データ位置情報、コマンド１に対応する有効データ位置情報、コマンド２に対する有効データ位置情報、・・・なとど判るように送信データ抽出部１０３に通知する。これらによって、送信データ抽出部１０３は受けたデータ、及び、有効データ位置情報がともにどのコマンドに対するものかが判別できるため、送信データ抽出部１０３はこれらの対応付けが可能となる。なお、アドレスを使うことは本発明のほんの一例であり、その他にストレージ装置１３から送信データ抽出部１０３に通知できる情報であれば何を利用しても良い。

このように、ブロックデータの宛先アドレス領域を分けることによって、送信データ抽出部１０３が受け取ったブロックデータの順番がもとのデータ列の順番（通常はネットワーク１４に送信する順番）と異なる場合でも、ブロックデータの宛先アドレスを確認することで、そのデータがどのコマンドに基づくデータかが判断できるので、それをもとにデータ列を元の順番に並び替えることが可能となる。

以上のストレージＩ／Ｆの詳細はほんの一例であり、本発明はこれに限るものではない。

また、ストレージ装置１３が内部エラー等何らかの理由により要求されたコマンドが完了できない場合がある。この場合、ストレージ装置１３はデータ転送装置１１にエラー通知を行うが、そのままではホストＣＰＵ１２はこの情報を得られないので、このような場合はデータ転送装置１１がホストＣＰＵ１２にエラー通知を中継して従来通りホストＣＰＵ１２も異常を知ることができるようにする。

以上、本発明の第一の実施の形態を説明した。以上のような形態をとることで、アプリケーションからの要求に基づき、ホストＣＰＵ１２と不図示のメインメモリにデータ転送処理の負荷を与えることなくストレージ装置１３上のデータをネットワーク１４に送信することができるので、処理効率が向上し、データ転送の速度を向上させることができる。または、ホストＣＰＵ１２、または、それに付随するチップセット、メモリ、マザーボードなどのグレードを下げることができるので、装置の低コスト化を図ることができる。または、データ転送の大部分の処理をホストＣＰＵ１２のソフトウェア処理ではなくデータ転送装置１１のハードウェア処理で実行することが可能となるので、装置の低消費電力化を図ることができる。

なお、以上のうち、通知振り分け部１０２は必ずしもデータ転送装置１１上に構成する必要はなく、ホストＣＰＵ１２上に構成してもよい。また、コマンド発行部１０１もその一部の処理をホストＣＰＵ１２側で行ってもよいが、一つの送信データ読み出し指示を複数のコマンドに分割する処理はデータ転送装置１１上で行う方が処理効率の面で望ましい。また逆に、メタデータ読み出し指示部、エクステントマップ取得部、送信データ読み出し指示部をデータ転送装置１１上に構成してもよい。

また、第一アプリ処理部２０１によって特定されたファイルの情報を後段の処理部に渡す処理は、例えばＬｉｎｕｘ ＯＳなどで実装されているｓｅｎｄｆｉｌｅ（）関数のような標準システムコールでＩ／Ｆし、この関数内の処理を前述の動作を実現できるようにするような実施の形態が望ましい。このような標準関数でアプリケーションとＩ／Ｆすることにより、既存のアプリケーションに改変を加える必要がなくなり、本発明の実施を容易にすることができる。

以上の構成によってストレージ装置１３からネットワーク１４へのホストＣＰＵ１２を介さないデータ転送が可能となるが、この形態が望ましくない場合もある。例えば、別のアプリケーション処理等によって、データ転送ではなくホストＣＰＵ１２自身でストレージ装置１３の中身のファイル（第二ファイル）のデータを参照したいような場合もある。その場合の構成は図４のようになる。図４の第二アプリ処理部３０１は、データ送信ではなく単純にストレージ上のデータを読み出したいアプリケーションの処理部である。さらに、図４は図１に加えて、当該データの読み出しをデータ転送装置１１に指示するアプリデータ読み出し指示部３０３、読み出された当該データを取得して有効データを抽出するアプリデータ抽出部３０２を備える。

図４の形態の動作は次のようになる。まず、第一アプリ処理部２０１によるデータ送信要求に基づく処理は図１と同様である。一方、第二アプリ処理部３０１が、ファイル（第二ファイル）のデータ読み出し要求（取得指示）を行うと、第一アプリ処理の場合と同様にメタデータを読み出し、読み出したいデータのエクステントマップ情報（第二マップ情報）を取得するが、それに基づくデータ読み出し指示を行う場合、アプリデータ読み出し指示部３０３によって、読み出したデータの宛先アドレスをメインメモリ（不図示）に設定した読み出し指示を出す。すると、ストレージ装置１３から読み出されたデータはメインメモリに書き込まれるので、アプリデータ抽出部３０２がそのデータを読み出す。ここで、送信データの抽出と同様、アプリデータのエクステントマップ情報のうち、有効データ位置情報をアプリデータ読み出し指示部３０３がアプリデータ抽出部３０２に渡すので、アプリデータ抽出部３０２はその情報を元に有効データを抽出して、アプリケーションに渡す。通知振り分け部１０２は、アプリデータの読み出しコマンドに対する応答通知をアプリデータ読み出し指示部３０３に振り分けて通知する。

以上のように動作することで、データ転送装置１１による効率的なデータ送信と、従来のアプリケーションによるデータ読み出しを共存することが可能となり、ひいては本発明の実施を容易にすることができる。

また、第二アプリ処理部３０１によるデータの読み出し要求は、例えばＬｉｎｕｘ ＯＳなどで実装されているｒｅａｄ（）関数のような標準システムコールでＩ／Ｆし、この関数内の処理を前述の動作を実現できるようにするような実施の形態が望ましい。このような標準関数でアプリケーションとＩ／Ｆすることにより、既存のアプリケーションに改変を加える必要がなくなり、本発明の実施を容易にすることができる。

（第２の実施形態）
第２の実施形態は、データ転送用に複数の通信コネクションが設定され、コネクション毎に独立してフロー制御を行う例を示している。例えばＮＡＳのようなネットワークストレージやＶＯＤサーバで複数のクライアント端末、あるいは、クライアント端末上の複数のアプリケーションから同時に読み出し要求やコンテンツ配信要求を受けた場合等、複数の独立したコネクションでストレージ装置１３からデータを読み出してネットワーク１４に送信する動作を可能とする。

図５は第２の実施形態に係るデータ送信システムの概略構成を示すブロック図である。図５のデータ転送装置１１は第１の実施形態に加えて、送信データ抽出部１０３と通信処理部１０４の間のデータの受け渡しのためにコネクション毎にデータをバッファリングするデータバッファ部１０６と、データバッファ部１０６のコネクション毎のバッファ状態を管理するバッファ管理部１０７と、バッファ管理部１０７からの通知に基づいてコネクション毎のデータのフロー制御を行うフロー制御部１０５とを備える。

図５において、図１と同じ符号で示した各部は、少なくとも図１と同様の動作を行い、さらにフロー制御のための動作が加わる。フロー制御情報の伝達は太い点線で表わしている。

図５のデータ送信システムの処理手順は次のようになる。まず、図１と同様に第一アプリ処理部２０１が何らかのアプリケーションソフトウェアの処理によって、送信するファイル、及び、必要に応じてそのファイルの中のデータ位置を特定する。典型的な例としては、ネットワーク１４に接続された他の機器からの要求に基づき、ファイルを特定する。そして、メタデータ読み出し指示部２０２にその情報を渡す。ただし、今回はアプリケーションが複数のコネクションを扱うので、第一アプリ処理部２０１はコネクションを識別するコネクション識別子とともに、特定したファイルデータの情報を渡す。

メタデータ読み出し指示部２０２は、渡されたファイル情報に基づき、ストレージ装置１３からファイルシステムのメタデータを読み出すべく、データ転送装置１１のコマンド発行部１０１にコマンド発行の指示を行う。ストレージ装置１３はこのコマンドに基づき、メタデータを読み出してエクステントマップ取得部２０３に渡す。エクステントマップ取得部２０３は、このメタデータ情報を解析し、読み出したいファイルのデータのエクステントマップを取得する。そして取得したエクステントマップ情報を、送信データ読み出し指示部２０４がデータ転送装置１１に渡し、データ転送装置１１に対してそのデータの読み出しと、前述のアプリケーションから渡されたコネクション識別子との情報を併せて渡し、送信の指示を行う。

データ転送装置１１では、まずフロー制御部１０５がその指示を受ける。フロー制御部１０５は、コネクション毎にエクステントマップ情報を保持する。つまり、複数のコネクションのデータ読み出し要求を一旦保持しておく。そして、バッファ管理部１０７からバッファに空きがあるコネクションの通知を受けると、そのコネクションの送信データの読み出し指示をコマンド発行部１０１に対して行う。初期状態では全てのコネクションのバッファは空いているので、そのままコマンド発行部１０１に送信データ読み出し指示を出すことになるが、同じコネクションのデータ送信要求が連続してくると、やがて一旦待ってからバッファ管理部１０７からの空き通知を待つ形になる場合がある。

コマンド発行部１０１に一度にコマンド発行要求するのはあくまでバッファが空いているサイズ以下でなければならない。一例として、データバッファ部１０６のコネクション毎のバッファが１２８ＫＢずつ確保されているとして、バッファ管理部１０７がいずれかのコネクションで６４ＫＢ以上バッファに空きが生じたら、そのコネクションのバッファ空きをフロー制御部１０５に通知するものとする。ホストＣＰＵ１２から渡されたエクステントマップはこれより大きいサイズのデータを示している場合も当然ながらあり得るが、フロー制御部１０５が一度にコマンド発行部１０１に要求可能なのは空いた分の６４ＫＢ以下のサイズの部分データなので、この部分データ（すなわち送信したいデータのうち、まだ読み出していない、当該サイズ以下のデータ）の読み出しをコマンド発行部１０１に要求する。同時に、この部分データの中の有効データ位置を送信データ抽出部１０３に渡す。そして、処理をし終えた部分データの位置を進捗情報としてコネクション毎に保持し、一旦コマンド発行要求を終える。

以上の処理を判り易く説明するため、データの一例を図６に示す。図６はホストＣＰＵ１２からブロック２３５〜１０００、有効位置データ情報としてオフセット１２４バイト、長さ３９１６０２バイトのエクステントマップを与えられた例を示している。この場合、最初の部分データは例えば６４ＫＢ以下の切りの良いところとしてブロック２３５〜３６２の６５４１２バイトとなる。そして、この部分データの有効データ位置はオフセット１２４バイト、長さ６５４１２バイトである。フロー制御部１０５はブロック２３５〜３６２の読み出しコマンドの発行をコマンド発行部１０１に要求し、同時に送信データ抽出部１０３にオフセット１２４、長さ６５４１２バイトという情報を渡し、進捗情報として次回処理するブロックはブロック３６３、あるいは、６５４１３バイト目、という情報を保持し、一旦処理を終え、バッファ管理部１０７からの次のバッファ空き通知を待つ。なお、以上で述べた６４ＫＢなどの各種データサイズはあくまで一例であり、この限りではない。また、データサイズは一定である必要もなく、サイズが毎回変わる場合も本発明に含まれる。

一旦部分データの処理を終え、その後に他のコネクションのデータバッファが空いたという通知をバッファ管理部１０７から受けると、フロー制御部１０５は、今度はそのコネクションに対して同様に部分データの読み出し要求処理を行う。そして、あるコネクションに関して与えられたエクステントマップが示すデータの全てを送信し終える（図６の場合は六番目の部分データの読み出し要求を完了する）と、そのコネクションの与えられたエクステントマップが示すすべてのデータの送信の完了となり、ホストＣＰＵ１２にその旨通知する。ホストＣＰＵ１２では例えばメタデータ読み出し指示部２０２がこの通知を受け取り、次のアプリケーションからのデータ送信処理、すなわちメタデータ読み出し指示部２０２から始まる一連の処理を実行可能とする。逆に、この通知を受けるまで、次のメタデータ読み出しをいったん保留することで、第一アプリ処理部２０１とのフロー制御を実現する。

なお、ホストＣＰＵ１２がこの通知を受けるのは必ずしもメタデータ読み出し指示部２０２である必要はなく、エクステントマップ取得部２０３、あるいは、送信データ読み出し指示部２０４でもよく、最終的にアプリケーションに対してバックプレッシャが伝達されるようになっていれば、どこが通知を受ける形でもよい。

また、以上の例ではデータ転送装置１１がコネクション毎に同時に一つしかエクステントマップを受け付けない例を示したが、二つ以上受け付ける形でもよい。いくつ受け付けるにしても必ず有限個にはなるので、その最大個数を受け付けた際にそれ以上受けられないような仕組みとして前述の方式が適用される。

コマンド発行部１０１と送信データ抽出部１０３の処理は図１と基本的に同様だが、送信データ抽出部１０３は、前述のとおりデータ有効位置情報をフロー制御部１０５から受け取り、その情報をもとに抽出したデータをデータバッファ部１０６に書き込む。データバッファ部１０６に書き込む際の宛先アドレスは、フロー制御部１０５が生成し、送信データ抽出部１０３に渡す。

例えば、データバッファ部１０６が前述の説明同様にコネクション毎に１２８ＫＢ確保されており、コネクション０のバッファの先頭アドレスが０ｘ００００００００、コネクション１のバッファの先頭アドレスがアドレス０ｘ０００２００００、コネクション２のバッファの先頭アドレスが０ｘ０００４００００、・・・のようにアサインされているとき、現在処理しているのはコネクション１で、初めて図６のデータ読み出しを要求されたとすると、最初の部分データの宛先アドレスは０ｘ０００２００００、次の部分データの宛先アドレスは６５４１３バイト加えた０ｘ０００２ｆｆ８５となる。このように宛先アドレスを部分データのサイズごとに増加させていくと、データバッファ部１０６にはもとの通りひとつながりのデータとして展開される。また、バッファが例えばバイト単位のリングバッファだとすると、０ｘ０００３ｆｆｆｆの次のバイトは０ｘ０００２００００に書き込むことになる。フロー制御部１０５は、送信データ抽出部１０３に対し、有効データ位置情報と共に、このような宛先アドレス情報を渡し、送信データ抽出部１０３がそれに従ったアドレスから抽出したデータを書き込むことで、データバッファ部１０６にコネクション毎に適切に送信データを展開することができる。

バッファ管理部１０７は、データバッファ部１０６のコネクション毎のデータバッファのデータの供給側の書き込み位置と、データの消費側の読み出し位置の常に把握し、コネクション毎にバッファの空き状態を把握する。

具体的には、フロー制御部１０５がコマンド発行部１０１に部分データの読み出し要求を行い、ストレージ装置１０３からその応答通知が返ってくると、フロー制御部１０５は当該コネクションのバッファにどこまでデータが書き込まれたか判るので、その位置を進捗としてバッファ管理部１０７に通知する。例えば図６の最初の部分データを書きこみ終わった際、６５４１３バイトという情報をコネクション識別子と添えて通知する。この通知によって、バッファ管理部１０７はコネクション１のバッファのデータの供給側の位置は６５４１３バイトと把握できる。

一方、通信処理部１０４がデータを送信すべくデータバッファ部１０６から読み出すと、その読み出し位置が移動するので、通信処理部１０４は、同様に読み出し終わったバイト位置（正確には次に読み出し始めるバイト位置）をコネクション毎にバッファ管理部１０７に通知する。

初期状態では、バッファは１２８ＫＢ（正確には２の１７乗の１３１０７２バイト）空いているが、最初にデータを書き込まれると６５４１３バイト減って空きサイズが６５６５９バイトになり、これは６４ＫＢ（正確には２の１６乗の６５５３６バイト）より大きいので、バッファ空き通知をフロー制御部１０５に行う。すると、フロー制御部１０５は次の部分データ（図６の例では６５５３６バイト）の読み出し要求を出すので、そのデータが書き込まれると、バッファサイズがさらに減って２３バイトになり、これは６４ＫＢより少ないので、バッファ管理部１０７は空き通知を行わず、フロー制御部１０５は次の部分データの読み出しを保留する。その後、通信処理部１０４がデータを例えば１ＫＢ（１０２４Ｂ）読み出すと、空きバッファサイズは１０４７バイトに増加する。引き続き通信処理部１０４がデータを読み出していき、空きサイズが６５５３６バイト以上になると、その段階でバッファ管理部１０７はフロー制御部１０５に空き通知を行う。

通信処理部１０４は、処理している通信プロトコル仕様やネットワーク１４の帯域などによって送信速度が制限される。例えばＴＣＰプロトコルのようにフロー制御や輻輳制御を行うような場合は、対向機やネットワーク１４の込み具合によって送信速度が低下し、データバッファ部１０６からのデータの読み出しの進み具合が遅くなるが、その場合でも、このような構成によって適切に最上位のアプリケーションまでのフロー制御を実現することができる。

以上、本発明の第二の実施の形態を説明した。以上のような形態をとることで、第一の実施の形態の効果に加えて、通信速度が遅くなっても適切にフロー制御を行うことができるようになる。また、通信コネクション毎にフロー制御を行うことができるので、あるコネクションのデータフローが止まっていても、それ以外のコネクションのデータフローには影響を与えないように動作することが可能である。

以上の実施の形態によりストレージ装置１３にあるデータを効率よく送信する例を示したが、アプリケーションによってはストレージ装置１３にないデータを、ストレージ装置１３のデータを送信するコネクションと同じコネクションで送信したくなる場合もある。例えば通信処理部１０４がＴＣＰ／ＩＰプロトコルより下位層の通信処理を行うときに、アプリケーションはそれより上位層のＨＴＴＰプロトコルに基づいた通信を行いたい場合に、ストレージ装置１３にあるデータとは別の制御情報をやりとりしたい場合や、あるいは、ストレージ装置１３にあるデータを送信する際にもデータのＨＴＴＰヘッダを送信する必要があるので、その場合はまずＨＴＴＰヘッダだけを送信してから、その次にボディとしてストレージ装置１３のデータを送信するように動作する必要がある。そのような動作を実現する構成を図７に示す。

図７は図６に加えて、ＨＴＴＰヘッダなどストレージ装置１３にないデータ（以下、アプリデータ）の送信を要求する第三アプリ処理部４０１と、その要求を受け付けアプリデータの書き込みをデータ転送装置１１に要求するアプリデータ書き込み要求部４０２と、アプリデータの書き込みを行うアプリデータ書き込み部４０３とを備える。アプリデータの流れは実線で示している。

具体的には次のように動作する。まず、第三アプリ処理部４０１が何らかの方法でアプリデータを用意する。これは例えばＨＴＴＰ通信を行っている場合だと通信手順やアプリケーションの状態やその他諸々の条件によって定められ、生成される。そして、そのアプリデータをデータ転送装置１１で送信すべく、アプリデータと送信するコネクション識別子を併せてアプリデータ書き込み要求部４０２に渡す形で送信を要求する。

アプリデータ書き込み要求部４０２はそれを受けると、フロー制御部１０５にそのアプリデータのサイズとともにデータの書き込みの要求を行う。

フロー制御部１０５はそれを受けると、その書き込み要求を一旦保持し、バッファ管理部１０７からの空き通知を待ち、バッファ管理部１０７からバッファの空き通知が来次第、書き込み許可を意味する応答をアプリデータ書き込み要求部４０２に返す。

するとアプリデータ書き込み要求部４０２はアプリデータ書き込み部４０３に書き込みを指示し、アプリデータ書き込み部４０３は実際にデータバッファにアプリデータの書き込みを行う。

書き込みが終わると、フロー制御部１０５がストレージ装置１３のデータを読み出してデータバッファ部１０６に書き込む際と同様に、書き込んだ位置を進捗としてバッファ管理部１０７に対して通知する。

以上の一連の処理を完了すると、第三アプリ処理部４０１に送信完了を通知する。通信処理部１０４はストレージからのデータと同様にこのデータを読み出し、送信する。

アプリデータのサイズがバッファ管理部１０７のバッファ空き通知を行うサイズ（先程の例だと６４ＫＢ）より大きい場合は、６４ＫＢだけ書き込めることになるので、その場合はアプリデータ書き込み部４０３はそのサイズまでの書き込みを行い、さらにまだ書き込んでいないデータがある場合は、再度アプリデータ書き込み要求部４０２がフロー制御部１０５に書き込み要求を出し、以下、書き込みたいデータがなくなるまで同様に処理を繰り返す。

また、通信ヘッダなどアプリデータの書き込みサイズが非常に小さい場合は、バッファ管理部１０７から通知してもらう空きサイズを、例えばアプリデータのサイズにしてもらうべく、フロー制御部１０５からバッファ管理部１０７にサイズ変更の指示を行ってもよい。例えば２０バイトのアプリデータを送信したい場合、フロー制御部１０５はバッファ管理部１０７に対し、次に２０バイトの空きが生じたら通知するように指示を行い、バッファ管理部１０７はそれに従う。これによって無駄にバッファが空くのを待つ必要がなくなる。

以上のように動作することにより、ストレージ装置１３のデータを送信する通信コネクションと同じ通信コネクションで任意のアプリケーションデータを送信することができる。

また、第三アプリ処理部４０１によって行われるアプリデータの送信要求処理は、例えばＬｉｎｕｘ ＯＳなどで実装されているｓｅｎｄ（）関数のような標準システムコールでＩ／Ｆし、この関数内の処理を前述の動作を実現できるようにするような実施の形態が望ましい。このような標準関数でアプリケーションとＩ／Ｆすることにより、既存のアプリケーションに改変を加える必要がなくなり、本発明の実施を容易にすることができる。

本発明の態様は、上述した個々の実施形態に限定されるものではなく、当業者が想到しうる種々の変形も含むものであり、本実施形態の効果も上述した内容に限定されない。すなわち、特許請求の範囲に規定された内容およびその均等物から導き出される本実施形態の概念的な思想と趣旨を逸脱しない範囲で種々の追加、変更および部分的削除が可能である。

上述した実施形態で説明したデータ送信システムの少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ソフトウェアで構成する場合には、データ送信システムの少なくとも一部の機能を実現するプログラムをフレキシブルディスクやＣＤ−ＲＯＭ等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の着脱可能なものに限定されず、ハードディスク装置やメモリ等の固定型の記録媒体でもよい。

また、データ送信システムの少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。

Claims (10)

1. ブロック単位でデータを管理するストレージ装置に記憶されているファイルのデータを読み出して送信するデータ転送装置であって、
   第一ファイルのデータが前記ストレージ装置のどの位置に記憶されているかを示す第一マップ情報を含むメタデータを受け取って前記メタデータを解析することにより前記第一マップ情報を取得する外部のホストＣＰＵにより取得された前記第一マップ情報に基づく前記第一ファイルのデータの読み出し指示に基づき、前記第一ファイルのデータを格納したブロックの読み出しコマンドを生成し、前記読み出しコマンドを前記ストレージ装置に送る発行部と、
   前記読み出しコマンドに応じて前記ストレージ装置から読み出されるブロックデータを受け取り、前記外部のホストＣＰＵから前記第一マップ情報を受け取り、前記第一マップ情報に基づき、前記ブロックデータから前記第一ファイルのデータを抽出する送信データ抽出部と、
   前記送信データ抽出部により抽出された前記第一ファイルのデータを送信する通信処理部と、
   を備えたデータ転送装置。
2. 前記外部のホストＣＰＵからの要求を受けて、前記第一マップ情報を含むメタデータの読み出しコマンドを生成し、前記読み出しコマンドを前記ストレージ装置に送る第一発行部をさらに備え、
   前記外部のホストＣＰＵは、前記読み出しコマンドに応じて前記ストレージ装置から送出されるメタデータを受け取る
   請求項１に記載のデータ転送装置。
3. 通信カードとして構成された
   ことを特徴とする請求項１または２に記載のデータ転送装置。
4. ブロック単位でデータを管理するストレージ装置に記憶されているファイルのデータを送信するデータ送信システムであって、
   ＣＰＵとデータ転送装置とを備え、
   前記ＣＰＵは、
   前記ストレージ装置に格納された第一ファイルのデータの送信指示を生成する第一アプリ処理部と、
   前記送信指示に基づき、前記第一ファイルのデータが前記ストレージ装置上のどの位置に記憶されているかを示す第一マップ情報を含むメタデータの読み出し指示を生成するメタデータ読み出し指示部と、を備え、
   前記データ転送装置は
   前記メタデータの読み出し指示に基づき、前記メタデータの読み出しコマンドを生成し、前記ストレージ装置に送る第一発行部を備え、
   前記ＣＰＵは、前記ストレージ装置から返される前記メタデータを受け取って前記メタデータを解析することにより前記第一マップ情報を取得し、前記第一マップ情報に基づき前記第一ファイルのデータの読み出し指示を生成する送信データ読み出し指示部を備え、
   前記データ転送装置は、前記第一ファイルのデータの読み出し指示に基づき、前記第一ファイルのデータを格納したブロックの読み出しコマンドを生成し、前記読み出しコマンドを前記ストレージ装置に送る第二発行部と、
   前記読み出しコマンドに応じて前記ストレージ装置から読み出されるブロックデータを受け取り、前記第一マップ情報に基づき、前記ブロックデータから前記第一ファイルのデータを抽出する送信データ抽出部と、
   前記送信データ抽出部により抽出された前記第一ファイルデータを、送信する通信処理部と、
   を備えたデータ送信システム。
5. 前記ＣＰＵは、
   第二アプリ処理部と、
   アプリデータ読み出し指示部と、
   アプリデータ抽出部と、をさらに備え、
   前記第二アプリ処理部は、第二ファイルのデータの取得指示を生成し、
   前記第一発行部は、前記取得指示に基づき、前記第二ファイルのデータが前記ストレージ装置上のどの位置に記憶されているかを示す第二マップ情報を含むメタデータの読み出しコマンドを生成して、前記ストレージ装置に送り、
   前記アプリデータ読み出し指示部は、前記ストレージ装置から返される前記メタデータを受け取り、前記メタデータを解析することにより前記第二マップ情報を取得し、前記第二マップ情報に基づく前記第二ファイルのデータの読み出し指示を生成し、
   前記第二発行部は、前記第二ファイルのデータの読み出し指示に基づき、前記第二ファイルのデータを格納したブロックの読み出しコマンドを生成し、前記読み出しコマンドを前記ストレージ装置に送り、
   前記アプリデータ抽出部は、前記ストレージ装置から読み出されるブロックデータを受け取り、前記第二マップ情報に基づき、前記ブロックデータから前記第二ファイルのデータを抽出し、抽出したデータを前記第二アプリ処理部に渡すことを特徴とする請求項４に記載のデータ送信システム。
6. 前記データ転送装置は、
   フロー制御部と、
   データバッファ部と、
   バッファ管理部をさらに備え、
   前記第一アプリ処理部は、前記第一ファイルのデータを送信するコネクションを指定し、
   前記データバッファ部は、コネクション毎のバッファを有し、前記送信データ抽出部により抽出されたデータを、前記第一アプリ処理部により指定されたコネクションに対応するバッファにバッファリングし、
   前記通信処理部は、前記データバッファにおける前記バッファから前記データを読み出して送信し、
   前記バッファ管理部は、前記指定されたコネクションに対応する前記バッファの空き状態を把握し、
   前記フロー制御部は、前記送信データ読み出し指示部による前記送信データ読み出し指示を受け、読み出し指示された前記第一ファイルのデータのうち、まだ読み出されていない、前記空き状態に応じたサイズ分のデータの読み出し指示を生成して、前記第二発行部に送る、
   ことを特徴とする請求項４に記載のデータ送信システム。
7. 前記ＣＰＵは、
   第三アプリ処理部と、
   アプリデータ書き込み要求部と、
   アプリデータ書き込み部と、をさらに備え、
   前記第三アプリ処理部は、前記ストレージ装置上に存在しないアプリデータの送信指示を生成し、前記アプリデータを送信するコネクションを指定し、
   前記バッファ管理部は、前記第三アプリ処理部により指定されたコネクションに対応するバッファの空き状態を把握し、
   前記フロー制御部は、前記バッファの空き状態に応じたサイズ分のデータの書き込み許可信号を生成し、
   前記アプリデータ書き込み部は、前記書き込み許可信号に基づいて、前記アプリデータのうち、まだ書き込んでいない前記サイズ分のデータを特定して、前記バッファに書き込み、
   前記通信処理部は、前記コネクションに対応するバッファからデータを読み出して送信する、
   ことを特徴とする請求項６に記載のデータ送信システム。
8. 前記第三アプリ処理部は、前記第一アプリ処理部と同じコネクションを指定する
   ことを特徴とする請求項７に記載のデータ送信システム。
9. ブロック単位でデータを管理するストレージ装置に記憶されているファイルデータを読み出して送信するデータ送信方法であって、
   ＣＰＵが前記ストレージ装置に格納された第一ファイルのデータの送信指示を生成するステップと、
   前記ＣＰＵが、前記送信指示に基づき、前記第一ファイルのデータが前記ストレージ装置上のどの位置に記憶されているかを示す第一マップ情報を含むメタデータの読み出し指示を生成するステップと、
   データ転送装置が、前記メタデータの読み出し指示に基づき、前記メタデータの読み出しコマンドを生成し、前記ストレージ装置に送るステップと、
   前記ＣＰＵが、前記ストレージ装置から返される前記メタデータを受け取って解析することにより前記メタデータに含まれる第一マップ情報を取得し、前記第一マップ情報に基づき前記第一ファイルのデータの読み出し指示を生成するステップと、
   前記データ転送装置が、前記第一ファイルのデータの読み出し指示に基づき、前記第一ファイルのデータを格納したブロックの読み出しコマンドを生成し、前記読み出しコマンドを前記ストレージ装置に送るステップと、
   前記データ転送装置が、前記読み出しコマンドに応じて前記ストレージ装置から読み出されるブロックデータを受け取り、前記第一マップ情報に基づき、前記ブロックデータから前記第一ファイルのデータを抽出するステップと、
   前記データ転送装置が、前記抽出された前記第一ファイルデータを送信するステップと、
   を備えたデータ送信方法。
10. ブロック単位でデータを管理するストレージ装置に記憶されているファイルのデータを読み出して送信するためのデータ転送プログラムであって、
    第一ファイルのデータが前記ストレージ装置のどの位置に記憶されているかを示す第一マップ情報を含むメタデータを受け取って解析することにより前記第一マップ情報を取得する外部のホストＣＰＵにより取得された前記第一マップ情報に基づく前記第一ファイルのデータの読み出し指示に基づき前記第一ファイルのデータを格納したブロックの読み出しコマンドを生成し、前記読み出しコマンドを前記ストレージ装置に送る発行手順と、
    前記読み出しコマンドに応じて前記ストレージ装置から読み出されるブロックデータを受け取り、前記外部のホストＣＰＵから前記第一マップ情報を受け取り、前記第一マップ情報に基づき、前記ブロックデータから前記第一ファイルのデータを抽出する送信データ抽出手順と、
    前記送信データ抽出手順により抽出された前記第一ファイルのデータを送信する通信処理手順と、
    をコンピュータに実行させるためのデータ転送プログラム。

Images