"コンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたデバイスに対するデータのリード又はライトを要求するコマンドが発行された場合に、前記コマンド発行元プロセスから前記コマンドが伝達されるデバイスドライバと、前記コンピュータ上のカーネル空間において作動するソフトウェアであり、前記デバイスドライバへ前記コマンドが伝達された場合に、前記デバイスドライバから前記コマンドが伝達されるデーモンプロセスと、前記デーモンプロセスと前記デバイスとの間に介在するハードウェア及びソフトウェアによって構成され、前記デーモンプロセスへ前記コマンドが伝達された場合に、前記コマンドを前記デーモンプロセスから前記デバイスへと伝送する通信用インターフェース部と、前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デバイスドライバから前記デーモンプロセスへ前記コマンドが伝達される際に、その旨を示す情報が前記デバイスドライバによって書き込まれて当該情報を記憶する第一記憶手段と、前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了した際に、その旨を示す情報が前記デーモンプロセスによって書き込まれて当該情報を記憶する第二記憶手段と、前記第一記憶手段及び前記第二記憶手段に記憶された情報を、前記コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部とを備え、前記コンピュータ上のユーザ空間において作動するプロセスが、前記情報公開用インターフェース部を介して前記第一記憶手段及び前記第二記憶手段それぞれに記憶された情報を読み取って、それらの情報に基づいて、前記デバイスへの前記コマンドの伝送が完了したか否かを判定可能とされていることを特徴とするデバイス制御システム。前記第一記憶手段は、前記デバイスドライバから前記デーモンプロセスへ前記コマンドが伝達されるたびに、所定値を加算又は減算した値に更新されるカウンタ値が、前記デバイスドライバによって書き込まれ、前記第二記憶手段は、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了するたびに、前記所定値を加算又は減算した値に更新されるカウンタ値が、前記デーモンプロセスによって書き込まれることを特徴とする請求項1に記載のデバイス制御システム。前記第一記憶手段は、前記デバイスドライバから前記デーモンプロセスへ前記コマンドが伝達されるたびに、当該コマンドによるリード又はライト対象として指定されたブロック数又はセクタ数を加算又は減算した値に更新されるカウンタ値が、前記デバイスドライバによって書き込まれ、前記第二記憶手段は、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了するたびに、当該コマンドによるリード又はライト対象として指定されたブロック数又はセクタ数を加算又は減算した値に更新されるカウンタ値が、前記デーモンプロセスによって書き込まれることを特徴とする請求項1に記載のデバイス制御システム。前記コンピュータは、Linux登録商標をオペレーティングシステムとして備えることを特徴とする請求項1~請求項3のいずれか一項に記載のデバイス制御システム。前記デバイスは、USBマスストレージデバイス、MMCMultiMediaCardデバイス、又はSDSecureDigitalメモリカードデバイスであることを特徴とする請求項1~請求項4のいずれか一項に記載のデバイス制御システム。コンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたデバイスに対するデータのリード又はライトを要求するコマンドが発行された場合に、前記コマンド発行元プロセスから前記コマンドが伝達されるデバイスドライバと、前記コンピュータ上のカーネル空間において作動するソフトウェアであり、前記デバイスドライバへ前記コマンドが伝達された場合に、前記デバイスドライバから前記コマンドが伝達されるデーモンプロセスと、前記デーモンプロセスと前記デバイスとの間に介在するハードウェア及びソフトウェアによって構成され、前記デーモンプロセスへ前記コマンドが伝達された場合に、前記コマンドを前記デーモンプロセスから前記デバイスへと伝送する通信用インターフェース部と、前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デバイスドライバから前記デーモンプロセスへ前記コマンドが伝達される際に、その旨を示す情報が前記デバイスドライバによって書き込まれて当該情報を記憶する第一記憶手段と、前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了した際に、その旨を示す情報が前記デーモンプロセスによって書き込まれて当該情報を記憶する第二記憶手段と、前記第一記憶手段及び前記第二記憶手段に記憶された情報を、前記コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部とを備えるデバイス制御システムが機能する前記コンピュータを、さらに、前記コンピュータ上のユーザ空間において作動するプロセスとして機能させるプログラムであって、前記コンピュータを、前記情報公開用インターフェース部を介して前記第一記憶手段及び前記第二記憶手段それぞれに記憶された情報を読み取る読取手段、前記読取手段によって読み取った情報に基づいて、前記デバイスへの前記コマンドの伝送が完了したか否かを判定する判定手段、及び前記判定手段による判定結果を、前記コンピュータ上のユーザ空間において作動する他のプロセスへ提供する情報提供手段として機能させることを特徴とするプログラム。しかし、アプリケーションソフトウェアが、連続的に複数の処理を実行した際に、先に実行した処理で上述のような遅延処理が生じていると、それに起因して後から実行する処理でエラーが発生することがある。例えば、アプリケーションソフトウェアが、先にストレージデバイスのフォーマット処理を実行し、引き続いてフォーマット後のファイルシステムのマウント処理を連続的に行うと、上述のような遅延処理に起因した問題を招くおそれがある。より詳しく説明すると、フォーマット処理での遅延書き込みが完了する前に、マウント処理が実行されると、管理領域データの書き込みが完了していないにもかかわらず、マウント処理において管理領域データが読み出されてしまう可能性がある。この場合、マウント処理では、フォーマット不正のストレージデバイスと認識されてしまうおそれがある。しかも、そのようなエラーが発生した直後に、フォーマット処理の遅延書き込みが完了して管理領域が正しい状態になると、フォーマット不正では無い状態に更新されてしまうので、エラーの発生原因を事後的に解析することがきわめて難しいという問題がある。この他、例えば、アプリケーションソフトウェア側でコンピュータの電源を切る場合にも、ストレージデバイスへの遅延書き込みが完了する前に電源を切ってしまうと、遅延書込予定となっていたデータの損失を招くおそれがある。こうした問題を解消するには、アプリケーションソフトウェアが、デーモンプロセスによる遅延処理の完了を確実に待ってから、次の処理要求をデバイスドライバやデーモンプロセスに伝達することが重要となる。しかし、Linux登録商標が搭載されたコンピュータでは、アプリケーションソフトウェア側からデーモンプロセスによる遅延処理が完了したか否かを確認できるような手段が用意されていない、という問題がある。そのため、現状では、アプリケーションソフトウェアによって上述のようなフォーマット処理やマウント処理、あるいは電源断処理を行うに当たっては、遅延書き込みの完了が期待できる程度まで十分に待ってから、次の処理を行ったり電源を切ったりする、といった対策を取らざるを得ないのが実情であった。また、このような対策を取ることならできるものの、どの程度待てば遅延書き込みが完了するのかは、単なる経験則に基づく想定に過ぎず、何ら保証される時間が規定されているわけではないので、非常に不確実な対策にしかなり得ないという問題があった。さらに、多くの場合は、ごく短時間例えば1秒足らずだけ待てば遅延書き込みが完了しており、遅延書き込みが完了するまでに長時間例えば20秒程度を要するのは、ごくまれなケースに過ぎない。しかし、このようなまれなケースにも対処するためには、常に十分に長時間例えば30秒程度が経過してからしか、次の処理を行ったり電源を切ったりすることができないため、非常に効率が悪いという問題もあった。本発明は、上記のような問題を解決するためになされたものであり、その目的は、デバイスドライバがデーモンプロセス経由でデバイスを制御するデバイス制御システムにおいて、デーモンプロセスでの処理が完了したか否かをアプリケーションソフトウェア側からでも確実に検知可能とすることにある。以下、本発明において採用した構成について説明する。本発明のデバイス制御システムは、コンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたデバイスに対するデータのリード又はライトを要求するコマンドが発行された場合に、前記コマンド発行元プロセスから前記コマンドが伝達されるデバイスドライバと、前記コンピュータ上のカーネル空間において作動するソフトウェアであり、前記デバイスドライバへ前記コマンドが伝達された場合に、前記デバイスドライバから前記コマンドが伝達されるデーモンプロセスと、前記デーモンプロセスと前記デバイスとの間に介在するハードウェア及びソフトウェアによって構成され、前記デーモンプロセスへ前記コマンドが伝達された場合に、前記コマンドを前記デーモンプロセスから前記デバイスへと伝送する通信用インターフェース部と、前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デバイスドライバから前記デーモンプロセスへ前記コマンドが伝達される際に、その旨を示す情報が前記デバイスドライバによって書き込まれて当該情報を記憶する第一記憶手段と、前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了した際に、その旨を示す情報が前記デーモンプロセスによって書き込まれて当該情報を記憶する第二記憶手段と、前記第一記憶手段及び前記第二記憶手段に記憶された情報を、前記コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部とを備え、前記コンピュータ上のユーザ空間において作動するプロセスが、前記情報公開用インターフェース部を介して前記第一記憶手段及び前記第二記憶手段それぞれに記憶された情報を読み取って、それらの情報に基づいて、前記デバイスへの前記コマンドの伝送が完了したか否かを判定可能とされていることを特徴とする。このようなデバイス制御システムによれば、デバイスドライバからデーモンプロセスへコマンドが伝達される際、その旨を示す情報が、デバイスドライバによって第一記憶手段に書き込まれる。また、デーモンプロセスから通信用インターフェース部を介してデバイスへのコマンドの伝送が完了した際、その旨を示す情報が、デーモンプロセスによって第二記憶手段に書き込まれる。さらに、コンピュータには、これら第一記憶手段及び第二記憶手段に記憶された情報を、コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部が設けられている。そのため、コンピュータ上のユーザ空間において作動するプロセス例えば、アプリケーションソフトウェアのプロセスは、情報公開用インターフェース部を介して第一記憶手段及び第二記憶手段それぞれに記憶された情報を読み取ることができ、それら読み取った情報に基づいて、デバイスへのコマンドの伝送が完了したか否かを判定できる。具体的には、例えば、前記第一記憶手段は、前記デバイスドライバから前記デーモンプロセスへ前記コマンドが伝達されるたびに、所定値を加算又は減算した値に更新されるカウンタ値が、前記デバイスドライバによって書き込まれ、前記第二記憶手段は、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了するたびに、前記所定値を加算又は減算した値に更新されるカウンタ値が、前記デーモンプロセスによって書き込まれるように構成されているとよい。この場合、第一記憶手段及び第二記憶手段それぞれに記憶されたカウンタ値が一致していれば、遅延処理が完了していると判断できる。また、この場合、カウンタ値はコマンドの発行回数に応じた値となるので、コマンドの発行回数をユーザ空間において作動するプロセス例えば、アプリケーションソフトウェアのプロセス側で検証することもできる。また、例えば、前記第一記憶手段は、前記デバイスドライバから前記デーモンプロセスへ前記コマンドが伝達されるたびに、当該コマンドによるリード又はライト対象として指定されたブロック数又はセクタ数を加算又は減算した値に更新されるカウンタ値が、前記デバイスドライバによって書き込まれ、前記第二記憶手段は、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了するたびに、当該コマンドによるリード又はライト対象として指定されたブロック数又はセクタ数を加算又は減算した値に更新されるカウンタ値が、前記デーモンプロセスによって書き込まれるように構成されているとよい。この場合も、第一記憶手段及び第二記憶手段それぞれに記憶されたカウンタ値が一致していれば、遅延処理が完了していると判断できる。また、この場合、カウンタ値はリード又はライト対象となったブロック数又はセクタ数に応じた値となるので、そのようなブロック数又はセクタ数をユーザ空間において作動するプロセス例えば、アプリケーションソフトウェアのプロセス側で検証することもできる。以上のようなデバイス制御システムは、デバイスドライバから発行されるコマンドが、いったんデーモンプロセスに伝達されて、そのデーモンプロセスにおいて遅延処理が行われることとなるコンピュータであれば採用できるが、そのようなコンピュータの代表例としては、Linux登録商標をオペレーティングシステムとして備えるコンピュータを挙げることができる。また、デバイス制御システムによる制御対象デバイスの代表例としては、USBマスストレージデバイス、MMCデバイス、又はSDメモリカードデバイスを挙げることができる。さらに、本発明のプログラムは、コンピュータ上のカーネル空間において作動するソフトウェアであり、前記コンピュータ上のユーザ空間において作動するコマンド発行元プロセスから、前記コンピュータに接続されたデバイスに対するデータのリード又はライトを要求するコマンドが発行された場合に、前記コマンド発行元プロセスから前記コマンドが伝達されるデバイスドライバと、前記コンピュータ上のカーネル空間において作動するソフトウェアであり、前記デバイスドライバへ前記コマンドが伝達された場合に、前記デバイスドライバから前記コマンドが伝達されるデーモンプロセスと、前記デーモンプロセスと前記デバイスとの間に介在するハードウェア及びソフトウェアによって構成され、前記デーモンプロセスへ前記コマンドが伝達された場合に、前記コマンドを前記デーモンプロセスから前記デバイスへと伝送する通信用インターフェース部と、前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デバイスドライバから前記デーモンプロセスへ前記コマンドが伝達される際に、その旨を示す情報が前記デバイスドライバによって書き込まれて当該情報を記憶する第一記憶手段と、前記コンピュータ上のカーネル空間に確保される記憶手段であり、前記デーモンプロセスから前記通信用インターフェース部を介して前記デバイスへの前記コマンドの伝送が完了した際に、その旨を示す情報が前記デーモンプロセスによって書き込まれて当該情報を記憶する第二記憶手段と、前記第一記憶手段及び前記第二記憶手段に記憶された情報を、前記コンピュータ上のユーザ空間において作動するプロセスから読み取り可能とする情報公開用インターフェース部とを備えるデバイス制御システムが機能する前記コンピュータを、さらに、前記コンピュータ上のユーザ空間において作動するプロセスとして機能させるプログラムであって、前記コンピュータを、前記情報公開用インターフェース部を介して前記第一記憶手段及び前記第二記憶手段それぞれに記憶された情報を読み取る読取手段、前記読取手段によって読み取った情報に基づいて、前記デバイスへの前記コマンドの伝送が完了したか否かを判定する判定手段、及び前記判定手段による判定結果を、前記コンピュータ上のユーザ空間において作動する他のプロセスへ提供する情報提供手段として機能させることを特徴とする。このようなプログラムに基づいて、コンピュータを上記各手段として機能させるプロセスを作動させれば、当該プロセスが、情報公開用インターフェース部を介して第一記憶手段及び第二記憶手段それぞれに記憶された情報を読み取り、読み取った情報に基づいてデバイスへのコマンドの伝送が完了したか否かを判定し、その判定結果を、コンピュータ上のユーザ空間において作動する他のプロセスへ提供する。したがって、このような判定結果を得るための処理を、他のプロセスが自ら実行できる仕組みを備えていなくても、他のプロセスは、上記判定結果を提供するプロセスを起動させて、そのプロセスから提供される判定結果を受け取ることができる。そして、他のプロセスでは、受け取った判定結果に基づいて、デバイスへのコマンドの伝送が完了したことを確認した後、引き続いて次の処理を実行できるので、デバイスへのコマンドの伝送が完了していないにもかかわらず、次の処理を実行してしまうのを未然に防止することができる。次に、本発明の実施形態について一例を挙げて説明する。[デバイス制御システムの構成]以下に例示するデバイス制御システムは、図1に示すように、コンピュータ1上で機能して、このコンピュータ1に接続されたデバイス例えば、USB-HUB2を介して接続されたUSBマスストレージデバイス3などを制御するシステムである。USB-HUB2には、USB規格に準拠した他のデバイスD1,D2なども接続可能となっている。また、図1においては図示を省略してあるが、コンピュータ1には、USBマスストレージデバイス3以外のストレージデバイス例えば、MMCデバイスやSDメモリカードデバイスなども接続可能で、これらのストレージデバイスも、以下に説明するデバイス制御システムによって制御可能となっている。なお、以下の説明では、USBマスストレージデバイス3、MMCデバイス、及びSDメモリカードデバイスなどを総称して、USBマスストレージデバイス3等のデバイスという。コンピュータ1は、OSとしてLinux登録商標が搭載されたものであり、このOSの機能により、コンピュータ1上には、OSによって管理されるカーネル空間及びユーザ空間が構成されている。これらのうち、ユーザ空間では、アプリケーションA1~A3、sfdisk,mkfsなどの特殊アプリケーションA4、動作完了確認ツールA5などが機能する。また、カーネル空間では、デバイス制御システムに関連するソフトウェアとして、ファイルシステム11、デバイスドライバ13、デーモンプロセス15、及びバスマネージャ17などが機能する。この他、コンピュータ1は、デバイス制御システムに関連するハードウェアとして、I/Fハードウェア19などを備えている。ファイルシステム11は、OSの一部として提供されるシステムで、ストレージデバイスなどが備える記憶領域に格納されるデータをファイルとして管理するとともに、そのファイルに対するリードやライトを行うためのアプリケーションインターフェースを提供する。本実施形態において、ファイルシステム11は、FATやXFSなどの規格に対応したものとされている。アプリケーションA1などは、ファイルシステム11によって提供されるアプリケーションインターフェースを利用して、USBマスストレージデバイス3等のデバイスに格納されたファイルにアクセスすることができる。デバイスドライバ13は、USBマスストレージデバイス3等のデバイスを制御するために、OSに組み込まれるソフトウェアである。アプリケーションA1などからUSBマスストレージデバイス3等のデバイスに対するデータのリード又はライトを要求するコマンドが発行された場合、そのコマンドはデバイスドライバ13へと伝達される。デバイスドライバ13は、自身が制御対象としているデバイスに対応する記憶領域を確保し、その記憶領域にデバイス固有データ13Aを格納する。デバイス制御システムに関連するデータとしては、6個のカウンタsdr_drvent,sdr_daeent,sdr_daedon,sdw_drvent,sdw_daeent,sdw_daedonが、デバイス固有データ13A内に確保される。なお、詳しくは後述するが、デバイスドライバ13は、2個のカウンタsdr_drvent,sdw_drventを更新する。また、デバイスドライバ13は、ファイルやデバイスに対するオープンコマンドが伝達されると、それに対応付けてハンドルと呼ばれる記憶領域図1ではハンドルH1,H2を例示。を確保し、その記憶領域にハンドル固有データ図1ではハンドル固有データ13B,13Cを例示。を格納する。アプリケーションA1などからファイルシステム11に対してファイルのオープンコマンドが発行された場合、オープンされたファイルに対応するデバイスをオープンするコマンドは、ファイルシステム11からデバイスドライバ13へと伝達される。また、アプリケーションの中には、デバイスに対して直接オープンコマンドを発行する特殊アプリケーションA4例えば、sfdisk,mkfs。などもあり、このような特殊アプリケーションA4からはデバイスドライバ13へ直接コマンドが伝達される。なお、図1では、図を簡潔にする都合上、単一のデバイスドライバ13を図示してあるが、実際は、個々のデバイス例えば、USBマスストレージデバイス3、MMCデバイス、SDメモリカードデバイスなどそれぞれに対応するデバイスドライバ13がコンピュータ1上で機能する。デーモンプロセス15は、デバイスドライバ13同様、OSの一部を構成するソフトウェアであり、上述のコマンドがデバイスドライバ13へと伝達された際には、さらにデバイスドライバ13からコマンドが伝達される。なお、詳しくは後述するが、このデーモンプロセス15は、上述のデバイス固有データ13A内にある4個のカウンタsdr_daeent,sdr_daedon,sdw_daeent,sdw_daedonを更新する。図1では、図を簡潔にする都合上、3つのUSBデバイスに対応するデーモンプロセスを図示してあるが、これも、実際は、個々のデバイス例えば、USBマスストレージデバイス3、MMCデバイス、SDメモリカードデバイスなどそれぞれに対応するデーモンプロセスがコンピュータ1上で機能する。ただし、デバイスの種別によっては、デバイスドライバが直接デバイスに対してコマンドを発行するものもあり、この場合はデバイスドライバとデバイスとの間に介在するデーモンプロセスは存在しない。バスマネージャ17及びI/Fハードウェア19は、デーモンプロセス15とUSBマスストレージデバイス3等のデバイスとの間に介在する通信用インターフェース部本発明でいう通信用インターフェース部。を構成している。デーモンプロセス15へコマンドが伝達された際には、そのコマンドがバスマネージャ17及びI/Fハードウェア19を介してデーモンプロセス15からUSBマスストレージデバイス3等のデバイスへと伝送される。さらに、このコンピュータ1においては、上述の6個のカウンタsdr_drvent,sdr_daeent,sdr_daedon,sdw_drvent,sdw_daeent,sdw_daedonに格納された値を、ユーザ空間で作動するプロセスから読み取り可能とするため、/procバイパスを利用した情報公開用インターフェース部本発明でいう情報公開用インターフェース部に相当。を設けてある。/procは、Linux登録商標において、OSの管理下にあるリソース関連の情報例えば、カーネル空間に確保された記憶領域に格納された値を、ファイルと同様の手順で読み出し可能とするために用意された仮想的なファイルシステムである。Linux登録商標において、USBマスストレージデバイス3に対応する/procバイパスとしては、/proc/scsi/usb-storage/Nただし、Nは0,1,2...などの数字。が標準で用意されているので、本実施形態では、これを流用して、上述の6個のカウンタ値を読み出し可能に構成した。また、MMCデバイスやSDメモリカードデバイス用の/procバイパスについては、OS標準での用意がないので、本実施形態では、/proc/driver/bil-mmc-infoを新設して、上述の6個のカウンタ値を読み出し可能とした。なお、このような/procバイパスは、本実施形態では、動作完了確認ツールA5によって利用される。動作完了確認ツールA5の詳細については後述する。[デバイスドライバにおいて実行される処理]次に、デバイスドライバ13において実行される処理について、図2のフローチャートに基づいて説明する。図2に示すデバイスドライバコマンド実行処理は、OS経由でデバイスドライバ13へと伝達されるコマンドを対象に、そのコマンドに応じてデバイスドライバ13が実行する処理である。デバイスドライバ13へと伝達されるコマンドは、例えば、アプリケーションA1などのコマンド発行元プロセスが、OSの提供するアプリケーションインターフェースを介してコマンドを発行したような場合に、デバイスドライバ13へと伝達されるものである。このようなコマンドは、OSがデバイスドライバ13に対して伝達する汎用形式のコマンドとされており、後述するSCSI形式のコマンドとは形式が異なるものである。以下の説明の中では、SCSI形式のコマンドについて言及する場合は、SCSIコマンドと明記する。図2に示す処理が実行されるタイミングは、多数のデバイスが並列処理できるようにするため、OSによってコントロールされている。デバイスドライバ13は、デバイスハンドルをパラメータとして受け取っており、指定されたハンドル内コマンドスタック内に1以上のコマンドが積まれた際に、1つのコマンドを対象に図2に示す処理が実行される。図2に示す処理を開始すると、デバイスドライバ13正確には、デバイスドライバ13としての処理を実行するコンピュータ1;以下、単にデバイスドライバ13という。は、指定されたハンドルのコマンドスタックから1コマンドを取り出すS105。そして、デバイスドライバ13は、コマンドを判別してS110、リードコマンドであった場合はS110:リードコマンド、リードのSCSIコマンドを生成しS115、カウンタsdr_drventをインクリメントするS120。なお、カウンタsdr_drventは、デバイスドライバ13の作動開始時に初期化ゼロクリアされており、その後は、S120が実行されるたびにインクリメントされることになる。一方、S110において、ライトコマンドであった場合S110:ライトコマンド、デバイスドライバ13は、ライトのSCSIコマンドを生成しS125、カウンタsdw_drventをインクリメントするS130。なお、カウンタsdw_drventは、デバイスドライバ13の作動開始時に初期化ゼロクリアされており、その後は、S130が実行されるたびにインクリメントされることになる。こうしてS120又はS130を終えたら、デバイスドライバ13は、生成したSCSIコマンドをメッセージキューに積んでS135、図2に示すデバイスドライバコマンド実行処理を完了する。なお、S110において、リードライト以外のコマンドであった場合S110:リードライト以外、デバイスドライバ13は、リードライト以外のコマンドに対応するの処理を実行しS140、図2に示すデバイスドライバコマンド実行処理を完了する。ただし、S140は本発明の要部とは関連性が低い処理となるので、これ以上の説明については省略する。以上説明したように、図2に示した処理では、S135においてSCSIコマンドがメッセージキューに積まれることとなるたびに、S120又はS130においてカウンタsdr_drvent又はカウンタsdw_drventがインクリメントされる。したがって、カウンタsdr_drvent及びカウンタsdw_drventには、デバイスドライバ13におけるリード又はライトのSCSIコマンドの発行回数が蓄積保持されることになる。[デーモンプロセスにおいて実行される処理]次に、デーモンプロセス15において実行される処理について、図3のフローチャートに基づいて説明する。デーモンプロセス15はデバイスドライバ13によって起動され、その後は、対応するデバイスが停止されるまでコンピュータ1に常駐する。図3に示す処理は、デーモンプロセス15が起動されたときに開始される。なお、以下、ディスクデバイスsda/dev/sdaに対応するデーモンプロセス15を例に挙げて説明を続けるが、sdaは単なる一例として例示するものであり、他のデバイスであっても同様の処理となるのはもちろんである。図3に示す処理を開始すると、デーモンプロセス15正確には、デーモンプロセス15としての処理を実行するコンピュータ1;以下、単にデーモンプロセス15という。は、他のデバイスにも時間を与えるため、所定時間ウエイトするS205。そして、ディスクデバイスsdaが取り外されたか否かを判断しS210、ディスクデバイスsdaが取り外されている場合はS210:はい、デーモンプロセス15による処理を終了する。一方、S210において、ディスクデバイスsdaが取り外されていないと判断された場合S210:いいえ、デーモンプロセス15は、デバイス固有データから最初のオープン中ハンドルを取得するS215。そして、オープン中のハンドルが無い場合はS220:はい、S205へと戻る一方、オープン中のハンドルがある場合S220:いいえ、デーモンプロセス15は、取得中ハンドルのメッセージキューから1メッセージを取り出すS225。続いて、デーモンプロセス15は、メッセージ内のSCSIコマンドの種別を判断しS230、SCSIコマンドがリードであった場合S230:リード、カウンタsdr_daeentをインクリメントするS235。なお、カウンタsdr_daeentは、デバイスドライバ13の作動開始時にデバイス固有データ内に確保されて初期化ゼロクリアされており、その後は、S235が実行されるたびにインクリメントされることになる。その後、デーモンプロセス15は、デバイスに対してSCSIコマンドリードを発行して完了を待つS240。S240において、完了を待つ間は他のデバイスに時間を解放する。そして、デバイスからの完了応答が返されたら、カウンタsdr_daedonをインクリメントするS245。なお、カウンタsdr_daedonは、デバイスドライバ13の作動開始時にデバイス固有データ内に確保されて初期化ゼロクリアされており、その後は、S245が実行されるたびにインクリメントされることになる。一方、S230において、SCSIコマンドがライトであった場合S230:ライト、デーモンプロセス15は、カウンタsdw_daeentをインクリメントするS250。なお、カウンタsdw_daeentは、デバイスドライバ13の作動開始時にデバイス固有データ内に確保されて初期化ゼロクリアされており、その後は、S250が実行されるたびにインクリメントされることになる。その後、デーモンプロセス15は、デバイスに対してSCSIコマンドライトを発行し完了を待つS255。S255において、完了を待つ間は他のデバイスに時間を解放する。デバイスからの完了応答が返されたら、カウンタsdw_daedonをインクリメントするS260。なお、カウンタsdw_daedonは、デバイスドライバ13の作動開始時にデバイス固有データ内に確保されて初期化ゼロクリアされており、その後は、S260が実行されるたびにインクリメントされることになる。さらに一方、S230において、SCSIコマンドがリードライト以外であった場合S230:リードライト以外、デーモンプロセス15は、デバイスに対してSCSIコマンドリードライト以外を発行し完了を待つS265。S265において、完了を待つ間は他のデバイスに時間を解放する。このようにしてS245,S260,又はS265を終えたら、デーモンプロセス15は、デバイス固有データから次のオープン中ハンドルを取得するS270。そして、オープン中のハンドルが無い場合はS275:はい、S205へと戻る一方、オープン中のハンドルがある場合はS275:いいえ、S225へと戻る。以上説明したように、図3に示した処理では、S240又はS255においてデバイスに対してSCSIコマンドが発行されることとなるたびに、その発行前後双方のタイミングとなるS235及びS245、もしくはS250及びS260において、カウンタsdr_daeent及びカウンタsdr_daedon、もしくはカウンタsdw_daeent及びカウンタsdw_daedonがインクリメントされる。したがって、これらのカウンタsdr_daeent、sdr_daedon、sdw_daeent、sdw_daedonには、デーモンプロセス15におけるリード又はライトのSCSIコマンドの発行回数が、発行直前及び発行後の待機完了直後双方のタイミングで蓄積保持されることになる。[動作完了確認ツールにおいて実行される処理]次に、動作完了確認ツールA5において実行される処理について、図4のフローチャートに基づいて説明する。動作完了確認ツールA5は、コマンド発行元プロセスからデバイスドライバ13へと伝達されるコマンドが、USBマスストレージデバイス3等のデバイスへ実際に伝達されたかどうかをコマンド発行元プロセス側で確認可能とするためのツールである。この動作完了確認ツールA5はコマンド発行元プロセス側で必要なときに任意に起動され、その際、図4に示す処理が実行されることになる。なお、以下の説明では、説明を簡便にするため、USBマスストレージデバイス3がコンピュータ1においてディスクデバイスsdaとして認識されている場合を例に挙げて説明する。ただし、動作完了確認ツールA5は、sda以外のディスクデバイス例えばsdb、sdc...を対象にして所期の処理を行うこともできる。また、USBマスストレージデバイス3以外のデバイスMMCデバイスやSDメモリカードデバイスを対象にして所期の処理を行うこともできる。USBマスストレージデバイス3とMMCデバイスやSDメモリカードデバイスとでは、具体的な処理内容に若干相違する部分もあるので、そのような相違点については、以下の説明の中で言及することにする。図4に示す処理を開始すると、動作完了確認ツールA5正確には、動作完了確認ツールA5としての処理を実行するコンピュータ1;以下、単に動作完了確認ツールA5という。は、/proc/scsi/usb-storageフォルダ内の最初のファイルを検索するS305。コンピュータ1にUSBデバイスが接続されている場合、/proc/scsi/usb-storageフォルダには、0,1,2,...などの数字をファイル名とする仮想的なファイルが生成されるので、S305では、そのようなファイル名を検索する。なお、MMCデバイスやSDメモリカードデバイスを対象とする場合は、/proc/driverフォルダ内のファイルbil-mmc-infoを検索する。ここで、/proc/scsi/usb-storageフォルダ内MMCデバイスやSDメモリカードデバイスの場合は、/proc/driverフォルダ内にファイルがない場合S310:はい、動作完了確認ツールA5は、図4に示す処理を終了するsdaが見つからないエラー終了。一方、S310において、ファイルがある場合S310:いいえ、動作完了確認ツールA5は、検索されたファイル名例えば、0,1,2,...などで情報取得を行うS315。S315において、ファイル/proc/scsi/usb-storage/Nからデータをリードすると、図8aに示すような形式の情報を読み込むことができる。なお、MMCデバイスやSDメモリカードデバイスの場合は、ファイル/proc/driver/bil-mmc-infoからデータをリードすると、図8bに示すような形式の情報を読み込むことができる。そこで、動作完了確認ツールA5は、読み込んだ情報中に含まれるBIL-SDxRWc:の行からディスク名を取得するS320。図8aに例示する情報の場合、BIL-SDxRWc:の行は、最下行のみの行の1行上にあり、この行には、ディスク名図8aではsdaと上述の6個のカウンタsdr_drvent,sdr_daeent,sdr_daedon,sdw_drvent,sdw_daeent,sdw_daedonに格納された値が列挙されている。S320では、このような形式の情報であるとの前提で、先頭に列挙されたディスク名を取得する。なお、MMCデバイスやSDメモリカードデバイスの場合、動作完了確認ツールA5は、S320において、読み込んだ情報中に含まれるBIL-MmcRdWrC:の行からディスク名を取得する。図8bに例示する情報の場合、BIL-MmcRdWrC:の行は、最下行のみの行の1行上にあり、この行には、ディスク名図8bでは0と上述の6個のカウンタsdr_drvent,sdr_daeent,sdr_daedon,sdw_drvent,sdw_daeent,sdw_daedonに格納された値が列挙されている。この情報中、ディスク名の0は、その前にあるべき文字列mmcblkが省略された形式になっているものなので、実際のディスク名はmmcblk0となる。こうしてディスク名を取得したら、本実施形態ではディスクデバイスsdaを対象とした処理を例示しているので、動作完了確認ツールA5は、ディスク名がsdaであるか否かを判断するS325。もちろん、ディスクデバイスsdbを対象とするのであれば、S325では、S320で取得したディスク名がsdbであるか否かを判断することとなる。また、ディスクデバイスmmcblk0を対象とするのであれば、S325では、S320で取得したディスク名が0であるか否かを判断することとなる。S325において、ディスク名がsdaでない場合S325:いいえ、動作完了確認ツールA5は、/proc/scsi/usb-storageフォルダ内MMCデバイスやSDメモリカードデバイスを対象とする場合は、/proc/driverフォルダ内の次のファイルを検索するS330。そして、ファイルがもう無い場合はS335:はい、動作完了確認ツールA5は、図4に示す処理を終了するsdaが見つからないエラー終了。一方、ファイルがまだある場合はS335:いいえ、S315へと戻る。これにより、フォルダ内にファイルがあり、且つ、その中から検索したファイルがsdaに対応するものでない場合は、S315~S335が繰り返されることとなる。そして、そのようなS315~S335を実行する中、S325において、ディスク名がsdaであった場合S325:はい、動作完了確認ツールA5では、sdaにつながるprocバイパス/proc/scsi/usb-storage/Nただし、N=0,1,2,...が見つかったことになるS340。そこで、この場合、動作完了確認ツールA5は、タイムアウトのカウンタとして所定時間例えば1分程度を設定しS345、一定時間例えば100msが経過するのを待つS350。その後、タイムアウトのカウンタを上記一定時間分上記例では100ms減らしてS355、タイムアウトか否かを判断するS360。ここで、タイムアウトであった場合S360:はい、動作完了確認ツールA5は、図4に示す処理を終了するタイムアウトエラー終了。一方、S360において、タイムアウトではない場合S360:いいえ、動作完了確認ツールA5は、ファイル/proc/scsi/usb-storage/NただしN=0,1,2,...から情報取得を行うS365。そして、動作完了確認ツールA5は、カウンタsdr_drvent,sdr_daeent,sdr_daedonの値が全て一致するか否かを判断するS370。ここで、カウンタsdr_drvent,sdr_daeent,sdr_daedonの値が全て一致するのは、S115~S120、S235~S245がすべて実行されている場合に該当する。これは、デバイスドライバ13で発行されたリードのSCSIコマンドが、デーモンプロセス15でもUSBマスストレージデバイス3等のデバイスへと発行され、その応答がデバイスからデーモンプロセス15へすでに返っていることを意味する。逆に、デバイスドライバ13で発行されたリードのSCSIコマンドが、デーモンプロセス15ではまだUSBマスストレージデバイス3等のデバイスへと発行されていない場合、上記カウンタ値は一致しない。また、デーモンプロセス15からUSBマスストレージデバイス3等のデバイスへコマンドが発行されたものの、その応答がデバイスからデーモンプロセス15へまだ返っていない場合も、上記カウンタ値は一致しない。そこで、S370において、カウンタsdr_drvent,sdr_daeent,sdr_daedonの値が一致しない場合はS370:いいえ、S350へと戻る。これにより、S345で設定した時間が経過するまでは、S350~S370が繰り返されることになる。一方、S370において、カウンタsdr_drvent,sdr_daeent,sdr_daedonの値が全て一致した場合S370:はい、動作完了確認ツールA5は、カウンタsdw_drvent,sdw_daeent,sdw_daedonが全て一致するか否かを判断するS375。ここで、カウンタsdw_drvent,sdw_daeent,sdw_daedonの値が全て一致するのは、S125~S130、S250~S260がすべて実行されている場合に該当する。これは、デバイスドライバ13で発行されたライトのSCSIコマンドが、デーモンプロセス15でもUSBマスストレージデバイス3等のデバイスへと発行され、その応答がデバイスからデーモンプロセス15へすでに返っていることを意味する。逆に、デバイスドライバ13で発行されたライトのSCSIコマンドが、デーモンプロセス15ではまだUSBマスストレージデバイス3等のデバイスへと発行されていない場合、上記カウンタ値は一致しない。また、デーモンプロセス15からUSBマスストレージデバイス3等のデバイスへコマンドが発行されたものの、その応答がデバイスからデーモンプロセス15へまだ返っていない場合も、上記カウンタ値は一致しない。そこで、S375において、カウンタsdw_drvent,sdw_daeent,sdw_daedonの値が一致しない場合はS375:いいえ、S350へと戻る。これにより、S345で設定した時間が経過するまでは、S350~S375が繰り返されることになる。したがって、リード又はライトいずれかのコマンドが完全にデバイスへと伝わらない限り、S350~S375が繰り返され、その繰り返しの中でタイムアウトとなった場合にはS360:はい、タイムアウトでエラー終了となるのである。一方、S370において、カウンタsdr_drvent,sdr_daeent,sdr_daedonの値が全て一致しS370:はい、且つS375において、カウンタsdw_drvent,sdw_daeent,sdw_daedonの値が全て一致した場合S375:はい、動作完了確認ツールA5は、図4に示す処理を正常終了する。以上説明したように、動作完了確認ツールA5は、リード及びライトのSCSIコマンドがデバイスドライバ13からデーモンプロセス15経由でUSBマスストレージデバイス3等のデバイスへと伝達され、デバイスからの応答がデーモンプロセス15へ返っている場合に正常終了する。また、リード及びライトのSCSIコマンドがデバイスドライバ13から発行されたものの、タイムアウトを待つ間にデバイスからの応答がデーモンプロセス15へ返る状態に至らなければエラー終了する。正常終了したかエラー終了したかを示す情報は、動作完了確認ツールA5を起動した上位プロセス例えば、アプリケーションなどへと返される。したがって、上位プロセスでは、動作完了確認ツールA5を利用して、USBマスストレージデバイス3等のデバイスに対して発行したコマンドが、デバイスドライバ13やデーモンプロセス15において処理済みとなっているか否かを確認することができる。[アプリケーションにおいて実行される処理の例その1]次に、上述のような動作完了確認ツールA5を利用するアプリケーションの一例を、図5~図7のフローチャートに基づいて説明する。以下に説明するアプリケーションA1は、ディスクデバイスsdaの再初期化を行ってから、引き続いてパーティションの切り直しを行い、さらに引き続いてファイルシステムsda1のマウントを行うものである。なお、以下の処理でも、説明を簡潔にするために、ディスクデバイスsda,ファイルシステムsda1,マウントポイント/mnt/usb1などの具体例を挙げながら説明を行うが、これらの具体例に限られないのはもちろんである。例えば、ディスクデバイスsdbやmmcblk0を対象とすることも可能である。図5に示すディスクの再初期化処理を開始すると、アプリケーションA1正確には、アプリケーションA1としての処理を実行するコンピュータ1;以下、単にアプリケーションA1という。は、/dev/sdaを対象にしてディスク使用停止処理を実行するS405。このディスク使用停止処理は、詳しくは図6に示すような処理となる。すなわち、図6に示す処理では、まず、アプリケーションA1からの指令により、全アプリケーションでマウントポイント/mnt/usb1以下の全てのオープン中のファイルをクローズするS505。なお、この例は、/dev/sda1が/mnt/usb1にマウント中であることを想定している例であり、マウントポイントの具体的パス名は任意である。続いて、アプリケーションA1は、syncコマンドを実行して、ディスクキャッシュ11Aに保持されているデータをUSBマスストレージデバイス3等のデバイスへ書き出すS510。そして、/mnt/usb1をアンマウントして、/dev/sda1のマウントを解除するS515。これにより、/dev/sda1に対しては、少なくともファイルシステム11経由でのアクセスが行われない状態になる。次に、アプリケーションA1は、ディスクデバイスsdaのflushdevice処理を行い、デバイスドライバ13の動作完了待ちになるS520。このflushdevice処理は、デバイスドライバ13が内部的に保持キャッシュしているデータをデバイス側へ掃き出させるために行われる処理であり、Linux登録商標搭載コンピュータではすでに行われている周知の処理である。具体的には、flushdevice処理は、図7aに示すような処理となり、アプリケーションA1は、/dev/sdaをオープンしてハンドルをファイルディスクリプタfdに格納しS605、システムコールioctlfd,BLKFLSBUF,0を実行するS610。これにより、デバイスドライバ13は、コマンドスタック内に未処理のコマンドが残されていたとしても、それらをすべてメッセージキューへ積み、これにより、それらのデータをデーモンプロセス15へ引き渡す準備を完了する。S610を終えたら、アプリケーションA1は、fdのクローズ/dev/sdaのクローズを行ってS615、図7aに示すを完了する。さて、こうしてflushdevice処理を完了したら、再び図6に戻って、アプリケーションA1は、動作確認完了ツールA5を起動してsdaの動作完了待ちになるS525。先に説明した通り、動作確認完了ツールA5は、デーモンプロセス15がデバイスからの応答を受け取ったことを検出したときに正常終了するので、S525では、デーモンプロセス15の動作完了待ちを行うことになる。ここで、動作確認完了ツールA5が正常終了すれば、デーモンプロセス15が保持していたデータすべてがデバイスに掃き出されたことを意味するので、これにて図6に示すディスクの使用停止処理を完了する。なお、動作確認完了ツールA5がエラー終了した場合は、エラーメッセージを表示して処理を中止するなどの対処を行えばよいが、この種のエラー処理自体は一般的なものなので、これ以上の詳細な説明は省略する。図6に示すディスクの使用停止処理を完了したら、図5のS405を終えたことになるので、続いて、アプリケーションA1は、sfdiskコマンドを実行し、パーティションの切り直しを行うS410。そして、sdaのflushdevice処理を行って、デバイスドライバ13の動作完了待ちになりS415、続いて、動作確認完了ツールA5でsdaの動作完了待ち、すなわち、デーモンプロセス15の動作完了待ちになるS420。S415,S420は、先に説明したS520,S525と同等な処理であり、これらの処理により、デバイスドライバ13の保持するデータ、デーモンプロセス15の保持するデータが、それぞれデバイス側へ確実に掃き出されるのを待つことになる。そして、S420を終えたら、sfdiskコマンドの実行に伴ってUSBマスストレージデバイス3等のデバイスへ書き込まれるべきデータが、確実にデバイスに書き込まれたことになる。そこで、アプリケーションA1は、mkfsコマンドを実行し、パーティションのフォーマットを行うS425。そして、sdaのflushdevice処理を行って、デバイスドライバ13の動作完了待ちとなりS430、続いて、動作確認完了ツールA5でsdaの動作完了待ち、すなわち、デーモンプロセス15の動作完了待ちになるS435。S430,S435も、先に説明したS520,S525,S415,S420と同等な主旨で実行する処理である。S435を終えたら、mkfsコマンドの実行に伴ってUSBマスストレージデバイス3等のデバイスへ書き込まれるべきデータが、確実にデバイスに書き込まれたことになるので、アプリケーションA1は、ディスクデバイス/dev/sdaの使用再開処理を行うS440。なお、S440は、詳しくは図7bに示すような処理となる。すなわち、アプリケーションA1は、/dev/sda1を/mnt/usb1にマウントするS705。なお、この例は、/dev/sda1が/mnt/usb1にマウントされることを想定している例であり、マウントポイントの具体的パス名は任意である。このようなマウントが行われると、以降は、全アプリケーションで/mnt/usb1以下のファイルが使用可能になりS710、図7bに示すディスクの使用再開処理が完了する。そして、図7bに示すディスクの使用再開処理が完了すると、図5のS440が完了するので、これにて図5に示すディスクの再初期化処理すべてが完了する。以上説明したように、上記のようなアプリケーションA1では、sfdiskの実行後、flushdevice処理を行ってデバイスドライバ13の管理下にあるデータをデーモンプロセス15へと引き渡している。しかも、動作確認完了ツールA5でデーモンプロセス15の管理下にあるデータが、すべてデバイスに書き込まれたことを確認してから、mkfsを実行している。したがって、このような確認をすることなくsfdiskやmkfsを連続的に実行するものや、sfdiskの実行後にflushdevice処理は行うものの、デーモンプロセス15の動作状況を確認することなくmkfsを実行するものなどとは異なり、ディスク上に生じた不整合なデータが残っているうちに、新たなコマンドが実行されてしまうことがなく、また、それを防止するために、経験則に基づく不確実な様子見を過剰に長時間にわたって行う必要もない。[アプリケーションにおいて実行される処理の例その2]次に、アプリケーションにおいて実行される処理について、上述の一例とは別の例を図7cのフローチャートに基づいて説明する。以下に説明する例は、アプリケーションA2が、コンピュータ1の電源断を行うために実行する処理である。なお、図7cに例示する処理は、ストレージデバイスとして/dev/sdaのみの場合を想定しているが、/dev/sda以外が存在していてもよいのはもちろんである。図7cに示す処理を開始すると、アプリケーションA2は、電源断前の各種処理を実行しS805、続いて、ディスク/dev/sdaについて使用停止処理を実行するS810。S810は、すでに説明した図6に示す処理と同等な処理であり、この処理の中でS520,S525が実行されることで、デバイスドライバ13の保持するデータ、デーモンプロセス15の保持するデータが、それぞれデバイス側へ確実に掃き出されるのを待つことになる。そして、S810を終えたら、アプリケーションA2は、パワーコントロールが可能なハードウェアの場合は電源を切ってS815、図7cに示す電源断処理を完了する。なお、S815において、パワーコントロールが不可能な場合は、電源を切って良いことを表示して、図7cに示す電源断処理を完了する。以上説明したような処理を行えば、S520,S525相当の処理を実行することなく電源断を行うものや、S520のflushdevice処理相当の処理は行うものの、S525相当のデーモンプロセス15の動作完了待機を行うことなく電源断を行うものなどとは異なり、ディスクに書き込まれていないデータが残っているうちに、電源断が行われてしまうことがなく、また、それを防止するために、経験則に基づく不確実な様子見を過剰に長時間にわたって行う必要もない。[変形例等]以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。例えば、上記実施形態では、より詳細なデータの流れを把握、分析しやすくするために、6個のカウンタsdr_drvent,sdr_daeent,sdr_daedon,sdw_drvent,sdw_daeent,sdw_daedonを用いたが、中間のタイミングで更新される2個のカウンタsdr_daeent,sdw_daeentを設けるか否かは任意である。また、上記実施形態では、リードライト双方を監視するために、6個のカウンタsdr_drvent,sdr_daeent,sdr_daedon,sdw_drvent,sdw_daeent,sdw_daedonを用いたが、ライトだけを監視してもよく、その場合は、3個のカウンタsdw_drvent,sdw_daeent,sdw_daedonもしくは2個のカウンタsdw_drvent,sdw_daedonを用いるだけでもよい。ちなみに、上記実施形態においては、カウンタsdr_drvent,sdw_drventが、それぞれ本発明でいう第一記憶手段に相当する。また、カウンタsdr_daedon,sdw_daedonが、それぞれ本発明でいう第二記憶手段に相当する。さらに、上記実施形態では、S115~S120、S125~S130、S235~S245、S250~S260において、コマンドを発行するごとにカウンタをインクリメントしていたので、カウンタにはコマンドの発行回数が蓄積されたが、コマンドの伝達状況を示す情報は、コマンドの発行回数に限らない。例えば、コマンド発行回数に代えて、データの転送量を蓄積してもよい。このデータの転送量も、どのような単位であってもよく、例えば、バイト数、セクタ数、ブロック数など、いずれを蓄積してもよい。このようなデータの転送量を蓄積すれば、蓄積された情報からデータ転送量も把握できるので、そのような分析が必要な場合には便利である。さらに、コマンド発行回数やデータ転送量をゼロから加算するだけではなく、所定の初期値から減算する計算方式を採用してもよく、必要があれば、それらの加算や減算をコマンド発行回数やデータ転送量の整数倍を単位として行ってもよい。"