(57)【要約】【課題】電源遮断に対処しつつ、データリフレッシュ処理の効率が低下するのを防止する。【解決手段】フラッシュＲＯＭ１１４は、ディスク１０１上に確保された予備トラックの位置を示す位置情報を保持する。ＣＰＵ１１５は、ディスク１０１上のリフレッシュされるべきトラックのデータをヘッド１０２により読み出して、当該読み出されたデータを前記位置情報の示す予備トラックに前記ヘッドにより書き込むためのリフレッシュ制御を行う。そしてＣＰＵ１１５は、前記データが読み出された前記トラックを新たな予備トラックに切り替えるために、前記位置情報を前記データが読み出された前記トラックの位置を示すように更新する。【選択図】      図１
2010182406.tif 000002
【特許請求の範囲】
【請求項１】
データリフレッシュを行う磁気ディスク装置において、
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループが設けられる磁気ディスクと、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータが前記第１の予備データトラックに移動されるように制御するコントローラと
を具備することを特徴とする磁気ディスク装置。
【請求項２】
データリフレッシュを行う磁気ディスク装置において、
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループおよび、データリフレッシュに用いられる第２の予備データトラックと複数のデータトラックを備える第２のデータトラックグループが設けられる磁気ディスクと、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータが前記第１の予備データトラックに移動され、前記第２のデータトラックグループ内において、前記第２の予備データトラックに隣接するデータトラックに記録されているデータが前記第２の予備データトラックに移動されるように制御するコントローラと
を具備することを特徴とする磁気ディスク装置。
【請求項３】
データリフレッシュを行う磁気ディスク装置において、
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループが設けられる磁気ディスクと、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータが前記第１の予備データトラックに移動され、これに応じて前記隣接データトラックが次の第１の予備データトラックとなるように制御するコントローラと
を具備することを特徴とする磁気ディスク装置。
【請求項４】
データリフレッシュを行う磁気ディスク装置において、
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループおよび、データリフレッシュに用いられる第２の予備データトラックと複数のデータトラックを備える第２のデータトラックグループが設けられる磁気ディスクと、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータが前記第１の予備データトラックに移動され、これに応じて前記隣接データトラックが次の第１の予備データトラックとなり、前記第２のデータトラックグループ内において、前記第２の予備データトラックに隣接するデータトラックに記録されているデータが前記第２の予備データトラックに移動され、これに応じて前記隣接データトラックが次の第２の予備データトラックとなるように制御するコントローラと
を具備することを特徴とする磁気ディスク装置。
【請求項５】
データリフレッシュを行う磁気ディスク装置において、
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループが設けられる磁気ディスクと、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータが前記第１の予備データトラックに移動され、これに応じて前記隣接データトラックが次の第１の予備データトラックとなる切り替えが繰り返されて、第１の予備データトラックが順に移動されるように制御するコントローラと
を具備することを特徴とする磁気ディスク装置。
【請求項６】
データリフレッシュを行う磁気ディスク装置において、
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループおよび、データリフレッシュに用いられる第２の予備データトラックと複数のデータトラックを備える第２のデータトラックグループが設けられる磁気ディスクと、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータが前記第１の予備データトラックに移動され、これに応じて前記隣接データトラックが次の第１の予備データトラックとなる切り替えが繰り返されて、第１の予備データトラックが順に移動され、前記第２のデータトラックグループ内において、前記第２の予備データトラックに隣接するデータトラックに記録されているデータが前記第２の予備データトラックに移動され、これに応じて前記隣接データトラックが次の第２の予備データトラックとなる切り替えが繰り返されて、第２の予備データトラックが順に移動されるように制御するコントローラと
を具備することを特徴とする磁気ディスク装置。
【請求項７】
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループが設けられる磁気ディスクに記録されているデータのリフレッシュを制御するコントローラであって、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータが前記第１の予備データトラックに移動されるように制御する制御手段を具備することを特徴とするコントローラ。
【請求項８】
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループおよび、データリフレッシュに用いられる第２の予備データトラックと複数のデータトラックを備える第２のデータトラックグループが設けられる磁気ディスクに記録されているデータのリフレッシュを制御するコントローラであって、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータが前記第１の予備データトラックに移動され、前記第２のデータトラックグループ内において、前記第２の予備データトラックに隣接するデータトラックに記録されているデータが前記第２の予備データトラックに移動されるように制御する制御手段を具備することを特徴とするコントローラ。
【請求項９】
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループが設けられる磁気ディスクに記録されているデータのリフレッシュを制御するコントローラであって、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータが前記第１の予備データトラックに移動され、これに応じて前記隣接データトラックが次の第１の予備データトラックとなるように制御する制御手段を具備することを特徴とするコントローラ。
【請求項１０】
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループおよび、データリフレッシュに用いられる第２の予備データトラックと複数のデータトラックを備える第２のデータトラックグループが設けられる磁気ディスクに記録されているデータのリフレッシュを制御するコントローラであって、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータが前記第１の予備データトラックに移動され、これに応じて前記隣接データトラックが次の第１の予備データトラックとなり、前記第２のデータトラックグループ内において、前記第２の予備データトラックに隣接するデータトラックに記録されているデータが前記第２の予備データトラックに移動され、これに応じて前記隣接データトラックが次の第２の予備データトラックとなるように制御する制御手段を具備することを特徴とするコントローラ。
【請求項１１】
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループが設けられる磁気ディスクに記録されているデータのリフレッシュを制御するコントローラであって、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータが前記第１の予備データトラックに移動され、これに応じて前記隣接データトラックが次の第１の予備データトラックとなる切り替えが繰り返されて、第１の予備データトラックが順に移動されるように制御する制御手段を具備することを特徴とするコントローラ。
【請求項１２】
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループおよび、データリフレッシュに用いられる第２の予備データトラックと複数のデータトラックを備える第２のデータトラックグループが設けられる磁気ディスクに記録されているデータのリフレッシュを制御するコントローラであって、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータが前記第１の予備データトラックに移動され、これに応じて前記隣接データトラックが次の第１の予備データトラックとなる切り替えが繰り返されて、第１の予備データトラックが順に移動され、前記第２のデータトラックグループ内において、前記第２の予備データトラックに隣接するデータトラックに記録されているデータが前記第２の予備データトラックに移動され、これに応じて前記隣接データトラックが次の第２の予備データトラックとなる切り替えが繰り返されて、第２の予備データトラックが順に移動されるように制御する制御手段を具備することを特徴とするコントローラ。
【請求項１３】
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループが設けられる磁気ディスクを具備する磁気ディスク装置におけるデータリフレッシュ方法であって、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータを前記第１の予備データトラックに移動することを特徴とするデータリフレッシュ方法。
【請求項１４】
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループおよび、データリフレッシュに用いられる第２の予備データトラックと複数のデータトラックを備える第２のデータトラックグループが設けられる磁気ディスクを具備する磁気ディスク装置におけるデータリフレッシュ方法であって、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータを前記第１の予備データトラックに移動し、
前記第２のデータトラックグループ内において、前記第２の予備データトラックに隣接するデータトラックに記録されているデータを前記第２の予備データトラックに移動する
ことを特徴とするデータリフレッシュ方法。
【請求項１５】
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループが設けられる磁気ディスクを具備する磁気ディスク装置におけるデータリフレッシュ方法であって、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータを前記第１の予備データトラックに移動し、これに応じて前記隣接データトラックを次の第１の予備データトラックとすることを特徴とするデータリフレッシュ方法。
【請求項１６】
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループおよび、データリフレッシュに用いられる第２の予備データトラックと複数のデータトラックを備える第２のデータトラックグループが設けられる磁気ディスクを具備する磁気ディスク装置におけるデータリフレッシュ方法であって、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータを前記第１の予備データトラックに移動し、これに応じて前記隣接データトラックを次の第１の予備データトラックとし、
前記第２のデータトラックグループ内において、前記第２の予備データトラックに隣接するデータトラックに記録されているデータを前記第２の予備データトラックに移動し、これに応じて前記隣接データトラックを次の第２の予備データトラックとする
ことを特徴とするデータリフレッシュ方法。
【請求項１７】
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループが設けられる磁気ディスクを具備する磁気ディスク装置におけるデータリフレッシュ方法であって、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータを前記第１の予備データトラックに移動し、これに応じて前記隣接データトラックを次の第１の予備データトラックとする切り替えを繰り返して、第１の予備データトラックを順に移動することを特徴とするデータリフレッシュ方法。
【請求項１８】
データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループおよび、データリフレッシュに用いられる第２の予備データトラックと複数のデータトラックを備える第２のデータトラックグループが設けられる磁気ディスクを具備する磁気ディスク装置におけるデータリフレッシュ方法であって、
前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータを前記第１の予備データトラックに移動し、これに応じて前記隣接データトラックを次の第１の予備データトラックとする切り替えを繰り返して、第１の予備データトラックを順に移動し、
前記第２のデータトラックグループ内において、前記第２の予備データトラックに隣接するデータトラックに記録されているデータを前記第２の予備データトラックに移動し、これに応じて前記隣接データトラックを次の第２の予備データトラックとする切り替えを繰り返して、第２の予備データトラックを順に移動する
ことを特徴とするデータリフレッシュ方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ディスクに書き込まれているデータをリフレッシュするのに好適な磁気ディスク装置及び同装置におけるデータリフレッシュ方法に関する。
【背景技術】
【０００２】
近年、磁気ディスク装置に搭載されるディスク（磁気ディスク）の面（記録面）当たりの記憶容量の大容量化が図られている。ディスクの面当たりの記憶容量を増加させるためには、線記録密度及び／またはトラック密度を上げればよい。線記録密度を上げるには、１トラックあたりのセクタ数を増やせばよい。トラック密度を上げるには、つまりディスクの面内により多くのトラックを確保するためには、トラック幅を狭くして隣接するトラック間の距離（つまりトラックピッチ）を短くすればよい。
【０００３】
ここで、トラック密度を上げるために、トラックピッチを短くするものとする。一般には、ヘッド（磁気ヘッド）によるデータの書き込みにより、データ書き込み先に隣接するトラック（隣接トラック）のデータを劣化させない程度までしか、トラックピッチを短くすることはできない。各トラックはヘッド（ヘッドに含まれる書き込み素子）の幅と同じ幅を持つ。しかし、データ書き込み時にヘッドによって生成される磁界（記録磁界）の分布の幅は必ずしも当該ヘッドの幅に一致せず、その周辺にも磁界が加わる（漏れる）状態となる。このため、トラックピッチを短くしすぎると、ディスク上のトラックにヘッドによりデータを書き込む際に、当該ヘッドからの漏れ磁界が隣接トラックに影響を与える度合いが高くなる。
【０００４】
しかし、トラックピッチを限界を超えて短くした場合でも、その程度が小さければ１度乃至数度のデータ書き込み動作によって隣接トラックのデータを即座に破壊してしまうことはない。つまり、データ書き込み動作の繰り返しにより、隣接トラックのデータが、その回数に応じて次第に劣化するのが一般的である。
【０００５】
そこで近年の磁気ディスク装置では、データ書き込み動作による隣接トラックのデータ劣化を回復するためのデータリフレッシュ（書き直し）が必須になりつつある。例えば、特許文献１には、データライト回数が規定回数に達したトラックの隣接トラックのデータをリフレッシュする技術（先行技術）について記載されている。
【０００６】
上記先行技術によれば、データライト回数が規定回数に達したトラックの隣接トラックのデータが読み出されてＲＡＭに一時記憶される。そして、このＲＡＭに一時記憶された隣接トラックのデータが当該隣接トラックに再度書き込まれる。つまり、データリフレッシュの対象となるトラックのデータが、当該トラックから読み出されたデータで書き直される。このようなデータ書き直し処理、つまりデータリフレッシュ処理により、データの劣化が回復される。したがって、データリフレッシュ処理を適用することにより、トラックピッチを、従来の限界を超えて短くすることが可能となる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００４−２７３０６０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上記先行技術では、データリフレッシュ処理の最中に磁気ディスク装置の電源が遮断すると、リフレッシュされるべきデータが失われる可能性がある。更に具体的に述べるならば、データリフレッシュの対象となるトラック（以下、ターゲットトラックと称する）から読み出されたデータを当該トラックに再度書き込むための動作（データ書き込み動作）の最中に磁気ディスク装置の電源が遮断すると、当該データが失われる可能性がある。この理由について説明する。
【０００９】
まず、ターゲットトラックへの再度のデータ書き込み動作の最中に電源が遮断したものとする。この場合、ターゲットトラックへのデータ書き込み動作が未完了となることから、当該トラックのデータが破壊される。このとき、ＲＡＭに一時記憶されているターゲットトラックのデータは消失する。このため、電源が復帰しても、未完了となったデータ書き込み動作を再度行うことができず、ターゲットトラックのデータは失われる。
【００１０】
このような不具合を防止するために、上記ＲＡＭに代えて、ディスク上の特定のトラックを用いることが考えられる。つまり、ディスク上の特定のトラックを、ターゲットトラックのデータを一時退避するための一時退避用のトラックとして用いることが考えられる。この場合、ターゲットトラックから読み出されたデータが、ディスク上の上記一時退避用のトラックに書き込まれる（一時退避される）。次に、上記読み出されたデータがターゲットトラック（つまり、当該データが書き込まれていたトラック）に再度書き込まれる。もし、ターゲットトラックへの再度のデータ書き込み中に電源が遮断しても、一時退避用のトラックに書き込まれた（退避された）データは失われない。このため、一時退避用のトラックに書き込まれたデータを用いることにより、未完了となったデータ書き込み動作を再度行うことができる。
【００１１】
しかし、ＲＡＭに代えてディスク上の一時退避用のトラックを用いることによって、ターゲットトラックのデータをリフレッシュするには、ターゲットトラックから読み出されたデータを当該ターゲットトラックに再度書き込む前に、当該データを上記一時退避用のトラックに書き込む（一時退避する）ための書き込み動作が必要となる。この書き込み動作は、ＲＡＭにデータを書き込む場合に比べて長時間を要するため、データリフレッシュ処理の効率が低下する。更に、ヘッドをターゲットトラックから一時退避用のトラックに移動させるためのシーク動作、及び当該ヘッドを一時退避用のトラックからターゲットトラックに移動させるためのシーク動作をも必要とする。この２回のシーク動作により、データリフレッシュ処理の効率が一層低下する。
【００１２】
このように、ＲＡＭに代えてディスク上の一時退避用のトラックを用いることにより、電源遮断に対処できるものの、データリフレッシュ処理の効率が低下するおそれがある。
【００１３】
本発明は上記事情を考慮してなされたものでその目的は、電源遮断に対処しつつ、データリフレッシュ処理の効率が低下するのを防止できる磁気ディスク装置及び同装置におけるデータリフレッシュ方法を提供することにある。
【課題を解決するための手段】
【００１４】
本発明の１つの態様によれば、データリフレッシュを行う磁気ディスク装置が提供される。この磁気ディスク装置は、データリフレッシュに用いられる第１の予備データトラックと複数のデータトラックを備える第１のデータトラックグループが設けられる磁気ディスクと、前記第１のデータトラックグループ内において、前記第１の予備データトラックに隣接するデータトラックに記録されているデータが前記第１の予備データトラックに移動されるように制御するコントローラとを具備する。
【発明の効果】
【００１５】
本発明によれば、リフレッシュされるべきトラックのデータを一時退避のためにディスク（一時退避用のトラック）に書き込む動作が不要となるため、一時退避用のトラックを用いる場合に比べて、ディスクへのデータ書き込みの動作を１回少なくでき、電源遮断に対処しつつ、リフレッシュ処理の効率が低下するのを防止できる。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施形態に係る磁気ディスク装置（ＨＤＤ）の構成を示すブロック図。
【図２】図２に示されるディスクのトラック配置を含むフォーマットを示す概念図。
【図３】同実施形態で適用されるデータリフレッシュ処理の概念図。
【図４】同実施形態で適用されるライトカウントテーブルのデータ構造例を示す図。
【図５】同実施形態で適用されるトラックシフトテーブルのデータ構造例を示す図。
【図６】図１のＨＤＤにおける全体的な動作を説明するためのフローチャート。
【図７】図６のフローチャートに含まれる実シリンダ番号の算出処理の詳細な手順を示すフローチャート。
【図８】図６のフローチャートに含まれるトラックリフレッシュ処理の詳細な手順を示すフローチャート。
【図９】逆方向のリフレッシュ処理による回転待ち時間の短縮を目的とした、リフレッシュの単位の最適化についての概念図。
【発明を実施するための形態】
【００１７】
以下、本発明の実施の形態につき図面を参照して説明する。  
図１は本発明の一実施形態に係る磁気ディスク装置（ＨＤＤ）１００の構成を示すブロック図である。図１に示すＨＤＤ１００は、ホストシステム２００からの要求に応じてディスク（磁気ディスク）１０１の記録面上にデータを書き込み、あるいは当該記録面からデータを読み出すための記憶装置である。ホストシステム２００は、ＨＤＤ１００を記憶装置として利用するパーソナルコンピュータのような電子機器である。
【００１８】
ディスク１０１はスピンドルモータ（ＳＰＭ）３に固定されており、ＳＰＭ１０３が駆動されることにより一定の速度で回転する。ディスク１０１の例えば一方のディスク面は、データが磁気記録される記録面をなしている。ヘッド（磁気ヘッド）１０２はディスク１０１の記録面に対応して配置される。ヘッド１０２はアクチュエータ１０５の一端に固定されており、アクチュエータ１０５の他端はボイスコイルモータ（ＶＣＭ）１０４に固定されている。ヘッド１０２は、ＶＣＭ１０４が駆動されることにより、ＶＣＭ１０４の軸を中心とした円弧軌道のうちディスク１０１の面に重なる範囲を移動する。
【００１９】
図１の構成では、単一枚のディスク１０１を備えたＨＤＤ１００を想定している。しかし、複数のディスク１０１がある間隙をもった状態でＳＰＭ１０３に固定された構成であっても構わない。この場合、複数のアクチュエータ１０５が、複数のディスク１０１の間隙に合わせて重なった状態でＶＣＭ１０４に固定される。複数のアクチュエータ１０５の一端にはそれぞれヘッド１０２が固定されている。したがってＳＰＭ１０３が駆動されると、全てのディスク１０１は同時に回転し、ＶＣＭ１０４が駆動されると、全てのヘッド１０２は同時に移動する。また、図１の構成では、ディスク１０１の一方の面が記録面をなしている。しかし、ディスク１０１の両面がいずれも記録面をなし、両記録面にそれぞれ対応してヘッド１０２が配置されても構わない。
【００２０】
図２はディスク１０１のトラック配置を含むフォーマットを示す概念図である。  
図２において、ディスク１０１の記録面には、複数のトラック２０１が同心円状に配置されている。ホストシステム２００からＨＤＤ１００が受け取ったデータは、当該ホストシステム２００によって指定されたアドレスに応じ、複数のトラック２０１の少なくとも１つに記録される。
【００２１】
また、ディスク１０１の複数のトラック２０１上にはサーボ領域２０２及びデータ領域２０３が交互に且つ等間隔に配置されている。サーボ領域２０２には、ヘッド１０２の位置決めに用いられるサーボ信号が記録されている。データ領域２０３は、ホストシステム２００から転送されるデータを記録するのに用いられる。
【００２２】
再び図１を参照すると、ＣＰＵ１１５はＨＤＤ１００の主コントローラとして機能する。ＣＰＵ１１５はモータドライバ１０６を介してＳＰＭ１０３の起動・停止及び回転速度維持のための制御を行う。ＣＰＵ１１５はまたモータドライバ１０６を介してＶＣＭ１０４を駆動制御することで、ヘッド１０２を目標とするトラックに移動させて、当該トラックの目標とする範囲内に整定するための制御を行う。ヘッド１０２を目標とするトラックに移動させる制御はシーク制御と呼ばれ、ヘッド１０２を目標とするトラックの目標とする範囲内に整定する制御はヘッド位置決め制御と呼ばれる。ＣＰＵ１１５は更に、ディスク１０１のトラック２０１に書き込まれているデータをリフレッシュするための制御（データリフレッシュ処理）を行う。
【００２３】
ヘッド１０２の位置決めはＳＰＭ１０３の起動後の定常回転状態で行われる。上述のように、サーボ領域２０２（図２参照）はディスク１０１の円周方向に等間隔に配置されている。このため、ヘッド１０２によってディスク１０１から読み出され、ヘッドＩＣ１０７で増幅されたアナログ信号中には、サーボ領域２０２に記録されているサーボ信号が時間的に等間隔に現れることになる。リード・ライトＩＣ１０８（リード・ライトＩＣ１０８に含まれているサーボブロック１２１）とゲートアレイ１０９とは、このことを利用して上記アナログ信号を処理することにより、ヘッド１０２の位置決めのための信号を生成する。ＣＰＵ１１５はこの信号をもとにモータドライバ１０６を制御することにより、当該モータドライバ１０６からＶＣＭ１０４に、ヘッド１０２の位置決めのための電流（ＶＣＭ電流）をリアルタイムで供給させる。
【００２４】
ＣＰＵ１１５は、上述のようにモータドライバ１０６を介してＳＰＭ１０３及びＶＣＭ１０４を制御する一方で、他のＩＣの制御及びコマンド処理など、ＨＤＤ全体を制御する。ＣＰＵ１１５はＣＰＵバス１１２に接続されている。
【００２５】
ＣＰＵバス１１２には、リード・ライトＩＣ１０８、ゲートアレイ１０９、ディスクコントローラ（ＨＤＣ）１１０、ＲＡＭ１１３及びフラッシュＲＯＭ１１４が接続されている。フラッシュＲＯＭ１１４は、書き換え可能な不揮発性メモリである。ここでは、フラッシュＲＯＭ１１４の書き換えは、ＣＰＵ１１５からの制御により行われる。フラッシュＲＯＭ１１４には、ＣＰＵ１１５が実行すべきプログラムが予め格納されている。ＣＰＵ１１５による上述の制御は、当該ＣＰＵ１１５が上記プログラムを実行することにより実現される。フラッシュＲＯＭ１１４の記憶領域の一部は、後述するトラックシフトテーブル５００（図５参照）を格納するのに用いられる。ＲＡＭ１１３は、例えばＣＰＵ１１５が使用する種々の変数を格納するのに用いられる。またＲＡＭ１１３の記憶領域の一部は、ＣＰＵ１１５のワーク領域として用いられる。
【００２６】
リード・ライトＩＣ１０８は、サーボブロック１２１とリード・ライトブロック１２２とを有する。サーボブロック１２１は、サーボ信号の抽出を含む、ヘッド１０２の位置決めに必要な信号処理を行う。リード・ライトブロック１２２は、データの読み出し・書き込みのための信号処理を行う。ゲートアレイ１０９は、サーボブロック１２１によるサーボ信号の抽出のための信号を含む、制御用の諸信号を生成する。
【００２７】
ＨＤＣ１１０は、ＣＰＵバス１１２以外に、リード・ライトＩＣ１０８、ゲートアレイ１０９及びバッファＲＡＭ１１１に接続されている。ＨＤＣ１１０は、ホストブロック１２３、リード・ライトブロック１２４及びバッファブロック１２５を有する。ホストブロック１２３は、ホストシステム２００から転送されるコマンド（ライトコマンド、リードコマンド等）を受信すると共にホストとＨＤＣ１１０との間のデータ転送を制御するホストインタフェース制御機能を有する。リード・ライトブロック１２４は、リード・ライトＩＣ１０８及びゲートアレイ１０９と接続され、リード・ライトＩＣ１０８を介して行われるデータの読み出し・書き込み処理を行う。バッファブロック１２５は、バッファＲＡＭ１１１を制御する。バッファＲＡＭ１１１の記憶領域の一部は、ＨＤＣ１１０（ＨＤＣ１１０内のリード・ライトブロック１２４）を介してディスク１０１に書き込まれるべきデータ（ライトデータ）を一時格納するためのライトバッファとして用いられる。バッファＲＡＭ１１１の記憶領域の別の一部は、ＨＤＣ１１０を介してディスク１０１から読み出されたデータ（リードデータ）を一時格納するためのリードバッファとして用いられる。
【００２８】
リード・ライトＩＣ１０８、ゲートアレイ１０９、及びＨＤＣ１１０は、それぞれ制御用レジスタを有する。これらの制御用レジスタは、それぞれＣＰＵ１１５のメモリ空間の一部に割り当てられており、ＣＰＵ１１５はこの一部の領域に対してアクセスすることで、制御用レジスタを介してリード・ライトＩＣ１０８、ゲートアレイ１０９、またはＨＤＣ１１０を制御する。
【００２９】
図１のＨＤＤ１００において、データの読み出しは次のように行われる。まずヘッド１０２によってディスク１０１から読み出された信号（アナログ信号）は、ヘッドＩＣ１０７によって増幅される。増幅されたアナログ信号はリード・ライトＩＣ１０８によってサーボ信号とデータ信号とに分離される。データ信号はリード・ライトＩＣ１０８内のリード・ライトブロック１２２で復号化された後ＨＤＣ１１０に送られる。ＨＤＣ１１０内のリード・ライトブロック１２４は、復号化されたデータ信号をゲートアレイ１０９からの制御用の信号に従って処理することにより、ホストシステム２００に転送すべきデータを生成する。ここでの処理は、後述するＥＣＣデータに基づくデータの誤りの検出と誤りの訂正とを含む。生成されたデータは、ＨＤＣ１１０内のバッファブロック１２５によって一旦バッファＲＡＭ１１１に格納されてから、当該ＨＤＣ１１０内のホストブロック１２３によってホストシステム２００に転送される。
【００３０】
図１のＨＤＤ１００において、データの書き込みは次のように行われる。ホストシステム２００からＨＤＣ１１０に転送されたデータは、当該ＨＤＣ１１０内のホストブロック１２３で受信された後、当該ＨＤＣ１１０内のバッファブロック１２５によって一旦バッファＲＡＭ１１１に格納される。バッファＲＡＭ１１１に格納されたデータは、バッファブロック１２５によって取り出された後、ゲートアレイ１０９からの制御用の信号に従ってＨＤＣ１１０内のリード・ライトブロック１２４によってリード・ライトＩＣ１０８へ送られる。リード・ライトＩＣ１０８に送られたデータは、当該リード・ライトＩＣ１０８内のリード・ライトブロック１２２によって符号化される。符号化されたデータはヘッドＩＣ１０７を介してヘッド１０２に送られて、当該ヘッド１０２によってディスク１０１に書き込まれる。上述のデータの読み出し／書き込みは、ＣＰＵ１１５の制御の下で行われる。
【００３１】
次に、図１のＨＤＤ１００で実行されるデータリフレッシュ処理の概要について説明する。  
発明が解決しようとする課題の欄で述べたように、データリフレッシュ中の電源遮断対策のために、データリフレッシュの対象となるトラック（ターゲットトラック）のデータをディスク上の特定のトラック（一時退避用のトラック）に一時退避させると、データリフレッシュ処理の効率が低下する。そこで本実施形態では、データリフレッシュ中の電源遮断対策を図りながら、処理効率の低下を防止可能な、次のような特徴あるデータリフレッシュ処理を適用している。
【００３２】
本実施形態では、ディスク１０１上に予備トラックＴｉが用意される。この予備トラックＴｉに隣接するトラックＴｊが、データリフレッシュの対象となるトラック（ターゲットトラック）Ｔｊとなる。
【００３３】
まず、ヘッド１０２によってターゲットトラックＴｊからデータが読み出される。次にヘッド１０２がターゲットトラックＴｊから予備トラックＴｉに移動される。ここで予備トラックＴｉはターゲットトラックＴｊに隣接するため、ターゲットトラックＴｊから予備トラックＴｉにヘッド１０２を高速に移動できる。
【００３４】
ヘッド１０２が予備トラックＴｉに移動されると、ターゲットトラックＴｊから読み出されたデータが、ヘッド１０２によって予備トラックＴｉに書き込まれる。これによりターゲットトラックＴｊのデータのリフレッシュが完了する。つまり本実施形態の特徴は、ターゲットトラックＴｊのデータを隣接する予備トラックＴｉに書き込むことで、当該データを予備トラックＴｉ上でリフレッシュする点にある。上述のターゲットトラックＴｊからのデータの読み出しと、読み出されたデータの予備トラックＴｉへの書き込みとは、ＣＰＵ１１５の制御の下で行われる。
【００３５】
もし、ターゲットトラックＴｊから読み出されたデータを予備トラックＴｉに書き込む書き込み動作の最中に電源が遮断しても、ターゲットトラックＴｊのデータは失われない。このため、電源が復帰した際に、ターゲットトラックＴｊからデータを読み出して、その読み出されたデータを予備トラックＴｉに書き込むことができる。
【００３６】
このように本実施形態では、ターゲットトラックＴｊから読み出されたデータが一時退避用のトラックを介して当該ターゲットトラック（つまり元のトラック）Ｔｊに再度書き込まれるのではないことに注意されるべきである。本実施形態によれば、ターゲットトラックのデータを一時退避のためにディスク１０１（一時退避用のトラック）に書き込む動作が不要となる。つまり本実施形態によれば、一時退避用のトラックを用いてターゲットトラックのデータをリフレッシュする場合に比べて、ディスク１０１へのデータ書き込みの動作を１回少なくでき、電源遮断に対処しつつ、リフレッシュ処理の効率が低下するのを防止できる。
【００３７】
ターゲットトラックＴｊから読み出されたデータが、予備トラックＴｉに書き込まれると、当該ターゲットトラックＴｊが新たな予備トラックＴｊとなる。そして、この新たな予備トラックＴｊにトラックＴｉとは逆側で隣接するトラックＴｋが、新たなターゲットトラックＴｋとなる。すると、ヘッド１０２が、トラックＴｉから新たなターゲットトラックＴｋに移動される。トラックＴｉと新たなターゲットトラックＴｋとの距離は２トラック分であるため、トラックＴｉから新たなターゲットトラックＴｋにヘッド１０２を高速に移動できる。
【００３８】
次に、ヘッド１０２によってターゲットトラックＴｋからデータが読み出される。次にヘッド１０２がターゲットトラックＴｋから隣接する新たな（現在の）予備トラックＴｊに移動される。そして、ターゲットトラックＴｋから読み出されたデータが、ヘッド１０２によって現在の予備トラックＴｊに書き込まれる。以下同様にして、予備トラックが１トラック単位で順次切り替えられ、その都度、その際の予備トラックに隣接するトラックのデータを、その際の予備トラックに書き込む動作が行われる。
【００３９】
本実施形態によれば、ターゲットトラックと予備トラックとは常に隣接しているため、ターゲットトラックから予備トラックに高速でヘッド１０２を移動できる。また、ターゲットトラックのデータを予備トラック上でリフレッシュすると、当該ターゲットトラックが新たな予備トラックとなる。そして、この新たな予備トラックにそれまで予備トラックとして用いられていたトラック（旧予備トラック）とは逆側で隣接するトラックが、新たなターゲットトラックとなる。旧予備トラックと新たなターゲットとの距離は２トラック分であるため、旧予備トラックから新たなターゲットトラックに高速でヘッド１０２を移動できる。よって本実施形態によれば、一時退避用のトラックを用いてターゲットトラックのデータをリフレッシュする場合に比べて、ヘッドの移動に要する時間を短縮できる。この点からも、本実施形態によれば、電源遮断に対処しつつ、リフレッシュ処理の効率が低下するのを防止できる。
【００４０】
次に、上述のデータリフレッシュ処理を、図３の概念図を参照して説明する。  
本実施形態では、ディスク１０１の記録面に配置されたトラック２０１の集合は予め定められた一定数のトラックを単位にグループ化されて、グループ単位でデータリフレッシュ処理が行われる。このグループを、トラックグループと称する。ここでは、トラックグループ毎に、そのトラックグループ全体へのデータ書き込み動作の総数（ライト回数）がカウントされる。このカウント値が予め定められた一定値に達したならば、該当するトラックグループを対象とするデータフリフレッシュ処理が行われる。
【００４１】
図３の例では、ディスク１０１上の１つのトラックグループが示されている。ここでは、説明の簡略化のために、トラックグループがトラック０乃至１０の１１トラックから構成されているものとする。トラック０乃至１０の表記における「０」乃至「１０」の数値は、トラックグループ内のトラックの相対位置（相対トラック位置）を示す。この値が小さいトラックほどディスク１０１上の外周側に位置し、値が大きいトラックほどディスク１０１上の内周側に位置するものとする。
【００４２】
図３において、状態３１は、１つのトラックグループ内に１つの予備トラックが確保されている状態を示す。ここでは、トラック１０が予備トラックに割り当てられている。但し、予備トラックは後述するように動的に切り替えられる。トラックグループ内の予備トラック１０以外のトラック０乃至９トラックには、それぞれデータＡ乃至Ｊが格納されているものとする。
【００４３】
今、状態３１にあるトラックグループがデータリフレッシュの対象となったものとする。この場合、本実施形態ではまず、予備トラック１０に（ディスク１０１の外周側で）隣接するトラック９がデータリフレッシュの対象トラック（ターゲットトラック）として選択される。そして、トラック９のデータＪが読み出され、当該読み出されたデータＪが、図３において矢印３１１で示されるように、その時点における予備トラックであるトラック１０に書き込まれる。これにより、トラック９のデータが、当該トラック９に隣接するトラック１０上でリフレッシュされる。
【００４４】
すると、それまでデータリフレッシュの対象となっていたトラック９が、トラック１０に代わって新たに予備トラックに割り当てられる。この状態では、新たな予備トラック９に（ディスク１０１の外周側で）隣接するトラック８がターゲットトラックとして選択される。そして、トラック８のデータＩが読み出され、当該読み出されたデータＩが、図３において矢印３１２で示されるように、その時点における予備トラックであるトラック９に書き込まれる。これにより、トラック８のデータが、当該トラック８に隣接するトラック９上でリフレッシュされる。
【００４５】
以下、同様の動作が予備トラックを切り替えながら順次行われる。やがて、トラック１のデータＢが、図３において矢印３１９で示されるようにトラック２に書き込まれ、トラック０のデータＡが図３において矢印３２０で示されるように、トラック１に書き込まれ、当該トラック０が新たに予備トラックに割り当てられたものとする。このように、トラック０が予備トラックになったところで、つまり図３において状態３１にあるトラックグループが図３に示される状態３２に遷移したところで、当該トラックグループを対象とするデータリフレッシュ処理（データリフレッシュ動作）が完了する。これを、順方向のリフレッシュ処理と呼ぶ。つまり、ターゲットトラックのデータがディスク１０１の内周方向（相対トラック位置の値が増加する方向）に隣接するトラック（予備トラック）に書き込まれるデータリフレッシュ処理を、順方向のリフレッシュ処理と呼ぶ。また、この方向をリフレッシュ方向と呼び、ターゲットトラックのデータを隣接するトラックに書き込む書き込み動作を、ずらし書き込み（シフトライト）と呼ぶ。
【００４６】
その後、図３において状態３２にあるトラックグループを対象とするデータリフレッシュ処理が必要になったものとする。この場合、先の順方向のリフレッシュ処理とは逆に、予備トラック０に隣接するトラック１がターゲットトラックとして選択される。そして、トラック１のデータＡが読み出され、当該読み出されたデータＡが、図３において矢印３２１で示されるように、その時点における予備トラックであるトラック０に書き込まれる。これにより、トラック１のデータＡが、当該トラック１に隣接するトラック０上でリフレッシュされる。
【００４７】
すると、それまでデータリフレッシュの対象となっていたトラック１が、トラック０に代わって新たに予備トラックに割り当てられる。この状態では、新たな予備トラック１に（ディスク１０１の内周側で）隣接するトラック２がターゲットトラックとして選択される。そして、トラック２のデータＢが読み出され、当該読み出されたデータＢが、図３において矢印３２２で示されるように、その時点における予備トラックであるトラック１に書き込まれる。これにより、トラック２のデータＢが、当該トラック２に隣接するトラック１上でリフレッシュされる。
【００４８】
以下、同様の動作が予備トラックを切り替えながら順次行われる。やがて、トラック９のデータＩが、図３において矢印３２９で示されるようにトラック８に書き込まれ、トラック１０のデータＪが図３において矢印３３０で示されるように、トラック９に書き込まれ、当該トラック１０が新たに予備トラックに割り当てられたものとする。このように、トラック１０が予備トラックになったところで、つまり図３において状態３２にあるトラックグループが図３に示される状態３３に遷移したところで、当該トラックグループを対象とするデータリフレッシュ処理が完了する。これを、逆方向のリフレッシュ処理と呼ぶ。つまり、ターゲットトラックのデータがディスク１０１の外周方向（相対トラック位置の値が減少する方向）に隣接するトラック（予備トラック）に書き込まれるリフレッシュ処理を、逆方向のリフレッシュ処理と呼ぶ。
【００４９】
以後は、図３に示されるトラックグループのリフレッシュが必要になる度にリフレッシュ方向を切り替えながら、リフレッシュ処理が行われる。つまり、順方向のリフレッシュ処理と逆方向のリフレッシュ処理とが交互に行われる。なお、図３の例では、説明の簡略化のために、トラックグループ当たりのトラック数は予備トラックを含めて１１である。この例では、ディスク１０１の実質的な記憶容量は、総トラック（シリンダ）数の１０／１１しか確保できない。したがって実際には、トラックグループ当たりのトラック数として、もっと大きな値を設定することが好ましい。
【００５０】
図４はトラックグループ毎のライト回数（データライト回数、ライト実行回数）を保持するライトカウントテーブル４００のデータ構造例を示す。ライトカウントテーブル４００は、例えば図１におけるＲＡＭ１１３の所定の領域に格納される。
【００５１】
図４のライトカウントテーブル４００の例では、説明の一般化のために、ＨＤＤ１００がｍ本のヘッド１０２を有すると共に、当該ＨＤＤ１００がｎ個のシリンダグループから構成される場合を想定している。この場合、ライトカウントテーブル４００は、ヘッド（ヘッド番号）ｈ、シリンダグループ（シリンダグループ番号）ｃを用いて表される全てのトラックグループの各々について、そのトラックグループへのライト回数（データライト回数）Ｗ（ｈ，ｃ）（０≦ｈ≦ｍ−１，０≦ｃ≦ｎ−１）を保持している。Ｗ（ｈ，ｃ）はヘッド番号ｈ及びシリンダグループ番号ｃで特定されるトラックグループへのライト回数をカウントするライトカウンタとして用いられる。なお、図１のＨＤＤ１００の構成の場合、ｍは１である。
【００５２】
シリンダグループとは、予め定められた一定数のシリンダの集合であり、１シリンダグループ当たりのシリンダ数は、１トラックグループ当たりのトラック数と同じである。したがって、同一のシリンダグループ番号を持つトラックグループは、ＨＤＤ１００内に、ヘッド１０２の数ｍに一致する数だけ存在する。トラックグループは、シリンダグループ番号ｃとヘッド番号ｈとにより特定される。シリンダグループ番号ｃとヘッド番号ｈとで特定されるトラックグループ内のトラックへのデータの書き込み（ライトアクセス）が行われると、カウントテーブル４００に保持されているライト回数（ライトカウンタ）Ｗ（ｈ，ｃ）が、書き込みが行われた回数だけインクリメントされる。
【００５３】
本実施形態では、ライトカウントテーブル４００は、前述のようにＲＡＭ１１３に格納される。ＲＡＭ１１３の内容はＨＤＤ１００の電源の遮断により失われる。したがって、ライトカウントテーブル４００の内容も電源遮断と共に失われる。このため本実施形態では、ライトカウントテーブル４００を含む、ＲＡＭ１１３内の予め定められた領域の内容は、必要に応じて（例えばＨＤＤ１００の省電力状態への移行時に）、ディスク１０１の所定領域に保存（退避）される。このディスク１０１の所定領域に保存されたカウントテーブル４００を含む内容は、ＨＤＤ１００の起動時（電源投入時）に読み出されて、ＲＡＭ１１３内に復元される。
【００５４】
本実施形態では、目的のデータが書き込まれているトラックは、当該トラックを含むトラックグループを対象とするデータリフレッシュの都度切り替えられる。例えば図３において、データＡが書き込まれているトラックは、状態３１または３３ではトラック０であり、状態３２ではトラック１である。この目的のデータにアクセスするためには、上述のずらし書き込みをどの向きでどこまで行ったかを示す情報を常時把握しておき、通常のアドレス変換の結果に対してシリンダ番号のずれを補正すればよい。
【００５５】
ここで、通常のアドレス変換について説明する。近年のＨＤＤは、いわゆるＣＤＲ（Constant Density Recording）方式を適用しているのが一般的である。図１のＨＤＤ１００もＣＤＲ方式を適用しているものとする。このようなＨＤＤ１００を利用するホストシステム２００は、当該ＨＤＤ１００に対してアクセス対象ブロックを指定する情報として、ＬＢＡ（Logical Block Address：論理ブロックアドレス）を当該ＨＤＤ１００に与えるのが一般的である。この場合、ＨＤＤ１００では、例えばホストシステム２００から指示されたリードコマンドまたはライトコマンドのようなコマンドの実行時に、当該ホストシステム２００によって与えられたＬＢＡ（論理ブロックアドレス）を、ディスク１０１上の物理的な位置を示す、シリンダ番号、ヘッド番号及びセクタ番号（から構成される物理アドレス）に変換するためのアドレス変換（アドレス計算）が行われる。これが通常のアドレス変換である。
【００５６】
本実施形態では、このような通常のアドレス変換の結果に対して、シリンダ番号のずれを補正可能なように、トラックグループ毎にトラックグループ内の予備トラックの位置（相対位置）を示す位置情報が保持・管理される。なお、シリンダ番号のずれを補正するには、ずらし書き込みの向き（リフレッシュ方向）も把握する必要がある。しかし、このリフレッシュ方向は、後述するようにトラックグループ内の予備トラックの位置から判定可能である。このため本実施形態では、トラックグループ毎にリフレッシュ方向を示す情報が保持・管理される構成は適用されない。但し、リフレッシュ処理の実行中（または中断）のトラックグループについては、後述するリフレッシュ管理情報によって当該リフレッシュ処理のリフレッシュ方向が管理される。
【００５７】
図５は、トラックグループ毎の予備トラックの位置（を示す位置情報）を保持するトラックシフトテーブル５００のデータ構造例を示す。図５のトラックシフトテーブル５００の例では、説明の一般化のために、ＨＤＤ１００がｍ本のヘッド１０２を有すると共に、当該ＨＤＤ１００がｎ個のシリンダグループから構成される場合を想定している。この場合、トラックシフトテーブル５００は、ヘッド（ヘッド番号）ｈ及びシリンダグループ（シリンダグループ番号）ｃを用いて表される全てのトラックグループの各々について、そのトラックグループ内における予備トラックの位置Ｓ（ｈ，ｃ）（０≦ｈ≦ｍ−１，０≦ｃ≦ｎ−１）を保持している。この予備トラックの位置Ｓ（ｈ，ｃ）は、当該予備トラックが属するトラックグループ内における当該予備トラックの相対位置（相対トラック位置）を示す。なお、図１のＨＤＤ１００の構成の場合、ｍは１である。
【００５８】
トラックシフトテーブル５００は、電源手段対策のために書き換え可能な不揮発性メモリに保存されるのが好ましい。このトラックシフトテーブル５００のデータ量は少ない。そこで本実施形態では、プログラムを格納するのに用いられるフラッシュＲＯＭ１１４の所定の領域にトラックシフトテーブル５００が保存される構成を適用している。
【００５９】
上述のように、ＨＤＤ１００では、ホストシステム２００によって与えられたＬＢＡからディスク１０１上の物理的な位置を示す、シリンダ番号、ヘッド番号及びセクタ番号に変換するための通常のアドレス変換が行われる。ところが本実施形態においては、トラックグループ内の予備トラックの位置とリフレッシュ方向とにより、目的とするトラックのシリンダ番号が変わる。このため、通常のアドレス変換に加え、上記トラックシフトテーブル５００によって示される予備トラックの位置とリフレッシュ方向とに応じたシリンダ番号の補正処理が必要となる。
【００６０】
このように、トラックシフトテーブル５００の内容は目的とするトラックのシリンダ番号を決定するための補正処理に欠かせない極めて重要なものである。このためトラックシフトテーブル５００は、たとえＨＤＤ１００の動作中に不意の電源遮断が発生しても決して失われることがあってはならない。そのためトラックシフトテーブル５００は、フラッシュＲＯＭ１１４に保存されている。
【００６１】
一方、トラックシフトテーブル５００とは対照的に、ライトカウントテーブル４００はＲＡＭ１１３に格納される。このため、ＨＤＤ１００の動作中に不意の電源遮断が発生した場合、当該ＨＤＤ１００の再起動後には、それ以前にディスク１０１に最後に保存されたライトカウントテーブル４００の内容が使用される。この場合、失われるデータは、ライトカウントテーブル４００の内容が最後に保存されてから電源遮断までのライト回数のみであることから影響は殆どない。
【００６２】
これに対して、トラックシフトテーブル５００において、ある期間のあるトラックグループにおける予備トラック位置Ｓ（ｈ，ｃ）の更新が欠落すると仮定するならば、そのトラックグループ内のトラックのシリンダ番号を補正できなくなる。このため、トラックシフトテーブル５００は常に完全な形で保存される必要がある。したがって、トラックシフトテーブル５００をライトカウントテーブル４００と同様にＲＡＭ１１３に格納すると仮定するならば、１トラックのデータがリフレッシュされる度に、当該トラックシフトテーブル５００の内容をディスク１０１の所定の領域に保存（退避）しなければならない。このようにすると、リフレッシュ処理の効率化を果たすことができなくなる。
【００６３】
そこで本実施形態では、上述のようにトラックシフトテーブル５００がフラッシュＲＯＭ１１４に保存される構成を適用している。ここで、トラックシフトテーブル５００の更新中における電源遮断にも対処できるように、正副２つのトラックシフトテーブル５００を用意するとよい。つまり、これら正副２つのテーブル（トラックシフトテーブル）５００がフラッシュＲＯＭ１１４の異なるページに保存され、テーブル更新が、正副２つのテーブルに対して行われるようにする。ここでは、正テーブル５００の更新が正常終了した後に、副テーブル５００の更新が実行される構成を適用する。これにより、どのタイミングでＨＤＤ１００の電源が遮断されても、トラックシフトテーブル５００の内容が失われるのを防止できる。
【００６４】
また、一般的にフラッシュＲＯＭ１１４の書き換えは、例えばページ単位でその内容を全て消去した後に、消去されたページに新しい内容を書き込むという手順で行われる。しかし、フラッシュＲＯＭ１１４の種類によってはページ内で追記することが可能である。もし、フラッシュＲＯＭ１１４がページ内で追記が可能なタイプであるならば、当該フラッシュＲＯＭ１１４内に差分用領域を設けておき、当該フラッシュＲＯＭ１１４を次のように利用することも可能である。
【００６５】
例えば、フラッシュＲＯＭ１１４内の差分用領域を使い切るまでは、トラックシフトテーブル５００を全て書き換える代わりに、差分、つまり変更されるＳ（ｈ，ｃ）のみが、当該差分用領域に順次記録される。そして、差分用領域に空きがなくなったところで、トラックシフトテーブル５００が全て更新される。このような構成を適用することで、フラッシュＲＯＭ１１４を消去する頻度を下げることもできる。ただし、差分を記録する手法では、トラックシフトテーブル５００を直接参照することはできない。そこで、最新の状態を示すトラックシフトテーブル５００をＲＡＭ１１３の所定の領域に配置し、この所定の領域内のトラックシフトテーブル５００を参照するとよい。
【００６６】
次に、トラックグループ単位のリフレッシュ処理が行われる図１のＨＤＤ１００における全体的な動作について、図６のフローチャートを参照して説明する。  
まず、ＨＤＤ１００の電源が投入され、ＣＰＵ１１５の動作が開始されたものとする（ステップ６０１）。するとＣＰＵ１１５は、ＨＤＤ１００全体を対象とする周知の初期化処理及び起動処理を行う（ステップ６０２）。起動処理が終わるとＣＰＵ１１５は、ＨＤＣ１１０を介してホストシステム２００からコマンドを受信できる状態になり、コマンド待ちループ（ステップ６０３乃至６０７）に入る。
【００６７】
ステップ６０３においてホストシステム２００からのコマンドの受信を確認すると、ＣＰＵ１１５は、ステップ６１１に分岐することでコマンド待ちループを抜けて、ホストシステム２００からのコマンドに応じた処理を実行する。ステップ６１１においてＣＰＵ１１５は、ホストシステム２００からのコマンドがライトコマンドであるかを判定する。もし、そうであれば、ＣＰＵ１１５は、ライトコマンドのための処理（ステップ６１２〜６１５）を行う。
【００６８】
受信したコマンドがライトコマンドである場合（ステップ６１１がＹＥＳ）、ホストシステム２００から要求されたアドレスへの書き込みを行うために、前述のようなシリンダ番号の補正が必要となる。そこでステップ６１２では、このシリンダ番号の補正（実シリンダ番号の算出）が行われる。図６のフローチャートには明示的には示されていないが、ステップ６１２に到達する以前に、ホストシステム２００からのコマンド（ライトコマンド）で指定されるアドレス（例えばＬＢＡ）を仮想シリンダ番号、ヘッド番号、セクタ番号に変換するための処理（通常のアドレス変換）が一般的な方法によって既に実施されているものとする。
【００６９】
仮想シリンダ番号とは、実際（通常）のシリンダ番号（実シリンダ番号）を求めるために中間的に設けられた計算上のシリンダ番号である。ここで、実際のシリンダ番号を、仮想シリンダ番号に対比させて実シリンダ番号と呼ぶ。仮想シリンダ番号で指定されるシリンダを仮想シリンダと呼び、実シリンダ番号で指定されるシリンダを実シリンダと呼ぶ。なお、単にシリンダと表現する場合には、実シリンダを指すものとする。
【００７０】
仮想シリンダ番号は、トラックグループ（シリンダグループ）毎に１つの予備トラックが確保されることにより必要となる概念であり、予備トラック（予備シリンダ）を除く、ホストシステム２００から認識可能なトラック（シリンダ）のシリンダ番号を指す。つまり、仮想シリンダ番号は各トラックグループ（シリンダグループ）内の予備トラックを飛ばして（予備トラックの存在を前提としないで）数えられる（算出される）シリンダ番号である。
【００７１】
仮想シリンダ番号という概念は、以下に述べるように、アドレス変換（アドレス計算）を階層化することを目的として導入されている。まず、本実施形態で適用されるようなトラックグループ単位のデータリフレッシュ処理（トラックリフレッシュ処理）が存在しないと仮定した場合と全く同様に第１のアドレス変換（アドレス計算）が行われる。この第１のアドレス変換では、ホストシステム２００によって指定されたＬＢＡが通常のアドレス変換と同様に、シリンダ番号、ヘッド番号及びセクタ番号に変換される。ホストシステム２００からは予備トラックは認識されない。このため、ホストシステム２００によって指定されたＬＢＡから第１のアドレス変換で取得されるシリンダ番号は、仮想シリンダ番号である。そこで、この仮想シリンダ番号が第２のアドレス変換（アドレス計算）によって実シリンダ番号に変換される。
【００７２】
上述のように本実施形態では、ステップ６１２への到達時には、ホストシステム２００によって指定されたＬＢＡが、既に仮想シリンダ番号、ヘッド番号及びセクタ番号に変換されている。そこでステップ６１２においてＣＰＵ１１５は、ライト処理を行うのに必要な仮想シリンダ番号から実シリンダ番号への変換（実シリンダ番号の算出）を行う。このステップ６１２の詳細については後述する。ＣＰＵ１１５は、ステップ６１２を実行すると、変換（算出）された実シリンダ番号と、ヘッド番号及びセクタ番号とに基づき、ライト処理（データ書き込み動作のための制御）を行う（ステップ６１３）。
【００７３】
ライト処理（ステップ６１３）が完了したなら、ＣＰＵ１１５は、そのライト処理がライトカウントテーブル４００に反映されるように、当該テーブル４００を更新する（ステップ６１４）。つまりＣＰＵ１１５は、ライト処理がヘッドｈ、シリンダグループｃで特定されるトラックグループに対して行われた場合、ライトカウントテーブル４００内のライト回数Ｗ（ｈ，ｃ）をライト処理が反映されるように更新する。更に詳細に述べるならば、ＣＰＵ１１５は、ライトカウントテーブル４００内のライト回数Ｗ（ｈ，ｃ）に対してライトが行われた回数を加算する。ここでは通常は、１が加算される。但し、ライト処理でリトライが行われた場合には、当該リトライも通常のライト動作と同様に隣接トラックに影響するので、当該リトライの回数も併せて加算される。
【００７４】
ステップ６１４が実行されると、ライトコマンドの処理は完了する。そこでＣＰＵ１１５は、レジスタ類の更新、及びビジー状態の解除など、コマンドの終了処理を行い（ステップ６１５）、コマンド待ちループに戻る。
【００７５】
一方、受信したコマンドがライトコマンド以外であった場合（ステップ６１１がＮＯ）、ＣＰＵ１１５は、当該受信したコマンドに応じた処理（ステップ６２０）及びコマンドの終了処理（ステップ６１５）を行い、コマンド待ちループに戻る。ライトコマンド以外の場合のコマンドに応じた処理については、便宜的にステップ６２０にまとめて記述されている。しかし実際には、ライトコマンド以外にも様々なコマンドが存在することから、ステップ６１１で行われるようなコマンドコードの判定や、ステップ６１２，６１３に相当する処理がコマンドの数だけ存在し、ライトコマンドの場合と同様に行われる。
【００７６】
特にリードコマンドやシークコマンドのようにホストシステム２００がアクセス対象を指定するコマンドにおいては、コマンド処理の前にステップ６１２と同様に仮想シリンダ番号から実シリンダ番号への変換処理が行われることに注意する必要がある。
【００７７】
次に、コマンド待ちループにおけるステップ６０３で、コマンドを受信していないと判定されたものとする。この場合、アイドル時処理が行われる。また、ステップ６１５でコマンドの終了処理が行われた後も、アイドル時処理が行われる。アイドル時処理は、トラックリフレッシュ処理を含む。本実施形態においてＣＰＵ１１５は、このトラックリフレッシュ処理の前に、トラックリフレッシュ処理を行うかを判定する（ステップ６０４，６０５）。
【００７８】
ステップ６０４においてＣＰＵ１１５は、トラックリフレッシュ処理を行わずにホストシステム２００からのコマンドを即座に実行する必要があるか、或いはリフレッシュ処理を回避すべき状況にあるかなどを総合的に判断する。コマンドを即座に実行する必要があるのは、例えば、ステップ６１５の直後にホストシステム２００からコマンドを受信した場合である。リフレッシュ処理を回避すべき状況は、外部からＨＤＤ１００に一定レベルを超える振動が加わった場合、ＨＤＤ１００の環境温度が、当該ＨＤＤ１００の動作が保証される温度範囲から外れた場合等、ＨＤＤ１００が悪条件下で用いられる場合である。ステップ６０５においてＣＰＵ１１５は、ステップ６０４での総合的な判断結果から、トラックリフレッシュ処理が実行可能かを判定する。
【００７９】
トラックリフレッシュ処理を行うと判定された場合のみ、ＣＰＵ１１５は、トラックリフレッシュ処理を行う（ステップ６０６）。このステップ６０６の詳細については後述する。
【００８０】
ステップ６０６でのトラックリフレッシュ処理が終了するか、ステップ６０５でトラックリフレッシュ処理を行うべきでないと判定された場合には、ＣＰＵ１１５は省電力状態に遷移するための省電力処理を実行するかを判定し、実行する必要があるならば当該処理を実行する（ステップ６０７）。省電力処理は、ヘッド１０２をディスク１０１上からアンロードさせるためのアンロード処理、及びまたは、ＳＰＭ１０３の回転を停止させるＳＰＭ停止処理のような処理を含む。
【００８１】
ステップ６０７で省電力処理が実行されると、ＣＰＵ１１５はステップ６０３に戻る。これに対し、ホストシステム２００からのコマンドを即座に実行する必要がある場合には、ステップ６０７で省電力処理を実行すべきでないと判定される。この場合、ＣＰＵ１１５は省電力処理を実行せずにステップ６０３に戻る。以後ＣＰＵ１１５は、ステップ６０３を含む上述の処理を繰り返す。
【００８２】
次に、上記ステップ６１２の実シリンダ番号の算出処理（シリンダ番号の補正処理）の詳細な手順について、図７のフローチャートを参照して説明する。
【００８３】
上述のように、本実施形態で適用される仮想シリンダ番号は、各シリンダグループ内の予備シリンダを飛ばして数えられるシリンダ番号、つまり予備シリンダが存在しないとして数えられるシリンダ番号である。このため、仮想シリンダ番号を直接に実シリンダ番号に変換することはできない。そこでＣＰＵ１１５は、図７のフローチャートで示される実シリンダ番号の算出処理７０１において、まず、仮想シリンダ番号から、当該仮想シリンダ番号のシリンダ（仮想シリンダ）が属するシリンダグループのシリンダグループ番号と、当該仮想シリンダの当該シリンダグループにおけるオフセット（相対シリンダ位置）とを算出する（ステップ７０２）。
【００８４】
本実施形態では、シリンダグループ当たりの仮想シリンダ数は一定値であり、図３の例では１０である。シリンダグループ番号は仮想シリンダ番号をこの一定値で割った商（整数値）、シリンダグループ内のオフセットはその余りとなる。例えば仮想シリンダ番号が３４の場合、シリンダグループ番号（ｃ）は３４を１０で割った商である３、オフセット（相対シリンダ位置、相対仮想シリンダ番号）はその余りである４となる。
【００８５】
次にＣＰＵ１１５は、ステップ７０２で算出された仮想シリンダのオフセット、即ちステップ７０２で算出されたシリンダグループ番号で示されるシリンダグループ内の相対仮想シリンダ番号から、以下に述べるように当該シリンダグループ内の相対実シリンダ番号を求める。
【００８６】
まずＣＰＵ１１５は、ステップ６１２に到達する前に求められているヘッド番号（ｈ）とステップ７０２で算出されたシリンダグループ番号（ｃ）とに基づき、トラックシフトテーブル５００を参照することにより、予備シリンダ（トラック）の位置（シリンダグループ内相対シリンダ位置）Ｓ（ｈ，ｃ）を得る（ステップ７０３）。上述のようにシリンダグループ番号（ｃ）が３の例で、更にヘッド番号（ｈ）が１の場合、予備シリンダ（トラック）のシリンダグループ内相対シリンダ位置はＳ（１，３）となる。
【００８７】
相対実シリンダ番号は、トラックシフトテーブル５００から取得された予備シリンダ（トラック）のシリンダグループ内相対シリンダ位置Ｓ（ｈ，ｃ）（＝Ｓ（１，３））と仮想シリンダのシリンダグループ内オフセット（相対仮想シリンダ番号）との位置関係により求めることができる。具体的には、予備シリンダ（トラック）のシリンダグループ内相対シリンダ位置を示す値が相対仮想シリンダ番号（オフセット）よりも大きいかによって（ステップ７０４）、相対実シリンダ番号が求められる。
【００８８】
予備シリンダのシリンダグループ内相対シリンダ位置を示す値が相対仮想シリンダ番号（オフセット）よりも大きい場合（ステップ７０４がＹＥＳ）、相対実シリンダ番号（実シリンダのシリンダグループ内相対シリンダ位置）は予備シリンダの影響を受けない。このため、相対仮想シリンダ番号と相対実シリンダ番号との間にずれは発生しない。つまり、予備シリンダが実シリンダよりも後方（シリンダ番号が大きい方）に存在する場合、相対仮想シリンダ番号と相対実シリンダ番号との間にずれは発生しない。この場合、相対実シリンダ番号は相対仮想シリンダ番号に等しい値となる。
【００８９】
これに対し、予備シリンダのシリンダグループ内相対シリンダ位置を示す値が相対仮想シリンダ番号（オフセット）以下の場合（ステップ７０４がＮＯ）、相対実シリンダ番号は予備シリンダの影響を受ける。つまり、予備シリンダが実シリンダよりも後方に存在しない場合、相対実シリンダ番号は予備シリンダの影響を受けて、予備シリンダの分だけずれが生じる。この場合、相対実シリンダ番号は、相対仮想シリンダ番号に対して１だけ大きい値となる。
【００９０】
そこでＣＰＵ１１５は、上述の相対実シリンダ番号に対し、更にシリンダグループの先頭シリンダの実シリンダ番号、即ちシリンダグループ番号とシリンダグループ当たりの実シリンダ数との積（上述の例では３と１１との積、つまり３３）、を加算することによって求められる値を、実シリンダ番号として取得する（ステップ７０５または７０６）。
【００９１】
ここで、ステップ７０５は、ステップ７０４がＮＯの場合に実行され、相対実シリンダ番号には、ステップ７０２で取得された相対仮想シリンダ番号（オフセット）に１が加算された値が用いられる。上述の例では、Ｓ（１，３）が相対仮想シリンダ番号（オフセット）４以下の場合にステップ７０５が実行され、３３に４と１とを加えることにより実シリンダ番号として３８が取得される。
【００９２】
これに対し、ステップ７０６は、ステップ７０４がＹＥＳの場合に実行され、相対実シリンダ番号には、ステップ７０２で取得された相対仮想シリンダ番号（オフセット）がそのまま用いられる。上述の例では、Ｓ（１，３）が相対仮想シリンダ番号（オフセット）４より大きい場合にステップ７０６が実行され、３３に４を加えることにより実シリンダ番号として３７が取得される。
【００９３】
次に、上記ステップ６０６のトラックリフレッシュ処理の詳細な手順について、図８のフローチャートを参照して説明する。
【００９４】
ＣＰＵ１１５は、図８のフローチャートで示されるトラックリフレッシュ処理８０１において、後述する実行中フラグを参照することにより、リフレッシュ処理が中断されているトラックグループが存在するかを判定する（ステップ８０２）。このステップ８０２は、トラックグループ内のデータリフレッシュされるべきトラック毎にリフレッシュ処理を中断できるようにしていることに関連する。
【００９５】
トラック毎にリフレッシュ処理を中断可能とする理由は、トラックグループ内の全てのトラック（但し予備トラックを除く）のデータをリフレッシュするには時間がかかるので、リフレッシュ処理の間に受信されたホストシステム２００からのコマンドへの応答性を低下させないためである。つまり本実施形態では、リフレッシュ処理の実行中にホストシステム２００からのコマンドが受信された場合、当該コマンドの実行を優先させるために、当該リフレッシュ処理が中断される。
【００９６】
リフレッシュ処理が中断されているトラックグループが存在するならば（ステップ８０２がＹＥＳ）、そのことはリフレッシュの対象となるトラックグループが決まっていることを意味する。この場合、ＣＰＵ１１５はステップ８０５以降のリフレッシュ処理を行う。
【００９７】
一方、リフレッシュ処理が中断されているトラックグループが存在しないならば（ステップ８０２がＮＯ）、ＣＰＵ１１５はリフレッシュ処理の対象となり得るトラックグループをライトカウントテーブル４００に基づいて探す（ステップ８０３）。ここではＣＰＵ１１５は、ライトカウントテーブル４００内で値の最も大きいライト回数Ｗ（ｈ，ｃ）を検索する。そしてＣＰＵ１１５は、検索されたライト回数Ｗ（ｈ，ｃ）が予め定められた一定値を超えているかによって、リフレッシュ処理が必要なトラックグループが存在するかを判定する（ステップ８０４）。
【００９８】
検索されたライト回数Ｗ（ｈ，ｃ）が一定値を超えている場合、ＣＰＵ１１５は、リフレッシュ処理が必要なトラックグループが存在し、そのトラックグループが当該ライト回数Ｗ（ｈ，ｃ）と対応付けられているトラックグループ（ヘッド番号ｈ、シリンダグループ番号ｃで表されるトラックグループ）であると判定する（ステップ８０４がＹＥＳ）。このように、リフレッシュ処理が必要なトラックグループ（つまりリフレッシュ処理が行われるべきトラックグループ）が存在すると判定される場合、そのトラックグループ（つまり値の最も大きいライト回数Ｗ（ｈ，ｃ）と対応付けられているトラックグループ）も特定される。この場合、ＣＰＵ１１５はステップ８０５以降のリフレッシュ処理を行う。
【００９９】
これに対し、検索されたライト回数Ｗ（ｈ，ｃ）が一定値以下の場合、ＣＰＵ１１５は、リフレッシュ処理が必要なトラックグループは存在しないと判断する（ステップ８０４がＮＯ）。この場合、リフレッシュ処理を行う必要はないので、ＣＰＵ１１５はトラックリフレッシュ処理８０１から元の処理にリターンする（ステップ８１７）。これにより図６のフローチャートにおけるステップ６０７が実行される。
【０１００】
ところで、トラックリフレッシュ処理を実行するかの判定は、上記ステップ６０４及び６０５でも行われている。但し、ステップ６０４及び６０５では、先の説明から明らかなように、ステップ８０３及び８０４で行われるようなライトカウントテーブル４００に基づく判定、即ちトラックリフレッシュ処理を行う必要があるトラックグループが存在するかの判定は行われない。
【０１０１】
しかし、ステップ６０４及び６０５の段階でライトカウントテーブル４００を参照する必要が生じるならば、この段階で、ステップ８０３及び８０４におけるのと同様の判定が行われる構成としてもよい。例えば、ステップ６０４及び６０５におけるリフレッシュ処理を実行するかの判定が、前述の振動及び温度のような環境条件に加えてトラックグループ毎のライト回数Ｗ（ｈ，ｃ）に基づいて行われる場合がこれに当たる。このような判定の詳細は次の通りである。まず、トラックグループへのライト回数が少ないうちは、一般にデータの劣化は少ない。このため、ＨＤＤ１００が悪条件下で用いられる場合には、リフレッシュ処理を実施するよりも当該リフレッシュ処理を回避した方がリスクが低いと判定される。これに対し、ライト回数が多くなるとデータの劣化が進む。このため、多少の悪条件でもリフレッシュ処理を行った方が逆にリスクが低くなると判定される。ステップ６０４及び６０５で、このような判定が行われるならば、当該ステップ６０４及び６０５で、ライト回数の最も多いトラックグループが特定されると共に、その回数が取得される。この場合、ステップ８０３及び８０４で再度これらが行われる必要はない。
【０１０２】
さて、ステップ８０５が実行される段階では、トラックリフレッシュ処理が行われるべきトラックグループ（以下、ターゲットトラックグループと称する）は確定している。このためステップ８０５においてＣＰＵ１１５は、トラックシフトテーブル５００を参照することにより、ターゲットトラックグループ内における予備トラックの相対位置Ｓ（ｈ，ｃ）を取得する。
【０１０３】
ステップ８０２からステップ８０３及び８０４を介してステップ８０５に進んだ場合、当該ステップ８０５においてＣＰＵ１１５は、取得された予備トラックの相対位置Ｓ（ｈ，ｃ）に基づいて、ターゲットトラックグループを対象とするリフレッシュ処理の方向（リフレッシュ方向）を順方向とするか、或いは逆方向とするかを決定する。この決定の仕方については後述する。ステップ８０５においてＣＰＵ１１５は更に、トラックグループ単位のリフレッシュを管理するためのリフレッシュ管理情報をＲＡＭ１１３の所定の領域に格納する。
【０１０４】
リフレッシュ管理情報は、トラックグループ番号、方向フラグ及び実行中フラグを含む。トラックグループ番号は、ステップ８０４で特定された、リフレッシュ処理の対象となるトラックグループ（つまりターゲットトラック）を示す。方向フラグは、トラックグループ番号で指定されるトラックグループを対象とするリフレッシュ処理の方向（リフレッシュ方向）が順方向であるか或いは逆方向であるかを示す。ここでは、方向フラグは、ステップ８０５で決定されたリフレッシュ方向を示す。実行中フラグは、トラックグループ番号で指定されるトラックグループを対象とするリフレッシュ処理が実行中（または中断中）であるかを示す。ここでは、実行中フラグはセットされており、実行中を示す。
【０１０５】
これに対し、ステップ８０２からステップ８０５に分岐した場合、ＲＡＭ１１３の所定の領域には後述するように有効なリフレッシュ管理情報が既に格納されている。このリフレッシュ管理情報に含まれている実行中フラグはセットされており、実行中（中断中）を示す。また、リフレッシュ管理情報に含まれている方向フラグは、実行中（中断中）のリフレッシュ処理の方向を示す。
【０１０６】
ステップ８０５以降の処理は、ターゲットトラックグループを対象とするリフレッシュ処理を順方向で行うか、或いは逆方向で行うかによって処理が分かれる。
【０１０７】
そこでＣＰＵ１１５は、ＲＡＭ１１３に格納されているリフレッシュ管理情報に含まれている方向フラグを参照することにより、当該管理情報に含まれているトラックグループ番号で指定されるトラックグループ（ターゲットトラックグループ）を対象とするリフレッシュ処理を順方向で行うかを判定する（ステップ８０６）。
【０１０８】
本実施形態ではリフレッシュが中断されているトラックグループが存在するならば、当該トラックグループを対象とするリフレッシュ処理が優先して行われる。このため、同時に複数のトラックグループがリフレッシュ処理中になることはない。このことから、リフレッシュ管理情報は、ＨＤＤ１００全体で１つのみ存在する。
【０１０９】
上述のように、リフレッシュ管理情報はＲＡＭ１１３に格納される。このためリフレッシュ管理情報は、ＨＤＤ１００の電源の遮断により失われる。そこで、本実施形態においてリフレッシュ管理情報は、ライトカウントテーブル４００と同様に、例えばＨＤＤ１００の省電力状態への移行時にディスク１０１の所定の領域に保存される。ディスク１０１の所定の領域に保存されたリフレッシュ管理情報は、ＨＤＤ１００の起動時（電源投入時）に実行される初期化処理で読み出されて、ＲＡＭ１１３内に復元される。
【０１１０】
しかし、不意の電源遮断が発生した場合には、その時点における最新のリフレッシュ管理情報は失われてしまう。そこでＣＰＵ１１５は、最新のリフレッシュ管理情報が失われたかを、つまり復元されたリフレッシュ管理情報は正しいかを、フラッシュＲＯＭ１１４に保存されているトラックシフトテーブル５００に基づいて、電源投入時の起動処理の中で次のように確認する。
【０１１１】
まずＣＰＵ１１５は、トラックシフトテーブル５００に保持されているトラックグループ毎の予備トラックの相対位置（相対トラック位置）Ｓ（ｈ，ｃ）を参照することにより、予備トラックの相対位置Ｓ（ｈ，ｃ）が当該トラックグループの先頭位置（最外周）でも最終位置（最内周）でもないトラックグループを探す（特定する）。特定されたトラックグループは、今回の電源投入に先行して発生した電源遮断時にリフレッシュ処理の対象となっていたトラックグループである。
【０１１２】
そこでＣＰＵ１１５は、特定されたトラックグループのトラックグループ番号が、ＲＡＭ１１３に復元されたリフレッシュ管理情報に含まれているトラックグループ番号に一致するかを判定する。もし、一致しているならば、ＣＰＵ１１５は、復元されたリフレッシュ管理情報は正しく、最新のリフレッシュ管理情報は失われていないと判定する。
【０１１３】
これに対し、一致していないならば、ＣＰＵ１１５は、復元されたリフレッシュ管理情報は誤っており、最新のリフレッシュ管理情報は失われていると判定する。この場合、ＣＰＵ１１５は、特定されたトラックグループを対象に、順方向または逆方向、いずれのリフレッシュを行うかを決定する。
【０１１４】
このリフレッシュの方向は、順方向または逆方向のいずれに決定されても構わない。本実施形態では、この方向を決定するのに、特定されたトラックグループにおける予備トラックの相対位置Ｓ（ｈ，ｃ）が用いられる。更に具体的に述べるならば、順方向のリフレッシュ及び逆方向のリフレッシュをそれぞれ前提とした場合に、予備トラックの相対位置Ｓ（ｈ，ｃ）から求められるリフレッシュされるべきトラックの数Ｎｆ及びＮｂの大小関係が用いられる。ここでは、ＮｆがＮｂ以下であるならば順方向のリフレッシュが決定され、ＮｂがＮｆ未満ならば逆方向のリフレッシュが決定される。
【０１１５】
決定されたリフレッシュ方向は、本来の方向と異なっている可能性がある。そこで本実施形態では、上記特定されたトラックグループを対象とする全てのリフレッシュが完了しても、当該トラックグループと対応付けられているライト回数（ライトカウンタ）Ｗ（ｈ，ｃ）が後述するステップ８１６でクリアされないように構成されている。これにより、上記特定されたトラックグループを対象とするリフレッシュが完了すると、当該トラックグループを対象とするリフレッシュ処理が、リフレッシュ方向を切り替えて続けて実行される。
【０１１６】
なお、フラッシュＲＯＭ１１４に保存されるトラックシフトテーブル５００に保持されている、トラックグループ毎の予備トラックの相対位置Ｓ（ｈ，ｃ）に、リフレッシュ方向を示す例えば１ビットの方向フラグＤ（ｈ，ｃ）が付加される構成とすることも可能である。つまり、トラックシフトテーブル５００により、トラックグループ毎の予備トラックの相対位置Ｓ（ｈ，ｃ）及び方向フラグＤ（ｈ，ｃ）を保持する構成としてもよい。このような構成を適用するならば、トラックグループ当たり１ビットの情報を追加するだけで、電源遮断時に実行されていたリフレッシュ処理の方向を特定することができる。このため、上述のような、リフレッシュ方向の決定を伴う電源遮断対策が不要となる。
【０１１７】
さて上記ステップ８０５において、ＲＡＭ１１３の所定の領域に有効なリフレッシュ管理情報が格納されているならば、ＣＰＵ１１５は、当該リフレッシュ管理情報に含まれている方向フラグの状態に基づいてリフレッシュ処理の方向を判定すればよい。ステップ８０２からステップ８０５に分岐した場合は、このような状態となる。
【０１１８】
しかし、ＲＡＭ１１３の所定の領域に有効なリフレッシュ管理情報が格納されていないならば、つまりリフレッシュ管理情報がクリアされているならば、そのことは新たにトラックリフレッシュを行うことを意味することから、リフレッシュ処理の方向を調べる必要がある。ステップ８０２からステップ８０３及び８０４を介してステップ８０５に進んだ場合は、このような状態となる。この場合、ステップ８０５で取得される、ターゲットトラックグループ内の予備トラックの相対位置Ｓ（ｈ，ｃ）は、必ず当該トラックグループの先頭位置（最外周）または最終位置（最内周）のいずれかにある。
【０１１９】
そこで、ターゲットトラックグループ内の予備トラックの相対位置Ｓ（ｈ，ｃ）が当該トラックグループの最内周にあるならば、ＣＰＵ１１５は、当該トラックグループを対象とするリフレッシュ処理の方向を順方向とすることを決定する（ステップ８０５）。これに対し、ターゲットトラックグループ内の予備トラックの相対位置Ｓ（ｈ，ｃ）が当該トラックグループの最外周にあるならば、ＣＰＵ１１５は、当該トラックグループを対象とするリフレッシュ処理の方向を逆方向とすることを決定する（ステップ８０５）。ステップ８０５においてＣＰＵ１１５は、決定されたリフレッシュ方向を示す方向フラグが含まれたリフレッシュ管理情報を、ＲＡＭ１１３の所定の領域に格納する。
【０１２０】
ＣＰＵ１１５はステップ８０５を実行すると、上述のように、ＲＡＭ１１３に格納されているリフレッシュ管理情報に含まれている方向フラグを参照することにより、リフレッシュ処理の方向が順方向であるかを判定する（ステップ８０６）
まず、ステップ８０６で判定されたリフレッシュ処理の方向が順方向である場合について説明する。この場合、ＣＰＵ１１５は、予備トラックにディスク１０１上の外周側で隣接するトラックをリフレッシュの対象となるトラック（ターゲットトラック）として、当該隣接するトラックのデータをヘッド１０２により読み出すためのデータ読み出し制御をＨＤＣ１１０を介して実行する（ステップ８１０）。次にＣＰＵ１１５は、読み出されたデータを、予備トラックに書き込むためのデータ書き込み制御をＨＤＣ１１０を介して実行する（ステップ８１１）。これにより、予備トラックに外周側で隣接するトラック（ターゲットトラック）のデータが、当該予備トラック上でリフレッシュされる。
【０１２１】
ＣＰＵ１１５は、ターゲットトラックのデータの予備トラックへの書き込み（ステップ８１１）が正常に終了したことを確認すると、トラックシフトテーブル５００に保持されている、現在リフレッシュ対象となっているトラックグループ内における予備トラックの相対位置Ｓ（ｈ，ｃ）を１トラック分ディスク１０１の外周側にずらす（ステップ８１２）。これにより、予備トラックが切り替えられる。このトラックシフトテーブル５００の更新（予備トラックの切り替え）をもって１トラック分のリフレッシュが完了する。
【０１２２】
トラックシフトテーブル５００の更新（ステップ８１２）の直前、直後のいずれの状態においても、ターゲットトラックに書き込まれていたデータは、当該トラック（元のトラック）と、当該トラックのデータの書き込み先（当該トラックにディスク１０１上の内周側で隣接するトラック）の両方に存在する。しかし、ターゲットトラックのデータの予備トラックへの書き込み（ステップ８１１）が正常に終了した場合、これら両トラックに同一データが存在する必要はない。
【０１２３】
そこで、上記ステップ８１２では、トラックシフトテーブル５００の更新直前にターゲットトラックとして扱われていたトラックが新たな予備トラックに切り替えられるように、上述のように予備トラックの相対位置Ｓ（ｈ，ｃ）が１トラック分外周側にずらされる。ここで新たな予備トラックとなったトラックには、次回のリフレッシュ処理（ステップ８１０，８１１）で、当該新たな予備トラックにディスク１０１上の外周側で隣接するトラックのデータが書き込まれることになる。なお、トラックシフトテーブル５００（フラッシュＲＯＭ１１４に保存されているトラックシフトテーブル５００）の更新が、前述のように更新中の電源遮断に配慮した形で行われるならば、更新中の電源遮断によって予備トラックの切り替えに失敗することはない。
【０１２４】
ＣＰＵ１１５は１トラック分のリフレッシュが完了すると、リフレッシュ処理の中断要求があるかを判定する（ステップ８１３）。ホストシステム２００からのコマンドの受信は、リフレッシュ処理の中断要求を判定する条件の１つである。ＨＤＣ１１０内のホストブロック１２３がホストシステム２００からコマンドを受信すると、当該ホストブロック１２３のハードウェアの機能によりＨＤＤ１００は即座にビジー状態に遷移する。同時に、このビジー状態を表すフラグ（ビジーフラグ）がセットされる。そこでＣＰＵ１１５は、ステップ８１３でビジーフラグの状態をチェックする。
【０１２５】
なお、ビジーフラグのセットはリフレッシュ動作が実行中であるかに関係なく行われる。したがって、ホストシステム２００から認識されるコマンドの応答時間は、当該コマンドを発行してからその際に実行中のリフレッシュが完了するまでの時間と本来のコマンド実行時間との合計となる。このことから、ホストシステム２００からのコマンドが受信された場合に、ターゲットトラックグループを対象とする全てのリフレッシュが終わるまで待つと、当該コマンドへの応答性を低下させてしまう。
【０１２６】
そこで本実施形態では、コマンドへの応答性の低下を回避するために、１トラック分のリフレッシュが完了する毎に、上述のようにリフレッシュ処理の中断要求があるかが判定される（ステップ８１３）。そして、１トラック分のリフレッシュの実行中にホストシステム２００からのコマンドが受信された場合のように、リフレッシュ処理の中断要求があるならば（ステップ８１３がＹＥＳ）、ＣＰＵ１１５はステップ８１７に分岐し、速やかにリフレッシュ処理を中断させてステップ６０６（図６参照）を終了させる。ＣＰＵ１１５はステップ６０６を終了させるとステップ６０７を実行する。このステップ６０７においても、ＣＰＵ１１５は、速やかにステップ６０３に分岐させてホストシステム２００からのコマンドのための処理を開始させるため、ステップ８１３と同様な処理を行う。
【０１２７】
一方、リフレッシュ処理の中断要求がない場合（ステップ８１３がＮＯ）、ＣＰＵ１１５は、ターゲットトラックグループを対象とするリフレッシュを全て完了したかを判定する（ステップ８１４）。この判定は、新たな予備トラックの相対位置Ｓ（ｈ，ｃ）がターゲットトラックグループ内の先頭位置（最外周）にあるかによって行われる。その理由は、リフレッシュ方向が順方向である場合、予備トラックの相対位置Ｓ（ｈ，ｃ）がターゲットトラックグループ内の先頭位置（最外周）になったときが、当該グループ内の全トラックに対するリフレッシュの完了を意味するためである。
【０１２８】
もし、新たな予備トラックの相対位置Ｓ（ｈ，ｃ）がターゲットトラックグループ内の先頭位置（最外周）になく、したがって当該グループ内の全トラックに対するリフレッシュが完了していなければ（ステップ８１４がＮＯ）、ＣＰＵ１１５はステップ８１０に分岐して、新たなターゲットトラック、つまり新たな予備トラックにディスク１０１上の外周側で隣接するトラックを対象としたリフレッシュを行う。これに対し、ターゲットトラックグループ内の全トラックに対するリフレッシュが完了しているならば（ステップ８１４がＹＥＳ）、ＣＰＵ１１５はステップ８１５に分岐することでステップ８１０乃至８１４の処理ループ（トラックグループ処理ループ）を抜ける。
【０１２９】
次に、ステップ８０６で判定されたリフレッシュ方向が逆方向である場合について簡単に説明する。この場合、ＣＰＵ１１５は、ステップ８２０乃至８２４の処理を行う。これらステップ８２０乃至８２４は、それぞれステップ８１０乃至８１４の順方向のリフレッシュ処理に対応した逆方向のリフレッシュ処理であり、方向が逆転する以外は順方向のリフレッシュ処理と同様である。逆方向のリフレッシュ処理で新たな予備トラックの相対位置Ｓ（ｈ，ｃ）がターゲットトラックグループ内の最終位置（最内周）になった結果、当該グループ内の全トラックに対するリフレッシュの完了が判定されると（ステップ８２４）、ＣＰＵ１１５はステップ８１５に分岐することでステップ８２０乃至８２４の処理ループを抜ける。
【０１３０】
ステップ８１５においてＣＰＵ１１５は、ターゲットトラックグループを対象とするリフレッシュ処理が完了し、現在処理中のトラックグループがないことを表すため、ＲＡＭ１１３に格納されているリフレッシュ管理情報をクリアする。このリフレッシュ管理情報のクリアにより、その後ステップ８０２及びステップ８０６での判定を正しく行うことが可能となる。
【０１３１】
次にＣＰＵ１１５は、リフレッシュ処理が完了したトラックグループに対応付けてライトカウントテーブル４００に保持されているライト回数Ｗ（ｈ，ｃ）を、０に初期化（つまりクリア）する（ステップ８１６）。ライトカウントテーブル４００に保持されているトラックグループ毎のライト回数Ｗ（ｈ，ｃ）は、そのトラックグループへのライト動作の実行回数を示す。ライト回数Ｗ（ｈ，ｃ）は、当該ライト回数Ｗ（ｈ，ｃ）と対応付けられているトラックグループにおけるデータの劣化の程度と相関がある。そのため本実施形態では、ライト回数Ｗ（ｈ，ｃ）は便宜的にデータ劣化の程度として扱われる。トラックグループを対象とするリフレッシュ処理が完了した直後は、当該グループにおけるデータの劣化はない。このことを、リフレッシュ処理が完了したトラックグループに対応付けられたライト回数Ｗ（ｈ，ｃ）に反映させるために、上述のように当該ライト回数Ｗ（ｈ，ｃ）が０に初期化される。
【０１３２】
ＣＰＵ１１５は、ステップ８１６を実行すると、再びステップ８０２に分岐して次のトラックグループに対する処理を開始する。この場合、ステップ８０２からの分岐先は常にステップ８０３になり、リフレッシュを必要とするトラックグループを検索するための動作を含む処理が上述の場合と同様に行われる。リフレッシュ処理の中断要求がなければ、トラックグループを対象とするリフレッシュ処理（トラックリフレッシュ処理）が終了するのは、それを必要とするトラックグループがなくなった場合のみである（ステップ８０４がＮＯ）。
【０１３３】
［第１の変形例］
次に上記実施形態の第１の変形例について説明する。第１の変形例の特徴は、トラックシフトテーブル５００が、ライトカウントテーブル４００と同様にＲＡＭ１１３に格納される点にある。このような構成は、例えば、図１に示されるフラッシュＲＯＭ１１４が頻繁にデータの書き換えが行えないか、或いはフラッシュＲＯＭ１１４に代えて、書き換えが不可能なＲＯＭが用いられる場合に必須となる。
【０１３４】
第１の変形例でにおいても、図８のフローチャートに従うトラックリフレッシュ処理が実行される。但し第１の変形例では、例えばステップ８０５の直後に、ＣＰＵ１１５の制御により、ＲＡＭ１１３に格納されているリフレッシュ管理情報及びトラックシフトテーブル５００がディスク１０１の所定の領域に保存される。このときリフレッシュ管理情報に含まれている実行中フラグはセットされており、当該管理情報に含まれているトラックグループ番号で指定されるトラックグループを対象とするリフレッシュ処理の実行中であることを示す。また第１の変形例では、例えばステップ８１６の直後に、ＣＰＵ１１５の制御により、ディスク１０１の上記領域に保存されているリフレッシュ管理情報に含まれている実行中フラグがリセットされる。しかる後に、その時点においてＲＡＭ１１３に格納されているトラックシフトテーブル５００が、ディスク１０１の上記領域に保存される。
【０１３５】
第１の変形例によれば、リフレッシュ処理の実行中に不意の電源遮断が発生しても、その次のＨＤＤ１００の起動時に、ディスク１０１の所定の領域に、実行中を示す実行中フラグが残っているかをチェックすることで、それを検知できる。
【０１３６】
さて、ディスク１０１の各トラックに配置される各セクタに書き込まれるデータには、ＨＤＣ１１０によりＥＣＣ（Error Correcting Code: エラー訂正符号）データが付加されるのが一般的である。第１の変形例では、このＥＣＣデータのシード値として、当該ＥＣＣデータが付加されるセクタが配置されるトラックの仮想シリンダ番号に基づいて生成される値が使用される。更に具体的に述べるならば、ＥＣＣデータのシード値として、当該ＥＣＣデータが付加されるセクタが配置されるトラックの仮想シリンダ番号及びヘッド番号と、当該セクタのセクタ番号とに基づいて生成される値、例えば仮想シリンダ番号、ヘッド番号及びセクタ番号が連結された値が使用される。
【０１３７】
このように、仮想シリンダ番号がＥＣＣデータのシード値の生成に用いられる構成では、たとえトラックシフトテーブル５００に保持されている予備セクタの相対位置が誤っていても、ＨＤＣ１１０において、その誤りを検出できる。その理由は次の通りである。まず、誤った予備セクタに隣接するトラックのデータがステップ８１０または８２０で読み出されるものとする。この場合、シード値が異なるのでＨＤＣ１１０においてＥＣＣエラー（シードエラー）となる。これにより、予備セクタの相対位置が誤っていることが検出できる。
【０１３８】
さて、ＨＤＤ１００の起動時に、ディスク１０１の所定の領域に、実行中を示す実行中フラグが残っているものとする。この場合、ＣＰＵ１１５は、リフレッシュ処理の実行中に不意の電源遮断が発生したことを判定（検知）する。ディスク１０１の所定の領域に保存されている、上記実行中フラグを含むリフレッシュ管理情報と、トラックシフトテーブル５００とは、ディスク１０１の所定の領域から読み出されてＲＡＭ１１３の所定の領域に格納（復元）される。
【０１３９】
ここで、不意の電源遮断が発生した際にリフレッシュ処理が実行されていたトラックグループに対応付けてトラックシフトテーブル５００に保持されている予備トラックの相対位置は、当該電源遮断のために誤っている可能性がある。そこで第１の変形例では、予備トラックの相対位置が誤っている場合、以下に述べるように正しい相対位置に訂正される。
【０１４０】
まず、ＲＡＭ１１３の所定の領域に格納されたトラックシフトテーブル５００から、電源遮断が発生した際にリフレッシュ処理が実行されていたトラックグループに対応付けられている予備トラックの相対位置が取得される。このトラックグループは、ＲＡＭ１１３の所定の領域に格納されたリフレッシュ管理情報に含まれているトラックグループ番号によって示される。
【０１４１】
次に、ターゲットトラックグループ内の各トラックを対象に、仮想シリンダ番号が実シリンダ番号と同じであると仮定してデータ読み出し動作が行われる。このデータ読み出し動作により、シード値が合致しているトラックとそうでないトラック（シードエラーが発生しているトラック）との境界が特定される。この境界に隣接する２つのトラックのうち、シードエラーが発生しているトラックが、正しい予備トラックとして決定される。決定された予備トラックの相対位置が、トラックシフトテーブル５００から取得された予備トラックの相対位置と異なるならば、当該取得された予備トラックの相対位置は誤っている。この場合、ＣＰＵ１１５は、トラックシフトテーブル５００に保持されている、誤っている予備トラックの相対位置の値を、上記決定された予備トラックの相対位置の値に訂正する。
【０１４２】
ここで、ターゲットトラックグループ内の各トラックからのデータの読み出しの順序の決定には、探索を早く行うために二分検索が用いられる。トラック内の読み出されるべきセクタについては特に制約はなく、例えば、当該トラック内の予め定められた相対位置のセクタであってもよい。また、トラック内で回転待ちが最も少なくなるセクタが動的に選択されてもよい。
【０１４３】
第１の変形例によれば、不意の電源遮断が発生しても、その次のＨＤＤ１００の起動時に、そのことを検知できる。しかも第１の変形例によれば、トラックシフトテーブル５００をフラッシュＲＯＭに格納しなくても、トラックシフトテーブル５００に保持されている予備トラックの相対位置の情報を復元できる。したがって第１の変形例によれば、フラッシュＲＯＭ１１４がトラックシフトテーブル５００を格納するのに利用できなくても、或いはフラッシュＲＯＭ１１４を有していないＨＤＤであっても、トラックシフトテーブル５００に基づくリフレッシュ処理を実現できる。
【０１４４】
［第２の変形例］
次に上記実施形態の第２の変形例について説明する。第２の変形例の特徴は、逆方向のリフレッシュ処理における回転待ち時間の短縮のために、リフレッシュの単位（つまりリフレッシュのためのデータの読み出し／書き込みの単位）を最適化するようにした点にある。
【０１４５】
図９は逆方向のリフレッシュ処理による回転待ち時間の短縮を目的とした、リフレッシュの単位の最適化についての概念図である。  
図９に示されるように、ディスク１０１に配置される互いに隣接するトラックの間にはそのトラック内の先頭セクタの位置を調整するための、トラックスキューがかけられている。トラックスキューの値は、順方向アクセス、即ちＬＢＡが増加する方向へのシーケンシャルアクセスでの回転待ち時間が最小になるように決められる。つまり、ディスク１０１上のあるトラックの最終セクタをアクセスした後、ヘッド１０２を次の（隣接する）トラックへ移動させるのに要する時間がトラックスキューの最小値となる。
【０１４６】
このことから、トラックリフレッシュが順方向に行われる場合にはトラックスキューが最適化されていることになり、回転待ち時間は少ない。しかし、逆方向にトラックリフレッシュが行われると、回転待ち時間が著しく増加する。
【０１４７】
図９（ａ）は、逆方向のトラックリフレッシュ（つまりリフレッシュの単位が上記実施形態のように１トラックの場合に行われる逆方向のリフレッシュ処理）において、ヘッド１０２がディスク１０１上に描く軌跡を表す。図９（ａ）に示されるように、逆方向のトラックリフレッシュでは、ヘッド１０２はディスク１０１上に、軌跡９０３、軌跡９０２及び軌跡９０１を順次描く。
【０１４８】
軌跡９０３は、ターゲットトラックからデータを読み出すための読み出し動作（リードアクセス）におけるヘッド１０２が描く軌跡を示し、軌跡９０１は読み出されたデータを予備トラックへ書き込むための書き込み動作（ライトアクセス）におけるヘッド１０２が描く軌跡を示す。ここでは、軌跡９０２の長さに相当する長い回転待ち時間が発生する。
【０１４９】
第２の変形例では、図９（ａ）における軌跡９０２のような回転待ち時間を短縮するために、リフレッシュの単位（１回のリフレッシュ処理当たりのリフレッシュ量）が最適化される。図９（ｂ）は、その一例として、リフレッシュの単位が１トラックを超えて２トラック以下に最適化された場合に行われる逆方向のリフレッシュ処理において、ヘッド１０２がディスク１０１上に描く軌跡を表す。図９（ｂ）の例では、ヘッド１０２はディスク１０１上に、軌跡９１３、軌跡９１２及び軌跡９１１を順次描く。
【０１５０】
軌跡９１３は、ターゲットトラックからデータを読み出すためのリードアクセスにおけるヘッド１０２が描く軌跡を示し、軌跡９１１は読み出されたデータを予備トラックへ書き込むためのライトアクセスにおけるヘッド１０２が描く軌跡を示す。軌跡９１２の長さに相当する回転待ち時間は、図９（ａ）の例（１トラック単位のリフレッシュ）における軌跡９０２の長さに相当する回転待ち時間に比べて短縮されている。
【０１５１】
トラックスキューの値によっては、リフレッシュの単位を、１トラック未満とする方がよいこともあり、このような最適化も可能である。図９（ｃ）は、このようなリフレッシュの単位が１トラック未満に最適化された場合に行われる逆方向のリフレッシュ処理において、ヘッド１０２がディスク１０１上に描く軌跡を表す。図９（ｃ）の例では、ヘッド１０２はディスク１０１上に、軌跡９２３、軌跡９２２及び軌跡９２１を順次描く。
【０１５２】
軌跡９２３は、ターゲットトラックからデータを読み出すためのリードアクセスにおけるヘッド１０２が描く軌跡を示し、軌跡９２１は読み出されたデータを予備トラックへ書き込むためのライトアクセスにおけるヘッド１０２が描く軌跡を示す。軌跡９２２の長さに相当する回転待ち時間は、図９（ａ）の例における軌跡９０２の長さに相当する回転待ち時間に比べて短縮されている。また、リフレッシュの単位を大きくすると、その大きさに応じてバッファＲＡＭ１１１内に大きなバッファ領域を確保する必要が生じる。そこで、このバッファ領域を減らす目的でリフレッシュの単位を小さくしてもよい。
【０１５３】
次に、リフレッシュの単位の具体的な算出方法について述べる。  
上述のように、図９（ｂ）はリフレッシュの単位が１トラックを超えて２トラック以下に最適化された場合に行われる逆方向のリフレッシュ処理において、ヘッド１０２がディスク１０１上に描く軌跡を表す。１トラック及び２トラックは、それぞれ、ディスク１０１の１回転及び２回転に相当する。したがって、リフレッシュの単位が１トラックを超えて２トラック以下を、リフレッシュの単位がディスク１０１の１回転を超えて２回転以下と言い換えることも可能である。
【０１５４】
ここで、ディスク１０１の単位時間（１秒）当たりの回転数をｆ［回転／ｓ］、ｘトラックに渡るディスク１０１の移動（シーク動作）に必要な時間をｔx［ｓ］とする。また、軌跡９１３に相当する（軌跡９１３を描くのに必要な）アクセス量、つまりリフレッシュの単位を、ディスク１０１の回転数ｕ［回転］で表す。但し、ｕは、リフレッシュの単位の前提条件から、１＜ｕ≦２である。
【０１５５】
次に、軌跡９１２（回転待ち時間）に相当するディスク１０１の回転数をｗ［回転］とする。ｔxはヘッド１０２の物理的な移動に要する時間のみでなく、ヘッド１０２の移動先でのリード・ライトアクセスのためのセットアップの時間も含む。トラックスキューは１トラック（ｘ＝１）のシークに必要な時間ｔ1［ｓ］に等しい。この時間ｔ1［ｓ］におけるディスク１０１の回転数は、ｆｔ1で表される。つまりトラックスキューは回転数ｆｔ1に相当する。
【０１５６】
このとき、図９（ｂ）から、軌跡９１３及び９１２にそれぞれ対応するリードアクセス及び回転待ち時間のために、ディスク１０１の２回転からトラックスキューに相当する回転数ｆｔ1を減じただけの回転数を要することがわかる。したがって、次式
ｕ＋ｗ＋ｆｔ1 ＝２                    （１）
が成立する。
【０１５７】
また、図９（ｂ）から、ｗは２トラックに渡るヘッド１０２の移動に要する回転数を少なくとも必要とすることがわかる。但し、軌跡９１３の開始位置が、図９（ｂ）の例とは異なって、例えば先頭トラックの終端側にある場合のように、軌跡９１３の開始位置によっては、トラック渡りが２度発生する可能性、すなわち軌跡９１３が３トラックに渡る可能性もある。このため、ｗは次式
ｗ≧ｆt3                              （２）
に示される制約を受ける。ｗがこの制約を満たさない場合、１回転余分に回転待ちが発生する。
【０１５８】
上記（１）式及び（２）式と、リフレッシュの単位ｕ［回転］の前提条件１＜ｕ≦２とから、リフレッシュの単位ｕ［回転］を、次式
１＜ｕ≦２−ｆ（ｔ1＋ｔ3）［回転］    （３）
のように求めることができる。ここでは、等号が成立する場合（つまりｕ＝２−ｆ（ｔ1＋ｔ3）の場合）が最も効率がよく、これ（２−ｆ（ｔ1＋ｔ3））を超えない範囲でリフレッシュの単位を決めればよい。
【０１５９】
なお、図９（ｂ）の例では、軌跡９１１に相当するライトアクセスが完了したら次のリフレッシュの単位を対象とするリフレッシュ処理が開始され、リードアクセスが行われる。このリードアクセスの開始位置は、軌跡９１３に相当するリードアクセスが完了した位置となる。軌跡９１１に相当するライトアクセスでのアクセス量は、軌跡９１３に相当するリードアクセスでのそれに等しい。したがって、軌跡９１１に相当するライトアクセスが完了した位置から次のリードアクセスの開始位置にヘッド１０２を移動させるためのシーク動作に要するディスク１０１の回転数は、トラックスキューに相当する回転数ｆｔ1に等しい。このため、最小の回転待ち時間で次のリフレッシュの単位に移行できる。
【０１６０】
次に図９（ｃ）は、上述のように、リフレッシュの単位が１トラック未満（１回転未満）に最適化された場合に行われる逆方向のリフレッシュ処理において、ヘッド１０２がディスク１０１上に描く軌跡を表す。この場合も、リフレッシュの単位が１トラック（１回転）を超える場合と同様に、リフレッシュの単位ｕ［回転］を、次式
０＜ｕ≦１−ｆ（ｔ1＋ｔ2）［回転］    （４）
のように求めることができる。
【０１６１】
リフレッシュの単位の最適化を、より一般的に表すために、ｋを１以上の整数として、リフレッシュの単位を（ｋ−１）回転を超え、ｋ回転以下に最適化する場合を想定する。この場合、リフレッシュの単位ｕ［回転］を、次式
ｋ−１＜ｕ≦ｋ−ｆ（ｔ1＋ｔk+1）［回転］  （５）
のように求めることができる。つまり、リフレッシュの単位ｕは、ｔ1にｔk+1を加算した値（ｔ1＋ｔk+1）に基づいて決定される。ここで、ｔ1は上述のようにトラックスキューの値に相当し、ｔk+1はリードアクセスが完了した位置から当該リードアクセスで読み出されたデータを書き込むためのライトアクセスの開始位置にヘッド１０２を移動させるのに必要な時間に相当する。
【０１６２】
例えば、ｆ＝５４００［ｒｐｍ］＝９０［回転／ｓ］、ｔ1＝２．０［ｍｓ］、ｔ2＝２．２［ｍｓ］、ｔ3＝２．４［ｍｓ］のＨＤＤ１００であれば、ｋが１の場合には、
０＜ｕ≦１−９０×（２．０＋２．２）×１０-3＝０．６２２［回転］
となる。また、ｋが２の場合には、
１＜ｕ≦２−９０×（２．０＋２．４）×１０-3＝１．６０４［回転］
となる。
【０１６３】
いずれの場合とも、１回のリフレッシュでのアクセス量を、これらの回転数を超えずにアクセスすることが可能なセクタ（ブロック）数にすればよい。セクタ数の算出にあたっては、アクセス範囲に含まれるトラック渡り部分にはアクセス可能なセクタがないことを考慮する必要がある。
【０１６４】
なお、本発明は、上記実施形態またはその変形例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態またはその変形例に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態またはその変形例に示される全構成要素から幾つかの構成要素を削除してもよい。
【符号の説明】
【０１６５】
１００…磁気ディスク装置（ＨＤＤ）、１０１…ディスク、１０２…ヘッド、１１３…ＲＡＭ、１１４…フラッシュＲＯＭ、１１５…ＣＰＵ（コントローラ）、２０１…トラック、４００…ライトカウントテーブル、５００…トラックシフトテーブル。
【図１】
2010182406.tif 000003
【図２】
2010182406.tif 000004
【図３】
2010182406.tif 000005
【図４】
2010182406.tif 000006
【図５】
2010182406.tif 000007
【図６】
2010182406.tif 000008
【図７】
2010182406.tif 000009
【図８】
2010182406.tif 000010
【図９】
2010182406.tif 000011