(58)【調査した分野】(Int.Cl.,DB名)
ストレージデバイスを検出するための方法であって、前記ストレージデバイスはホストシステムに接続され、前記ストレージデバイスは関連するメタデータを含み、前記関連するメタデータはそのようなストレージデバイスがリムーバブルメディアを有すると誤って示すことがあり、前記方法は、
前記ホストシステムから第1のストレージデバイスへメディアポーリングメッセージを送信することであって、前記メディアポーリングメッセージは前記第1のストレージデバイスが準備ができているかを問い合わせるものであることと、
前記第1のストレージデバイスが準備ができていないと応答する場合、前記第1のストレージデバイスが本当にリムーバブルメディアを有するとしてデータベースを更新することと、
前記ストレージデバイスから非同期通知メッセージを受信することと、
受信したときに、前記第1のストレージデバイスが本当にリムーバブルメディアを有するとして前記データベースを更新することと、
前記第1のストレージデバイスが本当はリムーバブルメディアを有さない場合、前記ホストシステムによる前記第1のストレージデバイスへのさらなるメディアポーリングを無効にすることと
を備える、方法。
リムーバブルメディアを誤って示す関連するメタデータを含む既知のストレージデバイスのデータベースで、前記第1のストレージデバイスに対するエントリを検索することであって、前記第1のストレージデバイスが前記ホストシステムに接続されることと、
エントリが前記第1のストレージデバイスに対して前記データベースに存在する場合、前記ホストによる前記第1のストレージデバイスへのポーリングを無効にすることと
をさらに備える、請求項1に記載の方法。
【発明を実施するための形態】
【0010】
本明細書で使用される場合、「コンポーネント」、「システム」、「インターフェース」、「コントローラ」などの用語は、ハードウェア、(たとえば実行中の)ソフトウェア、および/またはファームウェアのいずれであれ、コンピュータ関連のエンティティを指すものとする。たとえば、これらの用語のいずれかは、プロセッサ上で動作するプロセス、プロセッサ、オブジェクト、実行可能ファイル、プログラム、および/またはコンピュータとすることができる。例として、サーバ上で動作するアプリケーションおよびこのサーバの双方は、コンポーネントおよび/またはコントローラとすることができる。1つまたは複数のコンポーネント/コントローラは、プロセス内に存在することでき、コンポーネント/コントローラは、1つのコンピュータ上に局在させることができ、および/または2つ以上のコンピュータに分散させることができる。
【0011】
特許請求する主題を、図面を参照して説明するが、同様の参照番号を、全体を通して、同様の要素を参照するために用いる。以下の記載においては、説明の目的で、多数の具体的な詳細を記載し、本革新の完全な理解が得られるようにする。しかしながら、特許請求する主題が、これらの具体的な詳細なくとも実践可能であることは明らかであろう。他の例では、周知の構造およびデバイスを、本革新の説明を容易にするために、ブロック図の形式で示す。
【0012】
はじめに
一実施形態では、USBフラッシュドライブに対するメディア状態のポーリングを除去することで、電力を節約できる。しかしながら、以下の理由により、これを安全に行うことができない場合がある:(1)リムーバブルメディアを不正確に報告する大多数のUSBフラッシュドライブ(UFD)、(2)これらのUFDを、本当にリムーバブルメディアを含むデバイス(たとえばUSBフラッシュカードリーダデバイス)から一義的に区別する方法が現在存在しない。これは、そのようなリムーバブルメディアを実際には有さない場合に、リムーバブルメディアを含むと(誤っているが)符号化したレガシーUFDに特に当てはまる。
【0013】
現在、新しい非レガシーデバイスは、ホストが誤動作またはデータ破損のリスクなしでメディアポーリングを断定的および安全に除去できる、新しい非同期通知機構を実装することができる。しかしながら、これは、現在およびしばらくの間、使用中である全てのレガシーデバイスに対しては、何も行わない。
【0014】
状況を理解するために、
図1は、典型的なUSB3.0ホスト/ハブ/周辺デバイス構成の1つの構成図(100)の1つの例示の実施形態である。
図1からわかるように、新しいスーパースピードバスは、従来のUSB2.0バスと平行して動作するデュアルバスアーキテクチャの一部である。コントローラ102は、I/O処理および/または機能を提供するために、USB3.0ホスト104と通信可能である。USB3.0ホスト104は、レガシーUSB2.0ホスト106に対する互換性サポート、ならびに新しいスーパースピードホスト機能108を提供することができる。コントローラ102は、システムのCPU、I/Oコントローラ、またはそのようなコントローラのハードウェアおよび/またはソフトウェアコンポーネントの組合せでもよい。
【0015】
ホストは、多数のポート(たとえば110aおよび110b)を備えることができる。ポートは、複数のハブ112と接続することができる。ハブ112は、レガシーハブ114と、新しい(たとえばスーパースピード)ハブ116とをさらに備えることができる。そのようなハブは、今度は、複数のUSB周辺デバイス120と接続でき、これらは、非スーパースピード機能122およびスーパースピード機能124の組を備えることができる。
【0016】
そのような周辺デバイスは、種々のレガシーデバイス、たとえば、(リムーバブルメディアを有するとホストに誤って報告し得る)リムーバブルメディアを有さないUSBフラッシュドライブ126、または、実際のリムーバブルメディアコンポーネント(たとえばメモリーカード130)を有することができるカメラ128を含むことができる。
【0017】
図2は、修正されたBOTまたはUASP規格の下で行われ得る処理の1つの例示の実施形態(200)を示す。USBマスストレージデバイス208は、リムーバブルとは限らないストレージメディア216と、処理ユニット214と、インターフェースバンドル210とを備えることができる。インターフェースバンドル210は、レガシー(たとえば既存のBOTおよびUASP規格の)インターフェースINエンドポイント(EP)(210a)およびOUT EP 210b、ならびにステータスの非同期通知のための新たに導入されたインタラプトエンドポイント(INT EP 212)をさらに備えることができる。
【0018】
たとえば、リムーバブルストレージが取り外されたかまたは交換されたかに関するステータスの変化は、通知処理206aにおいて、ホストシステムに、たとえばUSBマスストレージドライバ206に、非同期で信号により通知することができる。この通知はさらに、ブロックストレージドライバ204へ、メディア変更処理204aへ、非同期で伝えることができる。最後に、そのようなステータスの変化は、上位レベルファイルシステムスタック202へ報告することができる。
【0019】
前述したように、レガシーデバイスは、新しい規格に従って実装されていないので、そのようなステータスの変化を非同期に報告することはない。実際には、レガシーデバイスは、BOT/UASP規格への新たに提案された修正より前から存在するか、またはこれらの修正を実装しないことを選択したデバイスであってもよい。加えて、レガシーデバイスは、リムーバブルメディアを有すると、そのようなリムーバブルメディアを有さない場合でさえ、誤って報告することがある(したがって、継続的なポーリングを要求する)。潜在的な節電に対する様々な態様をより理解するために、様々なコンポーネントへの影響を考慮することが望ましいだろう:
【0020】
ハブおよびコントローラの考慮
USBデバイスツリーの各ノードに対して電力を管理しながら、特定のノードの全ての子を、そのノード自身が休止し得る前に、休止させなければならない。そして、ホストコントローラに接続されたデバイスの全体のツリーが休止した場合、コントローラ自身を休止させることができる。コントローラを休止させることは、自身の回路をアクティブに保つことに関連する電力を節約するだけでなく、コントローラが生成し得る割り込みの停止によってホストCPU消費電力を低下させることもできる。
【0021】
CPUの考慮
リムーバブルメディアを有するデバイスの現在のメディア状態に関してホストを最新に保つために、システムは、たとえばメディアポーリングメッセージとしてTEST UNIT READY(TUR)コマンドを用いた定期的なポーリングに作用することができる。これは、この活動によってCPUをより高い電源状態に保持する傾向がある、タイマプロシージャコールのコンテキストにおけるコードの定期的な実行に対応する。全体のシステム消費電力の最小化を試みるために、以下を考慮するのが望ましいだろう:
(1)リムーバブルメディアを報告するデバイスは、メディア状態の任意の変化を検出するために、ホストによりTEST UNIT READYコマンドを用いて継続的にポーリングされる。これは、追加の電力を消費する傾向があり、実際のデータI/Oの不在下で、USBデバイスツリーならびにホストコントローラおよびホストCPUを不必要にアクティブに保つ。
(2)より多くの電力が最適化されたホストに接続されている間、バスパワー型マスストレージデバイスは、以前のホストのバージョンの場合より長い期間の間、自身が休止したままであると気づくことがある。休止状態におけるこの期間の長さは、デバイスが安定した動作を維持するために必要な長さを越えることがある。そのような環境下では、デバイスは、デバイスがある一連の内部のハウスキーピングタスクを完了可能な時間の間、ポートがアクティブのままで、臨時ポートを再開するように要求することになる。
【0022】
周辺機器/デバイスの種類
本明細書の一部の実施形態では、記載した機構の実装に対する見返りとして得られる利益は、デバイスの種類に応じて変化することがある。結果に影響し得る2種類の着脱性を広く考慮することは有益である:すなわち、デバイス着脱性およびメディア着脱性である。以下の表1は、これら2つの特性の入れ替えを表す様々なデバイスの種類の例を示す:
【0024】
カテゴリ1および3のデバイスは、TEST UNIT READYポーリングの除去から明らかに恩恵を受けやすいであろう一方で、カテゴリ2および4のデバイスは、ポートをリモートウェイク(remote wake)する機能から恩恵を多く受けることができる。加えて、カテゴリ1のデバイスのユーザは電力を節約するために単にプラグを抜くことができる一方で、カテゴリ3のデバイスのユーザは同じ選択肢が与えられないことがあるということを考慮することが望ましいだろう。カテゴリ3のデバイスは、リムーバブルメディアスロットが占有されているか否かに関わらず、システムの電力を消費することも指摘しておいてもよいだろう。加えて、正規のUSBフラッシュドライブが、カテゴリ1および2の双方に現れることを指摘しておいてもよいだろう。これは正しく、なぜなら、既存のフラッシュドライブの大部分が、リムーバブルメディアビット(RMB)に対してビット値1(真)を指定するので、リムーバブルストレージメディアの正しいベアラ(bearer)でないにも関わらず、TEST UNIT READYポーリングを誘発するためである。しかしながら、一部のフラッシュドライブは、たとえば、ゼロに設定されたリムーバブルメディアビット(RMB)(すなわち、RMB=0)により、自身の非リムーバブルメディアを正確に表現し、不正確な値(RMB=1)を報告するデバイスに比べて、接続されたホストシステムに対してより多くの電力を節約するのに効果的に役立つ。
【0025】
一実施形態
述べたように、USBフラッシュドライブのこの不要なメディアポーリングを安全に除去することにより得られる利益は多種多様である:
(1)継続的なポーリングは、デバイスをアクティブに保持する傾向があるので、選択的な休止を阻害する。ポーリングを除去することにより、デバイス自体をアイドル状態に到達させて、低電力非アクティブ状態に置くことが可能とすることができる。
(2)これは、デバイスだけでなく、全体のUSBデバイスツリーに影響することがあり、というのは、全ての介在するハブデバイスが、USBホストコントローラに加えて、アクティブのままである傾向があるためである。
(3)連続的なポーリングDPCタイマもまた、CPUを不必要にアクティブに保つ傾向がある場合がある。
【0026】
したがって、本当に着脱可能なリーダデバイス対USBフラッシュドライブの正確な識別に作用することで、ポーリングを安全に除去することが望ましいだろう。また、誤った識別を行うと、メディア変更が見逃されることがあるので、場合により、機能が低下し、データ崩壊が起こり得ることになる。
【0027】
図3は、USB3.0規格などに影響し得る、本システム(300)の1つの例示の実施形態を示す。レガシーUSBマスストレージデバイス308は、ストレージメディア316と、処理コンポーネント314と、インターフェースバンドル310とを備え、インターフェースバンドル310は、レガシーインターフェースIN EP 310aおよびOUT EP 310bをさらに備えることができる。
【0028】
この場合、レガシーデバイスがリムーバブルメディアを有するか否かを誤って指定することがあるとしても、システムは、非同期通知を、そのような非同期通知を待つUSBマスストレージドライバ306と共に、これは到着することはないが、依然として採用できることがある。システムがストレージデバイスから非同期通知メッセージを受信する場合、これはストレージデバイスがレガシーデバイスでないことを示す傾向があり、システムは、そのような通知メッセージを受信したときを含めて、そのデバイスをしかるべく扱うことができ、システムは、そのIDまたはストレージデバイスに関連する他のメタデータを用いて、ストレージデバイスが本当にリムーバブルメディアを有するとしてデータベースを更新することができる。このデータおよび/またはデータベースはさらに、テレメトリまたはその他により、他のホストシステムと共有することができる。
【0029】
ステータスは、メディア変更処理304aにより、ブロックストレージドライバ304に非同期で通知することができる。最後に、そのようなステータスはさらに、上位レベルファイルシステムドライバスタック302に通知することができる。ブロックストレージドライバ304はさらに、メディア変更処理、または、接続されたストレージデバイスのステータスを検出し、I/O処理に対する準備状況またはRMBステータスについてストレージデバイスに問い合わせるための何らかの十分な処理を実行するプロセッサを備えるか、または十分な処理能力にアクセスすることができる。
【0030】
この節電非同期ステータス更新に作用するために、本システムのいくつかの実施形態は、リムーバブルメディアの正しい指定および/または検出を改良するための様々な技法および/または方法を採用することができる。
【0031】
単なる一例として、製品を出荷する前に、データを照合することが可能である。まず、出来る限り多くの既知の(レガシーまたはその他の)USBフラッシュドライブ対リーダデバイスを識別することが可能である。これらのリーダおよびデバイスに関するメタデータは、検索可能テーブルまたは他の適したデータベース内に置くことができる。このデータベースは、(たとえば初期テーブルとして)調べることができ、システムは、正しいポーリング動作を必要に応じて用いることができる。
【0032】
しかしながら、この初期テーブル/データベースは、網羅的でも前向きでもないという点で制限があることがあるので、ホストシステムは、特定の追加のヒューリスティックな手続きおよび/または方法を用いて、以下のようにこれをさらに精製することが可能である:
(1)初期化中、RMB=1と報告する一部または全部のレガシーユニット(LUN)に、TURコマンド(または、デバイスがI/O処理の準備ができていることを示す何らかの他の「ready」コマンド)を一度発行する。少なくとも1つのLUNがTURに対してNOT READY−MEDIA NOT PRESENTと応答した場合、これは、フラッシュカードリーダまたは本当にリムーバブルメディアを有する他のデバイスである。システムまたはホストは、そのデバイスへのポーリングを無効にすることおよび/またはデバイスが本当にリムーバブルメディアを有するとしてテーブル/データベースを更新することを含めて、これを後でしかるべく扱うことができる。
(2)全てがREADYを報告する場合、さらなる証拠が、正確な判定を行うために要求されることがある。テレメトリのレポートにおいて、デバイスのハードウェアID(VIDおよびPID)、LUN数、および、各LUNがREADY対NOT READYを報告した回数(これは、若干のRMB=0のデバイスが時々および断続的にNOT READYを報告するので、望ましい場合がある)を含むように、データをアップロードし共有すること(たとえば他のホストと共にデバイス正誤(errata)データベースを更新すること)が可能である。
(3)テレメトリサンプルデータを集約し、初期テーブル/データベースに含まれなかった可能性のある、可能性の高いUFD対フラッシュカードリーダデバイスを識別する。このレビュー処理は、任意のまれなケースまたは異常を考慮から除外するのに役立つことがある。
(4)この新しい情報を定期的に用いて、テーブル/データベースを更新し、動的にドライバを更新する。
【0033】
述べたように、非同期通知を実装する新しいUSBマスストレージデバイスは、ホストに公開されたインターフェース記述子バンドルに挿入された追加のインタラプトエンドポイントを介して、そのようにすることができる。レガシー(または下位の)ホストは、この新しい非同期通知機能に気づいていないが、追加のエンドポイントを単に無視し、新しい機能を利用できないままとすることができる。
【0034】
しかしながら、新しいホストシステムだけが、この新しい非同期通知機構を認識し利用することができる。これは、新しいインタラプトエンドポイントを選択し、デバイスがアクティブなD0電源状態のままである限り、持続する未処理の要求をこのエンドポイント上に保持することで行う。この要求は、デバイスにより生成された任意のメディア変更イベントがあったときに、デバイスにより完了する。これに続いて、ホストは、最近完了した要求を置き換えるための他のインタラプトエンドポイント要求を再発行する。デバイスが非アクティブなD3電源状態に遷移したとき、ホストシステムは、インタラプトエンドポイントへのこの未処理の要求を取り消す。続いて、デバイスがアクティブD0電源状態に復旧したとき、デバイス上のローカルに検出されたメディア変更に対応するデバイスウェイクシグナリングの結果として、またはホストが開始した遷移に起因して、ホストは、持続するインタラプトエンドポイントの非同期通知要求を再確立する。
【0035】
いくつかの処理実施形態
図4は、リムーバブルメディアを有するとは限らないレガシーデバイス間を識別および/または区別するのを手助けし、電力を節約するのを手助けすることができる処理の1つのフローチャートの実施形態(400)を示す。
【0036】
402において、デバイスをハブに挿入することができ、その後、システムは、404においてInquiryコマンド(すなわち、何らかのreadyコマンド)を発行することができる。このデバイスがリムーバブルメディアを有さないこと(RMB=0)を折り返し報告する場合、システムは、414の節電経路へ遷移することができ、ここでデバイスアイドルタイマをリセットすることができる。システムは、デバイスが切断されているというレポートを受信することがあり、この場合、424においてデバイスをさらなる考慮から除外することができる。
【0037】
しかしながら、システムからのI/O要求がある場合、デバイスアイドルタイマを414に戻ってリセットすることができ、この要求は処理される。そのようなI/O要求がない場合、デバイスアイドルタイマは、420において期限切れになり得る。その場合、422において、電力を節約するために、デバイスポートを休止させることができる。
【0038】
しかしながら、406に戻って、デバイスがRMB=1(すなわちリムーバブルメディアを有する)と報告する場合、システムは、何らかのヒューリスティックなテストを用いて、デバイスが本当にリムーバブルメディアを有するかを判定することができる。一実施形態では、そのようなヒューリスティックなテストは、上記のものに従って進行することができる。デバイスがヒューリスティックスによると非リムーバブルメディアを有する場合、この処理は414に遷移し、しかるべく進行することができる。
【0039】
そうでなければ、システムは、デバイスが、(たとえば、BOT/UASP規格拡張、またはそのような非同期通知をサポート可能な任意の他の規格に従って)非同期メディア通知を実装しているかについて、さらに問い合わせることができる。その場合、システムは414に遷移することができる。そうでなければ、システムは、定期的なTURポーリングを実行することができ、デバイスはアイドル状態になることができない。
【0040】
図5は、節電の実施を支援可能な他の処理(たとえば
図4など)を補完し、ならびにリムーバブルメディアステータスを誤報告し得るデバイスに関するメタデータを更新し精製することが可能な、他のフローチャートの実施形態(500)である。502において、デバイスを挿入することができる。504において、システムは、テーブル/データベースを調べて、特定のデバイスのステータスを判定することができる。506において、デバイスがリムーバブルメディアを有さないものとしてリストに含まれる場合、508において、システムは、このデバイスに対してTURポーリングを無効にすることができる。
【0041】
そうでなければ、データベースエントリがない場合、システムは510に遷移し、デバイスが切断されるかを検出することができる。その場合、システムは、デバイス取り外し状態518に遷移することができる。そうでなければ、システムは、TURポーリングへのデバイスの応答を監視することができる。メディアが存在しないことを示す応答があった場合、システムは、516において、デバイスに関するデータを収集し、テレメトリによりデバイスを報告することができる。そうでなければ、システムは、TURポーリングに対するデバイスの応答を監視し続け、しかるべく進行することができる。
【0042】
図6は、参加しているホストシステムからテレメトリデータを収集し集約する(たとえばサーバシステム上でオフラインで動作し得る)処理のさらなる他のフローチャートの実施形態(600)である。これを用いて、リムーバブルメディアステータスを誤認し得るデバイスを正しく識別するように、テーブル/データベースを更新することができる。この処理は、オフラインか否かにかかわらず、進行することができる。602において、システムは、デバイスデータベースを更新するために、テレメトリデータをレビューすることができる。更新されたデータベースを用いて、システムは、604において、任意の非リムーバブルメディアが存在するかを判定することができる。その場合、システムは、606において、特定のデバイスの取り扱いについて全ての更新可能なホストシステムに通知するために、データベースを更新することができる。報告すべき新しいデバイスが存在する場合、システムはこの情報をデータベースにプッシュできる。ある後の時点で、このデータベースは、適切な更新処理により(たとえばWindows Update(登録商標)コンピュータサービスにより)、全ての更新可能なホストシステムと共有することができる。
【0043】
上記の記載には、本革新の例が含まれている。特許請求する主題を説明するために、コンポーネントまたは方法の全ての考え得る組合せを説明することはもちろん不可能であるが、当業者は、本革新の多数のさらなる組合せおよび順列が可能であることを理解するだろう。したがって、特許請求する主題は、添付の特許請求の範囲の趣旨および範囲内に含まれる全てのそのような変更、修正、および変形を含むものとする。
【0044】
具体的には、上述のコンポーネント、デバイス、回路、システムなどにより実行される様々な機能に関して、そのようなコンポーネントを記述するのに用いられる(「手段」への言及を含む)用語は、別段の指示がない限り、開示された構造と構造的に同等でなくても、記述したコンポーネントの指定機能を実行し、特許請求する主題の本明細書で示された例示の諸態様の機能を実行する、任意のコンポーネント(たとえば機能的な同等物)に対応するものとする。これに関して、本革新が、特許請求する主題の様々な方法の行為および/またはイベントを実行するためのコンピュータ実行可能命令を有するシステムならびにコンピュータ可読媒体を含むこともまた理解されよう。
【0045】
加えて、本革新の特定の特徴は、いくつかの実装のうちの1つのみに関して開示されている場合があるが、そのような特徴は、任意の所与のまたは特定の用途のために望むようにおよび有利なように、他の実装の1つまたは複数の他の特徴と組み合わせることができる。さらに、「含む(includes)」および「含む(including)」という用語およびこれらの変形が、発明を実施するための形態または特許請求の範囲において用いられる範囲においては、これらの用語は、「備える(comprising)」という用語と同様に、包含的であるものとする。