JP2010092239A - ファイルシステム管理装置 - Google Patents

Abstract

【課題】記憶装置の検査処理を効率化してナビゲーション装置を高速に起動することが可能な「ファイルシステム管理装置及びファイルシステム管理方法」を提供すること。
【解決手段】ファイルシステム管理装置は、第１のファイル管理テーブルのデータ及び第２のファイル管理テーブルのデータを格納した記憶装置と、データを第１のサイズ毎に検査するファイルシステムとデバイスドライバとを有したデータ管理手段と、第１のサイズより大きな所定のサイズの第１のキャッシュ及び第２のキャッシュとを備える。データ管理手段は、第１のファイル管理テーブルから所定のサイズ毎のデータを第１のキャッシュに読み込み、第２のファイル管理テーブルから所定のサイズ毎のデータを第２のキャッシュに読み込み、第１のキャッシュに読み込んだデータと第２のキャッシュに読み込んだデータから第１のサイズ毎のデータを抽出して整合性を検査する。
【選択図】図７

Description

本発明は、システム起動の高速化に有用なファイルシステム管理装置に関する。

車載用のナビゲーション装置では、外部記憶装置としてハードディスクドライブ（ＨＤＤ）が使用されている。このＨＤＤは、電源投入後、ＨＤＤに格納されたデータの読み込みができるようになるまで数秒（２〜３秒）程度を要している。さらにその後、ハードディスクの内容を解析するために４〜５秒程度を要し、解析結果に基づいてナビゲーション装置が起動し、データを読み始め、所要の地図情報等が画面に表示されるまでに１５秒程度要している。

このようなＨＤＤ内には、地図データベースの他にもユーザーが設定したデータや、他の車載機器（ＦＭ／ＡＭチューナーやＣＤプレーヤー等のオーディオ機器、ＤＶＤプレーヤーやＴＶ受信機等のオーディオ／ビデオ機器など）に関連した各種のデータ等が格納されている。このため、ナビゲーション装置の起動時に必要なデータをＨＤＤから読み込めるようになる時間が遅れると、それに応じて当該装置の起動時間が遅延することになる。

一般に、ＨＤＤ内に格納されているデータはWindows（登録商標）などのＯＳ管理下で使用する際には、ファイルを単位としてファイルシステムにより管理されている。ナビゲーション装置においても実際の地図データをＨＤＤから取得するため、ファイルに関する情報を読み込みファイルシステムによって検索される。

通常、ナビゲーション装置で使用される地図データは、ナビゲーションの操作中にデータが書き換えられることはないが、地点登録情報などはユーザーが任意に設定したり消去したりすることができる。このようなデータの書き換えが自由にできるファイルを管理する装置として、ファイルが更新や変更された場合に、ファイルに関する正しい情報の取得を可能とする技術がある。これに関連する技術として、例えば、ファイルの作成日付等のファイル情報をファイルと共に格納し、付加情報として同じファイル情報を格納しておき、これらのファイル情報を用いてファイルと付加情報の整合性のチェックを行う技術がある。
特開平９−３４７６４号公報

上述したように、システムを起動する際には、ＨＤＤをマウントしてＨＤＤに格納されている地図データや音楽データをシステムが取得するが、このマウント処理においてファイル管理テーブルのデータをファイルシステム内に読み込み、データが正常であるか否かをチェックしている。

近年、ＨＤＤの大容量化によって地図データも増大し、ファイル管理テーブルの容量も増加してきている。これに伴い、地図データ等の読み込み時間も従来よりかかり、システム起動が遅延してきている。

一方、データの正確性を向上させるために２つのファイル管理テーブルを備えた記憶装置がナビゲーション装置にも使用されており、２つのファイル管理テーブルのそれぞれのデータ間で整合がとれているか否かのチェックを行うようになっている。

このようなファイルシステムを使用する場合、データの正確性は向上するものの、チェックのための時間がかかり、システムの起動時間が１つのファイル管理テーブルを対象としたときよりもかかってしまう問題が発生している。

本発明は、かかる従来技術の課題に鑑みなされたものであり、記憶装置をマウントする際の検査処理を効率化してナビゲーション装置を高速に起動することが可能なファイルシステム管理装置及びファイルシステム管理方法を提供することを目的とする。

上述した従来技術の課題を解決するため、本発明の基本形態によれば、ファイルを所定の管理単位毎に管理する第１のファイル管理テーブルのデータ及び当該第１のファイル管理テーブルと同一サイズの第２のファイル管理テーブルのデータを格納した記憶装置と、前記ファイル管理テーブルのデータを第１のサイズ毎に検査するファイルシステムと前記記憶装置から前記ファイル管理テーブルのデータを取得するデバイスドライバとを有したデータ管理手段と、前記デバイスドライバが管理する前記第１のサイズより大きな所定のサイズの第１のキャッシュ及び第２のキャッシュとを備え、前記データ管理手段は、前記第１のファイル管理テーブルから前記所定のサイズ毎のデータを前記第１のキャッシュに読み込み、前記第２のファイル管理テーブルから前記所定のサイズ毎のデータを前記第２のキャッシュに読み込み、前記第１のキャッシュに読み込んだデータと前記第２のキャッシュに読み込んだデータから前記第１のサイズ毎のデータを抽出して整合性を検査することを特徴とするファイルシステム管理装置が提供される。

この形態に係るファイルシステム管理装置において、前記所定のサイズは、前記第１のサイズのｎ倍（ｎは２以上の自然数）であるようにしてもよく、前記第１のファイル管理テーブルと前記第２のファイル管理テーブルは連続した領域に格納されているようにしてもよい。

本発明のファイルシステム管理装置によれば、ファイルを所定の管理単位毎に管理するファイル管理テーブルを２つ備えた記憶装置に対して、ファイルシステムは２つのファイル管理テーブルのデータを所定の単位毎に整合性のチェックをしている。このデータはデバイスドライバを介して取得するが、デバイスドライバにおいて所定の単位よりも２倍のサイズのデータを取得し、デバイスドライバが管理するキャッシュに格納するようにしている。ファイルシステムの要求に応じて、キャッシュに格納されたデータから所定の単位毎のデータを送信するようにしている。これにより、データ管理手段が記憶装置にアクセスする回数が２分の１に減り、ファイル管理テーブルのデータの整合性をチェックする時間を短縮することが可能となる。

また、本発明の他の形態によれば、上記の形態に係るファイルシステム管理装置において実施されるファイルシステム管理方法が提供される。その一形態に係るファイルシステム管理方法は、前記ファイルシステムは、前記デバイスドライバに対して前記第１のファイル管理テーブルから前記第１のサイズの第１のデータの取得及び前記第２のファイル管理テーブルから前記第１のサイズの第２のデータの取得を要求するステップと、取得した前記第１のデータと第２のデータとの整合性を検査するステップとを有し、前記第１のデータ及び第２のデータの取得を要求された前記デバイスドライバは、前記第１のサイズを当該第１のサイズより大きな第２のサイズに変換するステップと、前記記憶装置の第１のファイル管理テーブルから前記第２のサイズのデータを取得して前記第１のキャッシュに格納するステップと、前記ファイルシステムに前記第１のキャッシュに格納したデータのうち前記第１のサイズのデータを送信するステップと、前記記憶装置の第２のファイル管理テーブルから前記第２のサイズのデータを取得して前記第２のキャッシュに格納するステップと、前記ファイルシステムに前記第２のキャッシュに格納したデータのうち前記第１のサイズのデータを送信するステップと、を有する。

また、この形態に係るファイルシステム管理方法において、前記デバイスドライバは、前記第１のキャッシュにデータを格納し、前記第１のサイズのデータを送信した後、前記ファイルシステムからの要求に応じて残りの前記第１のサイズのデータを送信するステップと、前記第２のキャッシュにデータを格納し、前記第１のサイズのデータを送信した後、前記ファイルシステムからの要求に応じて残りの前記第１のサイズのデータを送信するステップと、をさらに有するようにしてもよい。

以下、本発明の実施形態について、添付の図面を参照して説明する。

図１は、本発明の一実施形態に係るファイルシステム管理装置５０のブロック構成図を示している。また、図２は、ファイルシステム管理装置における主要部を機能ブロックで示した図である。本実施形態では、本発明に係るファイルシステム管理装置５０を車載システムに適用した場合を示している。

本実施形態に係るファイルシステム管理装置５０は、基本的には、車載システム全体で共有される外部記憶装置として機能するハードディスクドライブ（ＨＤＤ）１０と、このＨＤＤ１０のデータ管理を行うマイクロコンピューター（マイコン）２０とを備えて構成されており、さらにこの構成に、ＨＤＤ１０及びマイコン２０にそれぞれ所要の電源電圧を供給する電源３０が付加されている。

マイコン２０は、中央処理演算装置（ＣＰＵ）２２と、読み出し専用メモリ（ＲＯＭ）２３と、ランダムアクセスメモリ（ＲＡＭ）２４と、デバイスコントローラ２５と、電源制御部２６とを備えており、マイコン２０内の伝送路（内部バス２７）を介して各機能ブロック２２〜２６が相互に接続されている。これにより、各機能ブロック２２〜２６間でデータや制御信号等の授受が行われるようになっている。

また、マイコン２０のＣＰＵ２２には、マイコン外部の伝送路（外部バス４０）を介して、起動対象のシステムを構成する各車載機器（図示の例では、ナビゲーションユニット４１、オーディオユニット４２）が接続されている。

ＨＤＤ１０（ハードディスク上）には、図示のように各車載機器４１，４２に関連した地図データやオーディオデータが格納されており、さらにユーザーが設定した情報（ユーザ設定データ）等も格納されている。これらのデータは、起動対象のシステム（この場合、ナビゲーションユニット４１、オーディオユニット４２）の起動時に必要なデータ（例えば、電源投入時に最初に実行されるプログラム等）を含んでおり、後述するようにWindowsの管理下で使用される一般的なファイルシステムであるＦＡＴ(File Allocation Table)ファイルシステムの構造に従って格納されている。特に、ＦＡＴは２つ用意され、ＨＤＤ１０内に保存されているデータをシステムに読み込む際にデータの正当性を保証するようにしている。

マイコン２０においてＣＰＵ２２は、本装置５０全体を制御するものであり、ＲＯＭ２３から読み出したプログラムを実行することで、ＨＤＤ１０に格納したファイルへのアクセス、ファイルの削除、ＨＤＤへのファイルの新規作成などを管理する中枢機能を担っている。特に本発明に関連する処理として、電源投入時において２つのＦＡＴのデータの比較処理を高速に制御する。

ＲＯＭ２３には、ＣＰＵ２２が行う処理を規定したプログラムが格納されている。ＲＡＭ２４は、ＣＰＵ２２が各種処理を行う際に使用するワーク用メモリであり、デバイスコントローラ２５を機能させるためのデバイスドライバが格納されている。また、デバイスドライバが管理するメモリとしても機能する。

デバイスコントローラ２５は、ＣＰＵ２２からの制御に基づいてＨＤＤ１０に対しデータの読み出し及び書き込みを制御するためのブロックである。

要求電源制御部２６は、ＣＰＵ２２からの制御に基づいて電源３０をオン／オフ制御するためのブロックである。電源３０は、オン状態とされたときに、ＨＤＤ１０とマイコン２０内の各機能ブロック（ＣＰＵ２２、ＲＯＭ２３、ＲＡＭ２４、デバイスコントローラ２５）にそれぞれ所要の電源電圧を供給する。

図２は、図１のファイルシステム管理装置５０における機能ブロックを示している。ファイルシステム管理装置５０において、機能的にはＣＰＵ２２、ＲＯＭ２３、ＲＡＭ２４が相互に協働して動作することによりファイルを管理するファイルシステム２８を形成している。また、デバイスドライバ２９は、デバイスコントローラ２５を介してＨＤＤ１０を駆動し、ＨＤＤ１０との間でデータの入出力を行う機能を担っている。

このデバイスドライバは、ＨＤＤ１０に格納された２つのファイル管理テーブルのそれぞれのデータを所定の単位毎に格納するキャッシュバッファを管理している。また、ＣＰＵ（ファイルシステム）からの所定の単位毎のＦＡＴのデータを送信する要求に対して、そのサイズを変更する機能を有している。

ＨＤＤ１０は、上述したように一般的なファイルシステムであるＦＡＴファイルシステムの構造を有している。ＦＡＴファイルシステムでは、ハードディスクを「クラスタ」と呼ばれる論理単位に分割し、データサイズに応じてこのクラスタを１つもしくは複数割り当てることでファイルを実現している。このとき、あるファイルを構成しているのはどのクラスタか（１つのファイルを構成するクラスタは必ずしも連続している必要はない）、あるクラスタは現在使用中か、又は未使用かといった情報を、管理領域であるＦＡＴに記録して管理する。

図３は、ＨＤＤ１０内に構築されるＦＡＴファイルシステムの構造を示したものである。このＦＡＴファイルシステムの構造自体は当業者には知られているので、その内容の詳細な説明については省略する。

図３は、一つのパーティション内の論理レイアウトの一例を概念的に示している。ＢＰＢ（BIOS ParameterBlock）にはＨＤＤのフォーマットに関する各種情報が示されている。ＢＰＢに続いて、ＦＡＴ０領域及びＦＡＴ０と同一の内容が記録されるＦＡＴ１領域が配置されている。ＦＡＴ１領域に続いて、各ファイルをなすクラスタの先頭アドレスを示すルートディレクトリ領域があり、これに続いて、ファイル領域が配置され、クラスタを単位とするファイルデータが記憶される。

このような構造を有したＦＡＴファイルシステムにおいて、例えば、ファイル領域内のファイルＡを読む場合には、以下の手順のようにＨＤＤ１０へのアクセスが発生する。

先ず、ＭＢＲ(Master Boot Record)のパーティション・テーブルから、ＨＤＤ１０内の分割された領域（例えばパーティション０〜３）の分割情報を読む。次に、その分割情報に基づいて該当するパーティションの論理セクタ０（ＬＢＡ０）を解析し、そのＢＰＢから当該パーティションの内容情報を読む。

次に、その内容情報に基づいて論理セクタｐ（ＬＢＡｐ）を解析し、ルートディレクトリを読んで該当するファイル名を探す。次に、論理セクタｍ（ＬＢＡｍ）を解析してＦＡＴ０テーブルを参照し、該当するファイルＡが実際にはＨＤＤ１０上のどの位置（アドレス）に格納されているかを特定する。

最後に、論理セクタｑ（ＬＢＡｑ）を解析し、該当するファイルＡのデータを読む。

図３に示すＦＡＴファイルシステムの構造から分かるように、ファイルＡが書き換えられると、その書き換え後のファイルＡのＨＤＤ１０上での位置（アドレス）やサイズが更新されるため、その更新により、ルートディレクトリやＦＡＴ（ＦＡＴ０）テーブルのどの部分を読むべきかが変わってきくる。また、ファイルが書き換えられたり移動したりすることによりＦＡＴテーブルの内容も書き換えられることになるが、この書き換えが終了する前に電源がオフになると、正常なデータの書き換えが行われなくなる。

図４は、ＨＤＤ１０のＦＡＴデータの領域を示したマッピングテーブルであり、図４（ａ）はＨＤＤ１０が正常状態のときのＦＡＴテーブルの一例を示し、図４（ｂ）は、ＨＤＤ１０への書き込みの途中で電源がオフになった場合のＦＡＴテーブルの一例を示している。ＦＡＴは３２セクタ毎に管理されているものとすると、ＨＤＤ１０への書き込みにおいて３２セクタ毎にＦＡＴ０の領域（１），ＦＡＴ１の領域（２）、ＦＡＴ０の領域（３）、ＦＡＴ１の領域（４）のように交互にデータが記録される。図４（ａ）に示すように、正常状態であれば、領域（１）と領域（２）には同一データが記録され、領域（３）と領域（４）には同一データが記録される。

一方、図４（ｂ）は、ＦＡＴ１の領域（４）への書き込みの途中で電源がオフになったときの状態を示している。領域（１）と領域（２）には同一のデータが記録されているが、領域（４）にデータが記録されている途中で電源がオフされたため、領域（４）の途中までの領域αは正常であるが、それ以降の領域βには正しいデータが記録されていない。

このような状態のＨＤＤ１０をナビゲーション装置等にマウントする際に、ＦＡＴ０とＦＡＴ１に記録されているデータが相互に整合がとれているか否かをチェックしている。

上述した本実施形態のファイルシステム管理装置５０において、ＨＤＤ１０は「記憶装置」に、ＣＰＵ２２はＲＯＭ２３、ＲＡＭ２４と協働して「データ管理手段」に、ＦＡＴ０は「第１のファイル管理テーブル」に、ＦＡＴ１は「第２のファイル管理テーブル」に、それぞれ対応している。

以下に、ファイルシステム管理装置５０が行うＦＡＴデータの整合性チェック処理について図５から図７を参照しながら説明する。

図５は、ファイルシステム２８が実施する整合性チェック処理の概要を示すフローチャートであり、図６は、ＦＡＴデータの整合性チェック処理の詳細なフローチャートである。また、図７は、図２の機能ブロックに対応させて図６の処理を説明した図である。

なお、ファイルシステム２８でＦＡＴデータのチェックを行う基準となるデータの単位（基準データ単位Ｄ１：例えば３２セクタ）は予め設定されているものとする。また、デバイスドライバ２９が管理するキャッシュバッファのサイズは、基準データ単位Ｄ１（第１のサイズ）の２倍に設定されているものとする。

まず、ファイルシステム２８が行う処理の概要について説明する。図５のステップＳ１１において、ＦＡＴ０とＦＡＴ１のデータを取得する。これらのデータはファイルシステム２８が整合性チェックをする基本単位毎に取得される。

次のステップＳ１２において、取得したＦＡＴ０のデータとＦＡＴ１のデータとの整合性をチェックする。次のステップＳ１３においてデータ間で不整合が見つかれば、ステップＳ１４において整合処理を行い、不整合でなければステップＳ１５に移行する。

ステップＳ１４において整合処理を行う。整合処理はＦＡＴ０に記録されているデータとＦＡＴ１に記録されているデータのどちらが正しいデータかを判定し、壊れたデータを正しいデータに書き換えることによって行う。

次のステップＳ１５では、ＦＡＴ０及びＦＡＴ１のすべてのデータの整合性チェックが終了したか否かを判定し、終了していなければ連続している次のデータを取得して整合性のチェックを継続する。

ファイルシステム２８においては上記した処理が行われるが、ＨＤＤ１０にはデバイスドライバ２９を介してアクセスしており、デバイスドライバ２９がＨＤＤ１０のＦＡＴ０及びＦＡＴ１に記録されているデータを読み込んでいる。

以下に、ファイルシステム２８及びデバイスドライバ２９が行うＦＡＴデータの整合性チェック処理の詳細について、図６のフローチャート及び図７の機能ブロック図を参照しながら説明する。なお、図７の機能ブロック図における（１）から（１４）の処理は、図６のフローチャートの処理に対応している。

まず、図６のステップＳ２１において、ファイルシステム２８からデバイスドライバ２９に、基準データ単位Ｄ１のＦＡＴ０のデータの取得を指示する。図７の処理（１）に対応している。

次のステップＳ２２において、デバイスドライバ２９は、ＨＤＤ１０に対するリード命令において指定するデータのサイズを基準データ単位Ｄ１の２倍のデータ単位Ｄ２（図７では、６４セクタ）に変換する。このデータ単位Ｄ２のデータをＦＡＴ０から取得して、デバイスドライバ２９が管理するキャッシュバッファＣ１に格納する。図７の処理（２）から（４）に対応している。

次のステップＳ２３において、デバイスドライバ２９は、キャッシュバッファＣ１に格納したデータのうち、基準データ単位Ｄ１（図７では、３２セクタ）のデータＤａをファイルシステム２８に送信する。図７の処理（５）に対応している。

次のステップＳ２４において、ファイルシステム２８からデバイスドライバ２９に、基準データ単位Ｄ１のＦＡＴ１のデータの取得を指示する。図７の処理（６）に対応している。

次のステップＳ２５において、デバイスドライバ２９は、ＨＤＤ１０に対するリード命令において指定するデータのサイズを基準データ単位Ｄ１の２倍のデータ単位Ｄ２（図７では、６４セクタ）に変換する。このデータ単位Ｄ２のデータをＦＡＴ１から取得して、デバイスドライバ２９が管理するキャッシュバッファＣ２に格納する。図７の処理（７）から（９）に対応している。

次のステップＳ２６において、デバイスドライバ２９は、キャッシュバッファＣ２に格納したデータのうち、基準データ単位Ｄ１のデータＤｃをファイルシステム２８に送信する。図７の処理（１０）に対応している。

次のステップＳ２７において、ファイルシステム２８はデータＤａとデータＤｃの整合性チェックを行う。

次のステップＳ２８において、データＤａとデータＤｃが整合していたか否かを判定する。整合していたときは、ステップＳ３０に移行し、整合していないときはステップＳ２９に移行してデータの整合処理をした後、ステップＳ３０に移行する。

次のステップＳ３０において、ファイルシステム２８からデバイスドライバ２９に、基準データ単位Ｄ１のＦＡＴ０のデータの取得を指示する。図７の処理（１１）に対応している。

次のステップＳ３１において、デバイスドライバ２９は、キャッシュバッファＣ１に格納したデータのうち、ステップＳ２３でファイルシステム２８に送信したデータＤａに続いて格納されている基準データ単位Ｄ１のデータＤｂをファイルシステム２８に送信する。図７の処理（１２）に対応している。

次のステップＳ３２において、ファイルシステム２８からデバイスドライバ２９に、基準データ単位Ｄ１のＦＡＴ１のデータの取得を指示する。図７の処理（１３）に対応している。

次のステップＳ３３において、デバイスドライバ２９は、キャッシュバッファＣ２に格納したデータのうち、ステップＳ２６でファイルシステム２８に送信したデータＤｃに続いて格納されている基準データ単位Ｄ１のデータＤｄをファイルシステム２８に送信する。図７の処理（１４）に対応している。

次のステップＳ３４において、ファイルシステム２８はデータＤｂとデータＤｄの整合性チェックを行う。

次のステップＳ３５において、データＤｂとデータＤｄが整合していたか否かを判定する。整合していたときは、ステップＳ３７に移行し、整合していないときはステップＳ３６に移行してデータの整合処理をした後、ステップＳ３７に移行する。

次のステップＳ３７において、ＦＡＴすべてのデータに対して整合性チェックが終了したか否かを判定し、すべてのデータを読み込んでいれば、本処理が終了し、すべてのデータを読み込んでいなければ、ステップＳ２１に戻り、ＦＡＴに記録されている次のデータを読み込んで本処理を継続する。

以上、図５から図７を参照して説明したように、本発明のファイルシステム管理装置５０によれば、ファイルを所定の管理単位毎に管理するファイル管理テーブルを２つ備えたＨＤＤ１０に対して、ファイルシステム２８は２つのファイル管理テーブルのデータを所定の単位毎に整合性のチェックをしている。このデータはデバイスドライバ２９を介して取得するが、デバイスドライバ２９において所定の単位よりも２倍のサイズのデータを取得し、デバイスドライバ２９が管理するキャッシュバッファに格納するようにしている。キャッシュバッファに格納されたデータからファイルシステム２８の要求する単位のデータを送信するようにしている。これにより、デバイスドライバ２９がＨＤＤ１０にアクセスする回数が２分の１に減り、ファイル管理テーブルのデータの整合性をチェックする時間を短縮することが可能となる。

なお、上記実施形態では、デバイスドライバ２９が管理するキャッシュバッファのサイズをファイルシステム２８がデータのチェックをする基準データ単位の２倍としていたが、これに限らず、３倍以上でもよい。例えば３倍のサイズのキャッシュバッファを用意しておけば、ＨＤＤ１０にアクセスする回数が３分の１に減ることになり、整合性のチェックにかかる時間をより短縮することが可能となる。

また、デバイスドライバ２９が管理するキャッシュバッファとして、ＲＡＭ２４を使用していたが、これに限らず、専用の高速なメモリ（例えばフラッシュメモリ）を使用するようにしてもよい。

また、上記実施形態では、ナビゲーションシステムの起動を高速化する場合を例にとって説明したが、起動の高速化の対象とするシステムはこれに限定されない。例えば、オーディオユニットの起動を高速化する場合にも本実施形態のファイルシステム管理装置５０を同様に適用することができる。

また、上記実施形態では、記憶装置としてＨＤＤを例にとって説明したが、これに限らず、同じファイル管理テーブルが２つ用意されたものであれば、その他の記憶装置（例えば、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等）であっても適用することができる。

本発明の一実施形態に係るファイルシステム管理装置の構成を示すブロック図である。 図１におけるファイルシステム管理装置の機能ブロック図である。 図１におけるＨＤＤ内に構築されるＦＡＴファイルシステムの構造を示す図である。 図４（ａ）は記憶装置が正常状態のときのＦＡＴを示すメモリマップの一例であり、図４（ｂ）は記憶装置が異常状態のときのＦＡＴを示すメモリマップの一例である。 図１のファイルシステム管理装置のファイルシステムにおいて行うＦＡＴデータの整合性チェック処理の概要を示すフローチャートである。 図１のファイルシステム管理装置において行うＦＡＴデータの整合性チェック処理の一例を示すフローチャートである。 ＦＡＴデータの整合性チェック処理を説明する図である。

符号の説明

１０…ＨＤＤ（記憶装置）、
２２…ＣＰＵ（データ管理手段）、
２３…ＲＯＭ、
２４…ＲＡＭ（キャッシュ）、
２５…デバイスコントローラ、
２８…ファイルシステム、
２９…デバイスドライバ、
４１…ナビゲーションユニット、
４２…オーディオユニット、
５０…ファイルシステム管理装置。

Claims (7)

1. ファイルを所定の管理単位毎に管理する第１のファイル管理テーブルのデータ及び当該第１のファイル管理テーブルと同一サイズの第２のファイル管理テーブルのデータを格納した記憶装置と、
   前記ファイル管理テーブルのデータを第１のサイズ毎に検査するファイルシステムと前記記憶装置から前記ファイル管理テーブルのデータを取得するデバイスドライバとを有したデータ管理手段と、
   前記デバイスドライバが管理する前記第１のサイズより大きな所定のサイズの第１のキャッシュ及び第２のキャッシュとを備え、
   前記データ管理手段は、前記第１のファイル管理テーブルから前記所定のサイズ毎のデータを前記第１のキャッシュに読み込み、前記第２のファイル管理テーブルから前記所定のサイズ毎のデータを前記第２のキャッシュに読み込み、前記第１のキャッシュに読み込んだデータと前記第２のキャッシュに読み込んだデータから前記第１のサイズ毎のデータを抽出して整合性を検査することを特徴とするファイルシステム管理装置。
2. 前記所定のサイズは、前記第１のサイズのｎ倍（ｎは２以上の自然数）であることを特徴とする請求項１に記載のファイルシステム管理装置。
3. 前記第１のファイル管理テーブルと前記第２のファイル管理テーブルは連続した領域に格納されていることを特徴とする請求項２に記載のファイルシステム管理装置。
4. ファイルを所定の管理単位毎に管理する第１のファイル管理テーブルのデータ及び当該第１のファイル管理テーブルと同一サイズの第２のファイル管理テーブルのデータを格納した記憶装置と、前記ファイル管理テーブルのデータを第１のサイズ毎に検査するファイルシステムと前記記憶装置から前記ファイル管理テーブルのデータを取得するデバイスドライバとを有したデータ管理手段と、前記デバイスドライバが管理する前記第１のサイズより大きな所定のサイズの第１のキャッシュ及び第２のキャッシュとを備えたファイルシステム管理装置において実施されるファイルシステム管理方法であって、
   前記ファイルシステムは、
   前記デバイスドライバに対して前記第１のファイル管理テーブルから前記第１のサイズの第１のデータの取得及び前記第２のファイル管理テーブルから前記第１のサイズの第２のデータの取得を要求するステップと、
   取得した前記第１のデータと第２のデータとの整合性を検査するステップとを有し、
   前記第１のデータ及び第２のデータの取得を要求された前記デバイスドライバは、
   前記第１のサイズを当該第１のサイズより大きな第２のサイズに変換するステップと、
   前記記憶装置の第１のファイル管理テーブルから前記第２のサイズのデータを取得して前記第１のキャッシュに格納するステップと、
   前記ファイルシステムに前記第１のキャッシュに格納したデータのうち前記第１のサイズのデータを送信するステップと、
   前記記憶装置の第２のファイル管理テーブルから前記第２のサイズのデータを取得して前記第２のキャッシュに格納するステップと、
   前記ファイルシステムに前記第２のキャッシュに格納したデータのうち前記第１のサイズのデータを送信するステップと、
   を有することを特徴とするファイルシステム管理方法。
5. 前記デバイスドライバは、
   前記第１のキャッシュにデータを格納し、前記第１のサイズのデータを送信した後、前記ファイルシステムからの要求に応じて残りの前記第１のサイズのデータを送信するステップと、
   前記第２のキャッシュにデータを格納し、前記第１のサイズのデータを送信した後、前記ファイルシステムからの要求に応じて残りの前記第１のサイズのデータを送信するステップと、
   をさらに有することを特徴とする請求項４に記載のファイルシステム管理方法。
6. 前記所定のサイズは、前記第１のサイズのｎ倍（ｎは２以上の自然数）であることを特徴とする請求項４に記載のファイルシステム管理方法。
7. 前記第１のファイル管理テーブルと前記第２のファイル管理テーブルは連続した領域に格納されていることを特徴とする請求項６に記載のファイルシステム管理方法。

Images