以下、本発明の実施の形態につき図面を参照して説明する。
図1は本発明の一実施形態に係る磁気ディスク装置(HDD)100の構成を示すブロック図である。図1に示すHDD100は、ホストシステム200からの要求に応じてディスク(磁気ディスク)101の記録面上にデータを書き込み、あるいは当該記録面からデータを読み出すための記憶装置である。ホストシステム200は、HDD100を記憶装置として利用するパーソナルコンピュータのような電子機器である。
ディスク101はスピンドルモータ(SPM)3に固定されており、SPM103が駆動されることにより一定の速度で回転する。ディスク101の例えば一方のディスク面は、データが磁気記録される記録面をなしている。ヘッド(磁気ヘッド)102はディスク101の記録面に対応して配置される。ヘッド102はアクチュエータ105の一端に固定されており、アクチュエータ105の他端はボイスコイルモータ(VCM)104に固定されている。ヘッド102は、VCM104が駆動されることにより、VCM104の軸を中心とした円弧軌道のうちディスク101の面に重なる範囲を移動する。
図1の構成では、単一枚のディスク101を備えたHDD100を想定している。しかし、複数のディスク101がある間隙をもった状態でSPM103に固定された構成であっても構わない。この場合、複数のアクチュエータ105が、複数のディスク101の間隙に合わせて重なった状態でVCM104に固定される。複数のアクチュエータ105の一端にはそれぞれヘッド102が固定されている。したがってSPM103が駆動されると、全てのディスク101は同時に回転し、VCM104が駆動されると、全てのヘッド102は同時に移動する。また、図1の構成では、ディスク101の一方の面が記録面をなしている。しかし、ディスク101の両面がいずれも記録面をなし、両記録面にそれぞれ対応してヘッド102が配置されても構わない。
図2はディスク101のトラック配置を含むフォーマットを示す概念図である。
図2において、ディスク101の記録面には、複数のトラック201が同心円状に配置されている。ホストシステム200からHDD100が受け取ったデータは、当該ホストシステム200によって指定されたアドレスに応じ、複数のトラック201の少なくとも1つに記録される。
また、ディスク101の複数のトラック201上にはサーボ領域202及びデータ領域203が交互に且つ等間隔に配置されている。サーボ領域202には、ヘッド102の位置決めに用いられるサーボ信号が記録されている。データ領域203は、ホストシステム200から転送されるデータを記録するのに用いられる。
再び図1を参照すると、CPU115はHDD100の主コントローラとして機能する。CPU115はモータドライバ106を介してSPM103の起動・停止及び回転速度維持のための制御を行う。CPU115はまたモータドライバ106を介してVCM104を駆動制御することで、ヘッド102を目標とするトラックに移動させて、当該トラックの目標とする範囲内に整定するための制御を行う。ヘッド102を目標とするトラックに移動させる制御はシーク制御と呼ばれ、ヘッド102を目標とするトラックの目標とする範囲内に整定する制御はヘッド位置決め制御と呼ばれる。CPU115は更に、ディスク101のトラック201に書き込まれているデータをリフレッシュするための制御(データリフレッシュ処理)を行う。
ヘッド102の位置決めはSPM103の起動後の定常回転状態で行われる。上述のように、サーボ領域202(図2参照)はディスク101の円周方向に等間隔に配置されている。このため、ヘッド102によってディスク101から読み出され、ヘッドIC107で増幅されたアナログ信号中には、サーボ領域202に記録されているサーボ信号が時間的に等間隔に現れることになる。リード・ライトIC108(リード・ライトIC108に含まれているサーボブロック121)とゲートアレイ109とは、このことを利用して上記アナログ信号を処理することにより、ヘッド102の位置決めのための信号を生成する。CPU115はこの信号をもとにモータドライバ106を制御することにより、当該モータドライバ106からVCM104に、ヘッド102の位置決めのための電流(VCM電流)をリアルタイムで供給させる。
CPU115は、上述のようにモータドライバ106を介してSPM103及びVCM104を制御する一方で、他のICの制御及びコマンド処理など、HDD全体を制御する。CPU115はCPUバス112に接続されている。
CPUバス112には、リード・ライトIC108、ゲートアレイ109、ディスクコントローラ(HDC)110、RAM113及びフラッシュROM114が接続されている。フラッシュROM114は、書き換え可能な不揮発性メモリである。ここでは、フラッシュROM114の書き換えは、CPU115からの制御により行われる。フラッシュROM114には、CPU115が実行すべきプログラムが予め格納されている。CPU115による上述の制御は、当該CPU115が上記プログラムを実行することにより実現される。フラッシュROM114の記憶領域の一部は、後述するトラックシフトテーブル500(図5参照)を格納するのに用いられる。RAM113は、例えばCPU115が使用する種々の変数を格納するのに用いられる。またRAM113の記憶領域の一部は、CPU115のワーク領域として用いられる。
リード・ライトIC108は、サーボブロック121とリード・ライトブロック122とを有する。サーボブロック121は、サーボ信号の抽出を含む、ヘッド102の位置決めに必要な信号処理を行う。リード・ライトブロック122は、データの読み出し・書き込みのための信号処理を行う。ゲートアレイ109は、サーボブロック121によるサーボ信号の抽出のための信号を含む、制御用の諸信号を生成する。
HDC110は、CPUバス112以外に、リード・ライトIC108、ゲートアレイ109及びバッファRAM111に接続されている。HDC110は、ホストブロック123、リード・ライトブロック124及びバッファブロック125を有する。ホストブロック123は、ホストシステム200から転送されるコマンド(ライトコマンド、リードコマンド等)を受信すると共にホストとHDC110との間のデータ転送を制御するホストインタフェース制御機能を有する。リード・ライトブロック124は、リード・ライトIC108及びゲートアレイ109と接続され、リード・ライトIC108を介して行われるデータの読み出し・書き込み処理を行う。バッファブロック125は、バッファRAM111を制御する。バッファRAM111の記憶領域の一部は、HDC110(HDC110内のリード・ライトブロック124)を介してディスク101に書き込まれるべきデータ(ライトデータ)を一時格納するためのライトバッファとして用いられる。バッファRAM111の記憶領域の別の一部は、HDC110を介してディスク101から読み出されたデータ(リードデータ)を一時格納するためのリードバッファとして用いられる。
リード・ライトIC108、ゲートアレイ109、及びHDC110は、それぞれ制御用レジスタを有する。これらの制御用レジスタは、それぞれCPU115のメモリ空間の一部に割り当てられており、CPU115はこの一部の領域に対してアクセスすることで、制御用レジスタを介してリード・ライトIC108、ゲートアレイ109、またはHDC110を制御する。
図1のHDD100において、データの読み出しは次のように行われる。まずヘッド102によってディスク101から読み出された信号(アナログ信号)は、ヘッドIC107によって増幅される。増幅されたアナログ信号はリード・ライトIC108によってサーボ信号とデータ信号とに分離される。データ信号はリード・ライトIC108内のリード・ライトブロック122で復号化された後HDC110に送られる。HDC110内のリード・ライトブロック124は、復号化されたデータ信号をゲートアレイ109からの制御用の信号に従って処理することにより、ホストシステム200に転送すべきデータを生成する。ここでの処理は、後述するECCデータに基づくデータの誤りの検出と誤りの訂正とを含む。生成されたデータは、HDC110内のバッファブロック125によって一旦バッファRAM111に格納されてから、当該HDC110内のホストブロック123によってホストシステム200に転送される。
図1のHDD100において、データの書き込みは次のように行われる。ホストシステム200からHDC110に転送されたデータは、当該HDC110内のホストブロック123で受信された後、当該HDC110内のバッファブロック125によって一旦バッファRAM111に格納される。バッファRAM111に格納されたデータは、バッファブロック125によって取り出された後、ゲートアレイ109からの制御用の信号に従ってHDC110内のリード・ライトブロック124によってリード・ライトIC108へ送られる。リード・ライトIC108に送られたデータは、当該リード・ライトIC108内のリード・ライトブロック122によって符号化される。符号化されたデータはヘッドIC107を介してヘッド102に送られて、当該ヘッド102によってディスク101に書き込まれる。上述のデータの読み出し/書き込みは、CPU115の制御の下で行われる。
次に、図1のHDD100で実行されるデータリフレッシュ処理の概要について説明する。
発明が解決しようとする課題の欄で述べたように、データリフレッシュ中の電源遮断対策のために、データリフレッシュの対象となるトラック(ターゲットトラック)のデータをディスク上の特定のトラック(一時退避用のトラック)に一時退避させると、データリフレッシュ処理の効率が低下する。そこで本実施形態では、データリフレッシュ中の電源遮断対策を図りながら、処理効率の低下を防止可能な、次のような特徴あるデータリフレッシュ処理を適用している。
本実施形態では、ディスク101上に予備トラックTiが用意される。この予備トラックTiに隣接するトラックTjが、データリフレッシュの対象となるトラック(ターゲットトラック)Tjとなる。
まず、ヘッド102によってターゲットトラックTjからデータが読み出される。次にヘッド102がターゲットトラックTjから予備トラックTiに移動される。ここで予備トラックTiはターゲットトラックTjに隣接するため、ターゲットトラックTjから予備トラックTiにヘッド102を高速に移動できる。
ヘッド102が予備トラックTiに移動されると、ターゲットトラックTjから読み出されたデータが、ヘッド102によって予備トラックTiに書き込まれる。これによりターゲットトラックTjのデータのリフレッシュが完了する。つまり本実施形態の特徴は、ターゲットトラックTjのデータを隣接する予備トラックTiに書き込むことで、当該データを予備トラックTi上でリフレッシュする点にある。上述のターゲットトラックTjからのデータの読み出しと、読み出されたデータの予備トラックTiへの書き込みとは、CPU115の制御の下で行われる。
もし、ターゲットトラックTjから読み出されたデータを予備トラックTiに書き込む書き込み動作の最中に電源が遮断しても、ターゲットトラックTjのデータは失われない。このため、電源が復帰した際に、ターゲットトラックTjからデータを読み出して、その読み出されたデータを予備トラックTiに書き込むことができる。
このように本実施形態では、ターゲットトラックTjから読み出されたデータが一時退避用のトラックを介して当該ターゲットトラック(つまり元のトラック)Tjに再度書き込まれるのではないことに注意されるべきである。本実施形態によれば、ターゲットトラックのデータを一時退避のためにディスク101(一時退避用のトラック)に書き込む動作が不要となる。つまり本実施形態によれば、一時退避用のトラックを用いてターゲットトラックのデータをリフレッシュする場合に比べて、ディスク101へのデータ書き込みの動作を1回少なくでき、電源遮断に対処しつつ、リフレッシュ処理の効率が低下するのを防止できる。
ターゲットトラックTjから読み出されたデータが、予備トラックTiに書き込まれると、当該ターゲットトラックTjが新たな予備トラックTjとなる。そして、この新たな予備トラックTjにトラックTiとは逆側で隣接するトラックTkが、新たなターゲットトラックTkとなる。すると、ヘッド102が、トラックTiから新たなターゲットトラックTkに移動される。トラックTiと新たなターゲットトラックTkとの距離は2トラック分であるため、トラックTiから新たなターゲットトラックTkにヘッド102を高速に移動できる。
次に、ヘッド102によってターゲットトラックTkからデータが読み出される。次にヘッド102がターゲットトラックTkから隣接する新たな(現在の)予備トラックTjに移動される。そして、ターゲットトラックTkから読み出されたデータが、ヘッド102によって現在の予備トラックTjに書き込まれる。以下同様にして、予備トラックが1トラック単位で順次切り替えられ、その都度、その際の予備トラックに隣接するトラックのデータを、その際の予備トラックに書き込む動作が行われる。
本実施形態によれば、ターゲットトラックと予備トラックとは常に隣接しているため、ターゲットトラックから予備トラックに高速でヘッド102を移動できる。また、ターゲットトラックのデータを予備トラック上でリフレッシュすると、当該ターゲットトラックが新たな予備トラックとなる。そして、この新たな予備トラックにそれまで予備トラックとして用いられていたトラック(旧予備トラック)とは逆側で隣接するトラックが、新たなターゲットトラックとなる。旧予備トラックと新たなターゲットとの距離は2トラック分であるため、旧予備トラックから新たなターゲットトラックに高速でヘッド102を移動できる。よって本実施形態によれば、一時退避用のトラックを用いてターゲットトラックのデータをリフレッシュする場合に比べて、ヘッドの移動に要する時間を短縮できる。この点からも、本実施形態によれば、電源遮断に対処しつつ、リフレッシュ処理の効率が低下するのを防止できる。
次に、上述のデータリフレッシュ処理を、図3の概念図を参照して説明する。
本実施形態では、ディスク101の記録面に配置されたトラック201の集合は予め定められた一定数のトラックを単位にグループ化されて、グループ単位でデータリフレッシュ処理が行われる。このグループを、トラックグループと称する。ここでは、トラックグループ毎に、そのトラックグループ全体へのデータ書き込み動作の総数(ライト回数)がカウントされる。このカウント値が予め定められた一定値に達したならば、該当するトラックグループを対象とするデータフリフレッシュ処理が行われる。
図3の例では、ディスク101上の1つのトラックグループが示されている。ここでは、説明の簡略化のために、トラックグループがトラック0乃至10の11トラックから構成されているものとする。トラック0乃至10の表記における「0」乃至「10」の数値は、トラックグループ内のトラックの相対位置(相対トラック位置)を示す。この値が小さいトラックほどディスク101上の外周側に位置し、値が大きいトラックほどディスク101上の内周側に位置するものとする。
図3において、状態31は、1つのトラックグループ内に1つの予備トラックが確保されている状態を示す。ここでは、トラック10が予備トラックに割り当てられている。但し、予備トラックは後述するように動的に切り替えられる。トラックグループ内の予備トラック10以外のトラック0乃至9トラックには、それぞれデータA乃至Jが格納されているものとする。
今、状態31にあるトラックグループがデータリフレッシュの対象となったものとする。この場合、本実施形態ではまず、予備トラック10に(ディスク101の外周側で)隣接するトラック9がデータリフレッシュの対象トラック(ターゲットトラック)として選択される。そして、トラック9のデータJが読み出され、当該読み出されたデータJが、図3において矢印311で示されるように、その時点における予備トラックであるトラック10に書き込まれる。これにより、トラック9のデータが、当該トラック9に隣接するトラック10上でリフレッシュされる。
すると、それまでデータリフレッシュの対象となっていたトラック9が、トラック10に代わって新たに予備トラックに割り当てられる。この状態では、新たな予備トラック9に(ディスク101の外周側で)隣接するトラック8がターゲットトラックとして選択される。そして、トラック8のデータIが読み出され、当該読み出されたデータIが、図3において矢印312で示されるように、その時点における予備トラックであるトラック9に書き込まれる。これにより、トラック8のデータが、当該トラック8に隣接するトラック9上でリフレッシュされる。
以下、同様の動作が予備トラックを切り替えながら順次行われる。やがて、トラック1のデータBが、図3において矢印319で示されるようにトラック2に書き込まれ、トラック0のデータAが図3において矢印320で示されるように、トラック1に書き込まれ、当該トラック0が新たに予備トラックに割り当てられたものとする。このように、トラック0が予備トラックになったところで、つまり図3において状態31にあるトラックグループが図3に示される状態32に遷移したところで、当該トラックグループを対象とするデータリフレッシュ処理(データリフレッシュ動作)が完了する。これを、順方向のリフレッシュ処理と呼ぶ。つまり、ターゲットトラックのデータがディスク101の内周方向(相対トラック位置の値が増加する方向)に隣接するトラック(予備トラック)に書き込まれるデータリフレッシュ処理を、順方向のリフレッシュ処理と呼ぶ。また、この方向をリフレッシュ方向と呼び、ターゲットトラックのデータを隣接するトラックに書き込む書き込み動作を、ずらし書き込み(シフトライト)と呼ぶ。
その後、図3において状態32にあるトラックグループを対象とするデータリフレッシュ処理が必要になったものとする。この場合、先の順方向のリフレッシュ処理とは逆に、予備トラック0に隣接するトラック1がターゲットトラックとして選択される。そして、トラック1のデータAが読み出され、当該読み出されたデータAが、図3において矢印321で示されるように、その時点における予備トラックであるトラック0に書き込まれる。これにより、トラック1のデータAが、当該トラック1に隣接するトラック0上でリフレッシュされる。
すると、それまでデータリフレッシュの対象となっていたトラック1が、トラック0に代わって新たに予備トラックに割り当てられる。この状態では、新たな予備トラック1に(ディスク101の内周側で)隣接するトラック2がターゲットトラックとして選択される。そして、トラック2のデータBが読み出され、当該読み出されたデータBが、図3において矢印322で示されるように、その時点における予備トラックであるトラック1に書き込まれる。これにより、トラック2のデータBが、当該トラック2に隣接するトラック1上でリフレッシュされる。
以下、同様の動作が予備トラックを切り替えながら順次行われる。やがて、トラック9のデータIが、図3において矢印329で示されるようにトラック8に書き込まれ、トラック10のデータJが図3において矢印330で示されるように、トラック9に書き込まれ、当該トラック10が新たに予備トラックに割り当てられたものとする。このように、トラック10が予備トラックになったところで、つまり図3において状態32にあるトラックグループが図3に示される状態33に遷移したところで、当該トラックグループを対象とするデータリフレッシュ処理が完了する。これを、逆方向のリフレッシュ処理と呼ぶ。つまり、ターゲットトラックのデータがディスク101の外周方向(相対トラック位置の値が減少する方向)に隣接するトラック(予備トラック)に書き込まれるリフレッシュ処理を、逆方向のリフレッシュ処理と呼ぶ。
以後は、図3に示されるトラックグループのリフレッシュが必要になる度にリフレッシュ方向を切り替えながら、リフレッシュ処理が行われる。つまり、順方向のリフレッシュ処理と逆方向のリフレッシュ処理とが交互に行われる。なお、図3の例では、説明の簡略化のために、トラックグループ当たりのトラック数は予備トラックを含めて11である。この例では、ディスク101の実質的な記憶容量は、総トラック(シリンダ)数の10/11しか確保できない。したがって実際には、トラックグループ当たりのトラック数として、もっと大きな値を設定することが好ましい。
図4はトラックグループ毎のライト回数(データライト回数、ライト実行回数)を保持するライトカウントテーブル400のデータ構造例を示す。ライトカウントテーブル400は、例えば図1におけるRAM113の所定の領域に格納される。
図4のライトカウントテーブル400の例では、説明の一般化のために、HDD100がm本のヘッド102を有すると共に、当該HDD100がn個のシリンダグループから構成される場合を想定している。この場合、ライトカウントテーブル400は、ヘッド(ヘッド番号)h、シリンダグループ(シリンダグループ番号)cを用いて表される全てのトラックグループの各々について、そのトラックグループへのライト回数(データライト回数)W(h,c)(0≦h≦m−1,0≦c≦n−1)を保持している。W(h,c)はヘッド番号h及びシリンダグループ番号cで特定されるトラックグループへのライト回数をカウントするライトカウンタとして用いられる。なお、図1のHDD100の構成の場合、mは1である。
シリンダグループとは、予め定められた一定数のシリンダの集合であり、1シリンダグループ当たりのシリンダ数は、1トラックグループ当たりのトラック数と同じである。したがって、同一のシリンダグループ番号を持つトラックグループは、HDD100内に、ヘッド102の数mに一致する数だけ存在する。トラックグループは、シリンダグループ番号cとヘッド番号hとにより特定される。シリンダグループ番号cとヘッド番号hとで特定されるトラックグループ内のトラックへのデータの書き込み(ライトアクセス)が行われると、カウントテーブル400に保持されているライト回数(ライトカウンタ)W(h,c)が、書き込みが行われた回数だけインクリメントされる。
本実施形態では、ライトカウントテーブル400は、前述のようにRAM113に格納される。RAM113の内容はHDD100の電源の遮断により失われる。したがって、ライトカウントテーブル400の内容も電源遮断と共に失われる。このため本実施形態では、ライトカウントテーブル400を含む、RAM113内の予め定められた領域の内容は、必要に応じて(例えばHDD100の省電力状態への移行時に)、ディスク101の所定領域に保存(退避)される。このディスク101の所定領域に保存されたカウントテーブル400を含む内容は、HDD100の起動時(電源投入時)に読み出されて、RAM113内に復元される。
本実施形態では、目的のデータが書き込まれているトラックは、当該トラックを含むトラックグループを対象とするデータリフレッシュの都度切り替えられる。例えば図3において、データAが書き込まれているトラックは、状態31または33ではトラック0であり、状態32ではトラック1である。この目的のデータにアクセスするためには、上述のずらし書き込みをどの向きでどこまで行ったかを示す情報を常時把握しておき、通常のアドレス変換の結果に対してシリンダ番号のずれを補正すればよい。
ここで、通常のアドレス変換について説明する。近年のHDDは、いわゆるCDR(Constant Density Recording)方式を適用しているのが一般的である。図1のHDD100もCDR方式を適用しているものとする。このようなHDD100を利用するホストシステム200は、当該HDD100に対してアクセス対象ブロックを指定する情報として、LBA(Logical Block Address:論理ブロックアドレス)を当該HDD100に与えるのが一般的である。この場合、HDD100では、例えばホストシステム200から指示されたリードコマンドまたはライトコマンドのようなコマンドの実行時に、当該ホストシステム200によって与えられたLBA(論理ブロックアドレス)を、ディスク101上の物理的な位置を示す、シリンダ番号、ヘッド番号及びセクタ番号(から構成される物理アドレス)に変換するためのアドレス変換(アドレス計算)が行われる。これが通常のアドレス変換である。
本実施形態では、このような通常のアドレス変換の結果に対して、シリンダ番号のずれを補正可能なように、トラックグループ毎にトラックグループ内の予備トラックの位置(相対位置)を示す位置情報が保持・管理される。なお、シリンダ番号のずれを補正するには、ずらし書き込みの向き(リフレッシュ方向)も把握する必要がある。しかし、このリフレッシュ方向は、後述するようにトラックグループ内の予備トラックの位置から判定可能である。このため本実施形態では、トラックグループ毎にリフレッシュ方向を示す情報が保持・管理される構成は適用されない。但し、リフレッシュ処理の実行中(または中断)のトラックグループについては、後述するリフレッシュ管理情報によって当該リフレッシュ処理のリフレッシュ方向が管理される。
図5は、トラックグループ毎の予備トラックの位置(を示す位置情報)を保持するトラックシフトテーブル500のデータ構造例を示す。図5のトラックシフトテーブル500の例では、説明の一般化のために、HDD100がm本のヘッド102を有すると共に、当該HDD100がn個のシリンダグループから構成される場合を想定している。この場合、トラックシフトテーブル500は、ヘッド(ヘッド番号)h及びシリンダグループ(シリンダグループ番号)cを用いて表される全てのトラックグループの各々について、そのトラックグループ内における予備トラックの位置S(h,c)(0≦h≦m−1,0≦c≦n−1)を保持している。この予備トラックの位置S(h,c)は、当該予備トラックが属するトラックグループ内における当該予備トラックの相対位置(相対トラック位置)を示す。なお、図1のHDD100の構成の場合、mは1である。
トラックシフトテーブル500は、電源手段対策のために書き換え可能な不揮発性メモリに保存されるのが好ましい。このトラックシフトテーブル500のデータ量は少ない。そこで本実施形態では、プログラムを格納するのに用いられるフラッシュROM114の所定の領域にトラックシフトテーブル500が保存される構成を適用している。
上述のように、HDD100では、ホストシステム200によって与えられたLBAからディスク101上の物理的な位置を示す、シリンダ番号、ヘッド番号及びセクタ番号に変換するための通常のアドレス変換が行われる。ところが本実施形態においては、トラックグループ内の予備トラックの位置とリフレッシュ方向とにより、目的とするトラックのシリンダ番号が変わる。このため、通常のアドレス変換に加え、上記トラックシフトテーブル500によって示される予備トラックの位置とリフレッシュ方向とに応じたシリンダ番号の補正処理が必要となる。
このように、トラックシフトテーブル500の内容は目的とするトラックのシリンダ番号を決定するための補正処理に欠かせない極めて重要なものである。このためトラックシフトテーブル500は、たとえHDD100の動作中に不意の電源遮断が発生しても決して失われることがあってはならない。そのためトラックシフトテーブル500は、フラッシュROM114に保存されている。
一方、トラックシフトテーブル500とは対照的に、ライトカウントテーブル400はRAM113に格納される。このため、HDD100の動作中に不意の電源遮断が発生した場合、当該HDD100の再起動後には、それ以前にディスク101に最後に保存されたライトカウントテーブル400の内容が使用される。この場合、失われるデータは、ライトカウントテーブル400の内容が最後に保存されてから電源遮断までのライト回数のみであることから影響は殆どない。
これに対して、トラックシフトテーブル500において、ある期間のあるトラックグループにおける予備トラック位置S(h,c)の更新が欠落すると仮定するならば、そのトラックグループ内のトラックのシリンダ番号を補正できなくなる。このため、トラックシフトテーブル500は常に完全な形で保存される必要がある。したがって、トラックシフトテーブル500をライトカウントテーブル400と同様にRAM113に格納すると仮定するならば、1トラックのデータがリフレッシュされる度に、当該トラックシフトテーブル500の内容をディスク101の所定の領域に保存(退避)しなければならない。このようにすると、リフレッシュ処理の効率化を果たすことができなくなる。
そこで本実施形態では、上述のようにトラックシフトテーブル500がフラッシュROM114に保存される構成を適用している。ここで、トラックシフトテーブル500の更新中における電源遮断にも対処できるように、正副2つのトラックシフトテーブル500を用意するとよい。つまり、これら正副2つのテーブル(トラックシフトテーブル)500がフラッシュROM114の異なるページに保存され、テーブル更新が、正副2つのテーブルに対して行われるようにする。ここでは、正テーブル500の更新が正常終了した後に、副テーブル500の更新が実行される構成を適用する。これにより、どのタイミングでHDD100の電源が遮断されても、トラックシフトテーブル500の内容が失われるのを防止できる。
また、一般的にフラッシュROM114の書き換えは、例えばページ単位でその内容を全て消去した後に、消去されたページに新しい内容を書き込むという手順で行われる。しかし、フラッシュROM114の種類によってはページ内で追記することが可能である。もし、フラッシュROM114がページ内で追記が可能なタイプであるならば、当該フラッシュROM114内に差分用領域を設けておき、当該フラッシュROM114を次のように利用することも可能である。
例えば、フラッシュROM114内の差分用領域を使い切るまでは、トラックシフトテーブル500を全て書き換える代わりに、差分、つまり変更されるS(h,c)のみが、当該差分用領域に順次記録される。そして、差分用領域に空きがなくなったところで、トラックシフトテーブル500が全て更新される。このような構成を適用することで、フラッシュROM114を消去する頻度を下げることもできる。ただし、差分を記録する手法では、トラックシフトテーブル500を直接参照することはできない。そこで、最新の状態を示すトラックシフトテーブル500をRAM113の所定の領域に配置し、この所定の領域内のトラックシフトテーブル500を参照するとよい。
次に、トラックグループ単位のリフレッシュ処理が行われる図1のHDD100における全体的な動作について、図6のフローチャートを参照して説明する。
まず、HDD100の電源が投入され、CPU115の動作が開始されたものとする(ステップ601)。するとCPU115は、HDD100全体を対象とする周知の初期化処理及び起動処理を行う(ステップ602)。起動処理が終わるとCPU115は、HDC110を介してホストシステム200からコマンドを受信できる状態になり、コマンド待ちループ(ステップ603乃至607)に入る。
ステップ603においてホストシステム200からのコマンドの受信を確認すると、CPU115は、ステップ611に分岐することでコマンド待ちループを抜けて、ホストシステム200からのコマンドに応じた処理を実行する。ステップ611においてCPU115は、ホストシステム200からのコマンドがライトコマンドであるかを判定する。もし、そうであれば、CPU115は、ライトコマンドのための処理(ステップ612〜615)を行う。
受信したコマンドがライトコマンドである場合(ステップ611がYES)、ホストシステム200から要求されたアドレスへの書き込みを行うために、前述のようなシリンダ番号の補正が必要となる。そこでステップ612では、このシリンダ番号の補正(実シリンダ番号の算出)が行われる。図6のフローチャートには明示的には示されていないが、ステップ612に到達する以前に、ホストシステム200からのコマンド(ライトコマンド)で指定されるアドレス(例えばLBA)を仮想シリンダ番号、ヘッド番号、セクタ番号に変換するための処理(通常のアドレス変換)が一般的な方法によって既に実施されているものとする。
仮想シリンダ番号とは、実際(通常)のシリンダ番号(実シリンダ番号)を求めるために中間的に設けられた計算上のシリンダ番号である。ここで、実際のシリンダ番号を、仮想シリンダ番号に対比させて実シリンダ番号と呼ぶ。仮想シリンダ番号で指定されるシリンダを仮想シリンダと呼び、実シリンダ番号で指定されるシリンダを実シリンダと呼ぶ。なお、単にシリンダと表現する場合には、実シリンダを指すものとする。
仮想シリンダ番号は、トラックグループ(シリンダグループ)毎に1つの予備トラックが確保されることにより必要となる概念であり、予備トラック(予備シリンダ)を除く、ホストシステム200から認識可能なトラック(シリンダ)のシリンダ番号を指す。つまり、仮想シリンダ番号は各トラックグループ(シリンダグループ)内の予備トラックを飛ばして(予備トラックの存在を前提としないで)数えられる(算出される)シリンダ番号である。
仮想シリンダ番号という概念は、以下に述べるように、アドレス変換(アドレス計算)を階層化することを目的として導入されている。まず、本実施形態で適用されるようなトラックグループ単位のデータリフレッシュ処理(トラックリフレッシュ処理)が存在しないと仮定した場合と全く同様に第1のアドレス変換(アドレス計算)が行われる。この第1のアドレス変換では、ホストシステム200によって指定されたLBAが通常のアドレス変換と同様に、シリンダ番号、ヘッド番号及びセクタ番号に変換される。ホストシステム200からは予備トラックは認識されない。このため、ホストシステム200によって指定されたLBAから第1のアドレス変換で取得されるシリンダ番号は、仮想シリンダ番号である。そこで、この仮想シリンダ番号が第2のアドレス変換(アドレス計算)によって実シリンダ番号に変換される。
上述のように本実施形態では、ステップ612への到達時には、ホストシステム200によって指定されたLBAが、既に仮想シリンダ番号、ヘッド番号及びセクタ番号に変換されている。そこでステップ612においてCPU115は、ライト処理を行うのに必要な仮想シリンダ番号から実シリンダ番号への変換(実シリンダ番号の算出)を行う。このステップ612の詳細については後述する。CPU115は、ステップ612を実行すると、変換(算出)された実シリンダ番号と、ヘッド番号及びセクタ番号とに基づき、ライト処理(データ書き込み動作のための制御)を行う(ステップ613)。
ライト処理(ステップ613)が完了したなら、CPU115は、そのライト処理がライトカウントテーブル400に反映されるように、当該テーブル400を更新する(ステップ614)。つまりCPU115は、ライト処理がヘッドh、シリンダグループcで特定されるトラックグループに対して行われた場合、ライトカウントテーブル400内のライト回数W(h,c)をライト処理が反映されるように更新する。更に詳細に述べるならば、CPU115は、ライトカウントテーブル400内のライト回数W(h,c)に対してライトが行われた回数を加算する。ここでは通常は、1が加算される。但し、ライト処理でリトライが行われた場合には、当該リトライも通常のライト動作と同様に隣接トラックに影響するので、当該リトライの回数も併せて加算される。
ステップ614が実行されると、ライトコマンドの処理は完了する。そこでCPU115は、レジスタ類の更新、及びビジー状態の解除など、コマンドの終了処理を行い(ステップ615)、コマンド待ちループに戻る。
一方、受信したコマンドがライトコマンド以外であった場合(ステップ611がNO)、CPU115は、当該受信したコマンドに応じた処理(ステップ620)及びコマンドの終了処理(ステップ615)を行い、コマンド待ちループに戻る。ライトコマンド以外の場合のコマンドに応じた処理については、便宜的にステップ620にまとめて記述されている。しかし実際には、ライトコマンド以外にも様々なコマンドが存在することから、ステップ611で行われるようなコマンドコードの判定や、ステップ612,613に相当する処理がコマンドの数だけ存在し、ライトコマンドの場合と同様に行われる。
特にリードコマンドやシークコマンドのようにホストシステム200がアクセス対象を指定するコマンドにおいては、コマンド処理の前にステップ612と同様に仮想シリンダ番号から実シリンダ番号への変換処理が行われることに注意する必要がある。
次に、コマンド待ちループにおけるステップ603で、コマンドを受信していないと判定されたものとする。この場合、アイドル時処理が行われる。また、ステップ615でコマンドの終了処理が行われた後も、アイドル時処理が行われる。アイドル時処理は、トラックリフレッシュ処理を含む。本実施形態においてCPU115は、このトラックリフレッシュ処理の前に、トラックリフレッシュ処理を行うかを判定する(ステップ604,605)。
ステップ604においてCPU115は、トラックリフレッシュ処理を行わずにホストシステム200からのコマンドを即座に実行する必要があるか、或いはリフレッシュ処理を回避すべき状況にあるかなどを総合的に判断する。コマンドを即座に実行する必要があるのは、例えば、ステップ615の直後にホストシステム200からコマンドを受信した場合である。リフレッシュ処理を回避すべき状況は、外部からHDD100に一定レベルを超える振動が加わった場合、HDD100の環境温度が、当該HDD100の動作が保証される温度範囲から外れた場合等、HDD100が悪条件下で用いられる場合である。ステップ605においてCPU115は、ステップ604での総合的な判断結果から、トラックリフレッシュ処理が実行可能かを判定する。
トラックリフレッシュ処理を行うと判定された場合のみ、CPU115は、トラックリフレッシュ処理を行う(ステップ606)。このステップ606の詳細については後述する。
ステップ606でのトラックリフレッシュ処理が終了するか、ステップ605でトラックリフレッシュ処理を行うべきでないと判定された場合には、CPU115は省電力状態に遷移するための省電力処理を実行するかを判定し、実行する必要があるならば当該処理を実行する(ステップ607)。省電力処理は、ヘッド102をディスク101上からアンロードさせるためのアンロード処理、及びまたは、SPM103の回転を停止させるSPM停止処理のような処理を含む。
ステップ607で省電力処理が実行されると、CPU115はステップ603に戻る。これに対し、ホストシステム200からのコマンドを即座に実行する必要がある場合には、ステップ607で省電力処理を実行すべきでないと判定される。この場合、CPU115は省電力処理を実行せずにステップ603に戻る。以後CPU115は、ステップ603を含む上述の処理を繰り返す。
次に、上記ステップ612の実シリンダ番号の算出処理(シリンダ番号の補正処理)の詳細な手順について、図7のフローチャートを参照して説明する。
上述のように、本実施形態で適用される仮想シリンダ番号は、各シリンダグループ内の予備シリンダを飛ばして数えられるシリンダ番号、つまり予備シリンダが存在しないとして数えられるシリンダ番号である。このため、仮想シリンダ番号を直接に実シリンダ番号に変換することはできない。そこでCPU115は、図7のフローチャートで示される実シリンダ番号の算出処理701において、まず、仮想シリンダ番号から、当該仮想シリンダ番号のシリンダ(仮想シリンダ)が属するシリンダグループのシリンダグループ番号と、当該仮想シリンダの当該シリンダグループにおけるオフセット(相対シリンダ位置)とを算出する(ステップ702)。
本実施形態では、シリンダグループ当たりの仮想シリンダ数は一定値であり、図3の例では10である。シリンダグループ番号は仮想シリンダ番号をこの一定値で割った商(整数値)、シリンダグループ内のオフセットはその余りとなる。例えば仮想シリンダ番号が34の場合、シリンダグループ番号(c)は34を10で割った商である3、オフセット(相対シリンダ位置、相対仮想シリンダ番号)はその余りである4となる。
次にCPU115は、ステップ702で算出された仮想シリンダのオフセット、即ちステップ702で算出されたシリンダグループ番号で示されるシリンダグループ内の相対仮想シリンダ番号から、以下に述べるように当該シリンダグループ内の相対実シリンダ番号を求める。
まずCPU115は、ステップ612に到達する前に求められているヘッド番号(h)とステップ702で算出されたシリンダグループ番号(c)とに基づき、トラックシフトテーブル500を参照することにより、予備シリンダ(トラック)の位置(シリンダグループ内相対シリンダ位置)S(h,c)を得る(ステップ703)。上述のようにシリンダグループ番号(c)が3の例で、更にヘッド番号(h)が1の場合、予備シリンダ(トラック)のシリンダグループ内相対シリンダ位置はS(1,3)となる。
相対実シリンダ番号は、トラックシフトテーブル500から取得された予備シリンダ(トラック)のシリンダグループ内相対シリンダ位置S(h,c)(=S(1,3))と仮想シリンダのシリンダグループ内オフセット(相対仮想シリンダ番号)との位置関係により求めることができる。具体的には、予備シリンダ(トラック)のシリンダグループ内相対シリンダ位置を示す値が相対仮想シリンダ番号(オフセット)よりも大きいかによって(ステップ704)、相対実シリンダ番号が求められる。
予備シリンダのシリンダグループ内相対シリンダ位置を示す値が相対仮想シリンダ番号(オフセット)よりも大きい場合(ステップ704がYES)、相対実シリンダ番号(実シリンダのシリンダグループ内相対シリンダ位置)は予備シリンダの影響を受けない。このため、相対仮想シリンダ番号と相対実シリンダ番号との間にずれは発生しない。つまり、予備シリンダが実シリンダよりも後方(シリンダ番号が大きい方)に存在する場合、相対仮想シリンダ番号と相対実シリンダ番号との間にずれは発生しない。この場合、相対実シリンダ番号は相対仮想シリンダ番号に等しい値となる。
これに対し、予備シリンダのシリンダグループ内相対シリンダ位置を示す値が相対仮想シリンダ番号(オフセット)以下の場合(ステップ704がNO)、相対実シリンダ番号は予備シリンダの影響を受ける。つまり、予備シリンダが実シリンダよりも後方に存在しない場合、相対実シリンダ番号は予備シリンダの影響を受けて、予備シリンダの分だけずれが生じる。この場合、相対実シリンダ番号は、相対仮想シリンダ番号に対して1だけ大きい値となる。
そこでCPU115は、上述の相対実シリンダ番号に対し、更にシリンダグループの先頭シリンダの実シリンダ番号、即ちシリンダグループ番号とシリンダグループ当たりの実シリンダ数との積(上述の例では3と11との積、つまり33)、を加算することによって求められる値を、実シリンダ番号として取得する(ステップ705または706)。
ここで、ステップ705は、ステップ704がNOの場合に実行され、相対実シリンダ番号には、ステップ702で取得された相対仮想シリンダ番号(オフセット)に1が加算された値が用いられる。上述の例では、S(1,3)が相対仮想シリンダ番号(オフセット)4以下の場合にステップ705が実行され、33に4と1とを加えることにより実シリンダ番号として38が取得される。
これに対し、ステップ706は、ステップ704がYESの場合に実行され、相対実シリンダ番号には、ステップ702で取得された相対仮想シリンダ番号(オフセット)がそのまま用いられる。上述の例では、S(1,3)が相対仮想シリンダ番号(オフセット)4より大きい場合にステップ706が実行され、33に4を加えることにより実シリンダ番号として37が取得される。
次に、上記ステップ606のトラックリフレッシュ処理の詳細な手順について、図8のフローチャートを参照して説明する。
CPU115は、図8のフローチャートで示されるトラックリフレッシュ処理801において、後述する実行中フラグを参照することにより、リフレッシュ処理が中断されているトラックグループが存在するかを判定する(ステップ802)。このステップ802は、トラックグループ内のデータリフレッシュされるべきトラック毎にリフレッシュ処理を中断できるようにしていることに関連する。
トラック毎にリフレッシュ処理を中断可能とする理由は、トラックグループ内の全てのトラック(但し予備トラックを除く)のデータをリフレッシュするには時間がかかるので、リフレッシュ処理の間に受信されたホストシステム200からのコマンドへの応答性を低下させないためである。つまり本実施形態では、リフレッシュ処理の実行中にホストシステム200からのコマンドが受信された場合、当該コマンドの実行を優先させるために、当該リフレッシュ処理が中断される。
リフレッシュ処理が中断されているトラックグループが存在するならば(ステップ802がYES)、そのことはリフレッシュの対象となるトラックグループが決まっていることを意味する。この場合、CPU115はステップ805以降のリフレッシュ処理を行う。
一方、リフレッシュ処理が中断されているトラックグループが存在しないならば(ステップ802がNO)、CPU115はリフレッシュ処理の対象となり得るトラックグループをライトカウントテーブル400に基づいて探す(ステップ803)。ここではCPU115は、ライトカウントテーブル400内で値の最も大きいライト回数W(h,c)を検索する。そしてCPU115は、検索されたライト回数W(h,c)が予め定められた一定値を超えているかによって、リフレッシュ処理が必要なトラックグループが存在するかを判定する(ステップ804)。
検索されたライト回数W(h,c)が一定値を超えている場合、CPU115は、リフレッシュ処理が必要なトラックグループが存在し、そのトラックグループが当該ライト回数W(h,c)と対応付けられているトラックグループ(ヘッド番号h、シリンダグループ番号cで表されるトラックグループ)であると判定する(ステップ804がYES)。このように、リフレッシュ処理が必要なトラックグループ(つまりリフレッシュ処理が行われるべきトラックグループ)が存在すると判定される場合、そのトラックグループ(つまり値の最も大きいライト回数W(h,c)と対応付けられているトラックグループ)も特定される。この場合、CPU115はステップ805以降のリフレッシュ処理を行う。
これに対し、検索されたライト回数W(h,c)が一定値以下の場合、CPU115は、リフレッシュ処理が必要なトラックグループは存在しないと判断する(ステップ804がNO)。この場合、リフレッシュ処理を行う必要はないので、CPU115はトラックリフレッシュ処理801から元の処理にリターンする(ステップ817)。これにより図6のフローチャートにおけるステップ607が実行される。
ところで、トラックリフレッシュ処理を実行するかの判定は、上記ステップ604及び605でも行われている。但し、ステップ604及び605では、先の説明から明らかなように、ステップ803及び804で行われるようなライトカウントテーブル400に基づく判定、即ちトラックリフレッシュ処理を行う必要があるトラックグループが存在するかの判定は行われない。
しかし、ステップ604及び605の段階でライトカウントテーブル400を参照する必要が生じるならば、この段階で、ステップ803及び804におけるのと同様の判定が行われる構成としてもよい。例えば、ステップ604及び605におけるリフレッシュ処理を実行するかの判定が、前述の振動及び温度のような環境条件に加えてトラックグループ毎のライト回数W(h,c)に基づいて行われる場合がこれに当たる。このような判定の詳細は次の通りである。まず、トラックグループへのライト回数が少ないうちは、一般にデータの劣化は少ない。このため、HDD100が悪条件下で用いられる場合には、リフレッシュ処理を実施するよりも当該リフレッシュ処理を回避した方がリスクが低いと判定される。これに対し、ライト回数が多くなるとデータの劣化が進む。このため、多少の悪条件でもリフレッシュ処理を行った方が逆にリスクが低くなると判定される。ステップ604及び605で、このような判定が行われるならば、当該ステップ604及び605で、ライト回数の最も多いトラックグループが特定されると共に、その回数が取得される。この場合、ステップ803及び804で再度これらが行われる必要はない。
さて、ステップ805が実行される段階では、トラックリフレッシュ処理が行われるべきトラックグループ(以下、ターゲットトラックグループと称する)は確定している。このためステップ805においてCPU115は、トラックシフトテーブル500を参照することにより、ターゲットトラックグループ内における予備トラックの相対位置S(h,c)を取得する。
ステップ802からステップ803及び804を介してステップ805に進んだ場合、当該ステップ805においてCPU115は、取得された予備トラックの相対位置S(h,c)に基づいて、ターゲットトラックグループを対象とするリフレッシュ処理の方向(リフレッシュ方向)を順方向とするか、或いは逆方向とするかを決定する。この決定の仕方については後述する。ステップ805においてCPU115は更に、トラックグループ単位のリフレッシュを管理するためのリフレッシュ管理情報をRAM113の所定の領域に格納する。
リフレッシュ管理情報は、トラックグループ番号、方向フラグ及び実行中フラグを含む。トラックグループ番号は、ステップ804で特定された、リフレッシュ処理の対象となるトラックグループ(つまりターゲットトラック)を示す。方向フラグは、トラックグループ番号で指定されるトラックグループを対象とするリフレッシュ処理の方向(リフレッシュ方向)が順方向であるか或いは逆方向であるかを示す。ここでは、方向フラグは、ステップ805で決定されたリフレッシュ方向を示す。実行中フラグは、トラックグループ番号で指定されるトラックグループを対象とするリフレッシュ処理が実行中(または中断中)であるかを示す。ここでは、実行中フラグはセットされており、実行中を示す。
これに対し、ステップ802からステップ805に分岐した場合、RAM113の所定の領域には後述するように有効なリフレッシュ管理情報が既に格納されている。このリフレッシュ管理情報に含まれている実行中フラグはセットされており、実行中(中断中)を示す。また、リフレッシュ管理情報に含まれている方向フラグは、実行中(中断中)のリフレッシュ処理の方向を示す。
ステップ805以降の処理は、ターゲットトラックグループを対象とするリフレッシュ処理を順方向で行うか、或いは逆方向で行うかによって処理が分かれる。
そこでCPU115は、RAM113に格納されているリフレッシュ管理情報に含まれている方向フラグを参照することにより、当該管理情報に含まれているトラックグループ番号で指定されるトラックグループ(ターゲットトラックグループ)を対象とするリフレッシュ処理を順方向で行うかを判定する(ステップ806)。
本実施形態ではリフレッシュが中断されているトラックグループが存在するならば、当該トラックグループを対象とするリフレッシュ処理が優先して行われる。このため、同時に複数のトラックグループがリフレッシュ処理中になることはない。このことから、リフレッシュ管理情報は、HDD100全体で1つのみ存在する。
上述のように、リフレッシュ管理情報はRAM113に格納される。このためリフレッシュ管理情報は、HDD100の電源の遮断により失われる。そこで、本実施形態においてリフレッシュ管理情報は、ライトカウントテーブル400と同様に、例えばHDD100の省電力状態への移行時にディスク101の所定の領域に保存される。ディスク101の所定の領域に保存されたリフレッシュ管理情報は、HDD100の起動時(電源投入時)に実行される初期化処理で読み出されて、RAM113内に復元される。
しかし、不意の電源遮断が発生した場合には、その時点における最新のリフレッシュ管理情報は失われてしまう。そこでCPU115は、最新のリフレッシュ管理情報が失われたかを、つまり復元されたリフレッシュ管理情報は正しいかを、フラッシュROM114に保存されているトラックシフトテーブル500に基づいて、電源投入時の起動処理の中で次のように確認する。
まずCPU115は、トラックシフトテーブル500に保持されているトラックグループ毎の予備トラックの相対位置(相対トラック位置)S(h,c)を参照することにより、予備トラックの相対位置S(h,c)が当該トラックグループの先頭位置(最外周)でも最終位置(最内周)でもないトラックグループを探す(特定する)。特定されたトラックグループは、今回の電源投入に先行して発生した電源遮断時にリフレッシュ処理の対象となっていたトラックグループである。
そこでCPU115は、特定されたトラックグループのトラックグループ番号が、RAM113に復元されたリフレッシュ管理情報に含まれているトラックグループ番号に一致するかを判定する。もし、一致しているならば、CPU115は、復元されたリフレッシュ管理情報は正しく、最新のリフレッシュ管理情報は失われていないと判定する。
これに対し、一致していないならば、CPU115は、復元されたリフレッシュ管理情報は誤っており、最新のリフレッシュ管理情報は失われていると判定する。この場合、CPU115は、特定されたトラックグループを対象に、順方向または逆方向、いずれのリフレッシュを行うかを決定する。
このリフレッシュの方向は、順方向または逆方向のいずれに決定されても構わない。本実施形態では、この方向を決定するのに、特定されたトラックグループにおける予備トラックの相対位置S(h,c)が用いられる。更に具体的に述べるならば、順方向のリフレッシュ及び逆方向のリフレッシュをそれぞれ前提とした場合に、予備トラックの相対位置S(h,c)から求められるリフレッシュされるべきトラックの数Nf及びNbの大小関係が用いられる。ここでは、NfがNb以下であるならば順方向のリフレッシュが決定され、NbがNf未満ならば逆方向のリフレッシュが決定される。
決定されたリフレッシュ方向は、本来の方向と異なっている可能性がある。そこで本実施形態では、上記特定されたトラックグループを対象とする全てのリフレッシュが完了しても、当該トラックグループと対応付けられているライト回数(ライトカウンタ)W(h,c)が後述するステップ816でクリアされないように構成されている。これにより、上記特定されたトラックグループを対象とするリフレッシュが完了すると、当該トラックグループを対象とするリフレッシュ処理が、リフレッシュ方向を切り替えて続けて実行される。
なお、フラッシュROM114に保存されるトラックシフトテーブル500に保持されている、トラックグループ毎の予備トラックの相対位置S(h,c)に、リフレッシュ方向を示す例えば1ビットの方向フラグD(h,c)が付加される構成とすることも可能である。つまり、トラックシフトテーブル500により、トラックグループ毎の予備トラックの相対位置S(h,c)及び方向フラグD(h,c)を保持する構成としてもよい。このような構成を適用するならば、トラックグループ当たり1ビットの情報を追加するだけで、電源遮断時に実行されていたリフレッシュ処理の方向を特定することができる。このため、上述のような、リフレッシュ方向の決定を伴う電源遮断対策が不要となる。
さて上記ステップ805において、RAM113の所定の領域に有効なリフレッシュ管理情報が格納されているならば、CPU115は、当該リフレッシュ管理情報に含まれている方向フラグの状態に基づいてリフレッシュ処理の方向を判定すればよい。ステップ802からステップ805に分岐した場合は、このような状態となる。
しかし、RAM113の所定の領域に有効なリフレッシュ管理情報が格納されていないならば、つまりリフレッシュ管理情報がクリアされているならば、そのことは新たにトラックリフレッシュを行うことを意味することから、リフレッシュ処理の方向を調べる必要がある。ステップ802からステップ803及び804を介してステップ805に進んだ場合は、このような状態となる。この場合、ステップ805で取得される、ターゲットトラックグループ内の予備トラックの相対位置S(h,c)は、必ず当該トラックグループの先頭位置(最外周)または最終位置(最内周)のいずれかにある。
そこで、ターゲットトラックグループ内の予備トラックの相対位置S(h,c)が当該トラックグループの最内周にあるならば、CPU115は、当該トラックグループを対象とするリフレッシュ処理の方向を順方向とすることを決定する(ステップ805)。これに対し、ターゲットトラックグループ内の予備トラックの相対位置S(h,c)が当該トラックグループの最外周にあるならば、CPU115は、当該トラックグループを対象とするリフレッシュ処理の方向を逆方向とすることを決定する(ステップ805)。ステップ805においてCPU115は、決定されたリフレッシュ方向を示す方向フラグが含まれたリフレッシュ管理情報を、RAM113の所定の領域に格納する。
CPU115はステップ805を実行すると、上述のように、RAM113に格納されているリフレッシュ管理情報に含まれている方向フラグを参照することにより、リフレッシュ処理の方向が順方向であるかを判定する(ステップ806)
まず、ステップ806で判定されたリフレッシュ処理の方向が順方向である場合について説明する。この場合、CPU115は、予備トラックにディスク101上の外周側で隣接するトラックをリフレッシュの対象となるトラック(ターゲットトラック)として、当該隣接するトラックのデータをヘッド102により読み出すためのデータ読み出し制御をHDC110を介して実行する(ステップ810)。次にCPU115は、読み出されたデータを、予備トラックに書き込むためのデータ書き込み制御をHDC110を介して実行する(ステップ811)。これにより、予備トラックに外周側で隣接するトラック(ターゲットトラック)のデータが、当該予備トラック上でリフレッシュされる。
CPU115は、ターゲットトラックのデータの予備トラックへの書き込み(ステップ811)が正常に終了したことを確認すると、トラックシフトテーブル500に保持されている、現在リフレッシュ対象となっているトラックグループ内における予備トラックの相対位置S(h,c)を1トラック分ディスク101の外周側にずらす(ステップ812)。これにより、予備トラックが切り替えられる。このトラックシフトテーブル500の更新(予備トラックの切り替え)をもって1トラック分のリフレッシュが完了する。
トラックシフトテーブル500の更新(ステップ812)の直前、直後のいずれの状態においても、ターゲットトラックに書き込まれていたデータは、当該トラック(元のトラック)と、当該トラックのデータの書き込み先(当該トラックにディスク101上の内周側で隣接するトラック)の両方に存在する。しかし、ターゲットトラックのデータの予備トラックへの書き込み(ステップ811)が正常に終了した場合、これら両トラックに同一データが存在する必要はない。
そこで、上記ステップ812では、トラックシフトテーブル500の更新直前にターゲットトラックとして扱われていたトラックが新たな予備トラックに切り替えられるように、上述のように予備トラックの相対位置S(h,c)が1トラック分外周側にずらされる。ここで新たな予備トラックとなったトラックには、次回のリフレッシュ処理(ステップ810,811)で、当該新たな予備トラックにディスク101上の外周側で隣接するトラックのデータが書き込まれることになる。なお、トラックシフトテーブル500(フラッシュROM114に保存されているトラックシフトテーブル500)の更新が、前述のように更新中の電源遮断に配慮した形で行われるならば、更新中の電源遮断によって予備トラックの切り替えに失敗することはない。
CPU115は1トラック分のリフレッシュが完了すると、リフレッシュ処理の中断要求があるかを判定する(ステップ813)。ホストシステム200からのコマンドの受信は、リフレッシュ処理の中断要求を判定する条件の1つである。HDC110内のホストブロック123がホストシステム200からコマンドを受信すると、当該ホストブロック123のハードウェアの機能によりHDD100は即座にビジー状態に遷移する。同時に、このビジー状態を表すフラグ(ビジーフラグ)がセットされる。そこでCPU115は、ステップ813でビジーフラグの状態をチェックする。
なお、ビジーフラグのセットはリフレッシュ動作が実行中であるかに関係なく行われる。したがって、ホストシステム200から認識されるコマンドの応答時間は、当該コマンドを発行してからその際に実行中のリフレッシュが完了するまでの時間と本来のコマンド実行時間との合計となる。このことから、ホストシステム200からのコマンドが受信された場合に、ターゲットトラックグループを対象とする全てのリフレッシュが終わるまで待つと、当該コマンドへの応答性を低下させてしまう。
そこで本実施形態では、コマンドへの応答性の低下を回避するために、1トラック分のリフレッシュが完了する毎に、上述のようにリフレッシュ処理の中断要求があるかが判定される(ステップ813)。そして、1トラック分のリフレッシュの実行中にホストシステム200からのコマンドが受信された場合のように、リフレッシュ処理の中断要求があるならば(ステップ813がYES)、CPU115はステップ817に分岐し、速やかにリフレッシュ処理を中断させてステップ606(図6参照)を終了させる。CPU115はステップ606を終了させるとステップ607を実行する。このステップ607においても、CPU115は、速やかにステップ603に分岐させてホストシステム200からのコマンドのための処理を開始させるため、ステップ813と同様な処理を行う。
一方、リフレッシュ処理の中断要求がない場合(ステップ813がNO)、CPU115は、ターゲットトラックグループを対象とするリフレッシュを全て完了したかを判定する(ステップ814)。この判定は、新たな予備トラックの相対位置S(h,c)がターゲットトラックグループ内の先頭位置(最外周)にあるかによって行われる。その理由は、リフレッシュ方向が順方向である場合、予備トラックの相対位置S(h,c)がターゲットトラックグループ内の先頭位置(最外周)になったときが、当該グループ内の全トラックに対するリフレッシュの完了を意味するためである。
もし、新たな予備トラックの相対位置S(h,c)がターゲットトラックグループ内の先頭位置(最外周)になく、したがって当該グループ内の全トラックに対するリフレッシュが完了していなければ(ステップ814がNO)、CPU115はステップ810に分岐して、新たなターゲットトラック、つまり新たな予備トラックにディスク101上の外周側で隣接するトラックを対象としたリフレッシュを行う。これに対し、ターゲットトラックグループ内の全トラックに対するリフレッシュが完了しているならば(ステップ814がYES)、CPU115はステップ815に分岐することでステップ810乃至814の処理ループ(トラックグループ処理ループ)を抜ける。
次に、ステップ806で判定されたリフレッシュ方向が逆方向である場合について簡単に説明する。この場合、CPU115は、ステップ820乃至824の処理を行う。これらステップ820乃至824は、それぞれステップ810乃至814の順方向のリフレッシュ処理に対応した逆方向のリフレッシュ処理であり、方向が逆転する以外は順方向のリフレッシュ処理と同様である。逆方向のリフレッシュ処理で新たな予備トラックの相対位置S(h,c)がターゲットトラックグループ内の最終位置(最内周)になった結果、当該グループ内の全トラックに対するリフレッシュの完了が判定されると(ステップ824)、CPU115はステップ815に分岐することでステップ820乃至824の処理ループを抜ける。
ステップ815においてCPU115は、ターゲットトラックグループを対象とするリフレッシュ処理が完了し、現在処理中のトラックグループがないことを表すため、RAM113に格納されているリフレッシュ管理情報をクリアする。このリフレッシュ管理情報のクリアにより、その後ステップ802及びステップ806での判定を正しく行うことが可能となる。
次にCPU115は、リフレッシュ処理が完了したトラックグループに対応付けてライトカウントテーブル400に保持されているライト回数W(h,c)を、0に初期化(つまりクリア)する(ステップ816)。ライトカウントテーブル400に保持されているトラックグループ毎のライト回数W(h,c)は、そのトラックグループへのライト動作の実行回数を示す。ライト回数W(h,c)は、当該ライト回数W(h,c)と対応付けられているトラックグループにおけるデータの劣化の程度と相関がある。そのため本実施形態では、ライト回数W(h,c)は便宜的にデータ劣化の程度として扱われる。トラックグループを対象とするリフレッシュ処理が完了した直後は、当該グループにおけるデータの劣化はない。このことを、リフレッシュ処理が完了したトラックグループに対応付けられたライト回数W(h,c)に反映させるために、上述のように当該ライト回数W(h,c)が0に初期化される。
CPU115は、ステップ816を実行すると、再びステップ802に分岐して次のトラックグループに対する処理を開始する。この場合、ステップ802からの分岐先は常にステップ803になり、リフレッシュを必要とするトラックグループを検索するための動作を含む処理が上述の場合と同様に行われる。リフレッシュ処理の中断要求がなければ、トラックグループを対象とするリフレッシュ処理(トラックリフレッシュ処理)が終了するのは、それを必要とするトラックグループがなくなった場合のみである(ステップ804がNO)。
[第1の変形例]
次に上記実施形態の第1の変形例について説明する。第1の変形例の特徴は、トラックシフトテーブル500が、ライトカウントテーブル400と同様にRAM113に格納される点にある。このような構成は、例えば、図1に示されるフラッシュROM114が頻繁にデータの書き換えが行えないか、或いはフラッシュROM114に代えて、書き換えが不可能なROMが用いられる場合に必須となる。
第1の変形例でにおいても、図8のフローチャートに従うトラックリフレッシュ処理が実行される。但し第1の変形例では、例えばステップ805の直後に、CPU115の制御により、RAM113に格納されているリフレッシュ管理情報及びトラックシフトテーブル500がディスク101の所定の領域に保存される。このときリフレッシュ管理情報に含まれている実行中フラグはセットされており、当該管理情報に含まれているトラックグループ番号で指定されるトラックグループを対象とするリフレッシュ処理の実行中であることを示す。また第1の変形例では、例えばステップ816の直後に、CPU115の制御により、ディスク101の上記領域に保存されているリフレッシュ管理情報に含まれている実行中フラグがリセットされる。しかる後に、その時点においてRAM113に格納されているトラックシフトテーブル500が、ディスク101の上記領域に保存される。
第1の変形例によれば、リフレッシュ処理の実行中に不意の電源遮断が発生しても、その次のHDD100の起動時に、ディスク101の所定の領域に、実行中を示す実行中フラグが残っているかをチェックすることで、それを検知できる。
さて、ディスク101の各トラックに配置される各セクタに書き込まれるデータには、HDC110によりECC(Error Correcting Code: エラー訂正符号)データが付加されるのが一般的である。第1の変形例では、このECCデータのシード値として、当該ECCデータが付加されるセクタが配置されるトラックの仮想シリンダ番号に基づいて生成される値が使用される。更に具体的に述べるならば、ECCデータのシード値として、当該ECCデータが付加されるセクタが配置されるトラックの仮想シリンダ番号及びヘッド番号と、当該セクタのセクタ番号とに基づいて生成される値、例えば仮想シリンダ番号、ヘッド番号及びセクタ番号が連結された値が使用される。
このように、仮想シリンダ番号がECCデータのシード値の生成に用いられる構成では、たとえトラックシフトテーブル500に保持されている予備セクタの相対位置が誤っていても、HDC110において、その誤りを検出できる。その理由は次の通りである。まず、誤った予備セクタに隣接するトラックのデータがステップ810または820で読み出されるものとする。この場合、シード値が異なるのでHDC110においてECCエラー(シードエラー)となる。これにより、予備セクタの相対位置が誤っていることが検出できる。
さて、HDD100の起動時に、ディスク101の所定の領域に、実行中を示す実行中フラグが残っているものとする。この場合、CPU115は、リフレッシュ処理の実行中に不意の電源遮断が発生したことを判定(検知)する。ディスク101の所定の領域に保存されている、上記実行中フラグを含むリフレッシュ管理情報と、トラックシフトテーブル500とは、ディスク101の所定の領域から読み出されてRAM113の所定の領域に格納(復元)される。
ここで、不意の電源遮断が発生した際にリフレッシュ処理が実行されていたトラックグループに対応付けてトラックシフトテーブル500に保持されている予備トラックの相対位置は、当該電源遮断のために誤っている可能性がある。そこで第1の変形例では、予備トラックの相対位置が誤っている場合、以下に述べるように正しい相対位置に訂正される。
まず、RAM113の所定の領域に格納されたトラックシフトテーブル500から、電源遮断が発生した際にリフレッシュ処理が実行されていたトラックグループに対応付けられている予備トラックの相対位置が取得される。このトラックグループは、RAM113の所定の領域に格納されたリフレッシュ管理情報に含まれているトラックグループ番号によって示される。
次に、ターゲットトラックグループ内の各トラックを対象に、仮想シリンダ番号が実シリンダ番号と同じであると仮定してデータ読み出し動作が行われる。このデータ読み出し動作により、シード値が合致しているトラックとそうでないトラック(シードエラーが発生しているトラック)との境界が特定される。この境界に隣接する2つのトラックのうち、シードエラーが発生しているトラックが、正しい予備トラックとして決定される。決定された予備トラックの相対位置が、トラックシフトテーブル500から取得された予備トラックの相対位置と異なるならば、当該取得された予備トラックの相対位置は誤っている。この場合、CPU115は、トラックシフトテーブル500に保持されている、誤っている予備トラックの相対位置の値を、上記決定された予備トラックの相対位置の値に訂正する。
ここで、ターゲットトラックグループ内の各トラックからのデータの読み出しの順序の決定には、探索を早く行うために二分検索が用いられる。トラック内の読み出されるべきセクタについては特に制約はなく、例えば、当該トラック内の予め定められた相対位置のセクタであってもよい。また、トラック内で回転待ちが最も少なくなるセクタが動的に選択されてもよい。
第1の変形例によれば、不意の電源遮断が発生しても、その次のHDD100の起動時に、そのことを検知できる。しかも第1の変形例によれば、トラックシフトテーブル500をフラッシュROMに格納しなくても、トラックシフトテーブル500に保持されている予備トラックの相対位置の情報を復元できる。したがって第1の変形例によれば、フラッシュROM114がトラックシフトテーブル500を格納するのに利用できなくても、或いはフラッシュROM114を有していないHDDであっても、トラックシフトテーブル500に基づくリフレッシュ処理を実現できる。
[第2の変形例]
次に上記実施形態の第2の変形例について説明する。第2の変形例の特徴は、逆方向のリフレッシュ処理における回転待ち時間の短縮のために、リフレッシュの単位(つまりリフレッシュのためのデータの読み出し/書き込みの単位)を最適化するようにした点にある。
図9は逆方向のリフレッシュ処理による回転待ち時間の短縮を目的とした、リフレッシュの単位の最適化についての概念図である。
図9に示されるように、ディスク101に配置される互いに隣接するトラックの間にはそのトラック内の先頭セクタの位置を調整するための、トラックスキューがかけられている。トラックスキューの値は、順方向アクセス、即ちLBAが増加する方向へのシーケンシャルアクセスでの回転待ち時間が最小になるように決められる。つまり、ディスク101上のあるトラックの最終セクタをアクセスした後、ヘッド102を次の(隣接する)トラックへ移動させるのに要する時間がトラックスキューの最小値となる。
このことから、トラックリフレッシュが順方向に行われる場合にはトラックスキューが最適化されていることになり、回転待ち時間は少ない。しかし、逆方向にトラックリフレッシュが行われると、回転待ち時間が著しく増加する。
図9(a)は、逆方向のトラックリフレッシュ(つまりリフレッシュの単位が上記実施形態のように1トラックの場合に行われる逆方向のリフレッシュ処理)において、ヘッド102がディスク101上に描く軌跡を表す。図9(a)に示されるように、逆方向のトラックリフレッシュでは、ヘッド102はディスク101上に、軌跡903、軌跡902及び軌跡901を順次描く。
軌跡903は、ターゲットトラックからデータを読み出すための読み出し動作(リードアクセス)におけるヘッド102が描く軌跡を示し、軌跡901は読み出されたデータを予備トラックへ書き込むための書き込み動作(ライトアクセス)におけるヘッド102が描く軌跡を示す。ここでは、軌跡902の長さに相当する長い回転待ち時間が発生する。
第2の変形例では、図9(a)における軌跡902のような回転待ち時間を短縮するために、リフレッシュの単位(1回のリフレッシュ処理当たりのリフレッシュ量)が最適化される。図9(b)は、その一例として、リフレッシュの単位が1トラックを超えて2トラック以下に最適化された場合に行われる逆方向のリフレッシュ処理において、ヘッド102がディスク101上に描く軌跡を表す。図9(b)の例では、ヘッド102はディスク101上に、軌跡913、軌跡912及び軌跡911を順次描く。
軌跡913は、ターゲットトラックからデータを読み出すためのリードアクセスにおけるヘッド102が描く軌跡を示し、軌跡911は読み出されたデータを予備トラックへ書き込むためのライトアクセスにおけるヘッド102が描く軌跡を示す。軌跡912の長さに相当する回転待ち時間は、図9(a)の例(1トラック単位のリフレッシュ)における軌跡902の長さに相当する回転待ち時間に比べて短縮されている。
トラックスキューの値によっては、リフレッシュの単位を、1トラック未満とする方がよいこともあり、このような最適化も可能である。図9(c)は、このようなリフレッシュの単位が1トラック未満に最適化された場合に行われる逆方向のリフレッシュ処理において、ヘッド102がディスク101上に描く軌跡を表す。図9(c)の例では、ヘッド102はディスク101上に、軌跡923、軌跡922及び軌跡921を順次描く。
軌跡923は、ターゲットトラックからデータを読み出すためのリードアクセスにおけるヘッド102が描く軌跡を示し、軌跡921は読み出されたデータを予備トラックへ書き込むためのライトアクセスにおけるヘッド102が描く軌跡を示す。軌跡922の長さに相当する回転待ち時間は、図9(a)の例における軌跡902の長さに相当する回転待ち時間に比べて短縮されている。また、リフレッシュの単位を大きくすると、その大きさに応じてバッファRAM111内に大きなバッファ領域を確保する必要が生じる。そこで、このバッファ領域を減らす目的でリフレッシュの単位を小さくしてもよい。
次に、リフレッシュの単位の具体的な算出方法について述べる。
上述のように、図9(b)はリフレッシュの単位が1トラックを超えて2トラック以下に最適化された場合に行われる逆方向のリフレッシュ処理において、ヘッド102がディスク101上に描く軌跡を表す。1トラック及び2トラックは、それぞれ、ディスク101の1回転及び2回転に相当する。したがって、リフレッシュの単位が1トラックを超えて2トラック以下を、リフレッシュの単位がディスク101の1回転を超えて2回転以下と言い換えることも可能である。
ここで、ディスク101の単位時間(1秒)当たりの回転数をf[回転/s]、xトラックに渡るディスク101の移動(シーク動作)に必要な時間をtx[s]とする。また、軌跡913に相当する(軌跡913を描くのに必要な)アクセス量、つまりリフレッシュの単位を、ディスク101の回転数u[回転]で表す。但し、uは、リフレッシュの単位の前提条件から、1<u≦2である。
次に、軌跡912(回転待ち時間)に相当するディスク101の回転数をw[回転]とする。txはヘッド102の物理的な移動に要する時間のみでなく、ヘッド102の移動先でのリード・ライトアクセスのためのセットアップの時間も含む。トラックスキューは1トラック(x=1)のシークに必要な時間t1[s]に等しい。この時間t1[s]におけるディスク101の回転数は、ft1で表される。つまりトラックスキューは回転数ft1に相当する。
このとき、図9(b)から、軌跡913及び912にそれぞれ対応するリードアクセス及び回転待ち時間のために、ディスク101の2回転からトラックスキューに相当する回転数ft1を減じただけの回転数を要することがわかる。したがって、次式
u+w+ft1 =2 (1)
が成立する。
また、図9(b)から、wは2トラックに渡るヘッド102の移動に要する回転数を少なくとも必要とすることがわかる。但し、軌跡913の開始位置が、図9(b)の例とは異なって、例えば先頭トラックの終端側にある場合のように、軌跡913の開始位置によっては、トラック渡りが2度発生する可能性、すなわち軌跡913が3トラックに渡る可能性もある。このため、wは次式
w≧ft3 (2)
に示される制約を受ける。wがこの制約を満たさない場合、1回転余分に回転待ちが発生する。
上記(1)式及び(2)式と、リフレッシュの単位u[回転]の前提条件1<u≦2とから、リフレッシュの単位u[回転]を、次式
1<u≦2−f(t1+t3)[回転] (3)
のように求めることができる。ここでは、等号が成立する場合(つまりu=2−f(t1+t3)の場合)が最も効率がよく、これ(2−f(t1+t3))を超えない範囲でリフレッシュの単位を決めればよい。
なお、図9(b)の例では、軌跡911に相当するライトアクセスが完了したら次のリフレッシュの単位を対象とするリフレッシュ処理が開始され、リードアクセスが行われる。このリードアクセスの開始位置は、軌跡913に相当するリードアクセスが完了した位置となる。軌跡911に相当するライトアクセスでのアクセス量は、軌跡913に相当するリードアクセスでのそれに等しい。したがって、軌跡911に相当するライトアクセスが完了した位置から次のリードアクセスの開始位置にヘッド102を移動させるためのシーク動作に要するディスク101の回転数は、トラックスキューに相当する回転数ft1に等しい。このため、最小の回転待ち時間で次のリフレッシュの単位に移行できる。
次に図9(c)は、上述のように、リフレッシュの単位が1トラック未満(1回転未満)に最適化された場合に行われる逆方向のリフレッシュ処理において、ヘッド102がディスク101上に描く軌跡を表す。この場合も、リフレッシュの単位が1トラック(1回転)を超える場合と同様に、リフレッシュの単位u[回転]を、次式
0<u≦1−f(t1+t2)[回転] (4)
のように求めることができる。
リフレッシュの単位の最適化を、より一般的に表すために、kを1以上の整数として、リフレッシュの単位を(k−1)回転を超え、k回転以下に最適化する場合を想定する。この場合、リフレッシュの単位u[回転]を、次式
k−1<u≦k−f(t1+tk+1)[回転] (5)
のように求めることができる。つまり、リフレッシュの単位uは、t1にtk+1を加算した値(t1+tk+1)に基づいて決定される。ここで、t1は上述のようにトラックスキューの値に相当し、tk+1はリードアクセスが完了した位置から当該リードアクセスで読み出されたデータを書き込むためのライトアクセスの開始位置にヘッド102を移動させるのに必要な時間に相当する。
例えば、f=5400[rpm]=90[回転/s]、t1=2.0[ms]、t2=2.2[ms]、t3=2.4[ms]のHDD100であれば、kが1の場合には、
0<u≦1−90×(2.0+2.2)×10-3=0.622[回転]
となる。また、kが2の場合には、
1<u≦2−90×(2.0+2.4)×10-3=1.604[回転]
となる。
いずれの場合とも、1回のリフレッシュでのアクセス量を、これらの回転数を超えずにアクセスすることが可能なセクタ(ブロック)数にすればよい。セクタ数の算出にあたっては、アクセス範囲に含まれるトラック渡り部分にはアクセス可能なセクタがないことを考慮する必要がある。
なお、本発明は、上記実施形態またはその変形例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態またはその変形例に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態またはその変形例に示される全構成要素から幾つかの構成要素を削除してもよい。