JP2007323377A - 記録装置、管理データの書き込み方法および管理データの修復方法 - Google Patents

Abstract

【課題】管理データを記録媒体に二重に記録する際にオーバーヘッドが大きくなることを防止すると共に、電源遮断時における管理データの修復を適切に行う。
【解決手段】リクエスト内容判別部２０２は、パーティションに関わる情報を元に、ＨＤＤ１００に書き込むデータが管理データであるかファイルデータであるかの判別を行う。二重書き込み制御部２０４は、リクエストが管理データに係るものであれば、管理データをＨＤＤ１００の正管理データ領域に書き込むと共に、その後当該管理データをＨＤＤ１００の副管理データ領域に書き込む。ドライバレベルで二重書き込み処理を実現する。電源遮断後の起動時には、ＨＤＤ１００内の最終書き込みＬＢＡデータに基づき、電源遮断時に最後に書き込みが行われていた領域を判別し、その結果に基づいて、正副管理データを修復する。
【選択図】図３

Description

この発明は、ファイルシステム（FileSystem）に基づきファイルデータをドライバにより制御されるＨＤＤ(Hard Disk Drive)などの記録媒体に記録する記録装置、それに適用される管理データの書き込み方法および修復方法に関する。

詳しくは、この発明は、ドライバまたは記録媒体が、管理データの書き込み時には、記録媒体の各領域の利用用途情報に基づいて管理データであることを認識し、この管理データを正副管理データ領域の双方に書き込む構成とすることによって、管理データの二重書き込みによってオーバーヘッドが大きくなることを防止するようにした記録装置等に係るものである。

また、この発明は、記録媒体にファイルデータおよび正副管理データを記録する他に、最終書き込み位置のデータを記録し、データの書き込み中に電源の遮断があったとき、記録媒体の各領域の利用用途情報および最終書き込み位置のデータに基づいて記録媒体のいずれの領域への書き込み中に電源の遮断があったかを判断し、この判断結果に応じて正副管理データ領域に記録されている管理データの修復を行う構成とすることによって、管理データの修復を適切に行い得るようにした記録装置等に係るものである。

ＨＤＤを搭載するシステムにおいては、近年、映像のデジタル録画／再生のニーズが高い。このような映像のデジタル録画／再生（ストリーム録画／再生）を行うには、高いスループットが要求される。高画質のストリームを１つ扱うにはシステムとして３ＭＢ／secのスループットが必要となる。ファイルシステム、ＨＤＤへはそれよりも高いスループットが要求される。さらに、複数ストリームの録画、再生を行う場合にはさらに厳しいスループットが要求される。一般的に、録画、再生のストリーム数が増加すると、スループットは指数関数的に減少する傾向にある。

ファイルシステム、ＨＤＤを搭載した家電機器が爆発的に普及し、外的（停電など）、内的（温度異常など）からなる障害発生による電源遮断後の機器の早期回復のニーズがＰＣより高い。また、修復時における処理により記録済みコンテンツが破棄されることは望まれていない。

ここで、ファイルシステム、ＨＤＤに対する要求として、（１）複数ストリームを扱える高いスループット性能、（２）高速な障害発生からの復帰／修復、（３）障害からの記録済みコンテンツの保護、がある。

ファイルシステムの復旧の高速化を目指した技術として、代表的なものは、ジャーナリングファイルシステム（JournalingFileSystem）である。ジャーナリングファイルシステムの主な機能として、ライト（Write）トランザクションにおけるログの生成と記録がある。

ログの内容はライトトランザクションで更新される管理データの変更履歴である。ファイルシステムによっては、管理データの変更内容までを履歴として残す。ジャーナリングファイルシステムは、ファイルシステムの復旧、修復の際にこのログを参照して障害が発生している可能性のある管理データを判別し、その管理データの内容をチェックして、不整合がある場合は、関連する管理データの別の内容を参照し、不整合がある管理データを修正してファイルシステムの整合性を保つことを行う。

上述のログはログファイルとして記録媒体に記録される。ここで、記録媒体は管理データが記録される記録媒体上もしくは別記録媒体でもよい．ジャーナリングファイルシステムが記録媒体に書き出すデータは、管理データ、ファイル（File）データ、およびログデータである。

この３つのデータは記録媒体への反映順序（書出し順序）を正確に守る必要がある。順序としては、ファイルデータ、ログデータを記録媒体へ反映させた後に、管理データを反映させる必要がある。さもなければ、「ファイルデータが古い内容のまま正しいファイルとして扱われてしまう」、「修復処理の肝となるログと管理データの内容の乖離が大きくなり修復に時間がかかる」、「ファイルシステムとしての整合性を保つために正常なファイルすら破棄されてしまう」、という弊害が生じる。

さらに、障害発生時にログファイルが正常な状態であるという保障はなく、ログファイル自体に障害を生じている場合も考えられる。この場合の修復作業はログを用いずに管理データの内容を全てチェックして整合性を保つ必要があり、復旧には記録されている管理データの内容により時間が増加する傾向がある。

このように、ファイルシステム、ＨＤＤに対する、（２）高速な障害発生からの復帰／修復、（３）障害からの記録済みコンテンツの保護、の要求を満たすために、ジャーナリングファイルシステムを使用するには、ログを生成、記録（反映順序）するという処理を行わなくてはならないこと、ログファイルが正常であること等の要件をみたさなければ、要求を満たせないという問題がある。

ファイルシステムを使用するシステムにおいて、記録媒体として最も利用されているのがＨＤＤである。このＨＤＤは、ＨＤＤドライバにより制御されるホストコントローラ（HostController）に接続されている。

これらの各機能ブロックの集合を総称してＨＤＤユニット（HDDUnit）とした場合、近年このＨＤＤユニットは大容量化と高速化を目的とした技術向上が行われている。大容量化に関しては現在主流の５００ＧＢから数年後には１ＴＢという容量が見込まれており、ファイルシステムが管理する対象であるブロック数が増加する。

高速化技術に関してはＨＤＤユニットへの読み書き要求を各ブロック内でバッファ/キャッシュし、ＨＤＤ内部でヘッドのシークを最小に抑える、読み書き要求の発行や応答をまとめることにより効率よく読み書きを行う、などの高速化目指した取組みがなされておいる。

これらは、リオーダリング、ＮＣＱ(NativeCommand Queuing)、ＴＣＱ(Tagged Command Queuing)、クラスタリングといった技術として一般化されている。これらの技術の肝となるのが要求をキューイング（Queuing）し、読み書きのために最適化して次の機能ブロックに対して要求を発行するというものである。これに従いＨＤＤユニットが持つバッファ/キャッシュサイズも増加傾向にある。

要求が各機能ブロックでキューイングされることにより、アプリケーション（Application）からファイルシステム、ＨＤＤユニットへの読み書き要求を行っても、記録媒体へ読み書きが終了するまでにタイムラグが生じる。バッファ/キャッシュサイズの増加にともないキューイングされる要求も増加し、タイムラグも増加する。

上述したように、ＨＤＤユニットではキューイングにより読み書き要求の順序の入れ替え、集約が行われ、ジャーナリングファイルシステムが望む要件が満たされない状況が発生する。さらに、ログファイルが使用できない場合のファイルシステムの復旧／修復に関しても、ＨＤＤの容量が増え管理する対象が増加にするために修復にかかる時間が増加するという問題がある。

この問題への対処方法としては、ＨＤＤユニットに対して強制的にバッファ／キャッシュされているデータを記録メディアへ同期させることが考えられる。しかし、これはキューイングを使用しないと等価であり、ＨＤＤの高速化を犠牲にするという問題ある。

上述したように、ジャーナリングファイルシステムが目的とする、（２）高速な障害発生からの復帰／修復、（３）障害からの記録済みコンテンツの保護と、ＨＤＤが目的とする（１）複数ストリームを扱える高いスループット性能とは技術的に相反しており、双方を組みこむ機器においてはトレードオフの関係となっている。

さらに、上述したようにＨＤＤの高速化が行われて行く中で、ファイルシステム、ＨＤＤドライバの処理(ＣＰＵ処理)時間が全体に対するスループットへの影響が大きくなってきている．特に、家電においては組込まれるＣＰＵのメインストリームはＰＣより格段に性能(周波数、キャッシュ)が劣り、その影響が大きい。ＰＣや旧来のＨＤＤを使用している分にはＨＤＤへのデータの読み書き(ＩＯ処理)による待ち時間(ＩＯ待ち時間)中に次のＣＰＵ処理が収まっているが、非力なＣＰＵと高速なＨＤＤの組み合わせでは、ＩＯ待ち時間が短くＣＰＵ処理が長くなる傾向にある。特に、複数ストリームを扱う機器では重大な問題となる。

特許文献１には、ファイルの実データを記録した場所を示す情報（管理データ）を正規情報および予備情報として記録媒体に二重に記録しておき、正規情報に障害が発生して読めなくなった場合に、予備情報を用いて正規情報の復旧を可能とすることが記載されている。
特開２００３−６０１７号公報

上述した特許文献１のようにファイルシステムの管理データを記録媒体に二重に記録しておくものでは、上述したジャーナリングファイルシステムのようにログデータを用いてファイルシステムを復旧する場合に生じる問題はなくなる。

しかし、記録媒体にファイルデータ（実データ）を記録する都度、それに対応して管理データを当該記録媒体に記録する必要があり、この二重書き込みの処理がアプリケーションレベルで行われるものであり、オーバーヘッドが大きくなるという問題がある。

また、この特許文献１に記載される技術では、正規情報が読めなくなった場合に、予備情報に基づいて正規情報を復旧するものであるが、正規情報が読める場合であっても、その内容が正しい状態にあるとは限らない。

この発明の目的は、ファイルシステムの管理データを記録媒体に二重に記録する際にオーバーヘッドが大きくなることを防止することにある。また、この発明の目的は、記録媒体に管理データを二重に記録するものにあって電源遮断時における管理データの修復を適切に行うことにある。

この発明の概念は、
ファイルシステムに基づきファイルデータをドライバにより制御される記録媒体に記録する記録装置であって、
上記記録媒体は、少なくとも上記ファイルデータを記録するファイルデータ領域と、上記ファイルシステムの管理データをそれぞれ記録する正管理データ領域および副管理データ領域を有し、
上記ドライバまたは上記記録媒体は、上記記録媒体の各領域の利用用途情報が格納された情報格納部を有し、
上記ドライバまたは上記記録媒体は、上記管理データの書き込み時には、上記情報格納部に格納されている利用用途情報に基づいて管理データの書き込みであることを認識し、該管理データを上記記録媒体の正管理データ領域および副管理データ領域の双方に書き込む
ことを特徴とする記録装置にある。

この発明においては、ファイルシステムに基づいて、ファイルデータが記録媒体に記録される。この記録媒体はドライバにより制御される。記録媒体は、少なくともファイルデータを記録するファイルデータ領域と、ファイルシステムの管理データをそれぞれ記録する正管理データ領域および副管理データ領域を有している。

ファイルシステムにより記録媒体のファイルデータ領域にファイルデータの記録が行われるとき、それに関連して記録媒体の正、副管理データ領域に管理データの記録が行われる。

この場合、ドライバまたは記録媒体では、記録媒体の所定領域への所定データの書き込みが指示されるとき、記録媒体の各領域の利用用途情報に基づいて、つまり所定領域がファイルデータ領域であるか管理データ領域であるかにより、その所定データがファイルデータであるか管理データであるかが認識される。

そして、ドライバまたは記録媒体の処理により、記録すべき所定データが管理データであるときは、当該所定データが所定領域（正管理データ領域）に記録されると共に、副管理データ領域にも記録される。例えば、副管理データ領域の書き込み位置（例えば記録媒体がＨＤＤであるときはＬＢＡ）は、正管理データ領域の書き込み位置に予め設定されているオフセット値を加えることで得られる。

このように、ドライバまたは記録媒体が、管理データの書き込み時には、記録媒体の各領域の利用用途情報に基づいて管理データであることを認識し、この管理データを正副管理データ領域の双方に書き込む構成であり、その二重書き込みのための処理をドライバレベルあるいは記録媒体レベルで行うことから、上位階層の処理で行うものに比べてオーバーヘッドを小さくできる。

また、この発明の概念は、

ファイルシステムに基づきファイルデータを記録媒体に記録する記録装置であって、

上記記録媒体は、少なくとも上記ファイルデータを記録するファイルデータ領域と、上記ファイルシステムの管理データをそれぞれ記録する正管理データ領域および副管理データ領域と、最終書き込み位置のデータを記録する最終位置データ記録領域とを有し、

データの書き込み中に電源の遮断があったとき、上記記録媒体の各領域の利用用途情報および上記最終位置データ記録領域に記録されている最終書き込み位置のデータに基づいて上記記録媒体のいずれの領域への書き込み中に上記電源の遮断があったかを判断し、該判断結果に応じて上記正管理データ領域および上記副管理データ領域に記録されている管理データの修復を行う管理データ修復部を備える

ことを特徴とする記録装置にある。

この発明においては、ファイルシステムに基づいて、ファイルデータが記録媒体に記録される。この記録媒体はドライバにより制御される。記録媒体は、少なくともファイルデータを記録するファイルデータ領域と、ファイルシステムの管理データをそれぞれ記録する正管理データ領域および副管理データ領域と、最終書き込み位置のデータを記録する最終位置データ記録領域を有している。

データの書き込み中に電源の遮断があったとき、記録媒体の各領域の利用用途情報および最終書き込み位置のデータに基づいて、記録媒体のいずれの領域への書き込み時に電源の遮断があったかが判断される。そして、その判断結果に応じて正副管理データ領域に記録されている管理データの修復が行われる。

例えば、正管理データ領域への書き込み中に上記電源の遮断があったときは、副管理データ領域の内容が正管理データ領域にコピーされることで修復が行われる。また例えば、副管理データ領域への書き込み時に上記電源の遮断があったときは、正管理データ領域の内容が副管理データ領域にコピーされることで修復が行われる。

このように、記録媒体のいずれの領域への書き込み時に電源の遮断があったかの判断結果に応じて正副管理データ領域に記録されている管理データの修復が行われることで、正副管理データを適切に修復でき、従ってファイルシステムの復旧を適切に行い得る。

この発明によれば、ドライバまたは記録媒体が、管理データの書き込み時には、記録媒体の各領域の利用用途情報に基づいて管理データであることを認識し、この管理データを正副管理データ領域の双方に書き込む構成とするものであり、管理データの二重書き込みによってオーバーヘッドが大きくなることを防止できる。

また、この発明によれば、記録媒体にファイルデータおよび正副管理データを記録する他に、最終書き込み位置のデータを記録し、電源の遮断があったとき、記録媒体の各領域の利用用途情報および最終書き込み位置のデータに基づいて記録媒体のいずれの領域への書き込み時に電源の遮断があったかを判断し、この判断結果に応じて正副管理データ領域に記録されている管理データの修復を行うものであり、管理データの修復を適切に行うことができる。

以下、図面を参照しながら、この発明の実施の形態について説明する。図１は、実施の形態としての記録装置１０の構成を示している。この記録装置１０は、ソフトウェア（ＳＷ）部分と、ハードウェア（ＨＷ）部分とで構成されている。

ＳＷ部分は、アプリケーション（Application）１０６と、システムコールＩ／Ｆ（SystemCall I/F）１０７と、ファイルシステム（FileSystem）１０８と、ブロックナンバー（BlockNo）／ＬＢＡ(Logical Block Addressing)変換処理部１１０と、ＨＤＤドライバ（Driver）１１１からなっている。

ＨＷ部分は、ホストコントローラ１１４と、記録媒体を構成するＨＤＤ１００とからなっている。上述したＨＤＤドライバ１１１は、ホストコントローラ１１４を介して、ＨＤＤ１００を制御する。ＨＤＤ１００は、データが保存されるディスクメディア１０４を有し、このディスクメディア１０４にファイルデータ１０１、管理テーブル１０２、パーティションテーブル（Partition Table）１０３を記録すると共に、不揮発なメモリ空間上に最終書込みＬＢＡデータ１０５を記録する。

ＨＤＤ１００に記録されている上述のデータは電源が遮断されても永続的に保たれている。また、管理テーブル１０２には、管理データ１０９がデータの種類毎にまとめられて複数格納されている。管理データ１０９のデータの種類には、例えばフリーブロックの管理テーブル、ファイル名、格納先の管理テーブル、ファイルシステムのバージョンナンバー等がある。
本実施の形態では、管理テーブル１０２の２重書き込みを行うが、説明上、それぞれを正および副として識別する。

図２は、ＨＤＤ１００のパーティション構造を示している。パーティションは最小３つとする。１つは管理テーブル１０２の正の格納先とし、１つは管理テーブル１０２の副の格納先とし、１つはファイルの内容であるファイルデータ１０１の格納先とし、正管理データ領域３０１、副管理データ領域３０２、ファイルデータ領域３０３とする。正管理データ領域３０１と副管理データ領域と３０２のパーティションサイズは同じである。

図２では、パーティションを４つとしＬＢＡの中腹に正管理データ領域３０１と副管理データ領域３０２を設定し、これら管理データ領域３０１，３０２を挟むように、ファイルデータ領域３０３が存在する。ファイルデータ領域３０３は、２つのパーティションに分割されているが、連続したＬＢＡとして扱う。

図１において、アプリケーション１０６は、ファイルを扱うプログラムであり、ファイルデータ１１２を所有する。ファイルに対する操作は、アプリケーション１０６からシステムコールＩ／Ｆ１０７の関数を呼び出すことにより実行される。

システムコールＩ／Ｆは、ファイルシステム１０８に対し、アプリケーション１０６からのファイル操作にあったファイルシステム１０８の関数を、ファイル識別とファイルデータ１１２が格納されているメモリアドレスと、読み出し時にはファイルデータ１１２を格納するためのメモリアドレスとデータサイズ、処理に対するオプション／フラグなどを引数として呼び出す。

ファイルシステム１０８は、自身の初期化の際に、ＨＤＤ１００に記録されていた管理テーブル１０２から必要な管理データ１０９を読み込む。ファイルシステム１０８は、システムコールＩ／Ｆから呼び出しがあった機能に応じて、書き込みの場合は管理データ１０９を参照、検索し、操作対象となる管理データ１０９が格納されているファイルシステム１０８の管理単位であるブロックナンバーを特定する。

ファイルシステム１０８は、そのブロックナンバーに対して必要な書換えを行う。また操作対象となる管理データ１０９がない場合は、生成を行う。ファイルデータ１１２または管理データ１０９をＨＤＤ１００に書き込む際には、ファイルシステム１０８の管理単位であったフロックナンバーはブロックナンバー／ＬＢＡ変換処理部１１０に渡されてＬＢＡに変換される。ブロックナンバーとＬＢＡの変換テーブルはファイルシステム１０８の構築時に管理データの１つの種類として作成される。

ブロックナンバー／ＬＢＡ変換処理部１１０は、変換後のＬＢＡとファイルデータ１１２または管理データ１０９の格納メモリアドレスなど、読み込み書き込みに必要となる情報をリクエストとしてまとめて、ＨＤＤドライバ１１１に渡す。ＨＤＤドライバ１１１は、そのリクエストの情報を元にリクエスト内容を判別し、必要に応じて二重書き込み処理をおこない、その内容によってホストコントローラ１１４を制御する。ホストコントローラ１１４によって、ＨＤＤ１００に対してデータの送受信を行う。

図３は、管理データの二重書き込みの機能を、ＨＤＤドライバ１１１に実装した例を示している。図３に示すように、ＨＤＤドライバ１１１は、書き込みリクエストキュー(queue)２０１と、リクエスト内容判別部２０２と、パーティション利用用途情報格納部２０３と、二重書き込み制御部２０４と、コマンド生成部２０５と、ホストコントローラ制御部２０６とを有している。

ライトトランザクションを、図１および図３を使用して説明する。アプリケーション１０６がファイルデータ１１２をＨＤＤ１００に書き込む際、ファイルシステム１０８は、必要となる管理データ１０９を書き換え、書き換えられた管理データ１０９を、ファイルデータ１１２とは別のＨＤＤ１００へのリクエストとして、ＨＤＤドライバ１１１の書き込みリクエストキュー２０１に渡す。

リクエストの中には、ＨＤＤ１００のどのＬＢＡにその管理データ１０９を書くかのアドレス情報が入っている。ＨＤＤドライバ１１１は、パーティションテーブル１０３およびパーティション利用用途情報格納部２０３を参照する。ここで、パーティションテーブル１０３は単に各パーティションの区切りの情報を持つが、パーティション利用用途情報格納部２０３はさらに各パーティションの利用用途情報、つまりファイルデータを記録するための領域であるか管理テーブルを記録するための領域であるか等の情報を持っている。

リクエスト内容判別部２０２は、パーティションに関わる情報を元に、ＨＤＤ１００に書き込むデータが管理データ１０９であるかファイルデータ１１２であるかの判別を行う。リクエストが管理データ１０９に対するものであれば、管理データ１０９を正管理データ領域３０１に書き込む。

正管理データ領域３０１への管理データ１０９の書き込みが行われた後、当該管理データ１０９を、正管理データ領域３０１に書き込む際に使用したリクエストの内容にあるＨＤＤ１００のＬＢＡに対して、正管理データ領域３０１と副管理データ領域３０２のＬＢＡのオフセットを加えて、副管理データ領域３０２に書き込む。

この場合、正管理データ領域３０１に記録されている内容を副管理データ領域３０２に反映させることを意図するこれらの処理は、二重書き込み制御部２０４、コマンド生成部２０５、ホストコントローラ２０６で実現される。

ここで、管理データ１０９の正管理データ領域３０１への書き込みが終わらなければ、管理データ１０９の副管理データ領域３０２への書き込みは行われない。また、副管理データ領域３０２への管理データ１０９の書き込みが終了しなければ、次のリクエストの管理データ１０９の正管理データ領域３０１への書き込みは行わない。このように、管理データ１０９の正管理データ領域３０１、副管理データ領域３０２への書き込みの間で同期をとる。すなわち、これら正管理データ領域３０１および副管理データ領域３０２を同じ書き込み状態とする。

これに対して、リクエストがファイルデータ１１２に対するものであれば、当該ファイルデータをファイルデータ領域３０３に書き込む。

また、ＨＤＤ１００の最終書き込みＬＢＡデータ記録部２０７は、要求の内容からこれから書き込みを行う初めのＬＢＡと書き込みサイズを、最終書き込みＬＢＡデータ１０５と呼び、不揮発な領域に記録する。この場合、最終書き込みＬＢＡデータ１０５を、ディスクメディア１０４の所定領域に記録してもよく、あるいは別途備えられている不揮発性メモリに記録してもよい。

図４は、管理データ１０９、ファイルデータ１１２をＨＤＤ１００に書き込む際の、上述した処理の概略を示している。この書き込み処理では、管理データ１０９をＨＤＤ１００に書き込む際には、正管理データ領域３０１の書き込み内容が副管理データ領域３０２にも反映され、パーティションレベルでのミラーリングが行われる。

次に、図１に示す記録装置１０において、ライト（書き込み）トランザクション中に障害が発生して電源遮断が起きた場合における管理データの修復について説明する。図５は、電源遮断による管理データの修復パターンを示している。修復パターンとしては、パターン１とパターン２とがある。パターン１は、電源遮断のタイミングが、正管理データ領域への書き込み中であり、破壊状況が正管理データ領域の内容に不整合が発生している場合であって、その場合には修復方法としては、副管理データ領域の内容を正管理データ領域にコピーする方法が採られる。この場合には、修復後の状態としては、最後に発行したライトコマンドのデータが反映されていないものとなる。

パターン２は、電源遮断のタイミングが、副管理データ領域への書き込み中であり、破壊状況が副管理データ領域の内容に不整合が発生している場合であって、その場合には修復方法としては、正管理データ領域の内容を副管理データ領域にコピーする方法が採られる。この場合には、修復後の状態としては、最後に発行したライトコマンドのデータが反映されたものとなる。

図５Ａ，Ｂを用いて、本実施の形態におけるファイルシステムの復旧処理、つまり管理データの修復処理を、さらに説明する。

電源遮断後の記録装置１０の起動において、ＨＤＤ１００から最終書き込みＬＢＡデータ１０５を取得し、またパーティション情報とそのパーティションの利用用途情報を取得し、最後に書き込んでいたＬＢＡ（最終書き込みＬＢＡ）が、正管理データ領域３０１、副管理データ領域３０２、ファイルデータ領域３０３のいずれであるかを判別する。

最終書き込みＬＢＡがファイルデータ領域３０３であったときは、管理データの修復作業は行わずに、正管理データ領域３０１に格納されている管理データを元にファイルシステムをマウントする。

また、最終書き込みＬＢＡが正管理データ領域３０１であったときは、副管理データ領域３０２内の全データを、正管理データ領域３０１にコピーし、その後に正管理データ領域３０１に格納されている管理データを元にファイルシステムをマウントする。この場合の管理データの修復パターンは、上述した図５のパターン１に相当する。

図６Ａは最終書き込みＬＢＡが正管理データ領域３０１であったときのファイルシステムの状態を示しており、図６Ｂは修復後のファイルシステムの状態を示している。なお、図６は、ＨＤＤ１００には、管理データが書き込まれた後に、対応するファイルデータが書き込まれるものである。後述する、図７においても、同様である。

また、最終書き込みＬＢＡが副管理データ領域３０２であったときは、副管理データ領域３０２内の全データを、正管理データ領域３０１にコピーし、その後に正管理データ領域３０１に格納されている管理データを元にファイルシステムをマウントする。この場合の管理データの修復パターンは、上述したパターン２に相当する。

図７Ａは最終書き込みＬＢＡが副管理データ領域３０２であったときのファイルシステムの状態を示しており、図７Ｂは修復後のファイルシステムの状態を示している。

なお、上述した修復処理は、ソフトウェアでの実装、またはＨＤＤ１００内のファームとしての実装が可能である。

図１に示す記録装置１０によれば、ＨＤＤドライバ１００には管理データの二重書き込みの機能が実装されており、管理データ１０９の書き込み時には、当該機能により、管理データ１０９がＨＤＤ１００の正副の管理データ領域３０１，３０２に二重書き込みされるものであり、上位階層の処理で行うものに比べてオーバーヘッドを小さくできる。

またその際、正管理データ領域３０１に書き込む際に使用したリクエストの内容にあるＨＤＤ１００のＬＢＡに対して、正管理データ領域３０１と副管理データ領域３０２のＬＢＡのオフセットを加えて、副管理データ領域３０２へ管理データ１０９の書き込みを行うものであり、少ないＣＰＵ処理時間で二重書き込みを実現できる。

また、図１に示す記録装置１０によれば、ライトトランザクション中に電源遮断が起こった場合に、その後の起動時に、ＨＤＤ１００内の最終書き込みＬＢＡデータ記録部２０７の情報に基づいて、ＨＤＤ１００のいずれの領域への書き込み時に電源の遮断があったかを判断し、その判断結果に応じて管理データの修復を行っているので（図５〜図７参照）、管理データを適切に修復でき、従ってファイルシステムの復旧を適切に行うことができる。

なお、上述実施の形態においては、二重書き込みの機能をＨＤＤドライバ１１１に実装したものを示したが（図３参照）、この二重書き込みの機能をＨＤＤ１００に実装することも考えられる。

図８は、管理データの二重書き込みの機能を、ＨＤＤ１００に実装した例を示している。図８に示すように、ＨＤＤ１００は、コマンドキュー(queue)４０１と、コマンド内容判別部４０２と、パーティション利用用途情報格納部４０３と、二重書き込み制御部４０４と、メディア書き込み制御部４０５とを有している。

ライトトランザクションで、ＨＤＤドライバ１１４からホストコントローラ１１４を介して受け取る書き込みコマンドは、コマンドキュー４０１に入る。このコマンドの中には、ＨＤＤ１００のどのＬＢＡに書き込むかのアドレス情報が入っている。ＨＤＤ１００のコマンド内容判別部４０２は、パーティションテーブル１０３およびパーティション利用用途情報格納部４０３を参照し、これから書き込むデータが管理データ１０９かファイルデータ１１２かの判別を行う。

書き込みコマンドが管理データ１０９に対するものであれば、管理データ１０９を正管理データ領域３０１に書き込む。正管理データ領域３０１への管理データ１０９の書き込みが行われた後、当該管理データ１０９を、正管理データ領域３０１に書き込む際に使用したリクエストの内容にあるＨＤＤ１００のＬＢＡに対して、正管理データ領域３０１と副管理データ領域３０２のＬＢＡのオフセットを加えて、副管理データ領域３０２に書き込む。

この正管理データ領域３０１に記録されている内容を副管理データ領域３０２にも反映させることを意図する処理は、二重書き込み制御部４０４、メディア書き込み制御部４０５で実現される。

なお、書き込みコマンドがファイルデータ１１２に対するものであれば、ファイルデータ１１２を、ファイルデータ領域３０３に書き込む。

このように二重書き込みの機能がＨＤＤ１００に実装されるものにあっても、上述したように二重書き込みの機能がＨＤＤドライバ１１１に実装されるものと同様に、上位階層の処理で行うものに比べてオーバーヘッドを小さくできる。

また、上述実施の形態においては、記録媒体がＨＤＤ１００である記録装置１０にこの発明を適用したものであるが、この発明は、その他の記録媒体を使用するものにも同様に適用できることは勿論である。

この発明は、管理データの二重書き込みによってオーバーヘッドが大きくなることを防止でき、また電源の遮断があった場合にその管理データの修復を適切に行うことができるものであり、ファイルシステムに基づきファイルデータをＨＤＤなどの記録媒体に記録する記録装置に適用できる。

実施の形態としての記録装置の構成を示すブロック図である。 ＨＤＤのパーティション構造を説明するための図である。 二重書き込みの機能をＨＤＤドライバに実装した場合における、ＨＤＤドライバの機能ブロックを示す図である。 管理データ、ファイルデータの書き込み処理の概略を示す図である。 電源遮断による管理データの修復パターンを示す図である。 最終書き込みＬＢＡが正管理データ領域であったときのファイルシステムの修復前および修復後の状態を示している。 最終書き込みＬＢＡが副管理データ領域であったときのファイルシステムの修復前および修復後の状態を示している。 二重書き込みの機能をＨＤＤに実装した場合における、ＨＤＤの機能ブロックを示す図である

符号の説明

１０・・・記録装置、１０１・・・ファイルデータ、１０２・・・管理テーブル、１０３・・・パーティションテーブル、１０４・・・ディスクメディア、１０５・・・最終書き込みＬＢＡデータ、１０６・・・アプリケーション、１０７・・・システムコールＩ／Ｆ、１０８・・・ファイルシステム、１０９・・・管理データ、１１０・・・ブロックナンバー／ＬＢＡ変換処理部、１１１・・・ＨＤＤドライバ、１１２・・・ファイルデータ、１１３・・・パーティションテーブル、１１４・・・ホストコントローラ、２０１・・・書き込みリクエストキュー、２０２・・・リクエスト内容判別部、２０３・・・パーティション利用用途情報格納部、２０４・・・二重書き込み制御部、２０５・・・コマンド生成部、２０６・・・ホストコントローラ制御部、２０７・・・最終書き込みＬＢＡデータ記録部、３０１・・・正管理データ領域、３０２・・・副管理データ領域、３０３・・・ファイルデータ領域、４０１・・・コマンドキュー、４０２・・・コマンド内容判別部、４０３・・・パーティション利用用途情報格納部、４０４・・・二重書き込み制御部、４０５・・・メディア書き込み制御部

Claims (6)

1. ファイルシステムに基づきファイルデータをドライバにより制御される記録媒体に記録する記録装置であって、
   上記記録媒体は、少なくとも上記ファイルデータを記録するファイルデータ領域と、上記ファイルシステムの管理データをそれぞれ記録する正管理データ領域および副管理データ領域を有し、
   上記ドライバまたは上記記録媒体は、上記記録媒体の各領域の利用用途情報が格納された情報格納部を有し、
   上記ドライバまたは上記記録媒体は、上記管理データの書き込み時には、上記情報格納部に格納されている利用用途情報に基づいて管理データの書き込みであることを認識し、該管理データを上記記録媒体の正管理データ領域および副管理データ領域の双方に書き込む
   ことを特徴とする記録装置。
2. ファイルシステムに基づきファイルデータをドライバにより制御される記録媒体に記録し、該記録媒体は上記ファイルデータを記録するファイルデータを記録領域と上記ファイルシステムの管理データをそれぞれ記録する正管理データ領域および副管理データ領域を有する記録装置における管理データの書き込み方法であって、
   上記ドライバまたは上記記録媒体が上記ファイルシステムによる上記記録媒体の所定領域への所定データの書き込み指示が上記管理データの書き込みであるか否かを、上記記録媒体の各領域の利用用途情報に基づいて判定する判定ステップと、
   上記判定ステップで上記管理データの書き込みであると判定されるとき、上記ドライバまたは上記記録媒体が上記所定データを上記正管理データ領域および副管理データ領域に順次書き込む書き込みステップと
   を備えることを特徴とする管理データの書き込み方法。
3. ファイルシステムに基づきファイルデータを記録媒体に記録する記録装置であって、
   上記記録媒体は、少なくとも上記ファイルデータを記録するファイルデータ領域と、上記ファイルシステムの管理データをそれぞれ記録する正管理データ領域および副管理データ領域と、最終書き込み位置のデータを記録する最終位置データ記録領域とを有し、
   データの書き込み中に電源の遮断があったとき、上記記録媒体の各領域の利用用途情報および上記最終位置データ記録領域に記録されている最終書き込み位置のデータに基づいて上記記録媒体のいずれの領域への書き込み中に上記電源の遮断があったかを判断し、該判断結果に応じて上記正管理データ領域および上記副管理データ領域に記録されている管理データの修復を行う管理データ修復部を備える
   ことを特徴とする記録装置。
4. 上記管理データ修復部は、上記記録媒体の正管理データ領域への書き込み中に上記電源の遮断があったときは、上記副管理データ領域の内容を上記正管理データ領域にコピーする
   ことを特徴とする請求項３に記載の記録装置。
5. 上記管理データ修復部は、上記記録媒体の副管理データ領域への書き込み中に上記電源の遮断があったときは、上記正管理データ領域の内容を上記副管理データ領域にコピーする
   ことを特徴とする請求項３に記載の記録装置。
6. ファイルシステムに基づきファイルデータを記録媒体に記録し、該記録媒体は上記ファイルデータを記録するファイルデータを記録領域と上記ファイルシステムの管理データをそれぞれ記録する正管理データ領域および副管理データ領域と、最終書き込み位置のデータを記録する最終位置データ記録領域とを有する記録装置における管理データの修復方法であって、
   データの書き込み中に電源の遮断があったとき、上記記録媒体の各領域の利用用途情報および上記記録媒体に記録されている最終書き込み位置のデータに基づいて上記記録媒体のいずれの領域への書き込み中に上記電源の遮断があったかを判断する判断ステップと、
   上記判断ステップの判断結果に応じて上記正管理データ領域および上記副管理データ領域に記録されている管理データの修復を行う修復ステップと
   を備えることを特徴とする管理データの修復方法。

Images