(57)【要約】【課題】磁気ディスク装置の性能を低下させることなく、リフレッシュを行うことが可能な記録再生装置を実現する。【解決手段】実施形態によれば、記録再生装置は、受信手段と、リフレッシュ手段とを具備する。受信手段は、磁気ディスクへの書き込みを要求するライトコマンドを受信する。リフレッシュ手段は、前記磁気ディスク上のリフレッシュ対象である第１の領域に前記ライトコマンドに対応する第２の領域が含まれる場合、前記第１の領域から前記第２の領域を除いた第３の領域に記録されているデータをリフレッシュする。【選択図】図４
2014053062.tif 000002
【特許請求の範囲】
【請求項１】
磁気ディスクへの書き込みを要求するライトコマンドを受信するコマンド受信手段と、
前記磁気ディスク上のリフレッシュ対象である第１の領域に前記ライトコマンドに対応する第２の領域が含まれる場合、前記第１の領域から前記第２の領域を除いた第３の領域に記録されているデータをリフレッシュするリフレッシュ手段と
を具備する記録再生装置。
【請求項２】
前記リフレッシュ手段は、前記ライトコマンドに応じた書き込みを前記第２の領域に行った後、前記第３の領域に記録されているデータをリフレッシュする請求項１記載の記録再生装置。
【請求項３】
前記リフレッシュ手段は、前記第１の領域から読み出したデータと前記ライトコマンドのライトデータとを統合し、前記統合したデータを前記第１の領域に書き込む請求項１記載の記録再生装置。
【請求項４】
前記コマンド受信手段は、前記磁気ディスクからの読み出しを要求するリードコマンドを受信し、
前記リフレッシュ手段は、前記第３の領域に前記リードコマンドに対応する領域が含まれる場合、前記第１の領域からデータを読み出し、当該読み出したデータを前記第１の領域に書き込む請求項１記載の記録再生装置。
【請求項５】
前記リフレッシュ手段は、前記第１の領域から前記データを読み出す際のリードリトライ回数に基づき、前記読み出したデータを前記第３の領域に書き込むかどうかを決定する請求項４記載の記録再生装置。
【請求項６】
前記第３の領域が複数の分割された領域を有するかどうかを判定する判定手段をさらに具備し、
前記リフレッシュ手段は、前記ライトコマンドに応じた書き込みを前記第２の領域に行った後前記第３の領域に記録されているデータをリフレッシュするか、または、前記第１の領域から読み出したデータと前記ライトコマンドのライトデータとを統合し、前記統合したデータを前記第１の領域に書き込むかを前記判定手段による判定に基づき選択する請求項１記載の記録再生装置。
【請求項７】
磁気ディスクへの書き込みを要求するライトコマンドを受信し、
前記磁気ディスク上のリフレッシュ対象である第１の領域に前記ライトコマンドに対応する第２の領域が含まれる場合、前記第１の領域から前記第２の領域を除いた第３の領域に記録されているデータをリフレッシュするための制御をする
記録再生方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、データの読み出し及び書き込みができる記録再生装置および記録再生方法に関する。
【背景技術】
【０００２】
近年、データを記録する磁気ディスク装置等の記録再生装置において、データを高密度に記録することが求められている。磁気ディスク上のトラック密度を上げることによって、データを高密度に記録することが可能である。
【０００３】
しかしながら、トラック密度を上げることにより、データが書き込まれたトラックの周辺のトラックに磁気情報として記録されているデータが読み出せなくなるという現象（隣接トラック間干渉（ATI：Adjacent Track Interference））が生じる場合がある。
【０００４】
そこで、ＡＴＩが生じた場合、ＡＴＩによって読み出せなくなったデータを読み出し、読み出したデータを磁気ディスクに再び書き込むことにより、読み出せなくなったデータのリフレッシュを行う。リフレッシュを行うことによって、読み出せなくなったデータを回復させることができる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特許第４７３３４００号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、リフレッシュとは異なる通常のデータの書き込みまたは読み出し（以下、通常リードライトと称す。）を行う際においてリフレッシュを行う必要が生じた場合、通常リードライト中にリフレッシュが割り込んで行われる。また、リフレッシュと通常リードライトとで重複した不要な処理が行われる。そのため、例えば通常リードライトに要する時間が長くなり、磁気ディスク装置の性能が低下する。
【０００７】
本発明は、磁気ディスク装置の性能を低下させることなくリフレッシュを行うことが可能な記録再生装置および記録再生方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
実施形態によれば、記録再生装置は、受信手段と、リフレッシュ手段とを具備する。受信手段は、磁気ディスクへの書き込みを要求するライトコマンドを受信する。リフレッシュ手段は、前記磁気ディスク上のリフレッシュ対象である第１の領域に前記ライトコマンドに対応する第２の領域が含まれる場合、前記第１の領域から前記第２の領域を除いた第３の領域に記録されているデータをリフレッシュする。
【図面の簡単な説明】
【０００９】
【図１】第１の実施形態に係る磁気ディスク装置の構成例を示す図。
【図２】第１の実施形態に係る磁気ディスク装置に備えられたメモリ内の構成例を示す図。
【図３】第１の実施形態に係るＡＴＩ対策処理の概要を説明するための図。
【図４】第１の実施形態に係るＡＴＩ対策処理におけるライトコマンド処理手順の一例を示すフローチャート。
【図５】第１の実施形態に係るＡＴＩ対策処理におけるリフレッシュ処理手順の一例を示すフローチャート。
【図６】第２の実施形態に係るＡＴＩ対策処理の概要を説明するための図。
【図７】第２の実施形態に係るＡＴＩ対策処理におけるライトコマンド処理手順の一例を示すフローチャート。
【図８】第３の実施形態に係るＡＴＩ対策処理の概要を説明するための図。
【図９】第３の実施形態に係るＡＴＩ対策処理におけるリードコマンド処理手順の一例を示すフローチャート。
【図１０】第３の実施形態に係るＡＴＩ対策処理におけるリードベリファイ処理手順の一例を示すフローチャート。
【図１１】第４の実施形態に係るＡＴＩ対策処理手順の一例を示すフローチャート。
【発明を実施するための形態】
【００１０】
（第１の実施形態）
以下、図面を参照して、第１の実施形態を説明する。  
図１は、本実施形態に関する磁気ディスク装置の要部を示すブロック図である。  
図１に示すように、磁気ディスク装置は大別して、ヘッド・ディスクアセンブリ（head-disk assembly：ＨＤＡ）、ヘッドアンプ集積回路（ＩＣ）１１と、ハードディスクコントローラ（ＨＤＣ）１３等から構成されている。
【００１１】
ＨＤＡは、記録媒体である磁気ディスク１と、スピンドルモータ（ＳＰＭ）２と、ヘッド１０を搭載しているアーム３と、ボイスコイルモータ（ＶＣＭ）４とを有する。磁気ディスク１は、スピンドルモータ２により回転する。アーム３とＶＣＭ４は、アクチュエータを構成している。アクチュエータは、ＶＣＭ４の駆動により、アーム３に搭載されているヘッド１０を磁気ディスク１上の指定の位置まで移動制御する。
【００１２】
ヘッド１０はスライダを本体として、当該スライダに実装されているライトヘッド１０Ｗ及びリードヘッド１０Ｒを有する。ライトヘッド１０Ｗは、磁気ディスク１上にデータを書き込む。リードヘッド１０Ｒは、磁気ディスク１上のデータトラックに記録されているデータを読み出す。
【００１３】
ヘッドアンプＩＣ１１は、プリアンプ及びライトドライバを有する。プリアンプは、リードヘッド１０Ｒにより読み出されたリード信号を増幅して、リードデータとしてリード／ライト（Ｒ／Ｗ）チャネル１２に伝送する。一方、ライトドライバは、Ｒ／Ｗチャネル１２から出力されるライトデータに応じたライト電流をライトヘッド１０Ｗに伝送する。
【００１４】
Ｒ／Ｗチャネル１２は、リードデータの信号処理を実行するリードチャネルと、ライトデータの信号処理を実行するライトチャネルとを含む。  
ＨＤＣ１３は、ディスク制御部１３ｂ、Ｉ／Ｆ制御部１３ｃ、コマンド制御部１３ｄ、及びバッファ制御部１３ｅを含む。  
ディスク制御部１３ｂは、Ｒ／Ｗチャネル１２と接続されており、磁気ディスク１の制御を行う。  
Ｉ／Ｆ制御部１３ｃは、ホストシステム２０とＲ／Ｗチャネル１２との間のデータ転送の制御を行う。
【００１５】
コマンド制御部１３ｄは、ホストシステム２０から受信するライトコマンドまたはリードコマンドに関する制御を行う。
【００１６】
バッファ制御部１３ｅは、バッファ１７と接続されており、バッファ１７と送受信するデータに関する制御を行う。バッファ制御部１３ｅは、例えば、磁気ディスク１から読み出したデータ、ライトコマンドに応じて磁気ディスク１に書き込むデータ等をバッファ１７に一時的に格納する。
【００１７】
ＭＰＵ１４は磁気ディスク装置のメインコントローラであり、ＶＣＭ４を制御してヘッド１０の位置決めを行うサーボ制御等を実行する。
【００１８】
なお、Ｒ／Ｗチャネル１２、ＨＤＣ１３、及びＭＰＵ１４は１チップの集積回路から構成されていてもよい。  
ＤＲＡＭ１６は、磁気ディスク１から読み出された、磁気ディスク１を制御するためのプログラム、ＡＴＩ対策処理用のプログラム、及びＡＴＩ対策処理用の情報等を格納している。なお、ＤＲＡＭ１６は、磁気ディスク１を制御するためのプログラム、ＡＴＩ対策処理用のプログラム、及びＡＴＩ対策処理用の情報等を格納するためのメモリであればよく、例えばＳＲＡＭ等のＲＡＭでもよい。また、磁気ディスク１を制御するためのプログラム、ＡＴＩ対策処理用のプログラム、及びＡＴＩ対策処理用の情報等は、ファームウェアまたはファームウェアに関するデータとして、ＤＲＡＭ１６及び／またはＳＲＡＭに格納されていてもよい。ＡＴＩ対策処理とは、ＡＴＩの影響により読み出すことが困難なデータに対して、読み出すことができなくなる前にリフレッシュ及びリードベリファイ等の処理を行うことによって、読み出すことが困難なデータを回復させ、読み出すことができないデータが生じることを防ぐための処理である。例えば、トラック毎に書き込み回数を記録する場合において、全てのトラックに対する「書き込み回数記録」を用意し、あるトラックへ書き込みが行われた場合、その書き込みによる影響を受けるトラックの範囲について、書き込まれたトラックからの距離に応じた「ライトカウント重みテーブル」の値を、既に「書き込み回数記録」に記録されている値に加えるようにする。「ライトカウント重みテーブル」は、書き込みを行ったトラックを基準として、そのトラックの周辺トラックに関する重みの分布等を示している。そして、いずれかのトラックで「書き込み回数記録」の値が一定値を超えた場合、「書き込み回数記録」の値が一定値を超えたトラックの周辺のトラックのデータをリフレッシュする。
【００１９】
リフレッシュは、ＡＴＩによって読み出せなくなったデータの読み出しと読み出したデータの再度の同じ場所への書き込みとからなる。書き込みに関して、例えば、リフレッシュの書き込みを行った後、リフレッシュによって書き込まれたデータを通常リードライトによって書き込まれるデータで上書きするような場合がある。また、読み出しに関して、例えば、リフレッシュの読み出しを行った後、リフレッシュで読み出したデータと同じデータを通常リードライトでさらに読み出すような場合がある。このように、ホストシステム２０等の上位システムから受領したライトコマンド等の書き込み指示が、磁気ディスク１の特定の領域（範囲）に集中した場合等において、書き込みを行う領域に隣接する領域等に対する書き込みの品質が低下すると書き込み回数等に基づき判断した場合、リフレッシュが行われる。
【００２０】
リードベリファイは、ＡＴＩの影響を受けるトラックの領域よりも、例えば外側のトラックの磁気記録が薄れる場合がある。リフレッシュは、書き込み回数記録値が所定の値を超えたトラックに対して、磁気記録が劣化しリフレッシュのリライトが必要な状態となっていないかを検査するための処理である。具体的には、リードベリファイは、書き込んだトラックの周辺のトラックのデータを読み出し、データを読み出すことができたかどうかを示すリードリトライ回数に基づき、読み出すことができないトラック、そのトラックの一部、またはそのトラックの周辺のトラックに対してリフレッシュのリライトを行うための処理である。
【００２１】
また、ＡＴＩ対策処理は、ファームウェア等で行われる処理であってもよい。  
バッファメモリ１７は、バッファメモリ１７ｂ及びバッファメモリ１７ｃから構成される。バッファメモリ１７は、バッファ制御部１３ｅと接続されている。バッファメモリ１７は、バッファ制御部１３ｅから送られてくるデータを格納し、バッファ制御部１３ｅからの制御指示に応じて、格納しているデータをバッファ制御部１３ｅに送る。なお、バッファメモリ１７は、ＤＲＡＭ１６内に配置されていてもよい。
【００２２】
次に、図２を参照し、ＤＲＡＭ１６の構成例について説明する。  
ＤＲＡＭ１６は、制御プログラム２１及び制御情報（データ）２２を含む。  
制御プログラム２１は、コマンド処理部２１ｂ、ディスクアクセス部２１ｃ、データ送受信部２１ｄ、ＡＴＩ対策処理制御部２１ｅ、及びリオーダリング制御部２１ｆから構成されている。
【００２３】
コマンド処理部２１ｂは、ホストシステム２０から送られてくるコマンドの処理を行う。コマンドは、例えば、磁気ディスク１への書き込みを要求するライトコマンドと磁気ディスク１からデータを読み出すリードコマンドである。
【００２４】
また、コマンド処理部２１ｂは、アドレス判定部２４を備えている。アドレス判定部２４は、受信したコマンドに対応したデータブロックの論理ブロックアドレス（Logical Block Address：ＬＢＡ）を判定する。例えば、アドレス判定部２４は、複数のライトコマンドを受信した場合、複数のライトコマンドで指示された各々のＬＢＡが連続しているかどうか等を判定することができる。
【００２５】
ディスクアクセス部２１ｃは、ＡＴＩ対策処理に応じた磁気ディスク１へのアクセスを制御する。例えば、コマンド制御部１３ｄがライトコマンドを受信した場合、ディスクアクセス部２１ｃは、コマンド処理部２１ｂの指示にしたがいこのライトコマンドに対応するデータ（ライトデータ）を磁気ディスク１に書き込むために、磁気ディスク１にアクセスする。
【００２６】
データ送受信部２１ｄは、ホストシステム２０から送られてくるデータ（ライトデータ）を受信する。データ送受信部２１ｄは、磁気ディスク１から読み出されるデータ（リードデータ）をホストシステム２０に送信する。なお、ライトデータは、ライトコマンドに応じて磁気ディスク１に書き込まれるデータであり、リードデータは、リードコマンドに応じて磁気ディスク１から読み出されるデータである。
【００２７】
ＡＴＩ対策処理制御部２１ｅは、書き込み回数等と所定の閾値と比較し、リフレッシュを行う必要があるトラックがあれば、ライトコマンド群の実行範囲（ライトコマンド領域）を避け、リフレッシュ処理を行うために、ＡＴＩ対策処理に関する制御を行う。ＡＴＩ対策処理に関する制御は、ＡＴＩによってリフレッシュが必要な場合磁気ディスク装置の性能が低下しないように、例えば、リフレッシュを行う磁気ディスク上の領域を決定する制御、リフレッシュをどの領域に対して行うかどうかを決定する制御等である。なお、領域とは、例えば、磁気ディスクのトラック、データセクタ、またはデータブロック等である。
【００２８】
また、ＡＴＩ対策処理制御部２１ｅは、カウンタ監視部２５を備える。カウンタ監視部２５は、キューイングを行っているライトコマンドまたはリードコマンドの論理ブロックに対してトラック書き込み回数値を監視する。また、カウンタ監視部２５は、書き込み回数記録値が所定の閾値を越えているかどうかを監視し、書き込み回数記録値が所定の閾値を越えている場合、ＡＴＩ対策処理を行うための処理を行う。また、ＡＴＩ対策処理制御部２１ｅは、コマンド処理部２１ｂによって受信されるライトコマンドまたはリードコマンドに応じた書き込みまたは読み出しを行う前に、受信されるライトコマンドまたはリードコマンドに応じた書き込みまたは読み出しを行った場合リフレッシュを行う必要があるかどうかを、カウンタ監視部２５の監視結果に基づき、判定する。さらに、ＡＴＩ対策処理制御部２１ｅは、リフレッシュを行う必要がある場合、コマンド処理部２１ｂによって受信されるライトコマンドまたはリードコマンドに応じた書き込みまたは読み出しを行う前に、リフレッシュを行う必要がある領域を決定することができる。また、ＡＴＩ対策処理制御部２１ｅは、リフレッシュを行ったトラックの近傍のトラック群に対してリードベリファイを行う機能も有する。なお、リフレッシュを行う領域に関しては、図３を参照して後述する。
【００２９】
リオーダリング制御部２１ｆは、ホストシステム２０から受信した複数のコマンドについて、処理を行う順番を決定するための制御をする。リオーダリング制御部２１ｆは、この順番を、例えば複数のコマンドの内ＬＢＡが近いコマンドを連続して実行することができるように、並び替えられる。ＬＢＡが近いコマンドを順に実行することによって、ヘッド１０が磁気ディスク１上を移動する時間、例えばシーク時間、を短くすることができる。
【００３０】
制御情報（データ）２２は、ＡＴＩ対策処理制御情報２３として、書き込み回数記録値２３ｂ、ライトカウント重みテーブル２３ｃ、及びＡＴＩ対策処理済み情報テーブル２３ｄから構成される。  
書き込み回数記録値２３ｂは、磁気ディスク１への書き込み回数が記録されたテーブル（書き込み回数カウンタ値テーブル）等からなり、書き込み回数カウンタ値テーブルは、例えば全てのトラックに関して、ＡＴＩの影響の大きさを保持している。磁気ディスク１への書き込み回数は、磁気ディスク１のトラック毎に書き込み回数カウンタ値テーブルに記録される。なお、書き込み回数は、トラック毎に限定することなく、例えばトラックの一部分毎でもよいし、磁気ディスク１の複数のセクタからなるブロック毎に記録してもよい。また、書き込み回数記録値２３ｂは、リフレッシュを行うかどうかを判定するために使用される。例えば、あるトラックに関して、書き込み回数が所定の閾値を越えている場合、そのトラックに対してリフレッシュを行う。
【００３１】
ライトカウント重みテーブル２３Ｃは、書き込み回数記録値２３ｂに書き込み回数を記録する場合に使用される。ライトカウント重みテーブル２３Ｃには、書き込みを行うトラックを基準として、書き込みによる周囲への影響の大きさと、書き込まれたトラックからの距離と、の間の関係性を示す重みがテーブル形式で格納されている。ライトカウント重みテーブル２３Ｃには、例えば、トラック毎に書き込み回数を記録する場合、書き込みを行ったトラックを基準として、書き込みを行ったトラックからの距離等に応じた重みが設定されている。重みは、例えば、書き込みを行ったトラックの重みを０とし、書き込みを行ったトラックから離れるにしたがい小さくなるような重みである。このように重みを設定することによって、ＡＴＩによる影響が強いトラックの書き込み回数記録値が大きくなる。そのため、書き込み回数記録値２３ｂに基づきリフレッシュを行う必要があるかどうかを判定することができる。
【００３２】
ＡＴＩ対策処理済み情報テーブル２３ｄは、ＡＴＩ対策処理を行ったことに関する情報を格納する。ＡＴＩ対策処理を行ったことに関する情報とは、ＡＴＩ対策処理を行ったアドレス等である。
【００３３】
また、制御情報２２は、トラック位置情報テーブル２６を備える。トラック位置情報テーブル２６は、全論理ブロックに関するトラックの位置情報を格納している。リオーダリング制御部２１ｆによってリオーダリングを行う場合、例えば書き込みを行っているトラックに近いトラックを判定するために、トラック位置情報テーブル２６を利用することができる。
【００３４】
次に、図３を参照し、第１の実施形態におけるＡＴＩ対策処理について説明する。  
第１の実施形態では、リフレッシュを行う前に、リフレッシュを行う範囲（以下、リフレッシュ領域と称す。）の調整を予め行い、調整したリフレッシュ領域に対してリフレッシュを行う。なお、リフレッシュ領域は、例えば、リフレッシュの対象となるデータブロックのＬＢＡの範囲、磁気ディスク１上の所定の領域等である
具体的には、図３に示すように、磁気ディスク装置がライトコマンドＡ乃至ライトコマンドＤを受信した場合を説明する。ライトコマンドＡ乃至ライトコマンドＤは、リオーダリングされているため、ライトコマンドＡ、ライトコマンドＢ、ライトコマンドＤ、及びライトコマンドＣの順に実行されるようにコマンドキューに格納されている。
【００３５】
図３の右側の図は、各ライトコマンドに対応したＬＢＡの位置関係を示しており、リフレッシュ領域の変化を時系列的に示している。なお、ライトコマンドのデータとは、ライトコマンドを実行する論理ブロックに記録するデータを意味する。
【００３６】
Ｔ１は、ライトコマンドＡ乃至ライトコマンドＤが実行される前の状態を示している。Ｔ２は、ライトコマンドＡを実行した場合の状態を示している。Ｔ３は、ライトコマンドＢ乃至ライトコマンドＤを実行した場合の状態を示している。また、Ｔ１乃至Ｔ３の各々の状態において、図３に示す「Ａ」、「Ｂ」、「Ｃ」、及び「Ｄ」は、ライトコマンドＡ乃至ライトコマンドＤの各々に対応したＬＢＡの位置関係を示している。以下、「Ａ」、「Ｂ」、「Ｃ」、及び「Ｄ」の各々を、コマンドの種類に応じたコマンド領域Ａ、コマンド領域Ｂ、コマンド領域コマンド領域C、及びコマンド領域Ｄと称す。図３では、左側からコマンド領域Ａ、コマンド領域Ｂ、コマンド領域Ｄ、及びコマンド領域Cの順に並んでいる。なお、以下、ライトコマンドに対応したＬＢＡをライトＬＢＡ、リードコマンドに対応したＬＢＡをリードＬＢＡと称す。
【００３７】
また、第１の実施形態では、リフレッシュ領域内にあるコマンド領域Ｂがコマンド領域Ｄと隣接している（連続している）場合を想定しているが、第１の実施形態ではリフレッシュ領域が、例えば図３に示すように、必ずしもコマンド領域Ｂがコマンド領域Ｄと隣接していなくてもよい。
【００３８】
Ｔ２は、ライトコマンドＡが実行された場合の状態を示している。ライトコマンドＡを実行することによって、リフレッシュを行う必要がある、換言するとリフレッシュを行う予定の領域（図３ではｒ１で示されている領域、以下、リフレッシュ予定領域と称す。）を推定することができる。図３では、リフレッシュ予定領域ｒ１にコマンド領域Ｂ、コマンド領域C、及びコマンド領域Ｄで示される３つのライトＬＢＡが含まれている。
【００３９】
第１の実施形態では、リフレッシュ予定領域ｒ１にライトＬＢＡが含まれていた場合、リフレッシュ予定領域ｒ１を調整する。リフレッシュ予定領域ｒ１を調整するとは、リフレッシュ予定領域ｒ１を小さくすることである。これにより、例えば、リフレッシュを行う時間等を短くすることができる。
【００４０】
具体的には、リフレッシュ予定領域ｒ１に対してリフレッシュを実行する前に、ライトコマンドＢ、ライトコマンドＣ、及びライトコマンドＤを実行する。以下、ライトコマンドを実行する領域をライトコマンド領域と称す。データが書き込まれた直後のライトコマンド領域はＡＴＩの影響が消失したので、リフレッシュ不要な領域となる。
【００４１】
仮に、ライトコマンドＢ、ライトコマンドＣ、及びライトコマンドＤを実行する前に、リフレッシュ予定領域ｒ１に対してリフレッシュを実行した場合を想定する。ライトコマンド領域に記録されていたデータは、リフレッシュ予定領域ｒ１に対してリフレッシュを実行することによって、データが読み出された後、再び、読み出したデータがライトコマンド領域に書き込まれる。この場合、さらに、ライトコマンド領域に対してライトコマンドを実行することにより、ライトコマンド領域にライトデータが書き込まれる。このように、ライトコマンド領域に対して２度の書き込みが行われる。つまり、リフレッシュを実行した後にライトコマンドを実行するため、ライトコマンド領域には、リフレッシュで書き込まれたデータがライトコマンドのデータで上書きされる。したがって、１度目のリフレッシュの書き込みの処理は、不要な処理であることが分かる。
【００４２】
Ｔ３は、ライトコマンドＢ、ライトコマンドＣ、及びライトコマンドＤを実行した後の状態を示している。リフレッシュを行う前にライトコマンドを実行することによって、リフレッシュ予定領域ｒ１が、Ｔ３のリフレッシュ領域ｒ２で示すように、小さくなる。第１の実施形態では、このリフレッシュ領域ｒ２に対してリフレッシュを行う。
【００４３】
次に、図４を参照し、第１の実施形態において実行されるＡＴＩ対策処理の手順について説明する。  
始めに、ブロック４０で、コマンドキューから１つのコマンドを読み出す。  
次に、ブロック４１で、コマンドキューから読み出したコマンドがライトコマンドかどうかを判定する。ライトコマンドでない場合、ブロック４０に戻り、再びコマンドキューから１つのコマンドを読み出す。コマンドキューから読み出したコマンドがライトコマンドであった場合、ブロック４２に進む。
【００４４】
ブロック４２で、ライトコマンド領域がリフレッシュ予定領域であるかを、書き込み回数記録値２３ｂに基づき判定する。ライトコマンド領域がリフレッシュ予定領域であるとは、ライトコマンド領域がリフレッシュ予定領域に含まれている場合、またはライトコマンド領域とリフレッシュ予定領域とが一致する場合の何れかである。
【００４５】
ブロック４２で、ライトコマンド領域がリフレッシュ予定領域でない場合、ライトコマンドを実行する。ブロック４２で、ライトコマンド領域がリフレッシュ予定領域である場合、ブロック４３に進む。
【００４６】
ブロック４３で、リフレッシュ処理よりもライトコマンドを優先して実行する。図３を参照して上述したように、リフレッシュ処理を行う前にライトコマンドを実行し、リフレッシュ予定領域を小さくする等して調整する。
【００４７】
次に、ブロック４４で、リフレッシュ済みアドレスを、ＡＴＩ対策処理情報テーブル２３ｄに記録する。リフレッシュ済みアドレスとは、リフレッシュ予定領域内のライトコマンド領域を示すＬＢＡである。
【００４８】
ブロック４５で、コマンドキューにライトコマンドがあるかどうかを判定する。コマンドキューにライトコマンドがあった場合、ブロック４１に戻り、再びコマンドキューから読み出したライトコマンドに対応するライトコマンド領域がリフレッシュ予定領域であるかどうかを判定する。コマンドキューにライトコマンドがない場合、ＡＴＩ対策処理を終了する。
【００４９】
次に、図５を参照して第１の実施形態におけるリフレッシュの処理手順について説明する。  
ブロック５０で、ＭＰＵ１４等からの指示に従いリフレッシュを開始する。  
ブロック５１で、リフレッシュライトを行う領域（以下、リフレッシュライト領域と称す。）のアドレスに、リフレッシュ済みアドレスが含まれるかどうかを判定する。なお、図５におけるリフレッシュライトは、リフレッシュライトが必要な領域内の各アドレスに対して順に行う場合について説明している。また、リフレッシュライト領域は、リフレッシュ領域と同じ領域を指すが、仮にリフレッシュライト領域とリフレッシュ領域とが異なっている場合においても、図５に示すようなリフレッシュライトの処理を行うことができる。
【００５０】
ブロック５２で、リフレッシュライト領域のアドレスに、リフレッシュ済みアドレスが含まれない場合、リフレッシュライト領域に対してリフレッシュライトを行う。
【００５１】
ブロック５３で、リフレッシュライト領域の最後のアドレスに達したかを判定する。リフレッシュライト領域の最後のアドレスでない場合、リフレッシュライト領域内の次のアドレスに対してブロック５１の処理を行う。リフレッシュライト領域の最後のアドレスに達した場合、ブロック５４に進む。
【００５２】
ブロック５４で、リフレッシュ済み情報をクリアする。リフレッシュ済み情報とは、図４のブロック４４の処理におけるリフレッシュ済みアドレス、またはリフレッシュ済みアドレスに対して行ったリフレッシュのデータ等である。
【００５３】
なお、第１の実施形態では、リフレッシュ領域内にあるコマンド領域Ｂとコマンド領域Ｄとが隣接している（連続している）場合について述べたが、リフレッシュ領域内にあるコマンド領域Ｂとコマンド領域Ｄとが隣接していない場合でも第１の実施形態を適用することができる。
【００５４】
以上説明したように、第１の実施形態によれば、リフレッシュを行う回数またはリフレッシュを行う領域を小さくさせることができる。これにより、磁気ディスク装置のアクセス性能、特にライトコマンドの処理性能、を向上させることができる。また、リフレッシュ領域に連続するＬＢＡが含まれていた場合において、リフレッシュ領域を小さくすることができるため、リフレッシュの処理に要する時間等を短縮することができる。
【００５５】
（第２の実施形態）
以下、図面を参照して、第２の実施形態を説明する。なお、第１の実施形態と同様の構成及び機能に関しては説明を省略する。  
第１の実施形態では、リフレッシュ領域にライトＬＢＡの領域が含まれていた場合、リフレッシュ領域からライトＬＢＡの領域を除いた領域に対してリフレッシュを行った。第２の実施形態では、リフレッシュ領域にライトＬＢＡの領域が含まれていた場合、リフレッシュ領域から読み出されるリードデータ（以下、リフレッシュ用リードデータと称す。）とライトデータとを統合（マージ）し、マージしたデータをリフレッシュ領域にリライトする。
【００５６】
具体的に、図６を参照して、第２の実施形態におけるＡＴＩ対策処理について説明する。  第２の実施形態では、図６に示すように、リフレッシュ領域がライトコマンド領域によって複数の領域（ｒ２ｂ、ｒ２ｃ、及びｒ２ｄ）に分割されているような場合を想定している。
【００５７】
Ｔ４は、コマンドキューに格納されている４つのライトコマンドの何れのライトコマンドも実行されていない状態を示している。コマンド領域Ｂ、コマンド領域C、及びコマンド領域Ｄの各々は、ほぼ均等に間隔を空いている。
【００５８】
Ｔ５は、ライトコマンドＡを実行した場合における状態を示している。ライトコマンドＡを実行することによって、リフレッシュ予定領域ｒ１が推定される。コマンド領域Ｂ、コマンド領域C、及びコマンド領域Ｄは、リフレッシュ予定領域ｒ１に含まれる。
【００５９】
Ｔ６は、ライトコマンドＢ、ライトコマンドＣ、及びライトコマンドＤを、それぞれ順に実行するのではなく、リフレッシュの実行と共にライトコマンドＢ、ライトコマンドＣ、及びライトコマンドＤに相当する処理を行う状態を示している。第２の実施形態では、リフレッシュ予定領域ｒ１からリフレッシュ用リードデータ６０をバッファ１７に読み出す。そして、リフレッシュ用リードデータ６０に対して、各ライトコマンドのデータを、それぞれ、対応する場所にマージする。マージしたデータをリフレッシュ領域に書き込む。このようにすることで、不要な書き込みの処理を減少させることができ、リフレッシュの処理とライトコマンドの処理とを効率よく実行することができる。
【００６０】
次に、図７を参照し、第２の実施形態におけるリフレッシュの処理とライトコマンドの処理とを組み合わせた処理の手順について説明する。  
始めに、ブロック７０で、ホストシステム２０からライトコマンドを受信する。次に、ブロック７１で、リフレッシュが行われているかまたはリフレッシュが行われる予定であるかを判定する。リフレッシュが発動していないまたは発動する予定でない場合、ブロック７７に進み、書き込み回数記録を更新し、ライト処理を終了する。
【００６１】
リフレッシュが発動しているかまたは発動する予定である場合、ブロック７２に進む。ブロック７２で、リフレッシュ領域に対してライトコマンドを受信したかどうかを判定する。リフレッシュ領域に対してライトコマンドを受信していない場合、ブロック７７に進む。リフレッシュ領域に対してライトコマンドを受信した場合、ブロック７３に進み、ライトデータをバッファメモリＡ（バッファメモリ１７ｂ）に格納する。ブロック７４で、リフレッシュ領域をリードし、リードしたデータをバッファメモリＢ（バッファメモリ１７ｃ）に格納する。次に、ブロック７５で、バッファメモリＡに格納したライトデータをバッファメモリＢに移動する（マージする）。ブロック７６で、マージしたバッファメモリＢのデータをリフレッシュ領域に書き込む。
【００６２】
なお、第２の実施形態では、リフレッシュ領域内にあるコマンド領域Ｂ、コマンド領域C、及びコマンド領域Ｄの各々が隣接していない（連続していない）場合について述べたが、リフレッシュ領域内にあるコマンド領域Ｂ、コマンド領域C、及びコマンド領域Ｄの各々が隣接している場合でも第２の実施形態を適用することができる。
【００６３】
以上説明したように、第２の実施形態によれば、リフレッシュのリライトとライトコマンドに応じた書き込みを同時に行うことができる。そのため、例えば同じ領域に対する不要な書き込みを減少させることができる。特に、リフレッシュを行わなければならない場合において、ライトコマンドの処理性能を向上させることができる。また、特にリフレッシュ領域内にある複数のライトＬＢＡが隣接していない場合において、シーク時間等を短くすることができるため、リフレッシュの処理に要する時間等を短縮することができる。
【００６４】
（第３の実施形態）
以下、図面を参照して、第３の実施形態を説明する。なお、第１の実施形態及び第２の実施形態と同様の構成及び機能に関しては説明を省略する。  
第１の実施形態及び第２の実施形態では、ライトコマンドを受信した場合におけるＡＴＩ対策処理に関するものであったが、第３の実施形態では、リードコマンドを受信した場合におけるＡＴＩ対策処理に関するものである。また、第３の実施形態では、ＡＴＩ対策処理として、リフレッシュに加えてリードベリファイを行う。
【００６５】
リードベリファイは、磁気ディスク１に書き込んだデータを、正常に読み出すことができるかどうか確かめるための処理である。なお、正常に読み出すことができるとは、リードエラーが発生することなくデータを読み出すことができることである。
【００６６】
リードベリファイによって、正常に読み出すことができなかった場合、正常に読み出すことができなかった領域に格納されているデータに対してリフレッシュを行う。
【００６７】
図８を参照し、第３の実施形態におけるＡＴＩ対策処理の概要について述べる。  
コマンドキューには、ライトコマンドＡ、リードコマンドＢ、及びライトコマンドＣがこの順に格納されている。
【００６８】
Ｔ７は、コマンドキュー内の何れのコマンドも実行される前の状態を示している。  
Ｔ８は、ライトコマンドＡを実行した場合の状態を示している。また、Ｔ８は、リードコマンドが予定されているリードベリファイ予定領域ｒ３にリードコマンド領域ｒ４が含まれる場合を示している。ライトコマンドＡを実行することによって、後に実行されるコマンドキュー内のコマンドＣを実行した場合に、書き込み回数記録値２３ｂに基づき、リードベリファイが必要かどうかを推定することができる。
【００６９】
Ｔ８’は、仮にコマンド領域Ｂがリードベリファイ予定領域ｒ３に近い場所（コマンド領域Ｂ’）にあった場合における、リードベリファイ予定領域ｒ３とコマンド領域Ｂ’との位置関係を示している。Ｔ８’のように、リードコマンド領域がリードベリファイ予定領域に含まれていない場合でも、第３の実施形態におけるＡＴＩ対策処理を行うことができる。
【００７０】
Ｔ９は、リードコマンドＢを実行する場合における、拡張されたリードコマンドＢのリードコマンド領域ｒ４’を示している。Ｔ９のように、拡張されたリードコマンドＢのリードコマンド領域ｒ４’は、リードベリファイ予定領域ｒ３に相当する領域である。
【００７１】
このように、第３の実施形態では、リードベリファイが行われる予定である場合において、リードコマンドを実行する必要があった場合、リードベリファイを行う前に、リードコマンド領域を広げることによって、リードコマンドの読み出しの処理とリードベリファイの読み出しの処理とを同じタイミングで行う。これにより、読み出しに関して不要な処理を減少させることができる。
【００７２】
次に、図９を参照し、第３の実施形態におけるリード処理について説明する。なお、図９では、リードベリファイを行う必要がある場合においてリードコマンドを実行する際の処理である。  
ブロック９０で、ホストシステム２０からリードコマンドを受信する。ブロック９１で、受信したリードコマンド領域とリードベリファイ予定領域とが近いまたは一致するかどうかを判定する。受信したリードコマンド領域とリードベリファイ予定領域とが近くなくまたは一致しない場合、ブロック９５に進み、リードコマンド領域に対してリードを実行する。
【００７３】
ブロック９１で、受信したリードコマンドのブロック領域とリードベリファイ領域予定とが近いまたは一致する場合、ブロック９２に進む。ブロック９２で、リードベリファイ予定領域を含む領域にリードコマンド領域を拡張する。ブロック９３で、拡張した領域に対してリードを実行する。ブロック９４で、拡張した領域に対するリードの実行結果として、リードベリファイ領域のアドレスとリードリトライ回数とをＡＴＩ対策処理済み情報テーブル２３ｄ等の所定のメモリに記録する。なお、リードリトライ回数は、リードベリファイ領域においてリライトを実行するかどうかを判定する値であり、例えばリードエラーレート等に基づき得られる。
【００７４】
以上のように、図９を参照して説明したようなリード処理を行うことによって、リードベリファイを行う必要があった場合において、単にリードコマンドに応じたリード処理を行うのではなく、リードコマンド領域を拡張することによってリード処理とリードベリファイ処理とを効率的に行うことができる。
【００７５】
次に、図１０を参照し、第３の実施形態におけるリードベリファイの処理について説明する。  
ブロック１００で、リードベリファイを開始する。ブロック１０１で、リードベリファイ領域のアドレスと、ブロック９４において所定のメモリに記録したリードベリファイ領域のアドレスと、が一致するかどうかを判定する。リードベリファイ領域のアドレスが一致した場合、図９を参照して述べたようなリードを実行したことにより、リードベリファイを行おうとしている領域が既にリードベリファイを行ったリードベリファイ領域であるとすることができる。リードベリファイ領域のアドレスが一致しなかった場合、ブロック１０３でリードベリファイ領域に対してリードベリファイを行う。
【００７６】
ブロック１０２で、リードベリファイを行った結果であるリードリトライ回数に基づき、リードベリファイ領域に対してリライトを行う必要があるかどうかを判定する。リードベリファイ領域に対してリライトを行う必要があるかどうかは、例えば、リードリトライ回数と所定の閾値とを比較し、リードリトライ回数が所定の閾値を越えているか否かに基づき判定される。リードリトライ回数が所定の閾値を越えていない場合、リードベリファイ領域はリード可能な領域であるとし、リードベリファイを終了する。
【００７７】
ブロック１０２で、リードリトライ回数が所定の閾値を越えている場合、リードベリファイ領域は正常にリードできない領域であるとし、ブロック１０４に進む。ブロック１０４で、リードベリファイ領域に対して、図９のブロック９３でリードしたデータをリライトする。次に、ブロック１０５で、ＡＴＩ対策処理済み情報テーブル２３ｄに格納されている先行リードベリファイの結果をクリアする。先行リードベリファイとは、図９を参照して述べたリードベリファイの結果である。
【００７８】
以上説明したように、第３の実施形態によれば、リフレッシュを行うために必要なデータを読み出す処理であるリードベリファイを行う回数及びリードベリファイ領域を小さくすることができる。そのため、磁気ディスク装置のアクセス性能、特にリードコマンドに関する処理性能を向上させることができる。
【００７９】
（第４の実施形態）
以下、図面を参照して、第４の実施形態を説明する。なお、第１の実施形態乃至第３の実施形態と同様の構成及び機能に関しては説明を省略する。  
第１の実施形態乃至第３の実施形態では、単一のＡＴＩ対策処理を行う場合を想定していたが、第４の実施形態では、例えばコマンド領域の位置関係等に基づき、複数のＡＴＩ対策処理から適切なＡＴＩ対策処理を選択するための処理を行う。
【００８０】
図１１を参照して、適切なＡＴＩ対策処理を選択する手順について説明する。  
ブロック１１０で、磁気ディスク装置がライトコマンドを受信し、受信したライトコマンドをコマンドキューに入れる。  
ブロック１１１で、コマンドキューからライトコマンドを取り出す。そして、リフレッシュを行う前に、リフレッシュ予定領域がライト領域によって複数の領域に分割されているかどうかを判定する。リフレッシュ予定領域がライト領域によって複数の領域に分割されていた場合、ブロック１１２で、ライトデータとリフレッシュ用リードデータとをマージし、マージしたデータをリフレッシュ領域に書き込む。リフレッシュ予定領域がライト領域によって複数の領域に分割されていない場合、ブロック１１３で、リフレッシュ処理よりもライトコマンドを優先して実行する。なお、ブロック１１２の処理は、第２の実施形態で述べたＡＴＩ対策処理に相当する。ブロック１１３の処理は、第１の実施形態で述べたＡＴＩ対策処理に相当する。
【００８１】
リフレッシュ予定領域がライト領域によって複数の領域に分割されているとは、例えば、図６に示すように、リフレッシュ予定領域ｒ１が複数のライト領域によって分割されていることを意味する。なお、図６では、複数のライト領域のアドレスの各々が連続することなく、リフレッシュ予定領域がライト領域によって複数の領域に分割されているが、例えば、複数のライト領域のアドレスが連続している場合でも、リフレッシュ予定領域がライト領域によって複数の領域に分割されていれば、図１１で述べたような複数のＡＴＩ対策処理から適切なＡＴＩ対策処理を選択してもよい。
【００８２】
以上説明したように、第４の実施形態によれば、複数のＡＴＩ対策処理をダイナミックに切り替えることによって、単一のＡＴＩ対策処理を利用した場合と比べ、ライト領域のアドレスによって示されるブロック間の位置関係に応じて、より効率よくリフレッシュを行うことができる。
【００８３】
以上説明した第１の実施形態乃至第４の実施形態において、磁気ディスク装置の状態が、ライトコマンドまたはリードコマンド等に応じた処理が行われていないようなアイドル状態でない場合でも、ライトコマンドまたはリードコマンド等の処理を遅らせることなく、またライトコマンドまたはリードコマンド等の処理性能を低下させることなくＡＴＩ対策処理を行うことができる。具体的には、ライトコマンドの処理の優先度を上げて実行することにより、またはライトコマンドを行う領域をリフレッシュ処理の対象となる領域から除くことにより、ライトコマンドを行う領域の近傍の領域への書き込み処理の実行によるリフレッシュ処理の実行を抑止することができる。
【００８４】
なお、第１の実施形態乃至第３の実施形態の何れかを組み合わせた実施形態であってもよい。例えば、第１の実施形態と第２の実施形態とを組み合わせることによって、ライトコマンドの論理ブロックアドレスが連続していた場合、第１の実施形態のＡＴＩ対策処理を行い、ライトコマンドのアドレスが連続していない場合、第２の実施形態のＡＴＩ対策処理を行うこともできる。他の例として、第２の実施形態と第３の実施形態とを組み合わせることによって、リフレッシュ領域にリードＬＢＡとライトＬＢＡとがある場合、リードコマンドに応じた読み出しに代えてリフレッシュ用リードデータを読み出し、読み出したリフレッシュ用リードデータを用いてリードベリファイを行い、さらに、リフレッシュ用リードデータとライトデータとを統合し、統合したデータをリライトすることによって、コマンド処理に関する性能を低下させることなく、ＡＴＩ対策処理としてリフレッシュ及びリードベリファイを行うことができる。
【００８５】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００８６】
１…磁気ディスク、１３…ハードディスクコントローラ（ＨＤＣ）、１３ｄ…コマンド制御部、１３ｅ…バッファ制御部、１４…ＭＰＵ、１７…バッファ、２１ｅ…ＡＴＩ対策処理制御部、２３ｂ…書き込み回数記録値。
【図１】
2014053062.tif 000003
【図２】
2014053062.tif 000004
【図３】
2014053062.tif 000005
【図４】
2014053062.tif 000006
【図５】
2014053062.tif 000007
【図６】
2014053062.tif 000008
【図７】
2014053062.tif 000009
【図８】
2014053062.tif 000010
【図９】
2014053062.tif 000011
【図１０】
2014053062.tif 000012
【図１１】
2014053062.tif 000013