JP2009289085A

JP2009289085A - 情報処理システム

Info

Publication number: JP2009289085A
Application number: JP2008141686A
Authority: JP
Inventors: Yoshiki Ura; 圭希浦; Jun Yamamoto; 潤山本
Original assignee: Media Logic Corp
Current assignee: Media Logic Corp
Priority date: 2008-05-29
Filing date: 2008-05-29
Publication date: 2009-12-10
Anticipated expiration: 2028-05-29
Also published as: WO2009144833A1; JP4391569B2

Abstract

【課題】まとまった容量のデータを転送する情報処理システムにおいて、デバイス側のリード、ライト速度を向上させることができる情報処理システムを提供する。
【解決手段】下位側ドライバ１５２は、上位側からリード、ライト要求を受信し、転送されるデータをキャッシュする。ライト時には上位側から受信したデータをキャッシュし、所定のサイズ（１ＭＢ以上）のデータとしてまとめて下位側に送信する。リード時には下位側から１ＭＢ以上のデータをまとめて読み出し、上位側に送信する。コントローラ２２は、１ＭＢ以上のリード、ライト要求があった場合に、１ＭＢ以下のデータをリード、ライトするように、複数のコマンドに分割する。
【選択図】図５

Description

この発明は、パーソナルコンピュータおよびその外付周辺機器からなる情報処理システムに関し、特に、データ転送を高速化する情報処理システムに関する。

パーソナルコンピュータ（以下、ＰＣと言う。）のオペレーティングシステム（以下、ＯＳと言う。）が周辺機器を正常に認識、制御するためにはデバイスドライバというソフトウェアが必要になる。

近年のＰＣに搭載されるＯＳには、標準のデバイスドライバが多数組み込まれている。したがって、ＯＳは、標準的な周辺機器が接続された場合には、標準のデバイスドライバを自動的に割り当て、接続された周辺機器を認識、制御する。

しかし、標準のデバイスドライバは、各周辺機器に対して最適化されておらず、デバイスドライバが制御する転送速度よりも高速に動作する周辺機器（例えば高速にリード／ライトする外付ＨＤＤ等）が存在した場合であっても、標準のデバイスドライバが速度を制限してしまう。また、アプリケーションが速度を制限する場合もある。

特に、一般的なＯＳであるＷｉｎｄｏｗｓ（登録商標）の場合、ＵＳＢマスストレージデバイス（外付ＨＤＤ等）を接続してデータ転送を行なうと、Ｗｉｎｄｏｗｓ（登録商標）標準搭載のアプリケーションまたはデバイスドライバが６４ｋＢ毎にデータを区分し、ＵＳＢマスストレージドライバは区分したデータ毎にコマンド、ステータス等の情報を付加する。このコマンド、ステータス等の情報を処理する時間は長く（数百μｓｅｃ）、データ転送速度が低下する要因となっていた。

図１に、ＯＳ上に搭載されている各種ドライバの機能ブロック図を示す。同図において、アプリケーション５１、汎用ディスクドライバ５２、ＵＳＢマスストレージドライバ５３、およびＵＳＢホストコントローラドライバ５４は、ＯＳ上に搭載されている機能部である。

アプリケーション５１は、各種ドライバを介してＵＳＢマスストレージデバイス５５（例えば外付ＨＤＤ）にリードまたはライトの要求を行う。同図においては、アプリケーション５１がライトの要求を行い、データ転送する例を示す。アプリケーション５１は、汎用ディスクドライバ５２に、ライト要求を行い、データを転送する。汎用ディスクドライバ５２は、このデータを下位側であるＵＳＢマスストレージドライバ５３に転送する。このとき、ＵＳＢマスストレージドライバ５３のデータ転送サイズの上限が６４ｋＢのため、汎用ディスクドライバ５２は６４ｋＢ毎にデータを分割する。ＵＳＢマスストレージドライバ５３は、この６４ｋＢ毎に分割されたデータにコマンド、ステータスを付与して、順次、ＵＳＢホストコントローラドライバ５４に転送する。ＵＳＢホストコントローラドライバ５４は、このコマンド、データ、ステータスをＵＳＢバルク転送方式にて、順次、ＵＳＢマスストレージデバイス５５へ転送する。

図２は、汎用ディスクドライバ５２、およびＵＳＢマスストレージドライバ５３が転送するデータ（バルクオンリープロトコル）の構成を示した概念図である。同図に示すように、汎用ディスクドライバ５２は、６４ｋＢにデータを分割し、ＵＳＢマスストレージドライバ５３は、各データ部にコマンド、ステータスを付与し、順次、ＵＳＢホストコントローラドライバ５４に転送する。さらに、ＵＳＢホストコントローラドライバ５４は、このコマンド、６４ｋＢに分割されたデータ、ならびにステータスを順次、ＵＳＢマスストレージデバイス５５にデータを転送する。これにより、アプリケーション５１はＵＳＢマスストレージデバイス５５にライトを行う。

ＵＳＢマスストレージドライバ５３、ＵＳＢホストコントローラドライバ５４、およびＵＳＢマスストレージデバイス５５がコマンドおよびステータスを処理する時間は、ＵＳＢ２．０規格の環境下では５００μｓｅｃ程度である。すると、６４ｋＢのデータを転送する毎にコマンド、ステータスの処理時間あわせて５００μｓｅｃ程度の遅延が発生することになり、転送する総データ量が６４ｋＢ以上であると、データ転送速度が低下する。

また、図１に示すように、アプリケーション５１が直接ＵＳＢマスストレージドライバ５３にデータを転送する場合であっても、ＵＳＢマスストレージドライバ５３のデータ転送サイズの上限が６４ｋＢのため、アプリケーション５１は、６４ｋＢ毎にデータを分割し、ＵＳＢマスストレージドライバ５３は、各データ部にコマンド、ステータスを付与し、順次、ＵＳＢホストコントローラドライバ５４に転送する。なお、ドライバ側に６４ｋＢのデータ転送サイズの上限が存在しない場合で、かつアプリケーション５１が６４ｋＢより大きいデータの転送を行なう場合であってもアプリケーション側で６４ｋＢ毎にデータを分割する場合もある（例えばＷｉｎｄｏｗｓ（登録商標）標準搭載のエクスプローラなど）。

そのため、いずれにしても、転送する総データ量が所定量以上となると、転送速度が低下するという問題が発生していた。

一方で、従来、ホスト装置と下位側の装置との転送速度を向上させる手法として、複数のホスト装置から受信したコマンドを統合し、受信したデータをキャッシュしてからまとめてデータを転送することで、レスポンス性能を向上させるものが提案されている（例えば特許文献１参照）。

しかし、特許文献１に記載の手法では、上位側（汎用ディスクドライバ５２やＵＳＢマスストレージドライバ５３）から順次コマンドが送信されてくる場合、コマンドを統合する機会が得られなかった。すなわち、上位側のドライバでは、下位側からコマンド終了を示す旨を受信した後に次のコマンドを送信するため、特許文献１に記載の手法のように、単に下位側でデータをキャッシュして複数のコマンドを受信するまで待機していては、次のコマンドを受信することができず、コマンド統合の機会を得ることができなかった。

そこで、図３に示すように、コマンドを分割するドライバの下位側に専用のドライバ（下位側ドライバ１５２）を設けることが考えられる。下位側ドライバ１５２は、６４ｋＢのデータを受信する度に上位側に対してコマンド終了を擬似的に返信し、データをキャッシュする。この場合、下位側ドライバ１５２が、上位側から順次コマンドを受信し、６４ｋＢ以上のデータをまとめて転送（コマンドを生成）することができる。
特開２００６−３０９５７９号公報

上記の手法を用いることで、ＰＣと周辺機器とのデータ転送速度を向上させることができる。しかし、周辺機器によっては、あるサイズ以下のデータをリード、ライトするように最適化されている場合がある。この場合、特許文献１の装置や、従来の手法では、周辺機器側の最適な速度でリード、ライトを実行することができなかった。

そこで、この発明は、まとまった容量のデータを転送する情報処理システムにおいて、周辺機器側のリード、ライト速度を向上させることができる情報処理システムを提供することを目的とする。

この発明の情報処理システムは、パーソナルコンピュータと、パーソナルコンピュータに接続される周辺機器と、からなる情報処理システムであって、前記パーソナルコンピュータは、前記周辺機器に対するリードまたはライトの要求を複数のコマンドに分割して順次送信する汎用ドライバと、前記汎用ドライバの下位側に配置される下位側ドライバと、前記リードまたはライトの要求に対応するデータをキャッシュするキャッシュメモリと、前記下位側ドライバがライトの要求を受信したとき、各コマンドに対するコマンド終了を擬似的に上位側に返信するとともに、上位側から転送されるデータを順次前記キャッシュメモリにキャッシュし、前記汎用ドライバが分割する各コマンドあたりのデータ転送サイズの上限よりも大きいデータ転送サイズのコマンドを発行して前記キャッシュメモリのデータを前記周辺機器に転送し、前記下位側ドライバがリードの要求を受信したとき、前記汎用ドライバが分割する各コマンドあたりのデータ転送サイズの上限よりも大きいデータ転送サイズのコマンドを発行して前記周辺機器からデータを読み出して前記キャッシュメモリにキャッシュする予測処理を行う制御部と、を備え、前記周辺機器は、前記パーソナルコンピュータから転送されたリードまたはライトのコマンドが所定のサイズよりも大きいデータをリードまたはライトするものであった場合、当該コマンドを前記所定のサイズ以下のデータをリードまたはライトするものとなるように複数のコマンドに分割するコマンド分割部を備えたことを特徴とする。

このように、周辺機器側において、所定のサイズ（例えば１ＭＢ）よりも大きいデータをリード、ライトするコマンドが転送された場合、所定のサイズ以下のデータをリード、ライトするように、複数のコマンドに分割する。そして、各コマンドに対応してデータをリード、ライトする。これにより、ＰＣのドライバで複数コマンドを統合してまとまった容量のデータを転送する場合において、周辺機器側のリード、ライト速度を向上させることができる。

また、この発明の情報処理システムは、パーソナルコンピュータと、パーソナルコンピュータに接続される周辺機器と、からなる情報処理システムであって、前記パーソナルコンピュータは、前記周辺機器に対するリードまたはライトの要求を複数のコマンドに分割して順次送信する汎用ドライバと、前記汎用ドライバの下位側に配置される下位側ドライバと、前記汎用ドライバの上位側に配置される上位側ドライバと、前記周辺機器に対するリードまたはライトの要求を前記上位側ドライバから前記下位側ドライバに直接転送するリード、ライト要求受信部と、前記下位側ドライバにおいて、前記上位側ドライバから転送された前記リードまたはライトの要求に応じたリードまたはライトのコマンドを発行してデータ転送を行う制御部と、を備え、前記周辺機器は、前記パーソナルコンピュータから転送されたリードまたはライトのコマンドが所定のサイズよりも大きいデータをリードまたはライトするものであった場合、当該コマンドを前記所定のサイズ以下のデータをリードまたはライトするものとなるように複数のコマンドに分割するコマンド分割部を備えたことを特徴とする。

このように、コマンドを分割する汎用ドライバを回避するように、上位側ドライバと下位側ドライバを設けた場合であっても、周辺機器側で所定のサイズ以下のデータをリード、ライトするように複数のコマンドに分割するため、周辺機器側のリード、ライト速度を向上させることができる。

また、上記発明において、前記コマンド分割部は、その周辺機器の仕様に応じて、前記所定のサイズを変更することも可能である。

コマンド分割部は、周辺機器の仕様として、例えば、周辺機器側に設けられているキャッシュの容量に応じて分割サイズを設定する。また、メーカ名や型番等の情報を取得するようにしてもよい。この場合、メーカ名や型番等と最適なサイズとを予め対応づけたデータベースを用意しておき、このデータベースを参照することにより、最適な分割サイズを設定する。
なお、上記下位側ドライバが周辺機器の仕様を示す情報を取得し、その仕様に応じて、コマンド分割部に分割サイズの変更を設定指示するようにしてもよい。

この発明によれば、ＰＣ側からまとまった容量のデータを転送するコマンドが周辺機器に送信された場合において、周辺機器側のリード、ライト速度を向上させることができる。

ＰＣに搭載されるＯＳで一般的に普及しているものとしてＷｉｎｄｏｗｓ（登録商標）がある。本実施形態では、Ｗｉｎｄｏｗｓ（登録商標）ＸＰを搭載しているＰＣに、ＵＳＢインタフェースの外付ＨＤＤを接続する場合について、図を用いて説明する。なお、本発明においてＯＳの種別や接続デバイスの種別、インタフェースを限定するものではない。

図４は、本実施形態におけるＰＣと外付ＨＤＤのブロック図である。ＰＣ１と外付ＨＤＤ２はＵＳＢインタフェース（Ｉ／Ｆ）で接続される。ＰＣ１は、全体を管理するＯＳ１１上に、種々の処理を行うアプリケーション１０１、および周辺機器を動作させるための各種ドライバが含まれるドライバ１０２を搭載している。アプリケーション１０１は、ドライバ１０２、ＵＳＢコントローラ１２、およびＵＳＢＩ／Ｆ１３を介して外付ＨＤＤ２に記憶されているデータを読み出し（リード）、外付ＨＤＤ２にデータを書き込む（ライト）。

外付ＨＤＤ２は、コントローラ２２がＵＳＢＩ／Ｆ２１を介してリードまたはライトの要求を受信し、これに応じてＨＤＤ２３に記憶されているデータをリード、またはＨＤＤ２３にデータをライトする。また、本実施形態の外付ＨＤＤ２は、コントローラ２２が、ＰＣ１側から転送されたコマンドを分割し、ＨＤＤ２３に所定のサイズ（例えば１ＭＢ）以下の小さいデータでリード、ライトするものである（本発明のコマンド分割部に相当する）。

図５は、ＯＳ１１上に搭載されている各種ドライバおよび外付ＨＤＤ２の機能ブロック図である。同図において、アプリケーション１０１、汎用ディスクドライバ５０２、ＵＳＢマスストレージドライバ５０３、ＵＳＢホストコントローラドライバ５０４、上位側ドライバ１５１、および下位側ドライバ１５２は、ＯＳ１１上に搭載されている機能部である。実際には、これらの機能部は、ＯＳ１１にインストールされるソフトウェアとして実現する。

アプリケーション１０１は、ドライバ１０２に含まれる各種ドライバを介して外付ＨＤＤ２にリードまたはライトの要求を行う。同図においては、アプリケーション１０１がライトの要求を行い、データ転送する例を示す。

アプリケーション１０１は、上位側ドライバ１５１に、ライト要求を行い、外付ＨＤＤ２のＨＤＤ２３に書き込むべきデータを転送する。上位側ドライバ１５１は、このライト要求およびデータを下位側である汎用ディスクドライバ５０２に転送するとともに、アプリケーション１０１からライト要求があった旨、およびそのデータ量を示す情報をアクセス情報として下位側ドライバ１５２に送信する。上位側ドライバ１５１が下位側ドライバ１５２に転送するアクセス情報については後に詳しく述べる。

汎用ディスクドライバ５０２は、上位側ドライバ１５１から受信したデータをＵＳＢマスストレージドライバ５０３に転送する。このとき、ＵＳＢマスストレージドライバ５０３のデータ転送サイズの上限が６４ｋＢであるため、汎用ディスクドライバ５０２は、６４ｋＢ毎に分割してＵＳＢマスストレージドライバ５０３にデータを転送する。

ＵＳＢマスストレージドライバ５０３は、バルクオンリープロトコル（図２参照）によりデータ転送を行うため、この６４ｋＢに分割されたデータにコマンド、ステータスを付与し、順次、下位側ドライバ１５２に転送する。

下位側ドライバ１５２は、ＵＳＢマスストレージドライバ５０３から転送されたデータをキャッシュし、所定のタイミングでＵＳＢホストコントローラドライバ５０４に転送する。ＵＳＢホストコントローラドライバ５０４は、図４で示したＵＳＢホストコントローラ１２、ＵＳＢＩ／Ｆ１３を介して、このデータを外付ＨＤＤ２に転送する。なお、図５においてはＵＳＢホストコントローラ１２、ＵＳＢＩ／Ｆ１３、およびＵＳＢＩ／Ｆ２１を省略している。下位側ドライバ１５２が、ＵＳＢマスストレージドライバ５０３から転送されたデータをキャッシュし、ある程度の容量（６４ｋＢ以上）のデータとして、まとめてＵＳＢホストコントローラドライバ５０４に転送するため、コマンド、ステータスの発行が１度で（あるいは６４ｋＢ毎に付与するよりも少なくて）済む。したがって、コマンド、ステータスの処理時間による遅延が最小限で済む。なお、汎用ディスクドライバ５０２から下位側ドライバ１５２まで転送されるデータは、６４ｋＢ毎にコマンド、ステータスが付与されているが、この転送は、ＯＳ上のメモリ（ＲＡＭ）転送であるため、外付ＨＤＤ２へのデータ転送速度に比較して非常に高速である（ＲＡＭ転送速度に依存する）。

また、この実施形態において、アプリケーション１０１が直接ＵＳＢマスストレージドライバ５０３にデータ転送する場合があるが、上記と同様、ＵＳＢマスストレージドライバ５０３のデータ転送サイズの上限が６４ｋＢであるため、アプリケーション１０１が６４ｋＢ毎に分割してデータを転送し、ＵＳＢマスストレージドライバ５０３がコマンド、ステータスを付与したデータを転送する。この場合においても、下位側ドライバ１５２がデータをキャッシュしてから下位側にデータ転送するため、コマンド、ステータスの処理時間による遅延が最小限で済む。

外付ＨＤＤ２のコントローラ２２は、ＵＳＢＩ／Ｆ２１を介して、上記転送されたコマンドを受信する。ここで、コントローラ２２は、このコマンドを所定のサイズ（例えば１ＭＢ以下）に分割し、上位側から転送されるデータを順次、ＨＤＤ２３にライトする処理を行う。すなわち、コントローラ２２は、ライトのコマンドを受信したとき、１ＭＢよりも大きいデータをライトするものであるか否かを判断し、１ＭＢ以下であればそのままライトコマンドを実行し、１ＭＢよりも大きい場合、当該コマンドを１ＭＢ以下のデータをライトするものとなるように複数のコマンドに分割する。例えば転送されたコマンドが３ＭＢのデータをライトするものであった場合、これを１ＭＢのデータをライトするコマンドに３分割する。これにより、外付ＨＤＤ２が１ＭＢ以下のデータをライトするように最適化されている場合において、コントローラ２２が１ＭＢ以下のデータに分割してライトするため、デバイス側（外付ＨＤＤ２側）のライト速度を向上させることができる。

なお、分割するサイズは１ＭＢに限らず、上記のように６４ｋＢ毎に分割してもよい。この場合、ＰＣ側が複数コマンドに分割することを想定して、６４ｋＢＢ以下のデータをライトするように最適化されている周辺機器においても、ライト速度を向上させることができる。例えば、工場出荷時等において、デバイス毎に最適なライト速度となるように、コントローラ２２が分割するサイズを規定する（ファームウェアを設定しておく）。

また、上記コントローラ２２や下位側ドライバ１５２において、分割するサイズを変更するようにしてもよい。例えば、下位側ドライバ１５２が、そのデバイスのメーカ名や型番等の情報を取得し、最適な分割サイズを設定する。この場合、メーカ名や型番等と最適なサイズとを予め対応づけてデータベース化しておく。下位側ドライバ１５２は、メーカ名や型番等の情報を取得して当該データベースを参照することにより、最適な分割サイズを読み出し、これをコントローラ２２に設定する。

また、デバイス側に設けられているキャッシュの容量に応じて分割サイズを設定してもよい。いずれにしても、デバイスの仕様に応じて、最適な分割サイズの設定方法をとればよい。

次に、上位側ドライバ１５１および下位側ドライバ１５２の詳細な動作について説明する。図６は、上位側ドライバ１５１および下位側ドライバ１５２の詳細な構成を示す機能ブロック図である。なお、図５と共通する構成については同一の符号を付し、その説明を省略する。上位側ドライバ１５１は、リード、ライト要求受信部１５５を備えている。また、下位側ドライバ１５２は、コントローラ（制御プログラム）１５６、データベース１５７、キャッシュメモリ１５８Ａ〜１５８Ｃ、タイマ１５９、およびコマンドキュー１６０を備えている。なお、データベース１５７やキャッシュメモリ１５８Ａ〜１５８Ｃ、コマンドキュー１６０は、ＰＣ１に搭載されているＲＡＭにより実現される。また、リード、ライト要求受信部１５５やコントローラ１５６は、ソフトウェアにより実現される。

リード、ライト要求受信部１５５は、アプリケーション１０１からリードまたはライトの要求を受信する。リード、ライト要求受信部１５５は、この要求を下位側の汎用ディスクドライバ５０２に転送するとともに、要求の内容をアクセス情報として下位側ドライバ１５２に送信する。リードまたはライトの要求は、汎用ディスクドライバ５０２、およびＵＳＢマスストレージドライバ５０３を介して下位側ドライバ１５２に転送される。

アクセス情報には、ＬＢＡ（Logical Block Addressing：ＨＤＤのセクタ指定番号）、転送ブロック数、転送方向などが記載されている。転送ブロック数は転送データの容量を示す。転送方向は、下位側から上側への転送（リード）であるか、上位側から下位側への転送（ライト）であるかを示す情報である。

このアクセス情報は、下位側ドライバ１５２のデータベース１５７に予想データベースとして記憶される。下位側ドライバ１５２のコントローラ１５６は、ＵＳＢマスストレージドライバ５０３からリードまたはライトの要求を受信したとき、データベース１５７を参照する。予想データベースを参照することで、転送データ容量を予測することができる。

また、コントローラ１５６は、ＵＳＢマスストレージドライバ５０３から受信したリードまたはライトの要求を履歴データベースとしてデータベース１５７に記憶する。履歴データベースは、コントローラ１５６が予想データベースを作成、修正する場合に用いられる。すなわち、ＵＳＢマスストレージドライバ５０３からリードまたはライトの要求を受信したとき、過去の履歴データベースを参照し、ＬＢＡ、転送ブロック数、転送方向が同一または一部一致する（類似する）ものを予想データベースとして転記する。また、一致する履歴が存在した場合、これと関連する履歴（例えばＬＢＡと転送ブロック数に基づいて、連続して要求があったと判断できるもの）をまとめ、１つのコマンドとして予想データベースに記憶することもできる。なお、履歴データベースは、同図においてはデータベース１５７内に記憶され、ＰＣ１のＲＡＭ上に一時的に記憶されているが、これをＰＣ１のＯＳ１１（ＰＣ１のＨＤＤ）上、または外付ＨＤＤ２のＨＤＤ２３に記憶しておいてもよい。これにより、外付ＨＤＤ２を再接続したときやＰＣ１を再起動したときにおいても過去の履歴を参照することができる。

コントローラ１５６は、ＵＳＢマスストレージドライバ５０３から転送された要求がライトの要求であれば、予想データベースの転送ブロック数を参照することで、転送データ容量を予測することができる。このとき、上位側ドライバ１５１が下位側ドライバ１５２に、アクセス情報を送信して予想データベースに記憶されている場合は、転送データ容量（ライトすべき全データ）を予測することができる。コントローラ１５６は、６４ｋＢ以上のデータ転送が行われると予測した場合、上位側から転送されたデータをキャッシュメモリ１５８Ａ〜１５８Ｃのいずれかに格納する。

キャッシュメモリ１５８Ａ〜１５８Ｃは、ＲＡＭ上に仮想的に形成されたエリアであり、その数および容量はコントローラ１５６が設定する。キャッシュメモリの数および容量は、適宜設定し得るが、同図の例では、３つのキャッシュメモリを用意し、それぞれ４ＭＢの容量を設定しているものとする。なお、動作中にキャッシュメモリの数および容量を変化させることも可能である。キャッシュメモリの数および容量はユーザが手動で設定するようにしてもよいし、後述のように動作状態に応じて適宜変化させるようにしてもよい。

上記のように、コントローラ１５６は、キャッシュメモリ１５８Ａ〜１５８Ｃのうち、いずれか１つに上位側から転送されたデータを順次、格納する。このライト用のデータを格納したキャッシュメモリがライト用キャッシュメモリとなる。ただし、ＵＳＢマスストレージドライバ５０３から６４ｋＢ毎にコマンド、ステータスが付与されてデータ転送されるため、コントローラ１５６は、６４ｋＢのデータを受信する度に、ＵＳＢマスストレージドライバ５０３に対してコマンド終了を擬似的に返信する。これにより、ＵＳＢマスストレージドライバ５０３から順次コマンドを受信することができ、複数のコマンドを統合することができる。

コントローラ１５６は、所定のタイミングで下位側のＵＳＢホストコントローラドライバ５０４に対し、ライト要求を行い、ライト用キャッシュメモリのデータを転送する。この所定のタイミングは、ライト用キャッシュメモリの容量が一杯になったタイミング、上位側から６４ｋＢ未満のデータが転送されたタイミング、ＦＬＵＳＨＣＡＣＨＥコマンドのようなデータ書き込みを指示するコマンドを受信したタイミング、等である。

また、タイマ１５９を使用し、タイマ１５９の割り込み処理により決定されるタイミングで書き込みを行ってもよい。この場合、コントローラ１５６は、ＵＳＢマスストレージドライバ５０３からライト要求を受信したときにタイマ１５９を作動させる。タイマを使用すれば、一定時間コマンド発行が無い状態を検出して、ライト用キャッシュメモリの内容を書き込みすることができる。そのため、異常時（ＵＳＢケーブルが切断されたり、ＰＣ１がハングアップした場合）のファイル破壊等を防止することができる。

なお、ＵＳＢホストコントローラドライバ５０４以下の下位側において他の処理を行っている場合、コントローラ１５６は、一旦ライト要求をコマンドキュー１６０に登録しておき、後に下位側の処理が空いているときにライト要求を行う。

以上のようにして、アプリケーション１０１からデータのライトが行われる。次に、図７において、アプリケーション１０１がリードの要求を行い、データ転送する例を示す。

図７は、ＯＳ１１上に搭載されている各種ドライバの機能ブロック図である。なお、図５と共通する構成については同一の符号を付し、その説明を省略する。

まず、アプリケーション１０１は、上位側ドライバ１５１に、リード要求を行う。上位側ドライバ１５１は、この要求を下位側である汎用ディスクドライバ５０２に転送するとともに、アプリケーション１０１からリード要求があった旨（アクセス情報）を下位側ドライバ１５２に送信する。

汎用ディスクドライバ５０２は、上位側ドライバ１５１から受信したリード要求をＵＳＢマスストレージドライバ５０３に転送する。このとき、ＵＳＢマスストレージドライバ５０３のデータ転送サイズの上限が６４ｋＢであるため、汎用ディスクドライバ５０２は、６４ｋＢ毎にリード要求を分割する。ＵＳＢマスストレージドライバ５０３は、下位側ドライバ１５２に６４ｋＢ毎に分割されたリード要求を転送する。

下位側ドライバ１５２は、ＵＳＢマスストレージドライバ５０３から６４ｋＢ毎に分割されたリード要求を受信した場合、この後連続してリード要求がされると予測し、ある程度の容量（例えば３ＭＢ）のデータを転送するように、ＵＳＢホストコントローラドライバ５０４に予測リード要求を行う。ＵＳＢホストコントローラドライバ５０４は、この予測リード要求に基づいて、上記３ＭＢの容量のデータをＨＤＤ２のＨＤＤ２３から読み出すように、ＵＳＢホストコントローラ１２、ＵＳＢＩ／Ｆ１３を介して外付ＨＤＤ２にリードのコマンドを転送する。

外付ＨＤＤ２のコントローラ２２は、ＵＳＢＩ／Ｆ２１を介して、ＵＳＢホストコントローラドライバ５０４から転送されたリードのコマンドを受信する。ここで、コントローラ２２は、３ＭＢ分のリードのコマンドを所定のサイズ（例えば１ＭＢ以下）に分割してから、ＨＤＤ２３からリードする処理を行う。すなわち、コントローラ２２は、リードのコマンドおよびデータを受信したとき、１ＭＢよりも大きいデータをリードするものであるか否かを判断し、１ＭＢ以下であればそのままリードコマンドを実行し、１ＭＢよりも大きい場合、当該コマンドを１ＭＢ以下のデータをリードするものとなるように複数のコマンドに分割する。例えば３ＭＢのデータをリードするものであった場合、これを１ＭＢのデータをリードするコマンドに３分割する。そして、分割した各コマンドを実行し、上記ＵＳＢホストコントローラドライバ５０４に、リードしたデータを順次転送する。

これにより、外付ＨＤＤ２が１ＭＢ以下のデータをリードするように最適化されている場合において、コントローラ２２が１ＭＢ以下のコマンドに分割して順次リードを行うため、デバイス側のリード速度を向上させることができる。

なお、分割するサイズは１ＭＢに限らず、上記のように６４ｋＢ毎に分割してもよい。ライトと同様、ＰＣ側が複数コマンドに分割することを想定して、６４ｋＢ以下のデータをリードするように最適化されている周辺機器においても、リード速度を向上させることができる。また、ライトと同様、例えば工場出荷時等において、デバイス毎に最適なリード速度となるように、コントローラ２２が分割するサイズを規定する（ファームウェアを設定しておく）。

また、前述のように、デバイスのメーカ名や型番等の情報を取得して、分割するサイズを変更するようにしてもよいし、デバイス側に設けられているキャッシュの容量に応じて分割サイズを設定してもよい。

このようにしてリードされたデータが下位側ドライバ１５２に順次転送され、キャッシュされる。下位側ドライバ１５２は、ＵＳＢマスストレージドライバ５０３から受信したリード要求にしたがって、キャッシュしたデータを順次、上位側に転送する。ここで、ある程度の容量とは、上記の例では３ＭＢとしたが、転送容量が大きすぎる場合は、転送速度が遅くなる。すなわち、その転送の終了を待ち、その転送の正常終了のステータスを確認するまで、上位側にキャッシュしたデータの転送を開始できないため、転送速度が遅くなる原因となる。また、リード用キャッシュメモリの容量を大きくする必要がある。

そのため、コントローラ１５６は、最初に６４ｋＢ（あるいはそれ以下、３２ｋＢ等であってもよい。）のリード要求を受信したとき、その所定倍（例えば３２ｋＢの４倍である１２８ｋＢ）の容量のデータを読み出してキャッシュすることが望ましい。このキャッシュしたデータが、結果的に全て上位側に転送される場合、さらに所定倍（例えば１２８ｋＢの４倍である５１２ｋＢ）の容量のデータを読み出す。このように、順次、キャッシュするデータの容量を大きくすることで、転送時間を抑えながら、好適なリード用キャッシュメモリの容量に設定することができる。

このように、下位側ドライバ１５２が、外付ＨＤＤ２からある程度の容量を一度に読み出し、キャッシュしておくことで、外付ＨＤＤ２に対するコマンド、ステータスの発行が１度で（あるいは６４ｋＢ毎に付与するよりも少なくて）済む。したがって、コマンド、ステータスの処理時間による遅延が最小限で済む。なお、下位側ドライバ１５２から汎用ディスクドライバ５０２まで転送されるデータは、６４ｋＢに分割されるが、この転送は、ＯＳ上のメモリ（ＲＡＭ）転送であるため、外付ＨＤＤ２からのデータ転送速度に比較して非常に高速である（ＲＡＭ転送速度に依存する）。

図６を参照して、上記リード要求発生時の上位側ドライバ１５１および下位側ドライバ１５２の詳細な動作について説明する。リード、ライト要求受信部１５５は、アプリケーション１０１からリードの要求を受信する。リード、ライト要求受信部１５５は、この要求を下位側の汎用ディスクドライバ５０２に転送するとともに、要求の内容をアクセス情報として下位側ドライバ１５２に送信する。リード要求は、汎用ディスクドライバ５０２、およびＵＳＢマスストレージドライバ５０３を介して下位側ドライバ１５２に転送される。なお、汎用ディスクドライバ５０２、およびＵＳＢマスストレージドライバ５０３から転送されるリード要求は６４ｋＢ毎のリード要求に分割されている。

上位側ドライバ１５１が送信したアクセス情報は、下位側ドライバ１５２のデータベース１５７に予想データベースとして記憶される。下位側ドライバ１５２のコントローラ１５６は、ＵＳＢマスストレージドライバ５０３からリード要求を受信したとき、データベース１５７を参照する。予想データベースを参照することで、転送データ容量（リードすべき全データ）を予測することができる。

また、ＵＳＢマスストレージドライバ５０３から受信したリード要求を履歴データベースとしてデータベース１５７に記憶する。履歴データベースは、コントローラ１５６が予想データベースを作成、修正する場合に用いられる。すなわち、ＵＳＢマスストレージドライバ５０３からリード要求を受信したとき、過去の履歴データベースを参照し、ＬＢＡ、転送ブロック数、転送方向が同一または類似するものを予想データベースとして転記する。一致する履歴が存在する場合、これと関連する履歴（例えばＬＢＡと転送ブロック数に基づいて、連続して要求があったと判断できるもの）をまとめ、１つのコマンドとして予想データベースに記憶することもできる。

コントローラ１５６は、ＵＳＢマスストレージドライバ５０３からリード要求を受信したとき、予想データベースの転送ブロック数を参照することで、転送データ容量（リードすべき全データ）を予測することができる。コントローラ１５６は、６４ｋＢ以上のデータ転送が行われると予測した場合、ＵＳＢホストコントローラドライバ５０４に予想データベースに記載された６４ｋＢ以上のデータを転送するようにリード要求を行い、転送されたデータをキャッシュメモリ１５８Ａ〜１５８Ｃのいずれかに格納する。

このデータを格納したキャッシュメモリがリード用キャッシュメモリとなる。コントローラ１５６は、ＵＳＢマスストレージドライバ５０３から転送されるリード要求に応じて、順次リード用キャッシュメモリのデータを転送する。なお、上位側ドライバ１５１が、リードすべき全データのアクセス情報を送信した場合は、リード用キャッシュメモリに正確に全データをキャッシュすることができるが、アプリケーション１０１が直接ＵＳＢマスストレージドライバ５０３にリード要求を行う場合や上位側ドライバ１５１がリードすべき全データのアクセス情報を送信しない場合は、コントローラ１５６が上位側からリード要求を受信したときに予想データベースを作成する必要がある。この場合、上記のように履歴データベースを参照すればよい。例えば、最初に６４ｋＢ（あるいはそれ以下）のリード要求を受信したとき、そのリード要求に連続した開始ＬＢＡから、所定倍の容量のデータがリードされるように予測する。この予測した開始ＬＢＡに対するリード要求を上位側のドライバから受信した場合、その予測容量分のリードを行い、予測したデータが全て上位側のドライバからリードされた場合、さらにその予測リードに連続する開始ＬＢＡから、さらに所定倍の容量のデータがリードされるように予測する。

以上のようにして、アプリケーション１０１からデータのリードが行われる。

次に、上位側ドライバ１５１、下位側ドライバ１５２、および外付ＨＤＤ２のコントローラ２２の動作をフローチャートを用いて説明する。図８（Ａ）は、上位側ドライバ１５１の動作を示すフローチャートである。上位側ドライバ１５１は、アプリケーションからリード、ライト要求を受信したとき、この要求の内容をアクセス情報として下位側ドライバ１５２に送信する（ｓ１）。また、上位側ドライバ１５１は、下位側（汎用ディスクドライバ５０２）にリード、ライト要求を転送する（ｓ２）。アクセス情報は、下位側ドライバ１５２のデータベース１５７に予想データベースとして記憶される。

なお、上位側ドライバ１５１は、図８（Ｂ）および図１４に示すような動作を行うこともできる。図８（Ｂ）は、上位側ドライバ１５１の別の動作を示す図であり、図１４は、この動作を行う場合の上位側ドライバ１５１および下位側ドライバ１５２の詳細な構成を示す機能ブロック図である。なお、図６と共通する構成については、同一の符号を付し、その説明を省略する。

図８（Ｂ）において、上位側ドライバ１５１は、アプリケーションからリード、ライト要求を受信したとき、転送されるデータ容量が所定量以上（例えば６４ｋＢ以上）であるか否かを判断する（ｓ５）。所定量以上でなければ要求の内容をアクセス情報として下位側ドライバ１５２に転送し（ｓ６）、汎用ディスクドライバ５０２にリード、ライト要求を転送する（ｓ７）。所定量以上であれば、図１４に示すように、リード、ライト要求を直接下位側ドライバ１５２のコントローラ１５６に転送する（ｓ８）。この場合、汎用ディスクドライバ５０２にはリード、ライト要求を転送しない。リード、ライト要求を直接コントローラ１５６に転送することで、６４ｋＢにデータが分割されることなく転送することができる。また、汎用ディスクドライバ５０２、およびＵＳＢマスストレージドライバ５０３を介さないため、処理時間を短縮することができ、より高速化を期待できる。転送されるデータ容量が所定量以上でなければ、ＵＳＢマスストレージドライバ５０３が一度にデータを処理することができるため、下位側（汎用ディスクドライバ５０２）に転送するようにしている。

なお、ｓ５の処理に換えて、リード要求であるか否かの判断としてもよい。リード要求であれば直接下位側ドライバ１５２のコントローラ１５６に転送する。コントローラ１５６では、上位側（ＵＳＢマスストレージドライバ）からリード、ライト要求を受信したときに予測処理を行うため、特に、リード時には予測結果に基づいてある程度のデータ容量をデバイス側から読み出し、キャッシュしてから上位側に返信するため、その分の遅延が生じる可能性がある。そのため、リード要求時には上位側ドライバ１５１からコントローラ１５６に直接この要求を転送し、予測処理やキャッシュ処理を行わず、転送時間（転送開始までの時間）を短縮することができる。

なお、リード要求であるか否かの判断とｓ５の判断とをいずれか１つ行うようにしてもよいし、両方行ってもよい。なお、その他の判断手法を用いてもよい。例えば、デバイス側から予めデータを読み出しておき、キャッシュしておくことを重視する場合（アプリケーションが同じデータ内容にアクセスすることを繰り返すような場合）、リード要求時においても直接コントローラ１５６に要求を転送せずに、下位側に転送する。上位側ドライバ１５１が下位側ドライバ１５２のコントローラ１５６に直接リード、ライト要求を転送する場合、キャッシュメモリにデータが蓄積されない。そのため、アプリケーションが同じファイルにアクセスするような場合であればキャッシュメモリにデータが蓄積されるように下位側に転送すればよい。ただし、下位側ドライバ１５２がデータを転送するとともに、このデータをキャッシュメモリにコピーすることで、直接リード、ライト要求を受信した場合であっても、データを蓄積することが可能である。この場合、ＲＡＭ上のコピーであるため、コピー速度は高速であり、処理速度が著しく低下することはない。

図９は、下位側ドライバ１５２の動作を示すフローチャートである。上位側ドライバ（ＵＳＢマスストレージドライバ５０３またはアプリケーション１０１）からリード要求、ライト要求、またはその他の要求を受信するとこの動作を開始する。

まず、下位側ドライバ１５２は、アクセス予測を行う（ｓ１１）。アクセス予測は、上位側ドライバ１５１から送信されたアクセス情報や履歴データベースを参照することで行う。また、以下のようにして、精密にアクセス予測を行ってもよい。

（１）ファイルシステムに基づく予測
この予測手法は、外付ＨＤＤ２のファイルシステムを解析することでアクセス予測を行う手法である。ＨＤＤのファイルシステムが、例えばＦＡＴファイルシステムフォーマットである場合、ファイル管理領域を参照することで、個々のファイルの記録位置（セクタ）やサイズを判断することができる。よって、上位側のアプリケーションやドライバからリード要求が有ったとき、その要求が示す記録位置に対応するファイルのデータにアクセスが有ると予測する。またファイルサイズ以上のリードを行わないように予測することで、必要以上のリードをせずに、無駄な処理時間を削減する。

なお、このファイル管理領域は、頻繁にアクセスを行う領域であるため、リード用キャッシュメモリにリードし、保持しておいてもよい。都度、外付ＨＤＤ２にアクセスしなくとも、リード用キャッシュメモリに保持しているファイル管理領域にアクセスすることで、アクセス予測の処理時間を削減することができる。

（２）デバイス種別、コンテンツ種別に基づく予測
この予測手法は、接続される対象デバイスのタイプ（上記実施形態ではＨＤＤ）や転送すべきデータのファイル構成（コンテンツ種別）に基づいてアクセス予測を行う手法である。例えば、接続されるデバイスがＤＶＤ−ＲＯＭであり、このデバイスにＤＶＤ−Ｖｉｄｅｏメディアが挿入されている場合、順次リードがされ、ライト要求がされることがない。そのため、リード用キャッシュメモリの容量一杯までデータがキャッシュされるように予測データベースを作成する。なお、リード用キャッシュメモリにキャッシュしたデータが全てリードされた場合、即時このキャッシュを破棄し、新たなデータをキャッシュすれば、効率的にリード用キャッシュメモリを用いることができる。

また、キャッシュメモリの数および容量を変化させる場合、デバイス種別に基づいて変化させることができる。例えば、上記のようにＤＶＤ−Ｖｉｄｅｏメディアが挿入されている場合、ライト要求されることがないため、リード用キャッシュメモリの数を増やし、その容量も大きく設定する。逆に未書き込みのＤＶＤ−Ｒメディアが挿入されている場合、主にライト要求がされるため、ライト用キャッシュメモリの数を増やし、その容量を大きく設定する。

（３）転送速度の解析に基づく予測
この予測手法は、上記デバイス種別、コンテンツ種別に基づく予測の応用例であり、デバイス種別に応じてデータ転送速度の傾向を判断し、これに基づいてアクセス予測を行う手法である。例えば、多層型ＤＶＤメディアが接続される場合、各層の境界線を越えるランダムアクセスは、転送速度が非常に遅くなる。そのため、各層の境界線をまたぐアクセスの頻度が低くなるようにキャッシュするようにして、予測データベースを作成する。

また、キャッシュメモリの数および容量を変化させる場合には、このデバイス種別やデータ転送速度の傾向に基づいて変化させることもできる。例えば、対象デバイスとのデータ転送速度が遅い場合（例えばＵＳＢＭＯ（光磁気ディスク）のように４ＭＢ／ｓ程度である場合）、キャッシュメモリの容量を大きくして大量にデータをキャッシュしても、そもそもデータ転送速度が遅いために転送速度の向上が望めない。そのため、対象デバイスとのデータ転送速度が遅い場合、キャッシュメモリの容量を小さく設定し、ＲＡＭの消費を抑える。

（４）リード要求時に１度に転送するデータを徐々に増加させる手法
この予測手法は、リード要求時に、上記（１）〜（３）の手法で予測したリード要求に基づいて、対象デバイスから一度にデータ転送しないように、予測データベースを修正する（分割する）手法である。例えばリード要求の所定倍（例えば４倍）の容量のデータをまずキャッシュするように予測データベースを修正する。このキャッシュしたデータが、結果的に全て上位側に転送される場合、さらに所定倍の容量のデータをキャッシュするように予想データベースを修正する。順次、キャッシュするデータの容量を大きくすることで、転送時間を抑えることができる。また、実際の要求が予想データベースと異なり、その後リードが無かった場合に無駄となるデータ量を削減することができる。また、都度キャッシュメモリの容量を変化させることで、ＲＡＭの消費を抑えることもできる。なお、予想データベースの修正処理は、実際にリードを行うとき（後述のｓ２９の処理時）に行ってもよい。

以上のようにして、アクセス予測を行う。なお、キャッシュメモリの数および容量はユーザが手動で設定することができる。また、ライト用キャッシュメモリ、リード用キャッシュメモリの確保数もユーザが設定することができる。ユーザがリードを優先したい場合はリード用キャッシュメモリの数を増やし、ライトを優先したい場合はライト用キャッシュメモリの数を増やす。

次に、図９において、下位側ドライバ１５２は、上側から送信された要求の内容を判断する（ｓ１２）。リード、ライトの要求でなければ、対象デバイスが他のリード、ライト等の処理を行っているか否かを判断し（ｓ１３）、処理が空いていればこの要求を下位側に転送する（ｓ１４）。他の処理を行っていればこの要求をコマンドキューに登録する（ｓ１５）。コマンドキューに登録しておけば、後に処理が空いたときに実行することができる。また、ＦＬＵＳＨＣＡＣＨＥコマンドのような、ライト用キャッシュメモリのデータを書き込み指示するようなコマンドを受領した場合、このときにライト用キャッシュメモリにキャッシュされているデータを下位側へ転送する。

ｓ１２において、下位側ドライバ１５２は、リード、ライトの要求であると判断した場合、キャッシュメモリを参照する（ｓ１６）。ここで、上位側からの要求がリード要求であり、リード用キャッシュメモリまたはライト用キャッシュメモリに該当するデータがキャッシュされていれば、これを上側に転送し、コマンド終了を返信する（ｓ１７）。

ｓ１２において、下位側ドライバ１５２は、上位側からの要求が連続したライト要求であると判断した場合、ライト用キャッシュメモリに連続してデータを書き込み、コマンド終了を返信する（ｓ１８）。その後、ライト用キャッシュメモリの容量が一杯であるかを判断し（ｓ１９）、容量が一杯でなければタイマを起動させ（ｓ２０）、動作を終える。

ｓ１９において、ライト用キャッシュメモリの容量が一杯であれば、対象デバイスが他のリード、ライト等の処理を行っているか否かを判断し（ｓ２１）、処理が空いていればライト要求を下位側に送信し、キャッシュしたデータを転送する（ｓ２２）。他の処理を行っていればこのライト要求をコマンドキューに登録する（ｓ２３）。コマンドキューに登録しておけば、後に処理が空いたときに実行することができる。

ｓ１６において、下位側ドライバ１５２は、上位側からの要求に該当するキャッシュデータがないと判断した場合、予想データベースを参照し、上位側からの要求と予想データベースの内容を比較する（ｓ２４）。上位側からの要求と予想データベースの内容が不一致（ＬＢＡや転送ブロック数が不一致）であれば、この要求をそのまま下位側に転送する（ｓ２５）。なお、このとき、下位側が他の処理を行っていればコマンドキューに登録し、後に実行するようにしてもよい。

上位側からの要求がライト要求であり、予想データベースの内容と一致（ＬＢＡや転送ブロック数が一致）すれば、ライト用キャッシュメモリを確保する（ｓ２６）。ここで、空きキャッシュメモリが有れば、そのキャッシュメモリをライト用キャッシュメモリとして確保し、キャッシュメモリが全てライト用またはリード用に用いられていた場合、最も過去に更新したキャッシュメモリの内容を消去してライト用キャッシュメモリを確保する。なお、ライト用キャッシュメモリのデータは、リード用キャッシュメモリのデータとしても使用可能である。

その後、確保したライト用キャッシュメモリに上位側から転送されるデータを保存し、コマンド終了を返信する（ｓ２７）。

ｓ２４において、下位側ドライバ１５２は、上位側からの要求がリード要求であり、予想データベースの内容と一致（ＬＢＡや転送ブロック数が一致）すると判断した場合、リード用キャッシュメモリを確保する（ｓ２８）。上記と同様、空きキャッシュメモリが有ればこれをリード用キャッシュメモリとし、空きが無ければ最も過去に更新したキャッシュメモリの内容を消去してリード用キャッシュメモリを確保する。

その後、予想データベースに基づいて、予想分のリード要求を下位側に送信し、リード用キャッシュメモリにデータをキャッシュする（ｓ２９）。このとき、一度に大量のデータをキャッシュするのではなく、複数回に分けてデータキャッシュしてもよい。この場合、残りのリード要求はコマンドキューに登録する。リード要求を複数に分割することで、キャッシュ済みデータを上位側のドライバへ転送しながら、それと並行して、次に連続するリードデータをキャッシュすることができ、ＵＳＢバスの使用率向上が期待できる。

次に、図１０は、下位側からのコマンド終了割り込みがあった場合の動作を示すフローチャートである。

まず、下位側ドライバ１５２は、下位側から受信したコマンド終了が、ライト用キャッシュメモリにキャッシュしておいたデータを書き終えた旨を示すコマンドであるか否かを判断する（ｓ３１）。ライト用キャッシュメモリのデータが書き終わった場合は、このライト用キャッシュメモリをリード用キャッシュメモリに変更する（ｓ３２）。なお、ライト用キャッシュメモリをリード用キャッシュメモリに変更するタイミングは、このタイミングに限るものではない。また、上述のように、ライト用キャッシュメモリのデータをリード用キャッシュメモリのデータとして用いることも無論可能である。

その後、下位側ドライバ１５２は、上位側に対して終了報告（転送）が必要なコマンドであるか否かを判断する（ｓ３３）。必要であれば上位側にコマンド終了を返送する（ｓ３４）。

さらに、下位側ドライバ１５２は、コマンドキュー１６０を参照し、キューイングされたコマンドが存在するか否かを判断する（ｓ３５）。キューイングされたコマンドが存在すれば、これを下位側に転送する（ｓ３６）。

次に、図１１は、タイマ割り込み、ドライバ初期化時、ドライバ終了時の動作を示すフローチャートである。

まず、同図（Ａ）は、タイマ割り込み動作を示すフローチャートである。下位側ドライバ１５２は、タイマがタイムアップするとこの動作を開始する。下位側ドライバ１５２は、ライト用キャッシュメモリにデータがキャッシュされているか否かを確認する（ｓ４１）。キャッシュされていれば、下位側にライト要求を送信し、ライト用キャッシュメモリにキャッシュされているデータを下位側に転送し（ｓ４２）、動作を終える。ライト用キャッシュメモリにデータがキャッシュされていなければ動作を終える。

同図（Ｂ）は、ドライバ終了時の動作を示すフローチャートである。ＰＣのシャットダウン時、外付ＨＤＤ２の接続を解除する時にこの動作を開始する。下位側ドライバ１５２は、履歴データベースを外付ＨＤＤ２またはＯＳ１１に転記して保存する（ｓ５１）。

同図（Ｃ）は、ドライバ初期化時の動作を示すフローチャートである。ＰＣ１を再起動したり、外付ＨＤＤ２を再接続した場合にこの動作を開始する。下位側ドライバ１５２は、履歴データベースを外付ＨＤＤ２またはＯＳ１１から読み出し、ＲＡＭに展開してデータベース１５７を構築する（ｓ６１）。

次に、図１２は、外付ＨＤＤ２のコントローラ２２の動作を示すフローチャートである。コントローラ２２は、ＰＣ１側からコマンドを受信したときにこの動作を開始する。まず、コントローラ２２は、受信したコマンドが、所定のサイズ（１ＭＢ）よりも大きいデータをリード、ライトするものであるかを判断する（ｓ７１）。所定のサイズ（１ＭＢ）以下であればそのままＨＤＤ２３に書き込み、または読み出しを行う（ｓ７３）。

一方、所定のサイズ（１ＭＢ）よりも大きいデータをリード、ライトするものであった場合、このコマンドを所定のサイズ（１ＭＢ以下）に分割し（ｓ７２）、順次、ＨＤＤ２３に書き込み、または読み出しを行う（ｓ７３）。

なお、上記実施形態では、上位側ドライバ１５１、下位側ドライバ１５２を実現し、汎用ディスクドライバ５０２、またはＵＳＢマスストレージドライバ５０３に接続される例を示したが、ＵＳＢマスストレージドライバを専用ドライバに置き換える形でも、本発明のデバイスコントローラを実現することができる。図１３は、ＵＳＢマスストレージドライバを専用ドライバに置き換える場合の例を示す機能ブロック図である。なお、図５と共通する構成については同一の符号を付し、その説明を省略する。

この例では、ＵＳＢホストコントローラドライバ５０４、汎用ディスクドライバ５０２、およびアプリケーション１０１に接続される専用ＵＳＢマスストレージクラスドライバ１７１を備えている。専用ＵＳＢマスストレージクラスドライバ１７１は、従来の標準のＵＳＢマスストレージドライバを置き換えるものである（図１を参照）。

この専用ＵＳＢマスストレージクラスドライバ１７１は、上記実施形態と同様に、キャッシュメモリを内蔵しており、上位側から受信したリード、ライト要求に応じてデータをキャッシュする。専用マスストレージクラスドライバ１７１の動作は図９から図１１に示した下位側ドライバの動作と同様である。

この例においても、アプリケーション１０１が６４ｋＢ毎にデータを分割して、リード／ライトの要求を発行する場合は、専用ＵＳＢマスストレージクラスドライバ１７１がキャッシュメモリにデータをキャッシュし、データ転送する。

なお、この専用ＵＳＢマスストレージクラスドライバ１７１は、６４ｋＢのデータ転送サイズの上限を持たず、６４ｋＢより大きいサイズのリード／ライトの要求を処理可能なものである。したがって、アプリケーション１０１、または汎用ディスクドライバ５０１は、リード／ライトの要求を６４ｋＢ単位に分割することなく発行することが可能であるため、コマンド、ステータスの処理の遅延が少なくて済み、データ転送を高速にすることができる。

ＵＳＢインタフェースで接続されるＰＣと外付ＨＤＤを表したブロック図である。バルクオンリープロトコルの構成を示した概念図である。コマンドを分割するドライバの下位側に専用のドライバを設ける場合のブロック図である。本実施形態におけるＰＣと外付ＨＤＤのブロック図である。ＯＳ１１上に搭載されている各種ドライバの機能ブロック図である。上位側ドライバ１５１および下位側ドライバ１５２の詳細な構成を示す機能ブロック図である。ＯＳ１１上に搭載されている各種ドライバの機能ブロック図である。上位側ドライバ１５１の動作を示すフローチャートである。下位側ドライバ１５２の動作を示すフローチャートである。コマンド終了割り込み時の動作を示すフローチャートである。タイマ割り込み、初期化時、ドライバ終了時の動作を示すフローチャートである。外付ＨＤＤ２のコントローラ２２の動作を示すフローチャートである。本発明のデバイスコントローラを実現する他の例を示すブロック図である。上位側ドライバ１５１および下位側ドライバ１５２が別の動作を行う場合の構成を示す機能ブロック図である。

符号の説明

１−ＰＣ
２−外付ＨＤＤ

Claims

パーソナルコンピュータと、パーソナルコンピュータに接続される周辺機器と、からなる情報処理システムであって、
前記パーソナルコンピュータは、前記周辺機器に対するリードまたはライトの要求を複数のコマンドに分割して順次送信する汎用ドライバと、
前記汎用ドライバの下位側に配置される下位側ドライバと、
前記リードまたはライトの要求に対応するデータをキャッシュするキャッシュメモリと、
前記下位側ドライバがライトの要求を受信したとき、各コマンドに対するコマンド終了を擬似的に上位側に返信するとともに、上位側から転送されるデータを順次前記キャッシュメモリにキャッシュし、前記汎用ドライバが分割する各コマンドあたりのデータ転送サイズの上限よりも大きいデータ転送サイズのコマンドを発行して前記キャッシュメモリのデータを前記周辺機器に転送し、
前記下位側ドライバがリードの要求を受信したとき、前記汎用ドライバが分割する各コマンドあたりのデータ転送サイズの上限よりも大きいデータ転送サイズのコマンドを発行して前記周辺機器からデータを読み出して前記キャッシュメモリにキャッシュする予測処理を行う制御部と、
を備え、
前記周辺機器は、前記パーソナルコンピュータから転送されたリードまたはライトのコマンドが所定のサイズよりも大きいデータをリードまたはライトするものであった場合、当該コマンドを前記所定のサイズ以下のデータをリードまたはライトするものとなるように複数のコマンドに分割するコマンド分割部を備えた情報処理システム。
パーソナルコンピュータと、パーソナルコンピュータに接続される周辺機器と、からなる情報処理システムであって、
前記パーソナルコンピュータは、前記周辺機器に対するリードまたはライトの要求を複数のコマンドに分割して順次送信する汎用ドライバと、
前記汎用ドライバの下位側に配置される下位側ドライバと、
前記汎用ドライバの上位側に配置される上位側ドライバと、
前記周辺機器に対するリードまたはライトの要求を前記上位側ドライバから前記下位側ドライバに直接転送するリード、ライト要求受信部と、
前記下位側ドライバにおいて、前記上位側ドライバから転送された前記リードまたはライトの要求に応じたリードまたはライトのコマンドを発行してデータ転送を行う制御部と、
を備え、
前記周辺機器は、前記パーソナルコンピュータから転送されたリードまたはライトのコマンドが所定のサイズよりも大きいデータをリードまたはライトするものであった場合、当該コマンドを前記所定のサイズ以下のデータをリードまたはライトするものとなるように複数のコマンドに分割するコマンド分割部を備えた情報処理システム。
前記コマンド分割部は、その周辺機器の仕様に応じて、前記所定のサイズを変更する請求項１、または請求項２に記載の情報処理システム。