(57)【要約】    ホスト（１００）からのリードコマンドに応じて、リード処理し、且つライトコマンドに応じて、ライト処理する媒体記憶装置において、受領したリードコマンドにより、ホスト（１００）が、連続データの再生処理のため、一定間隔で発行されるリードコマンドであることを認識し、再生処理中に受信したライトコマンドに対し、ライト処理で、前記ライト失敗の可能性があるかを判定し、ライト失敗の可能性がある場合に、一定間隔で発行されるリードコマンドの受信を許可する制御回路（２８）を設けた。音楽や映像の再生処理中に、リードコマンドの間に送信されるライトコマンドの処理遅延により、リードコマンドの受け付け及び処理が遅延することを防止でき、音楽や映像再生の途切れを防止できる。
2009050765.tif 000002
【特許請求の範囲】
【請求項１】
記録媒体からデータを読み出し、且つデータを記録するリード／ライト機構と、
前記読み出したリードデータと、ホストからのライトデータを一時格納するバッファメモリと、
ホストからのリード要求に応じて、前記バッファメモリ又は前記記憶媒体からリードデータを読み出し、前記ホストに送信し、且つ前記ホストからのライト要求に応じて、前記ホストからライトデータを前記バッファメモリに格納後、前記記憶媒体にライトし、前記ライト失敗時に、ライトリトライを行う制御回路とを有し、
前記制御回路は、受領した前記リードコマンドにより、前記ホストが、連続データの再生処理のため、一定間隔で発行されるリードコマンドであることを認識し、前記再生処理中に受信したライトコマンドに対し、ライト処理で、前記ライト失敗の可能性があるかを判定し、前記ライト失敗の可能性がある場合に、前記一定間隔で発行されるリードコマンドの受信を許可する
ことを特徴とする媒体記憶装置。
【請求項２】
前記制御回路は、前記ライト失敗の可能性がある場合に、前記バッファメモリに、前記ライトコマンドで指定されたライトデータを格納できる空き容量があるかを判定し、前記空き容量がある場合に、前記ホストにライトデータを要求し、前記バッファメモリに格納した後、前記一定間隔で発行されるリードコマンドの受信を許可する
ことを特徴とする請求項１の媒体記憶装置。
【請求項３】
前記制御回路は、前記ライト失敗の可能性がある場合に、前記バッファメモリに、前記ライトコマンドで指定されたライトデータを格納できる空き容量があるかを判定し、前記空き容量がない場合に、前記ホストへのライトデータの要求を禁止し、前記一定間隔で発行されるリードコマンドの受信を許可する
ことを特徴とする請求項２の媒体記憶装置。
【請求項４】
前記制御回路は、前記バッファメモリに前記ライトデータを格納後、ライト処理を実行するとともに、前記一定間隔でのリードコマンドの到来を待つ
ことを特徴とする請求項２の媒体記憶装置。
【請求項５】
前記制御回路は、前記リードコマンドで要求されたデータサイズにより、前記再生処理であることを認識する
ことを特徴とする請求項１の媒体記憶装置。
【請求項６】
前記制御回路は、前記リードコマンドの発行パターンを解析して、前記再生処理であることを認識する
ことを特徴とする請求項１の媒体記憶装置。
【請求項７】
前記制御回路は、前記ライト失敗可能性を、前記ライト失敗の過去の履歴から、判定する
ことを特徴とする請求項１の媒体記憶装置。
【請求項８】
前記制御回路は、前記ライト失敗可能性を、前記ライト処理のリトライ及び前記装置が受ける振動発生の履歴の少なくとも一方により、判定する
ことを特徴とする請求項７の媒体記憶装置。
【請求項９】
前記制御回路は、前記ライト失敗可能性を、前記装置の環境温度により、判定する
ことを特徴とする請求項１の媒体記憶装置。
【請求項１０】
前記制御回路は、前記ライト失敗可能性を、前記装置が振動を受けたか否かにより、判定する
ことを特徴とする請求項１の媒体記憶装置。
【請求項１１】
ホストからのリード要求に応じて、バッファメモリ又は媒体リード／ライト機構により記憶媒体からリードデータを読み出し、前記ホストに送信するリード処理ステップと、
前記ホストからのライト要求に応じて、前記ホストからライトデータを前記バッファメモリに格納後、前記媒体リード／ライト機構により、前記記憶媒体にライトし、前記ライト失敗時に、ライトリトライを行うライト処理ステップと、
前記受領した前記リードコマンドにより、前記ホストが、連続データの再生処理のため、一定間隔で発行されるリードコマンドであることを認識するステップと、
前記再生処理中に受信したライトコマンドに対し、前記ライト処理で、前記ライト失敗の可能性があるかを判定するステップと、
前記ライト失敗の可能性がある場合に、前記一定間隔で発行されるリードコマンドの受信を許可するステップとを有する
ことを特徴とする媒体記憶装置のリード／ライト処理方法。
【請求項１２】
前記ライト失敗の可能性がある場合に、前記バッファメモリに、前記ライトコマンドで指定されたライトデータを格納できる空き容量があるかを判定するステップと、
前記空き容量がある場合に、前記ホストにライトデータを要求し、前記バッファメモリに格納した後、前記一定間隔で発行されるリードコマンドの受信を許可するステップとを更に有する
ことを特徴とする請求項１１の媒体記憶装置のリード／ライト処理方法。
【請求項１３】
前記判定により、前記空き容量がない場合に、前記ホストへのライトデータの要求を禁止し、前記一定間隔で発行されるリードコマンドの受信を許可するステップを更に有する
ことを特徴とする請求項１２の媒体記憶装置のリード／ライト処理方法。
【請求項１４】
前記許可ステップは、前記バッファメモリに前記ライトデータを格納後、ライト処理を実行するとともに、前記一定間隔でのリードコマンドの到来を待つステップからなる
ことを特徴とする請求項１２の媒体記憶装置のリード／ライト処理方法。
【請求項１５】
前記認識ステップは、前記リードコマンドで要求されたデータサイズにより、前記再生処理であることを認識するステップからなる
ことを特徴とする請求項１１の媒体記憶装置のリード／ライト処理方法。
【請求項１６】
前記認識ステップは、前記リードコマンドの発行パターンを解析して、前記再生処理であることを認識するステップからなる
ことを特徴とする請求項１１の媒体記憶装置のリード／ライト処理方法。
【請求項１７】
前記判定ステップは、前記ライト失敗可能性を、前記ライト失敗の過去の履歴から、判定するステップからなる
ことを特徴とする請求項１１の媒体記憶装置のリード／ライト処理方法。
【請求項１８】
前記判定ステップは、前記ライト失敗可能性を、前記ライト処理のリトライ及び前記装置が受ける振動発生の履歴の少なくとも一方により、判定するステップからなる
ことを特徴とする請求項１７の媒体記憶装置のリード／ライト処理方法。
【請求項１９】
前記判定ステップは、前記ライト失敗可能性を、前記装置の環境温度により、判定するステップからなる
ことを特徴とする請求項１１の媒体記憶装置のリード／ライト処理方法。
【請求項２０】
前記判定ステップは、前記ライト失敗可能性を、前記装置が振動を受けたか否かにより、判定するステップからなる
ことを特徴とする請求項１１の媒体記憶装置のリード／ライト処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ヘッドにより媒体のデータをリード及びライトする媒体記憶装置及び媒体記憶装置のリード／ライト処理方法に関し、特に、外部ユニットから定期的に音楽又は映像データのリード要求を発行される媒体記憶装置及び媒体記憶装置のリード／ライト処理方法に関する。
【背景技術】
【０００２】
磁気ディスク装置や光ディスク装置等の媒体記憶装置は、ヘッドにより、媒体にデータをライトして、データを記憶し、リードして、記憶データを再生する。近年、媒体記憶装置が、音楽や映像データの記憶に利用されている。このような媒体記憶装置は、パーソナルコンピュータ等のホストに接続され、ホストの記憶装置としても使用される。図９に示すように、パーソナルコンピュータやモバイルコンピュータ等のホスト１００に、内蔵又は外付けで、媒体記憶装置１１０が接続される。【０００３】
このようなホスト１００では、音楽再生をクリックすると、ホスト１００は、媒体記憶装置１１０の音楽データをリードする。この場合、図１０に示すように、ホスト１００は、一定間隔で、媒体記憶装置１１０にリード要求を発し、リード要求毎に、媒体記憶装置１１０から音楽データとステータスＳＴＳとを受け、音楽再生する。【０００４】
即ち、音楽や映像は、時間とともに変化するため、ホスト１００は、一度に、所望の音楽データ全部をリードすると、その分、メモリ容量が必要となるため、音楽データの一部を、順次要求する。【０００５】
又、ホスト１００は、媒体記憶装置１１０をホストの処理のための記憶装置としても利用する。例えば、ホスト１００が、あるアプリケーションを立ち上げ、処理しながら、音楽再生を行うケースがある。この場合に、ホスト１００が、アプリケーションの処理におけるデータコピー等の指示により、媒体記憶装置１１０に、ライト要求を発行する場合がある。【０００６】
一方、媒体記憶装置のライト処理においては、受信したライトデータを一旦、キャッシュメモリ（又はバッファメモリ）に格納し、その後、媒体にヘッドでライトする。そして、ライト失敗時には、キャッシュメモリのライトデータを読み出し、再度、ヘッドで媒体にライトする（これをライトリトライという）。このライト失敗の原因としては、外部から装置が振動を受けた場合や、温度等の環境変化が生じた場合が挙げられる。【０００７】
このような振動等を受けた場合、その振動を受けない状態に変化するまでは、何度もライトリトライを実行しても、ライト動作が成功しないおそれがある。このため、従来は、振動等のライト失敗の可能性のある環境状態では、ライトリトライを実行せずに、キャッシュメモリのライトデータを、他の半導体メモリにセーブし、振動等のライト失敗の可能性がなくなると、セーブしたライトデータを、媒体にヘッドで、ライトすることが、提案されている（例えば、特許文献１，２）。
【特許文献１】特開２００６−２６９００６号公報
【特許文献２】特開２００４−１７３２４４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ところが、このライトリトライは、ホストの要求を待たせることになる。図１１に示すように、ホスト１００が、リード要求Ｒ１を媒体記憶装置１１０に発行すると、媒体記憶装置１１０は、媒体から要求されたセクタ数分の音楽データを読み出し、キャッシュメモリに格納した後、ホスト１００に転送する。次に、ホスト１００が、ライト要求Ｗ１，Ｗ２を媒体記憶装置１１０に発行すると、媒体記憶装置１１０は、ホスト１００からのライトデータを、キャッシュメモリに格納した後、ヘッドにより媒体に対して、ライトデータを書き込むことになる。【０００９】
この時、振動等により、ライトが失敗すると、ライトリトライが実行される。一方、音楽や映像再生アプリケーションが起動している場合には、このライト処理と関係なく、図１０で説明したように、一定間隔で、音楽データ等のリード要求を発行する。【００１０】
しかしながら、振動が頻繁に発生する状態で、ライトコマンドが発行されると、バッファがフルの状態となったり、ステータスをホストに報告できないため、ホスト１００からの一定間隔のリードコマンドの受け付けが不可能となる。【００１１】
このため、図１１に示すように、ホスト１００は、ライト処理が完了するまで、リードコマンドを発行できないため、音楽再生では、音飛びという現象が、映像再生では、動画像が途切れるという現象が生じることになる。【００１２】
従って、本発明の目的は、ライトリトライが生じても、一定時間間隔で発行されるリードコマンドに対する応答の遅延を防止するための媒体記憶装置のリード／ライト処理方法及び媒体記憶装置を提供することにある。【００１３】
又、本発明の他の目的は、一定時間間隔で発行されるリード処理のモードを認識し、ライトリトライが生じても、リードコマンドに対する応答遅延を防止するための媒体記憶装置のリード／ライト処理方法及び媒体記憶装置を提供することにある。【００１４】
更に、本発明の他の目的は、ライトコマンドを受け付けても、リードコマンドによる音楽や映像再生の途切れを防止するための媒体記憶装置のリード／ライト処理方法及び媒体記憶装置を提供することにある。
【課題を解決するための手段】
【００１５】
この目的の達成のため、本発明の媒体記憶装置は、記録媒体からデータを読み出し、且つデータを記録するリード／ライト機構と、前記読み出したリードデータと、ホストからのライトデータを一時格納するバッファメモリと、ホストからのリード要求に応じて、前記バッファメモリ又は前記記憶媒体からリードデータを読み出し、前記ホストに送信し、且つ前記ホストからのライト要求に応じて、前記ホストからライトデータを前記バッファメモリに格納後、前記記憶媒体にライトし、前記ライト失敗時に、ライトリトライを行う制御回路とを有する。そして、前記制御回路は、受領した前記リードコマンドにより、前記ホストが、連続データの再生処理のため、一定間隔で発行されるリードコマンドであることを認識し、前記再生処理中に受信したライトコマンドに対し、ライト処理で、前記ライト失敗の可能性があるかを判定し、前記ライト失敗の可能性がある場合に、前記一定間隔で発行されるリードコマンドの受信を許可する。【００１６】
又、本発明のリード／ライト処理方法は、ホストからのリード要求に応じて、バッファメモリ又は媒体リード／ライト機構により記憶媒体からリードデータを読み出し、前記ホストに送信するリード処理ステップと、前記ホストからのライト要求に応じて、前記ホストからライトデータを前記バッファメモリに格納後、前記媒体リード／ライト機構により、前記記憶媒体にライトし、前記ライト失敗時に、ライトリトライを行うライト処理ステップと、前記受領した前記リードコマンドにより、前記ホストが、連続データの再生処理のため、一定間隔で発行されるリードコマンドであることを認識するステップと、前記再生処理中に受信したライトコマンドに対し、前記ライト処理で、前記ライト失敗の可能性があるかを判定するステップと、前記ライト失敗の可能性がある場合に、前記一定間隔で発行されるリードコマンドの受信を許可するステップとを有する。【００１７】
更に、本発明では、好ましくは、前記制御回路は、前記ライト失敗の可能性がある場合に、前記バッファメモリに、前記ライトコマンドで指定されたライトデータを格納できる空き容量があるかを判定し、前記空き容量がある場合に、前記ホストにライトデータを要求し、前記バッファメモリに格納した後、前記一定間隔で発行されるリードコマンドの受信を許可する。【００１８】
更に、本発明では、好ましくは、前記制御回路は、前記ライト失敗の可能性がある場合に、前記バッファメモリに、前記ライトコマンドで指定されたライトデータを格納できる空き容量があるかを判定し、前記空き容量がない場合に、前記ホストへのライトデータの要求を禁止し、前記一定間隔で発行されるリードコマンドの受信を許可する。【００１９】
更に、本発明では、好ましくは、前記制御回路は、前記バッファメモリに前記ライトデータを格納後、ライト処理を実行するとともに、前記一定間隔でのリードコマンドの到来を待つ。【００２０】
更に、本発明では、好ましくは、前記制御回路は、前記リードコマンドで要求されたデータサイズにより、前記再生処理であることを認識する。【００２１】
更に、本発明では、好ましくは、前記制御回路は、前記リードコマンドの発行パターンを解析して、前記再生処理であることを認識する。【００２２】
更に、本発明では、好ましくは、前記制御回路は、前記ライト失敗可能性を、前記ライト失敗の過去の履歴から、判定する。【００２３】
更に、本発明では、好ましくは、前記制御回路は、前記ライト失敗可能性を、前記ライト処理のリトライ及び前記装置が受ける振動発生の履歴の少なくとも一方により、判定する。【００２４】
更に、本発明では、好ましくは、前記制御回路は、前記ライト失敗可能性を、前記装置の環境温度により、判定する。【００２５】
更に、本発明では、好ましくは、前記制御回路は、前記ライト失敗可能性を、前記装置が振動を受けたか否かにより、判定する。
【発明の効果】
【００２６】
受領した前記リードコマンドにより、ホストが、連続データの再生処理のため、一定間隔で発行されるリードコマンドであることを認識し、再生処理中に受信したライトコマンドに対し、ライト処理で、前記ライト失敗の可能性があるかを判定し、ライト失敗の可能性がある場合に、一定間隔で発行されるリードコマンドの受信を許可するため、音楽や映像の再生処理中に、リードコマンドの間に送信されるライトコマンドの処理遅延により、リードコマンドの受け付け及び処理が遅延することを防止でき、音楽や映像再生の途切れを防止できる。
【図面の簡単な説明】
【００２７】
【図１】本発明の一実施形態を示す媒体記憶装置の構成図である。
【図２】図１の音楽再生認識処理の第１の実施の形態の処理フロー図である。
【図３】図１の音楽再生認識処理の第２の実施の形態の処理フロー図である。
【図４】図１の音楽再生認識処理の第３の実施の形態の処理フロー図である。
【図５】図１のリード／ライト処理の第１の実施の形態の処理フロー図である。
【図６】図５のリード／ライト処理の説明図である。
【図７】図１のリード／ライト処理の第２の実施の形態の処理フロー図である。
【図８】図７のリード／ライト処理の説明図である。
【図９】従来のシステムの構成図である。
【図１０】図９の構成の音楽再生時のリードコマンドの発行タイミングの説明図である。
【図１１】図９のシステムでの音楽再生中に、ライト処理を実行した場合の問題点の説明図である。
【符号の説明】
【００２８】
１０  記憶媒体（ディスク）
１２  ヘッド
１４  アクチュエータ
１８  スピンドルモータ
１９  スピンドルモータの回転軸
２０  リードチャネル
２２  プリアンプ
２６  サーボ・コンボ回路
２８  ＭＣＵ
３０  ＤＳＰ
３２  ドライブインタフェース回路
３４  フラッシュＲＯＭ
３６  ハードディスクコントローラ
３８  データバッファ
５２〜５３  ＭＣＵのＲＡＭ
４０，４２，４４，４６，４８  バス
【発明を実施するための最良の形態】
【００２９】
以下、本発明の実施の形態を、媒体記憶装置、音楽再生認識処理、リード／ライト処理の第１の実施の形態、リード／ライト処理の第２の実施の形態、他の実施の形態の順で説明するが、本発明は、この実施の形態に限られない。【００３０】
（媒体記憶装置）
図１は、本発明の一実施の形態の媒体記憶装置の構成図であり、媒体記憶装置として、磁気ディスク装置を示す。図１に示すように、磁気記憶媒体である磁気ディスク１０が、スピンドルモータ１８の回転軸１９に設けられている。スピンドルモータ１８は、磁気ディスク１０を回転する。アクチュエータ（ＶＣＭ）１４は、先端に磁気ヘッド１２を備え、磁気ヘッド１２を磁気ディスク１０の半径方向に移動させる。【００３１】
アクチュエータ１４は、回転軸を中心に回転するボイスコイルモータ（ＶＣＭ）で構成される。図では、磁気ディスク装置に、２枚の磁気ディスク１０が搭載され、４つの磁気ヘッド１２が、同一のアクチュエータ１４により同時に駆動される。【００３２】
磁気ヘッド１２は、リード素子と、ライト素子とからなる。磁気ヘッド１２は、スライダに、磁気抵抗（ＭＲ）素子を含むリード素子を積層し、その上にライトコイルを含むライト素子を積層して、構成される。【００３３】
プリアンプ２２は、磁気ヘッド１２に書込み信号を送出し、磁気ヘッド１２の読み取り信号を増幅する。サーボ・コンボ回路２６は、スピンドルモータ１８を駆動し、且つボイスコイルモータ（ＶＣＭ）１４に駆動電流を供給し、ＶＣＭ１４を駆動する。【００３４】
リードチャネル回路２０は、プリアンプ２２からの読み取り信号の内、サーボ信号から、磁気ヘッド１２の位置を復調する。コントローラは、マイクロコントローラ（ＭＣＵ）２８と、ＤＳＰ（デジタルシグナルプロセッサ）３０と、ドライブインタフェース回路３２とからなる。【００３５】
ＤＳＰ３０は、リードチャネル回路２０からの復調位置から現在位置を検出し、検出した現在位置と目標位置との誤差に従い、ＶＣＭ駆動指令値を演算する。即ち、シーク、トラックフォローイングを含むサーボ制御を行う。【００３６】
ＭＣＵ２８は、ＭＰＵと、ＲＯＭと，ＲＡＭとからなる。リードオンリーメモリ（ＲＯＭ）は、ＭＰＵの制御プログラム等を格納する。ランダムアクセスメモリ（ＲＡＭ）は、ＭＰＵの処理のためのデータ等を格納する。このＭＣＵ２８が、後述する音楽再生認識処理及びリード／ライト処理、リトライ処理等を行う。【００３７】
ドライブインタフェース回路３２は、ドライブ側回路（リードチャネル２０、プリアンプ２２、サーボ・コンボ回路２６）と、ＭＣＵ２８，ＤＳＰ３０とのブリッジを形成し、ＭＣＵ２８と、第１の内部バス４４で接続され、ＤＳＰ３０と、第２の内部バス４６で接続される。【００３８】
フラッシュＲＯＭ（Read Only Memory）３４は、マイクロコード等のブートプログラムを格納する。ハードディスクコントローラ（ＨＤＣ）３６は、サーボ信号のセクタ番号を基準にして，１周内の位置を判断し，リードチャネル２０に、データの記録・再生を指示する。【００３９】
バッファ用ランダムアクセスメモリ（ＲＡＭ）３８は、ＨＤＣ３６にメモリバス４８で接続され、リードデータやライトデータを一時格納する。ＨＤＣ３６は、ＳＡＴＡ（Ｓｅｒｉａｌ  AT Attached）やＳＣＳＩ(Small Computer System Interface) 等のインターフェイスＩＦで、ホスト１００（図９参照）と通信する。バス４０は、ＭＣＵ２８，フラッシュＲＯＭ３４、ＨＤＣ３６を接続する。又、ＨＤＣ３６は、リード及びライトデータのやりとりのため、データバス４２で、リードチャネル２０に接続される。【００４０】
図１の構成では、ＨＤＣ３６が、ホスト１００やドライブとのデータのやりとりを行い、ＤＳＰ３０が、磁気ヘッド１２のシーク、トラックフォローイング制御を行い、ＭＣＵ２８が、ＨＤＣ３６が受領したコマンドに従い、各部を制御する処理を行う。【００４１】
このＭＣＵ２８に、振動を検出するショックセンサ５０が接続され、ＭＣＵ２８が、ショックセンサ５０の出力から、装置に振動が印加されたことを検出する。又、ＭＣＵ２８は、音楽再生モードを検出した時に、セットされる音楽再生フラグ５２と、振動やリトライを受けた履歴を格納するリトライ履歴格納域５３を有する。【００４２】
通常のリード動作では、ホスト１００からＨＤＣ３６が、コマンドを受けると、ＨＤＣ３６又はＭＣＵ２８が、コマンドを解析する。解析により、リードコマンドと判定されると、ＨＤＣ３６は、データバッファ３８にリードコマンドの対象データがキャッシュされているかを判定し、キャッシュされていれば、データバッファ３８の対象データを、ホスト１１０へ転送する。【００４３】
一方、対象データが、データバッファ３８にキャッシュされていない場合には、ＨＤＣ３６は、ＭＣＵ２８に、媒体リードを要求する。これに応じて、ＭＣＵ２８は、ＤＳＰ３０にリード対象データのセクタへのヘッドのシークを要求する。ＤＳＰ３０は、サーボ・コンボ回路２６を介し、ＶＣＭ１４をサーボ制御し、磁気ヘッド１２を、磁気ディスク１０の目標トラックに位置付ける。【００４４】
そして、位置付け完了により、ＲＤＣ２０は、磁気ヘッド１２（リード素子）からのリード出力を復調し、リードデータを、ＨＤＣ３６へ転送する。ＨＤＣ３６は、転送されたリードデータを、バッファメモリ３８に格納する。リードキャッシュ機能を持つ場合には、バッファメモリ３８に格納されるリードデータは、リードコマンドで要求されたセクタのデータのみならず、その後のセクタのデータを含む。ＨＤＣ３６は、バッファメモリ３８に格納されたリードデータから対象データを取り出し、ホスト１００へ転送する。【００４５】
又、コマンドが、ライトコマンドと解析されると、ＨＤＣ３６は、ホスト１００からコマンドに続くライトデータを受信し、データバッファ３８に格納する。そして、ＭＣＵ２８の指示により、ディスク１０へのライト処理が実行される。即ち、ＭＣＵ２８は、ＤＳＰ３０にライト対象のセクタへのヘッドのシークを要求する。ＤＳＰ３０は、サーボ・コンボ回路２６を介し、ＶＣＭ１４をサーボ制御し、磁気ヘッド１２を、磁気ディスク１０の目標トラックに位置付ける。【００４６】
そして、位置付け完了により、ＨＤＣ３６は、データバッファ３８のライトデータを、ＲＤＣ２０に転送する。ＲＤＣ２０は、リードデータに、ＥＣＣ符号等を付し、プリアンプ２２を介し、磁気ヘッド１２（ライト素子）にライトデータに従うライト電流を与える。これにより、磁気ディスク１０の対象セクタにライトデータが書き込まれる。【００４７】
このライト処理中に、ＭＣＵ２８は、ショックセンサ５０からの振動検出信号をモニターし、ＤＳＰ３０は、磁気ヘッド１２の位置誤差を監視する。そして、ＭＣＵ２８が、所定値以上の振動を検出した場合、ＤＳＰ３０が、所定値以上の位置誤差を検出した場合に、ライト失敗と判定し、ライト動作を停止する。【００４８】
ライト動作の停止後、ＭＣＵ２８は、ライトリトライ処理を行う。このライトリトライ処理は、前述のライト処理を再度行うものである。このライトリトライを所定回数実行しても、ライト処理が成功しなかった場合には、ホスト１００へエラーを通知する。【００４９】
この実施例では、ＭＣＵ２８が、後述するように、ホスト１００からのリード要求が、音楽再生のリード要求であるかを認識し、音楽再生フラグ５２をセットする。又、ＭＣＵ２８は、過去の振動検出やリトライの履歴を、履歴領域５３に記憶しておき、ライトに時間がかかるか否かを判定する。そして、音楽再生モードで、ライトに時間がかかると判定すると、後述する音楽再生モードのリード／ライト処理を実行する。【００５０】
（音楽再生認識処理）
次に、媒体記憶装置で、音楽再生モードの認識を行う処理を説明する。この処理は、ホスト１００側の音楽再生アプリケーションに特別の処理を必要とせずに、媒体記憶装置側で認識できる。図２は、本発明の音楽再生認識処理の第１の実施の形態の処理フロー図である。【００５１】
（Ｓ１０）ＭＣＵ２８は、リードコマンドを受領したと判断すると、コマンドブロックのタスクファイルを解析する。タスクファイルには、前述のコマンド、開始ＬＢＡ（論理ブロックアドレス）、要求セクタ数等が記載されている。【００５２】
（Ｓ１２）ＭＣＵ２８は、タスクファイルの要求セクタ数が、音楽再生データ用のセクタ数かを判定する。通常、音楽再生では、一定時間毎に、一定セクタ数のデータを要求する。ＭＣＵ２８は、タスクファイルの要求セクタ数が、音楽再生データ用のセクタ数でないと判定すると、音楽再生中フラグ５２をセットすることなく、通常のリード処理に移行する。【００５３】
（Ｓ１４）一方、ＭＣＵ２８は、タスクファイルの要求セクタ数が、音楽再生データ用のセクタ数であると判定すると、音楽再生モードであるため、音楽再生中フラグ５２をセットして、通常のリード処理に移行する。【００５４】
このように、ホスト１００が音楽再生する場合に、要求セクタ数が、通常のセクタ数より異なり、一定であることから、媒体記憶装置側で、この要求セクタ数からホスト１００が、音楽再生モードであることを認識できる。【００５５】
図３は、本発明の音楽再生認識処理の第２の実施の形態の処理フロー図である。【００５６】
（Ｓ２０）ＭＣＵ２８は、リードコマンドを受領したと判断すると、コマンドブロックのタスクファイルを解析する。タスクファイルには、前述のコマンド、開始ＬＢＡ（論理ブロックアドレス）、要求セクタ数等が記載されている。【００５７】
（Ｓ２２）ＭＣＵ２８は、シーケンシャルアクセスであるかを判定する。即ち、ＭＣＵ２８は、リードコマンドが一定時間内で継続しているか否か、及びリードコマンドが一定時間間隔で発行されているか否かを、先に受けたリードコマンドと今回受けたリードコマンドの時間関係から判定する。前述のように、通常、音楽再生では、一定時間毎に、一定セクタ数のデータを要求する。ＭＣＵ２８は、シーケンシャルアクセスでないと判定すると、音楽再生中フラグ５２をセットすることなく、通常のリード処理に移行する。【００５８】
（Ｓ２４）一方、ＭＣＵ２８は、シーケンシャルアクセスであると判定すると、音楽再生モードであるため、音楽再生中フラグ５２をセットして、通常のリード処理に移行する。【００５９】
このように、ホスト１００が音楽再生する場合に、一定時間間隔で、リードコマンドを発行することから、媒体記憶装置側で、このリードコマンドの時間間隔（コマンド発行パターン）からホスト１００が、音楽再生モードであることを認識できる。【００６０】
図４は、本発明の音楽再生認識処理の第３の実施の形態の処理フロー図である。【００６１】
（Ｓ３０）ＭＣＵ２８は、リードコマンドを受領したと判断すると、データパターンを解析する。即ち、読み出し対象データのヘッダが、音楽データ特有のパターンかを解析する。【００６２】
（Ｓ３２）ＭＣＵ２８は、要求データパターンが音楽データ特有のパターンであるかを判定する。即ち、音楽データは、先頭に、フレーム番号や時間等の特有のパターンを有している。ＭＣＵ２８は、要求データパターンが、音楽特有のパターンでないと判定すると、音楽再生中フラグ５２をセットすることなく、通常のリード処理に移行する。【００６３】
（Ｓ３４）一方、ＭＣＵ２８は、要求データパターンが、音楽特有のパターンであると判定すると、音楽再生モードであるため、音楽再生中フラグ５２をセットして、通常のリード処理に移行する。【００６４】
このように、ホスト１００が音楽再生する場合に、音楽データが、先頭に特有のパターン（フレーム番号、時間等）を有することから、媒体記憶装置側で、この音楽データのパターンからホスト１００が、音楽再生モードであることを認識できる。【００６５】
（リード／ライト処理の第１の実施の形態）
図５は、本発明のリード／ライト処理の第１の実施の形態の処理フロー図、図６は、図５の処理のタイムチャート図である。【００６６】
（Ｓ４０）ＭＣＵ２８は、ライトコマンドをホスト１００から受領すると、ライトデータ受領処理を開始する。ＭＣＵ２８は、音楽再生中フラグ５２がセットされているか否かを判定する。【００６７】
（Ｓ４２）ＭＣＵ２８は、音楽再生中フラグ５２がセットされていない場合には、ホスト１００が音楽再生中でないため、ホスト１００にライトデータを、要求し、ホスト１００からのライトデータを、受信し、バッファメモリ（キャッシュメモリ）３８に保存する。これにより、ライトデータ受領処理を終了する。【００６８】
（Ｓ４４）ＭＣＵ２８は、音楽再生中フラグ５２がセットされている場合には、ホスト１００が音楽再生中であるため、履歴領域５３を参照して、以前のライト処理で、時間がかかったかを判定する。即ち、履歴領域５３には、前述のように、以前の振動やリトライの発生の履歴を格納しているため、履歴領域５３の参照により、以前のライト処理に時間がかかったか否かを判定できる。ＭＣＵ２８は、履歴領域５３の参照により、以前のライト処理に時間がかからなかったと判定すると、図示しない温度センサから温度を検出する。ＭＣＵ２８は、検出温度と、低温検出のための基準閾値と比較して、低温であるかを判定する。低温であると、記憶媒体１０の保持力が、温度依存性を持つため、増大し、ライト処理に失敗し、リトライが発生する可能性が高いため、このチエックを行う。ＭＣＵ２８は、低温でない場合には、ステップＳ４２に進む。【００６９】
（Ｓ４６）逆に、ステップＳ４４で、以前のライト処理に時間がかかった、又は低温であると判定された場合には、ライト処理に失敗して、リトライする可能性がある。このため、ＭＣＵ２８は、バッファメモリ３８に、ライトコマンドで要求されたデータ分の空きがあるかを判定する。ＭＣＵ２８は、ライトコマンドで要求されたデータ分の空きがあると判定すると、ホスト１００にライトデータを、要求し、ホスト１００からのライトデータを、受信し、バッファメモリ（キャッシュメモリ）３８に保存する。これにより、ライトデータ受領処理を終了する。【００７０】
逆に、ＭＣＵ２８は、ライトコマンドで要求されたデータ分の空きがないと判定すると、ホスト１００にライトデータを、要求せずに、ステータスを通知する。そして、ライトデータ受領処理を終了する。【００７１】
図６で、具体的に説明すると、音楽再生中に、ＭＣＵ２８は、ホスト１００からライトコマンドＷ１を受け、バッファメモリ３８に空きがあるため、ホスト１００にライトデータを要求し、ホスト１００は、ライトデータＷ１Ｄａｔａを送信する。このライトデータは、バッファメモリ３８に格納された後、媒体１０に、ヘッド１２で、書込みを行う。【００７２】
続いて、ＭＣＵ２８は、ホスト１００からライトコマンドＷ２を受ける。この場合に、前のライトデータＷ１Ｄａｔａの書込みが失敗し、リトライする場合には、バッファメモリ３８に空きがない。従って、ＭＣＵ２８は、ホスト１００にライトデータを要求しない。これにより、ホスト１００は、音楽再生のリードコマンドＲ２を発行でき、キャッシュメモリ３８から、リードデータＲ２をホスト１００に送信できる。【００７３】
このように、音楽再生中に、ライトコマンドを受領すると、先ず、ライト失敗する可能性があるかを調べ、ライト失敗する可能性がある場合には、バッファメモリ３８に格納できる分のデータを要求し、ライト処理を行い、それ以上のライトデータは、要求しない。【００７４】
このため、一定間隔で発行されるリードコマンドを受付、リードデータをホストへ送信できる。この場合、リードデータは、キャッシュメモリから得ても良く、又、ライトデータをこれ以上受信しないため、ライトリトライは、遅らせても良いから、媒体１０をヘッド１２でリードして、リードデータを得ても良い。【００７５】
このため、音楽再生中に、ライトコマンドを受領しても、リードコマンドの応答時間の遅延を防止でき、ホストの再生処理の遅延を防止できる。このコマンドとしては、ＳＡＴＡ（Serial AT Attached）のＮＣＱ（Native Command Queing）コマンドを利用すると良い。【００７６】
（リード／ライト処理の第２の実施の形態）
図７は、本発明のリード／ライト処理の第１の実施の形態の処理フロー図、図８は、図７の処理のタイムチャート図である。【００７７】
（Ｓ５０）ＭＣＵ２８は、ライトコマンドをホスト１００から受領すると、ライトデータ受領処理を開始する。ＭＣＵ２８は、音楽再生中フラグ５２がセットされているか否かを判定する。【００７８】
（Ｓ５２）ＭＣＵ２８は、音楽再生中フラグ５２がセットされていない場合には、ホスト１００が音楽再生中でないため、ホスト１００にライトデータを、要求し、ホスト１００からのライトデータを、受信し、バッファメモリ（キャッシュメモリ）３８に保存する。そして、ステップＳ６０に進む。【００７９】
（Ｓ５４）ＭＣＵ２８は、音楽再生中フラグ５２がセットされている場合には、ホスト１００が音楽再生中であるため、履歴領域５３を参照して、以前のライト処理で、時間がかかったかを判定する。即ち、履歴領域５３には、前述のように、以前の振動やリトライの発生の履歴を格納しているため、履歴領域５３の参照により、以前のライト処理に時間がかかったか否かを判定できる。ＭＣＵ２８は、履歴領域５３の参照により、以前のライト処理に時間がかからなかったと判定すると、図示しない温度センサから温度を検出する。ＭＣＵ２８は、検出温度と、低温検出のための基準閾値と比較して、低温であるかを判定する。低温であると、記憶媒体１０の保持力が温度依存性を持つため、保持力が増大し、ライト処理に失敗し、リトライが発生する可能性が高いため、このチエックを行う。ＭＣＵ２８は、低温でない場合には、ステップＳ５２に進む。【００８０】
（Ｓ５６）逆に、ステップＳ５４で、以前のライト処理に時間がかかった、又は低温であると判定された場合には、ライト処理に失敗して、リトライする可能性がある。このため、ＭＣＵ２８は、バッファメモリ３８に、ライトコマンドで要求されたデータ分の空きがあるかを判定する。ＭＣＵ２８は、ライトコマンドで要求されたデータ分の空きがあると判定すると、ホスト１００にライトデータを、要求し、ホスト１００からのライトデータを、受信し、バッファメモリ（キャッシュメモリ）３８に保存する。そして、ライトデータ受領処理を終了する。逆に、ＭＣＵ２８は、ライトコマンドで要求されたデータ分の空きがないと判定すると、ホスト１００にライトデータを、要求しない。【００８１】
（Ｓ５８）ＭＣＵ２８は、前回の音楽データからの経過時間が、一定時間を越えたかを判定する。即ち、ライトコマンドのステータス報告（ＳＴＳ）を、音楽再生用リードコマンドの発行タイミングまで待つ。発行タイミングの時間は、音楽再生中フラグをセットする時に、保持しておく。【００８２】
（Ｓ６０）ＭＣＵ２８は、経過時間が一定時間を越えると、ホスト１００に、ステータスを通知する。そして、ライトデータ受領処理を終了する。【００８３】
図８で、具体的に説明すると、音楽再生中に、ＭＣＵ２８は、ホスト１００からライトコマンドＷ１を受け、バッファメモリ３８に空きがあるため、ホスト１００にライトデータを要求し、ホスト１００は、ライトデータＷ１Ｄａｔａを送信する。このライトデータは、バッファメモリ３８に格納された後、媒体１０に、ヘッド１２で、書込みを行う。【００８４】
そして、この媒体へのライト処理に係らず、ＭＣＵ２８は、経過時間が、一定時間を越えると、ホスト１００にステータスを報告する。これにより、ホスト１００は、音楽再生のリードコマンドＲ２を発行でき、キャッシュメモリ３８又は媒体１０から、リードデータＲ２をホスト１００に送信できる。【００８５】
この場合に、ライトデータＷ１Ｄａｔａの書込みが失敗し、リトライしても、ホスト１００は、音楽再生のリードコマンドＲ２を発行でき、キャッシュメモリ３８から、リードデータＲ２をホスト１００に送信できる。【００８６】
このように、音楽再生中に、ライトコマンドを受領すると、先ず、ライト失敗する可能性があるかを調べ、ライト失敗する可能性がある場合には、バッファメモリ３８に格納できる分のデータを要求し、ライト処理を行い、それ以上のライトデータは、要求せずに、リードコマンドの繰り返し時点で、ステータスを報告する。【００８７】
このため、一定間隔で発行されるリードコマンドを受付、リードデータをホストへ送信できる。この場合、リードデータは、キャッシュメモリから得ても良く、又、ライトデータをこれ以上受信しないため、ライトリトライは、遅らせても良いから、媒体１０をヘッド１２でリードして、リードデータを得ても良い。【００８８】
（他の実施の形態）
前述の実施の形態では、媒体記憶装置を、磁気ディスク装置の適用の例で説明したが、光ディスク装置等の他のディスク装置や、回転する記憶媒体を使用する装置にも適用できる。又、コントローラの構成も、図１のもので説明したが、他の構成のものを適用できる。更に、ライト失敗可能性を、過去の履歴で判断したが、現在の振動センサの出力から、判定しても良い。又、音楽再生の例で説明したが、映像等の動画再生等の他の連続性を持ったデータの再生に適用できる。【００８９】
以上、本発明を、実施の形態で説明したが、本発明は、その趣旨の範囲内で種々の変形が可能であり、これを本発明の範囲から排除するものではない。
【産業上の利用可能性】
【００９０】
受領した前記リードコマンドにより、ホストが、連続データの再生処理のため、一定間隔で発行されるリードコマンドであることを認識し、再生処理中に受信したライトコマンドに対し、ライト処理で、前記ライト失敗の可能性があるかを判定し、ライト失敗の可能性がある場合に、一定間隔で発行されるリードコマンドの受信を許可するため、音楽や映像の再生処理中に、リードコマンドの間に送信されるライトコマンドの処理遅延により、リードコマンドの受け付け及び処理が遅延することを防止でき、音楽や映像再生の途切れを防止できる。
【図１】
2009050765.tif 000003
【図２】
2009050765.tif 000004
【図３】
2009050765.tif 000005
【図４】
2009050765.tif 000006
【図５】
2009050765.tif 000007
【図６】
2009050765.tif 000008
【図７】
2009050765.tif 000009
【図８】
2009050765.tif 000010
【図９】
2009050765.tif 000011
【図１０】
2009050765.tif 000012
【図１１】
2009050765.tif 000013
【国際調査報告】
2009050765.tif 000014
2009050765.tif 000015
2009050765.tif 000016
2009050765.tif 000017