JP2010009622A - デバイスドライバ - Google Patents

Abstract

【課題】転送する総データ量が所定量以上となる場合に、デバイス側に特別な構成を必要とせず、転送速度を向上するデバイスドライバを提供する。
【解決手段】ＵＳＢマスストレージドライバ５０３とＵＳＢホストコントローラドライバ５０４の間に下位側ドライバ１５２を設ける。下位側ドライバ１５２は、上位側からリード、ライト要求を受信し、転送されるデータをキャッシュする。ライト時には上位側から受信したデータをキャッシュし、ある程度の容量のデータとしてまとめて下位側に送信する。リード時には下位側からある程度の容量のデータをまとめて読み出し、上位側に送信する。
【選択図】図４

Description

この発明は、パーソナルコンピュータの外付周辺機器を制御するデバイスドライバに関し、特に、データ転送を高速化するデバイスドライバに関する。

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

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

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

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

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

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

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

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

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

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

一方で、従来、ＰＣとデバイスとの間の転送速度を向上させる手法として、デバイスコントローラにバッファを備え、このバッファにデータをキャッシュし、まとめて転送するものがあった（例えば特許文献１参照）。特許文献１の装置は、転送するデータの総容量がバッファの容量を超えるデータの場合、都度書き込み処理が発生するため、バッファ容量を超えるデータについては、バッファを介さずに直接転送するものである。

また、複数のバッファを備え、１つのバッファのデータを転送する処理を行いながら、他のバッファに上位側からのデータをキャッシュすることで転送速度を向上させるもの（例えば特許文献２参照）や、コマンド、データ、ステータスをそれぞれキャッシュし、まとめて処理するものが提案されている（例えば特許文献３参照）。

また、ＰＣ側およびデバイス側で上記のようにデータを分割して処理する必要が有る場合において、ＰＣ側のデバイスコントローラがある程度のデータをまとめて転送し、デバイス側の制御部でこれを再び分割して処理するものが提案されている（例えば特許文献４参照）。

特開平４−１３０５２３号公報 特開２００２−３４４５３７号公報 特開２００６−２１５８９１号公報 特開２００１−１５４８１１号公報

しかし、特許文献１に記載の装置では、アプリケーションやドライバがデータを分割した場合に高速化できるものではなかった。また、特許文献２および特許文献３に記載の装置は、転送部の処理速度を向上することができるが、アプリケーションやドライバがデータを分割した場合に高速化できるものではなかった。

また、特許文献４に記載の計算機システムは、デバイス側の制御部で再びデータを分割して処理する必要が有った。また、リード時には、デバイス側の制御部において、分割された各要求を統合してデータ転送する構成が必要であった。

そこで、この発明は、転送する総データ量が所定量である場合において、デバイス側に特別な構成を必要とせず、転送速度を向上するデバイスドライバを提供することを目的とする。

本発明のデバイスドライバは、周辺機器が接続されたパーソナルコンピュータのＯＳに搭載され、前記周辺機器に対するライトの要求を上限のデータ転送サイズで複数のコマンドに分割して順次送信するソフトウェアの下位側に配置されるデバイスドライバであって、前記パーソナルコンピュータを、前記ライトの要求に対応するデータをキャッシュするキャッシュメモリと、前記ドライバが前記上限のデータ転送サイズのライトの要求を受信したとき、この後連続してライトの要求がされると予測し、各コマンドに対するコマンド終了を擬似的に上位側に返信するとともに、上位側から転送されるデータを順次前記キャッシュメモリにキャッシュし、前記ソフトウェアが分割する各コマンドあたりのデータ転送サイズの上限よりも大きいデータ転送サイズのコマンドを発行して前記キャッシュメモリのデータを前記周辺機器に転送する処理を行う制御部と、して機能させることを特徴とする。

また、本発明のデバイスドライバは、周辺機器が接続されたパーソナルコンピュータのＯＳに搭載され、前記周辺機器に対するリードの要求を上限のデータ転送サイズで複数のコマンドに分割して順次送信するソフトウェアの下位側に配置されるデバイスドライバであって、前記パーソナルコンピュータを、前記リードの要求に対応するデータをキャッシュするキャッシュメモリと、前記ドライバが前記上限のデータ転送サイズのリードの要求を受信したとき、この後連続してリードの要求がされると予測し、前記ソフトウェアが分割する各コマンドあたりのデータ転送サイズの上限よりも大きいデータ転送サイズのコマンドを発行して前記周辺機器からデータを読み出して前記キャッシュメモリにキャッシュする処理を行い、その後上位側から順次送信されたリード要求のコマンドに対応するデータが前記キャッシュメモリにキャッシュされている場合に前記キャッシュメモリから当該データを上位側に転送する制御部と、して機能させることを特徴とする。

このように、本発明のデバイスドライバは、上位側のアプリケーションやデバイスドライバから受信したリード／ライトの要求を統合し、デバイスに転送する。これにより、アプリケーションやデバイスドライバから受信したデータをキャッシュし、ある程度の容量のデータとして、まとめて対象デバイスに転送する。また、その逆に、対象デバイスからある程度の容量をまとめて受信し、キャッシュしたデータとして順次アプリケーションやデバイスドライバに転送する。アプリケーションやデバイスドライバが転送データ容量を制限し、分割してデータを転送する場合であっても、ある程度の容量のデータをまとめて１つの（あるいは数を減らして）コマンド、ステータスを発行し、転送することで、高速化を実現する。また、リード要求を受信したとき、この要求に対応するデータがキャッシュメモリに記憶されていれば、これを転送することができる。一度転送したデータをキャッシュしておけば、次に同じデータのリード要求を受信したときに高速に転送することができる。また、一般に、ストレージデバイスのランダムアクセスは、ヘッドのシーク動作を伴うため、これが転送速度の低下を引き起こすが、上記のようにキャッシュメモリからデータを転送することで、対象デバイスへのリード要求の発行頻度を軽減することができるとともに、対象デバイスのランダムアクセスの発生頻度の軽減にもつながり、さらなる高速化を実現できる。

この発明によれば、アプリケーションやデバイスドライバが制限するデータ量以上のデータを転送することができるため、転送速度を向上することができる。

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

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

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

外付ＨＤＤ２は、コントローラ２２がＵＳＢＩ／Ｆ２１を介してリードまたはライトの要求を受信し、これに応じてＨＤＤ２３に記憶されているデータをリード、またはＨＤＤ２３にデータをライトする。

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

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

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

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

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

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

また、この実施形態において、アプリケーション１０１が直接ＵＳＢマスストレージドライバ５０３にデータ転送する場合があるが、上記と同様、ＵＳＢマスストレージドライバ５０３のデータ転送サイズの上限が６４ｋＢであるため、アプリケーション１０１が６４ｋＢ毎に分割してデータを転送し、ＵＳＢマスストレージドライバ５０３がコマンド、ステータスを付与したデータを転送する。この場合においても、下位側ドライバ１５２がデータをキャッシュしてから下位側にデータ転送するため、コマンド、ステータスの処理時間による遅延が最小限で済む。
次に、上位側ドライバ１５１および下位側ドライバ１５２の詳細な動作について説明する。図５は、上位側ドライバ１５１および下位側ドライバ１５２の詳細な構成を示す機能ブロック図である。なお、図４と共通する構成については同一の符号を付し、その説明を省略する。上位側ドライバ１５１は、リード、ライト要求受信部１５５を備えている。また、下位側ドライバ１５２は、コントローラ１５６、データベース１５７、キャッシュメモリ１５８Ａ〜１５８Ｃ、タイマ１５９、およびコマンドキュー１６０を備えている。

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

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

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

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

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

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

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

コントローラ１５６は、所定のタイミングで下位側のＵＳＢホストコントローラドライバ５０４に対し、ライト要求を行い、ライト用キャッシュメモリのデータを転送する。この所定のタイミングは、ライト用キャッシュメモリの容量が一杯になったタイミング、またはタイマ１５９の割り込み処理により決定されるタイミングである。コントローラ１５６は、ＵＳＢマスストレージドライバ５０３からライト要求を受信したときにタイマ１５９を作動させる。また、ライト用キャッシュメモリの容量が一杯になった場合も、ＵＳＢホストコントローラドライバ５０４に対し、ライト要求を行い、ライト用キャッシュメモリのデータを転送する。

なお、ＵＳＢホストコントローラドライバ５０４以下の下位側において他の処理を行っている場合、コントローラ１５６は、一旦ライト要求をコマンドキュー１６０に登録しておき、後に下位側の処理が空いているときにライト要求を行う。なお、タイマが無い場合、ライト用キャッシュメモリの内容がそのまま保持され、ＨＤＤ２３に書き込まれなくなるため、この状態で異常発生した場合（ＵＳＢケーブルが切断されたり、ＰＣ１がハングアップした場合）、本来ＨＤＤ２３に書き込まれるべきであったデータが破棄され、ファイル破損等の被害が想定される。そのため、タイマを使用して、例えば一定時間コマンド発行が無い状態が経過した場合に、ライト用キャッシュメモリの内容を書き込みすることで、異常時のファイル破壊等を防止するようにしている。

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

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

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

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

下位側ドライバ１５２は、ＵＳＢマスストレージドライバ５０３から６４ｋＢ毎に分割されたリード要求を受信した場合、この後連続してリード要求がされると予測し、ある程度の容量のデータを転送するように、ＵＳＢホストコントローラドライバ５０４に予測リード要求を行う。ＵＳＢホストコントローラドライバ５０４は、この予測リード要求に基づいて、ある程度の容量のデータをＨＤＤ２のＨＤＤ２３から読み出す。このリードデータが下位側ドライバ１５２にキャッシュされる。下位側ドライバ１５２は、ＵＳＢマスストレージドライバ５０３から受信したリード要求にしたがって、キャッシュしたデータを順次、上位側に転送する。ある程度の容量とは、適宜設定すればよいが、転送容量が大きすぎる場合は、転送速度が遅くなる。すなわち、その転送の終了を待ち、その転送の正常終了のステータスを確認するまで、上位側にキャッシュしたデータの転送を開始できないため、転送速度が遅くなる原因となる。また、リード用キャッシュメモリの容量を大きくする必要がある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

１−ＰＣ
２−外付ＨＤＤ

Claims (4)

1. 周辺機器が接続されたパーソナルコンピュータのＯＳに搭載され、
   前記周辺機器に対するライトの要求を上限のデータ転送サイズで複数のコマンドに分割して順次送信するソフトウェアの下位側に配置されるデバイスドライバであって、
   前記パーソナルコンピュータを、
   前記ライトの要求に対応するデータをキャッシュするキャッシュメモリと、
   当該デバイスドライバが前記上限のデータ転送サイズのライトの要求を受信したとき、この後連続してライトの要求がされると予測し、各コマンドに対するコマンド終了を擬似的に上位側に返信するとともに、上位側から転送されるデータを順次前記キャッシュメモリにキャッシュし、前記ソフトウェアが分割する各コマンドあたりのデータ転送サイズの上限よりも大きいデータ転送サイズのコマンドを発行して前記キャッシュメモリのデータを前記周辺機器に転送する処理を行う制御部と、
   して機能させるデバイスドライバ。
2. 周辺機器が接続されたパーソナルコンピュータのＯＳに搭載され、
   前記周辺機器に対するリードの要求を上限のデータ転送サイズで複数のコマンドに分割して順次送信するソフトウェアの下位側に配置されるデバイスドライバであって、
   前記パーソナルコンピュータを、
   前記リードの要求に対応するデータをキャッシュするキャッシュメモリと、
   当該デバイスドライバが前記上限のデータ転送サイズのリードの要求を受信したとき、この後連続してリードの要求がされると予測し、前記ソフトウェアが分割する各コマンドあたりのデータ転送サイズの上限よりも大きいデータ転送サイズのコマンドを発行して前記周辺機器からデータを読み出して前記キャッシュメモリにキャッシュする処理を行い、その後上位側から順次送信されたリード要求のコマンドに対応するデータが前記キャッシュメモリにキャッシュされている場合に前記キャッシュメモリから当該データを上位側に転送する制御部と、
   して機能させるデバイスドライバ。
3. 前記制御部は、ＵＳＢマスストレージデバイスである前記周辺機器とデータ転送を行うことを特徴とする請求項１または２に記載のデバイスドライバ。
4. 前記制御部は、ＯＳ標準のＵＳＢマスストレージドライバで動作する前記周辺機器とデータ転送を行うことを特徴とする請求項３に記載のデバイスドライバ。

Images