ファイル管理装置、ファイル管理方法およびプログラム
【課題】 ファイル操作の実行中に電源断が発生するとファイルシステムに矛盾が生じてしまうことが多かった。
【解決手段】 ファイル操作を実行した際に更新すべき領域をファイル操作の種類に応じた記録順序に従って領域ごとにバッファキャッシュをまとめて記録装置に書き出して更新する。
【解決手段】 ファイル操作を実行した際に更新すべき領域をファイル操作の種類に応じた記録順序に従って領域ごとにバッファキャッシュをまとめて記録装置に書き出して更新する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムのファイルシステムおよびファイリング装置に関し、特に電子記憶装置におけるファイル管理装置、ファイル管理方法およびプログラムに関する。
【背景技術】
【０００２】
近年、ＣＰＵの高速化やメモリ容量の増大に伴い、組み込みシステムにも高い機能が要求されている。例えば、記憶装置にデータを格納する際も大量のデータの蓄積やＰＣとのデータのやり取りを行うためにファイルシステムを用いることが当然とされるようになってきている。
【０００３】
組み込みシステムでは、標準フォーマットと互換性があるファイルシステムを利用することが多い。ＰＣの事実上の標準と言えるファイルシステムが、マイクロソフト社製のＦＡＴファイルシステムである。ＦＡＴファイルシステムはＭＳ−ＤＯＳやＷｉｎｄｏｗｓ（登録商標）を筆頭に、多くの組み込みＯＳ用ファイルシステムにおいてもサポートされている。
【０００４】
ＦＡＴファイルシステムは、ファイルの実データと、ＦＡＴ（Ｆｉｌｅ−Ａｌｌｏｃａｔｉｏｎ−Ｔａｂｌｅ）と呼ばれるデータブロックの管理情報およびディレクトリエントリと呼ばれるファイルのインデックス情報などのメタデータと、から構成される。
【０００５】
一般的にファイルシステムにおいて、メタデータの整合性を維持することは重要な課題である。例えば、ファイル操作中に停電などによる電源断や記憶装置の抜き取りが発生した場合、ファイル操作の処理が完了しないままメタデータの一部が欠損し、メタデータ間の整合性が取れなくなってしまうことがある。このようなメタデータの整合性が取れていないファイルに対してファイル操作を行うと、正しく操作が完了できないだけでなく、場合によっては正常なデータ領域に格納されているデータを破壊してしまうこともある。
【０００６】
ファイルシステムとしての整合性を保つ方法には、ジャーナリングファイルシステムのようなファイルシステムの整合性が損なわれたことを検出した後に、ファイルシステムを復旧する方法がある。他にも、特許文献１に示されるようなファイルシステムの整合性が損なわれる前に未然に抑制する方法がある。
【０００７】
特許文献１では、ファイルシステムの領域をデータ領域、ディレクトリスロット領域、クラスタチェーン領域に区分している。ディレクトリスロットが前述のディレクトリエントリに当たり、クラスタチェーンが前述のＦＡＴに当たる。そして、ファイルシステムのキャッシュ機構であるバッファキャッシュに即時記録、遅延記録の機能を持たせることで、ファイルへのデータ書き込み時に各領域を（１）データ領域（２）ディレクトリスロット領域（３）クラスタチェーン領域の順番に記録する。このように、重要なメタデータの記録は後回しにすることで、データ書き込み中の電源断についてファイルシステムへのダメージを抑えようとしている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００４−２７２６０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
前述のジャーナリングファイルシステムでは、バックアップ情報を余分に記憶しておく領域を確保する必要があり、また、復旧処理の負荷も大きい。一方で、特許文献１に示す方法では、ファイル操作の種類であるＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ−Ｐｒｏｇｒａｍｍｉｎｇ−Ｉｎｔｅｒｆａｃｅ）を考慮しておらず、データ書込み（ｗｒｉｔｅ（））ＡＰＩ以外のＡＰＩを利用する際にファイルシステムの整合性を保つ機能が著しく損なわれてしまう。
そこで、本発明はこれらの問題を鑑みて、電源断によるファイルシステムの不整合に起因する不具合などをファイル操作の種類（ＡＰＩ種別など）に応じて好ましく抑制するファイルシステムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記目的を達成するための本発明に係るファイル管理装置は、ファイルに含まれるデータを格納するデータ領域と、前記データ領域の使用状態および連結状態を示す管理情報を格納する第１メタデータ領域と、前記ファイルのサイズを示すインデックス情報を格納する第２メタデータ領域と、を記憶装置に設けてファイルを管理するファイル管理装置であって、ファイル操作指示を受け付ける受け付け手段と、前記データ領域と、前記第１メタデータ領域と、前記第２メタデータ領域と、の少なくとも２つ以上の領域について、前記受け付け手段で受け付けたファイル操作指示の種類に応じた順番で更新する制御手段と、を有することを特徴とする。
【発明の効果】
【００１１】
本発明のファイルシステムによれば、ファイル操作種別を考慮して、電源断などによってファイルシステムに生じる不整合による問題を低減させることができる。
【図面の簡単な説明】
【００１２】
【図１】ハードウェア構成の概略を示すブロック図である。
【図２】ソフトウェア構成の概略を示す概念図である。
【図３】実施形態１のファイルシステムの機能構成の概略を示すブロック図である。
【図４】ソフトウェア構成の概略を示す概念図である。
【図５】ファイルサイズとＦＡＴチェーンとが整合していない状態を示す。
【図６】完結していないＦＡＴチェーンの例である。
【図７】「ファイルの作成」処理における安全な同期制御のフローチャートである。
【図８】「ファイルへのデータ書き込み」処理における安全な同期制御のフローチャートである。
【図９】「ファイルの削除」処理における安全な同期制御のフローチャートである。
【図１０】「ファイルの伸長」処理における安全な同期制御のフローチャートである。
【図１１】「ファイルの短縮」処理における安全な同期制御のフローチャートである。
【図１２】「ディレクトリの作成」処理における安全な同期制御のフローチャートである。
【図１３】ファイルシステムのＡＰＩの一覧を示す。
【図１４】ＡＰＩ毎のフラッシュ順序を示す。
【発明を実施するための形態】
【００１３】
＜実施形態１＞
本発明の一実施形態である実施形態１を、ＦＡＴファイルシステムを例に用いて説明する。なお、ＦＡＴファイルシステムをＦＡＴとして呼称されることも多いが、本実施形態の説明ではＦＡＴはファイルアロケーションテーブルそのものとして説明する。
【００１４】
本実施形態におけるファイルシステムの構成を、図１および図２を参照して説明する。
【００１５】
図１は本実施形態のハードウェア構成の概略であり、組み込みコンピュータ１０１は、バス１０２、ＣＰＵ１０３、ＲＯＭ１０４、ＲＡＭ１０５、記憶装置１０６を有している。ここで、記憶装置１０６は組み込みコンピュータ１０１に対して着脱可能であってもよい。
【００１６】
図２は本実施形態のファイル管理装置の機能構成を示し、アプリケーションプログラム２０１、オペレーティングシステム２０２、ファイルシステム２０３、バッファキャッシュ２０４、記憶装置２０５、データブロック２０６を備えている。
【００１７】
組み込みコンピュータ１０１においてＣＰＵ１０３は、バス１０２によって相互に接続されたＲＯＭ１０４、ＲＡＭ１０５、記憶装置１０６の制御を行う。ＣＰＵ１０３はＲＯＭ１０４などに格納されたアプリケーションプログラム、ファイルシステムプログラムを実行することにより、記憶装置１０６に記録された論理ファイルの操作を行う。その際、ＲＡＭ１０５は作業領域として利用される。
【００１８】
アプリケーションプログラム２０１は、記憶装置２０５に対してアクセスを行う際、オペレーティングシステム２０２を通してファイルシステム２０３の各種ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ−Ｐｒｏｇｒａｍｍｉｎｇ−Ｉｎｔｅｒｆａｃｅ）を呼び出す。代表的なＡＰＩの一覧を図１３に示す。図１３では代表的なファイルシステムＡＰＩ、そのＡＰＩの機能の説明と、そのＡＰＩによって更新される領域との対応付けを図示している。
【００１９】
ファイルシステム２０３はアプリケーションプログラム２０１から呼び出されたＡＰＩに応じて記憶装置２０５に対するアクセスを行うが、その際、記憶装置２０５のデータブロック２０６の内アクセスのあったブロックをキャッシュ情報としてファイルシステム２０３のバッファキャッシュ２０４に一時的にキャッシュしておく。すると、次回、同じブロックにアクセスする際のＩ／Ｏ処理を省略し高速な動作を実現することができる。また、記憶装置に書き込む際も、同じブロックへの変更をまとめて処理することで効率化を図ることができる。このような機能は特に書き換え頻度の高いＦＡＴやディレクトリエントリの領域において有効である。ちなみに、図２においては一つのデータブロックの内容をキャッシュ情報として保持するために一つのバッファキャッシュを使用しているが、一つのデータブロックの内容を複数のバッファキャッシュを使用して記憶する形態にしてもよい。なお、バッファキャッシュはキャッシュ情報を複数保持できることが好ましい。
【００２０】
バッファキャッシュ２０４は従来の方式では、ＬＲＵ（Ｌｅａｓｔ−Ｒｅｃｅｎｔｌｙ−Ｕｓｅｄ）アルゴリズムで管理され、バッファキャッシュが不足した場合は、最も昔にアクセスしたブロックのキャッシュから記憶装置２０５に書き出され（フラッシュされ）、そのキャッシュが新たな領域のバッファリングに使用される。また、ＬＲＵにより自動的にフラッシュされる以外にもアプリケーション２０１が明示的に同期を発行することで、全てのキャッシュを一度に記録装置２０５にフラッシュする場合もある。
【００２１】
前述のようなファイルシステムにおいてメタデータの整合性を維持させる場合、ＡＰＩ実行ごとに記憶装置へのフラッシュを管理する必要がある。例えば、一度もキャッシュのフラッシュを行うことなく複数のＡＰＩを実行すると、それまでの操作によりアクセスのあった様々な領域に渡るキャッシュが混在する可能性がある。そして、混在したキャッシュをファイルシステムの整合性が維持されるように同期して一度にフラッシュすることは困難である。
【００２２】
本実施形態では、記憶装置へのフラッシュを実施するに当たって、書き込みＡＰＩ毎に適した更新領域の順序で記録する。図１３のＡＰＩ一覧に示す通り、書き込みＡＰＩはＡＰＩ毎に更新する領域が決まっている。図中のＤＡＴＡはデータ領域、ＤＩＲはディレクトリエントリ領域、ＦＡＴはＦＡＴ領域を表す。
【００２３】
ここで、一覧にあるＡＰＩのうち「Ｔｒｕｎｃａｔｅ（）（伸長）：ファイルの伸長」と「Ｔｒｕｎｃａｔｅ（）（短縮）：ファイルの短縮」に着目すると、どちらもディレクトリエントリ領域およびＦＡＴ領域を更新するが、本実施形態では、「ファイルの伸長」においてはＦＡＴの更新を先に実施し、「ファイルの短縮」においてはディレクトリエントリの更新を先に実施する。これは、それぞれの場合において、ディレクトリエントリのサイズが実際より大きい状態になりリンクされていないデータブロックを指し示す現象が発生することを防ぐためである。（なお、以降の説明ではファイル操作を単にカギ括弧で表記する。）
図４を用いて、「ファイルの伸長」処理を具体的に説明する。「ファイルの伸長」においてバッファキャッシュのフラッシュを実施する前の状態の例をバッファキャッシュ４０４として図示する。そして、データブロック４０７５がディレクトリエントリ領域として更新され、データブロック４０６１、４０６３、４０６４、４０６５がＦＡＴ領域として更新される。これらはバッファキャッシュ４０４１〜４０４５にキャッシュされているが、記憶装置へのフラッシュは、ＤＩＲ領域のバッファキャッシュ４０４３より先にＦＡＴ領域のバッファキャッシュである４０４１、４０４２、４０４４、４０４５から実施する。
【００２４】
この時のディレクトリエントリ、ＦＡＴ、データブロックの状態について図５を用いて説明する。図５の初期状態５０１はエントリのファイルサイズが１ブロック分であるのに対して、５番のデータブロックのみが割り当たっている。この状態から５１番、９１番のデータブロックを割り当て、ファイルサイズを３ブロック分に伸長する処理を行う。
【００２５】
この時、点線で示すＦＡＴ領域・ＤＩＲ領域がフラッシュされる必要がある。ここで、ＦＡＴ領域からフラッシュした場合は途中状態５０２を通過する。なお、以降の説明で登場する途中状態とは、正常なファイル操作をした場合にも遷移すると考えられる状態であるが、電源断や記憶装置へのアクセス不能の発生などの不慮の事態が生じない限りこの途中状態が露呈する可能性は低い。この途中状態５０２では、エントリのファイルサイズが１ブロック分であるのに対して、５番、５１番、９１番のデータブロックが割り当たっている。エントリのファイルサイズと実際のファイルサイズに不整合が生じているが、実際にアクセスする領域であるエントリのサイズ（１ブロック分）に相当するデータブロックは割り当たっているため問題とならない。この状態から更にＤＩＲ領域をフラッシュすることで、安全にファイルサイズと実際のデータブロック数の整合性をとることができるためである。
【００２６】
一方で、初期状態５０１からＤＩＲ領域を先にフラッシュすると途中状態５０３を通過する。この途中状態５０３ではエントリのファイルサイズが３ブロック分であるのに対して、５番のデータブロックのみが割り当たっている。すると、実際にアクセスするエントリのサイズ（３ブロック分）に相当するデータブロックに存在しない領域が含まれるため問題になる。例えば、ファイルの読み込みなどにおける特定のサイズに対応するデータブロックの検索を行うような処理においてエラーを引き起こす恐れがある。
【００２７】
また、「ファイルの短縮」の場合、ＤＩＲ領域のバッファキャッシュからフラッシュして先にファイルサイズを小さくしておくことで、「ファイルの伸長」の場合と同様に実際にリンクされていない領域を指し示す状態を防ぐことができる。
【００２８】
このように、記憶装置に対する各領域の記録順序はファイル操作の種類（例えば、上述のファイル伸長とファイル短縮）もしくはＡＰＩごとに異なるので、ＡＰＩごとに正しい更新領域の記録順序を定義することで、より安全なファイルシステムを実現することができる。
【００２９】
さらに本実施形態では、特定領域のフラッシュ制御も実施する。例えば、「ファイルの伸長」では、（１）ＦＡＴ領域のフラッシュ（２）ディレクトリエントリ領域のフラッシュという順序で記憶装置への記録処理を行うことになっている。このとき、（１）でフラッシュするＦＡＴ領域は複数個所にまたがることも多い。これらが不規則な順番でフラッシュされていくと一時的にＦＡＴクラスタチェーンが断裂した状態になり、その状態で電源断などに陥るとファイルシステムに矛盾が発生する可能性がある。
【００３０】
従って、本実施形態ではこのような状況を防ぐために、「ファイルの伸長」においては、記憶装置に元々記憶されているＦＡＴクラスタチェーン（ファイルの連結状態）の終端（末尾）を含むバッファキャッシュは保護することでフラッシュ対象から除外し、（１）ＦＡＴ領域のフラッシュの最後で保護を解除しフラッシュするようにしておく。すると、保護した領域以外の箇所を先にフラッシュすることで、延長する部分のＦＡＴクラスタチェーンを完成させてから、ＦＡＴクラスタチェーンの終端をフラッシュし完成したチェーンに接続することができるため、より安全に「ファイルの伸長」処理を実行することができる。なお、ＦＡＴクラスタチェーンの終端とは、ＦＡＴの中でファイル末尾（第１の情報、第３の情報）を示す情報に相当し、それ以外のＦＡＴに含まれる情報（第２の情報）と区別している。
【００３１】
具体的に図４を用いて、「ファイルの伸長」においてバッファキャッシュのフラッシュを実施する前の状態がバッファキャッシュ４０４だとする。このとき、ディレクトリエントリ領域として更新があったのがデータブロック４０７５でＦＡＴ領域として更新があったのがデータブロック４０６１、４０６３、４０６４、４０６５である。ＦＡＴ領域はバッファキャッシュ４０４１、４０４２、４０４４、４０４５にキャッシュされ、ＦＡＴクラスタチェーンの終端を含むバッファキャッシュが４０４１であるとする。本実施形態ではバッファキャッシュ４０４１に変更が加えられた時点でこのバッファキャッシュを保護し、ＦＡＴ領域の更新は４０４２、４０４４、４０４５から実施する。
【００３２】
この時のディレクトリエントリ、ＦＡＴ、データブロックの状態について図６を用いて説明する。図６の初期状態６０１はエントリのファイルサイズが１ブロック分であるのに対して、５番のデータブロックのみが割り当たっている。この状態から５１番、９１番のデータブロックを割り当て、ファイルサイズを３ブロック分に伸長する処理を行う。この時、ＦＡＴのフラッシュは点線で示す単位で３箇所に渡って行われる。
【００３３】
元々のＦＡＴの末尾（５番を含むＦＡＴ領域）を保護した状態でフラッシュすると記憶装置に元々記憶されているファイルの末尾（ＦＡＴクラスタチェーンの終端）を保護した場合は途中状態６０２のようになる。この途中状態６０２状態では、エントリのファイルサイズが１ブロック分であるのに対して、５番のデータブロックが割り当たっている。さらに、５１番と９１番のデータブロックがチェーン（連結）しているが、これらのブロックはアクセスされる領域として残っていないため問題とならない。この途中状態６０２から元々のＦＡＴの末尾の保護を解除しフラッシュすることで、５番と５１番を正常にチェーンすることができる。
【００３４】
一方で、無秩序にフラッシュされた場合途中状態６０３のようになることがある。この途中状態６０３では、エントリのファイルサイズが１ブロック分であるのに対して、５番、５１番のデータブロックのみが割り当たっている。一見、実際にアクセスする領域であるエントリのサイズ（１ブロック分）に相当するデータブロックは存在するので問題ないように見えるが、５１番のデータブロックはＦＡＴ上では未使用状態（ＦＡＴの値が０）であるため、例えばファイルの削除などにおける順次ＦＡＴを辿るような処理においてエラーを引き起こす恐れがある。
【００３５】
また、前述のように「ファイルの延長」においてはバッファキャッシュのフラッシュを一時的に保留させることでファイルシステムの安全性を高めることができるが、逆に「ファイルの短縮」においてはバッファキャッシュのフラッシュを即座に実施することでそれが可能となる（詳細は後述する）。このように、バッファキャッシュのフラッシュを一時的に保留させる（もしくは即座にフラッシュする）ことで、より安全なファイルシステムを実現することができる。
【００３６】
次に、図３に本実施形態のファイルシステム（ファイル管理装置）の概念的な機能構成を示す。
【００３７】
図３に示す様にファイルシステム３００はＡＰＩ制御部３０１、フラッシュ順序制御部３０２、バッファキャッシュ制御部３０３を有する。記憶装置３１０は予め本実施形態のファイルシステムを利用できるようにフォーマットされ、インデックス情報を含むディレクトリエントリを格納するＤＩＲ領域（第２メタデータ領域）３１１、データ領域の使用状態と連結状態を示す管理情報を含むファイルアロケーションテーブルを格納するＦＡＴ領域（第１メタデータ領域）３１２、ＤＡＴＡ領域３１３を設けられている。
【００３８】
バッファキャッシュ制御部３０３のバッファキャッシュ（不図示）はファイルシステムが管理するＲＡＭ１０５の記憶領域であればよい。記憶装置３１０のＤＩＲ領域３１１、ＦＡＴ領域３１２、ＤＡＴＡ領域３１３に記録すべき内容をキャッシュする。バッファキャッシュはバッファとしても機能し、詳細には、ＡＰＩ制御部３０１が判別した記憶装置のアクセス対象の内容をバッファキャッシュに読み出し、その内容をＡＰＩ３０１のファイル操作に応じて更新し、アクセス対象に更新した内容を書き戻す。
【００３９】
フラッシュ順序制御部３０２は図１４に示すテーブルのように各ＡＰＩのフラッシュ順序（ＦＡＴ内のフラッシュ順序含む）を規定する情報を有している。ただし、実際にテーブルとして保持する必要はなく、ライブラリとしてファイルシステムから参照できるように構成してもよいし、ファイルシステム内の各ＡＰＩのコードの中に埋め込んでしまってもよい。
【００４０】
ＡＰＩ制御部３０１はアプリケーションやオペレーションプログラム側からＡＰＩ呼び出し（第１ファイル操作指示、第２ファイル操作指示）を受けると、フラッシュ順序制御部３０２にアクセスしフラッシュ順序が保持されているＡＰＩであれば、そのフラッシュ順序に従ってバッファキャッシュ３０３のバッファしているデータを記憶装置３１０に書き出す。なお、フラッシュ順序が保持されていないＡＰＩについて簡易的にＤＡＴＡ、ディレクトリ、ＦＡＴなどの固定順にフラッシュするようにしてもよいし、無秩序にフラッシュしてもよい。また、本実施形態ではバッファキャッシュを用いて説明しているが、バッファキャッシュを用いなくても、ファイル操作指示の種類に応じた順序で、ＤＩＲ領域３１１、ＦＡＴ領域３１２、ＤＡＴＡ領域３１３のうちの少なくとも２つ以上を更新できればよい。
【００４１】
また、ＡＰＩ制御部３０１は、ＦＡＴ領域の中のフラッシュ順序として、「保留」が示されていればデータブロックを他のＦＡＴ領域を全て書き出してから最後に書き出すように制御する。一方で、「即時」がしめされていればデータブロックを他のＦＡＴ領域よりも最初に（優先的に）書き出すように制御する。
【００４２】
以降の説明では、図３に示す本実施形態のファイル管理装置が図１４に示すフラッシュ順序（およびＦＡＴ末尾保護の有無）に基づいて、ファイル操作種類ごと（以下の説明ではＡＰＩごと）に適する順序でバッファキャッシュを記録するためのＡＰＩ制御部３０１による制御フローについて具体的に説明する。
【００４３】
＜ファイルの作成：Ｏｐｅｎ（），Ｃｒｅａｔ（）＞
通常、ファイルを作成するときに書込みが発生する領域は、新たに作成されるディレクトリエントリを書き込む領域のみである。しかし、ディレクトリエントリを書き込むディレクトリに空き領域がない場合はディレクトリの拡張が行われる。この場合、ディレクトリエントリの領域に加えてＦＡＴ領域にも書込みが発生する。本実施形態のファイル管理装置によるファイルの作成処理にについて、同期制御の手順を図７のフローチャートを基に説明する。
【００４４】
まず、ステップＳ７０１においてファイルを作成するディレクトリに十分な空き領域があるか確認する。空きがある場合はステップＳ７０３に飛んでディレクトリエントリの作成を行う。空きがない場合はディレクトリの拡張を行うためにステップＳ７０２に進む。
【００４５】
ステップＳ７０２では空きデータブロックを元々のディレクトリと連結するために、ＦＡＴ領域をバッファキャッシュのみ更新する。不定な領域にディレクトリがリンクするのを防ぐため、ディレクトリエントリ領域がフラッシュされるまで記憶装置へのフラッシュは行わないようにする。さらに、最終的なフラッシュより前に元々のＦＡＴチェーンの終端が記憶装置へ書き込まれないよう、元々のＦＡＴチェーンの終端を含むキャッシュをリプレイスから保護してフラッシュを保留させる。
【００４６】
ステップＳ７０３では新たに獲得したデータブロックのゼロクリアおよびディレクトリエントリの作成を行う。データブロックのゼロクリアはたくさんのバッファキャッシュを消費するためキャッシュのリプレイスが頻発することがあるが、ステップＳ７０２で保護したキャッシュだけはリプレイス対象から外れフラッシュされずに残るため、不定な領域がリンクされることはない。ステップＳ７０１からこのステップに飛んだ場合、ゼロクリアは不要で、ディレクトリエントリの作成のみ行う。
【００４７】
ステップＳ７０４ではディレクトリエントリ領域のみフラッシュを行う。ステップＳ７０３において発生したバッファキャッシュのリプレイスにより既にいくつかのキャッシュはフラッシュされている可能性があるため、残りの領域が対象となる。
【００４８】
最後に、ステップＳ７０５でＦＡＴ領域のフラッシュを行う。このとき、ステップＳ７０２で保護したバッファキャッシュはそのままでＦＡＴ領域のフラッシュを行う。その後でステップＳ７０２で保護したキャッシュの保護を解除しフラッシュする。ステップＳ７０１からステップＳ７０３に飛んだ後このステップに到達した場合、このステップで実施する処理は不要である。
【００４９】
＜ファイルへのデータ書き込み：Ｗｒｉｔｅ（）＞
ファイルへのデータの書込みにおいても新たに領域を確保する場合はデータ領域、ディレクトリエントリ領域に加えてＦＡＴ領域への書き込みが必要となる。「ファイルへのデータ書き込み」における最適な同期制御の手順を図８のフローチャートを基に説明する。
まず、ステップＳ８０１においてデータを書き込む領域に十分な空き領域があるか確認する。空きがある場合はステップＳ８０３に飛んでデータの書き込みを行う。空きがない場合はファイルの拡張を行うためにステップＳ８０２に進む。
【００５０】
ステップＳ８０２では空きデータブロックを元々のファイルと連結するために、ＦＡＴ領域をバッファキャッシュのみ更新する。不定な領域にファイルがリンクするのを防ぐため、データ領域がフラッシュされるまで記憶装置へのフラッシュは行うことはできない。さらに、最終的なフラッシュより前に元々のＦＡＴチェーンの終端が記憶装置へ書き込まれないよう、元々のＦＡＴチェーンの終端を含むキャッシュをリプレイスから保護してフラッシュを保留させる。
【００５１】
ステップＳ８０３ではデータの書き込みを行う。データの書き込みはたくさんのバッファキャッシュを消費するためキャッシュのリプレイスが頻発することがあるが、ステップＳ８０２で保護したキャッシュだけはリプレイス対象から外れフラッシュされずに残るため、不定な領域がリンクされることはない。ちなみに、データ領域はアクセス頻度が低く、かつ、「ファイルへのデータ書き込み」において最初に記憶装置にフラッシュされる領域であるため、この時点でバッファを通さず直接記憶装置にフラッシュしても良い。
【００５２】
ステップＳ８０４ではファイルのサイズを変更するために、ディレクトリエントリ領域をバッファキャッシュのみ更新する。リンクされていない領域をディレクトリエントリが指し示すのを防ぐため、ＦＡＴ領域がフラッシュされるまで記憶装置へのフラッシュは行うことはできない。ここでも、ステップＳ８０２で保護したキャッシュだけはリプレイス対象から外れフラッシュされずに残るため、不定な領域がリンクされることはない。
【００５３】
ステップＳ８０５ではデータ領域のみフラッシュを行う。ステップＳ８０３でデータ領域を直接記憶装置に書き込んでいる場合はこのステップは不要である。
ステップＳ８０６ではＦＡＴ領域のみフラッシュを行う。このとき、ステップＳ８０２で保護したバッファキャッシュはそのままでＦＡＴ領域のフラッシュを行う。その後でステップＳ８０２で保護したキャッシュの保護を解除しフラッシュする。ステップＳ８０１からステップＳ８０３に飛んだ後このステップに到達した場合、このステップで実施する処理は不要である。
【００５４】
最後に、ステップＳ８０７でディレクトリ領域のフラッシュを行う。
【００５５】
＜ファイルの削除：Ｕｎｌｉｎｋ（）＞
データブロックが割り当てられているファイルを削除する場合は、ディレクトリエントリ領域とＦＡＴ領域への書込みが必要となる。データブロックの割り当てがないファイルではディレクトリエントリ領域への書き込みのみである。本実施形態のファイル管理装置によるファイルの削除処理における同期制御の手順を図９のフローチャートを基に説明する。
【００５６】
まず、ステップＳ９０１においてディレクトリエントリの削除を行う。解放されるデータブロックへの参照を防ぐため、更新したディレクトリエントリ領域は即座に記憶装置へフラッシュする。
【００５７】
次に、ステップＳ９０２において削除するファイルにデータブロックの割り当てがあるか確認する。割り当てがない場合はそこで「ファイルの削除」は完了である。割り当てがある場合はデータブロックの解放を行うためにステップＳ９０３に進む。
【００５８】
ステップＳ９０３ではファイルに割り当てられたデータブロックを解放するために、ＦＡＴ領域のバッファキャッシュを更新する。既にディレクトリエントリが削除され、割り当てられたデータブロックを参照するものはないので、キャッシュのリプレイスによる不測のタイミングにおけるフラッシュを心配する必要もない。
【００５９】
最後に、ステップＳ９０４でＦＡＴ領域のフラッシュを行う。ステップＳ９０３においてバッファキャッシュのリプレイスにより既にいくつかのキャッシュはフラッシュされている可能性があるため、残りの領域が対象となる。
【００６０】
＜ファイルの伸長：Ｔｒｕｎｃａｔｅ（）（伸長）＞
データの書き込みが発生しない点以外は「ファイルへのデータ書き込み」と同じである。よって、更新領域はディレクトリエントリ領域およびＦＡＴ領域である。ただし、伸長した領域にゼロを書き込む実装においては「ファイルへのデータ書き込みと」全く同じ記録手順となる。本実施形態のファイル管理装置による伸長処理について同期制御の手順を図１０のフローチャートを基に説明する。
【００６１】
まず、ステップＳ１００１において指定されたファイルサイズが新たなデータブロックの連結を必要とするか確認する。必要がない場合はステップＳ１００３に飛んでディレクトリエントリの更新を行う。必要がある場合はファイルの拡張を行うためにステップＳ１００２に進む。
【００６２】
ステップＳ１００２では空きデータブロックを元々のファイルと連結するために、ＦＡＴ領域をバッファキャッシュのみ更新する。最終的なフラッシュより前に元々のＦＡＴチェーンの終端に対する更新が記憶装置へフラッシュされないよう、元々のＦＡＴチェーンの終端を含むキャッシュをリプレイスから保護してフラッシュを保留させる。
【００６３】
ステップＳ１００３ではファイルのサイズを変更するために、ディレクトリエントリ領域をバッファキャッシュのみ更新する。リンクされていない領域をディレクトリエントリが指し示すのを防ぐため、ＦＡＴ領域がフラッシュされるまで記憶装置へのフラッシュは行うことはできない。ステップＳ１００２で保護したキャッシュだけはリプレイス対象から外れフラッシュされずに残るため、キャッシュのリプレイスが発生しても不定な領域がリンクされることはない。
【００６４】
ステップＳ１００４ではＦＡＴ領域のみフラッシュを行う。このとき、ステップＳ１００２で保護したバッファキャッシュはそのままでＦＡＴ領域のフラッシュを行う。その後、ステップＳ１００２で保護したキャッシュの保護を解除しフラッシュする。ステップＳ１００１からステップＳ１００３に飛んだ後このステップに到達した場合、このステップで実施する処理は不要である。
【００６５】
最後に、ステップＳ１００５でディレクトリ領域のフラッシュを行う。
【００６６】
＜ファイルの短縮：Ｔｒｕｎｃａｔｅ（）（短縮）＞
基本的には「ファイルの伸長」の逆順である。ただし、短縮という性質上、ディレクトリエントリ領域のゼロクリアはないので、その点も伸長の場合と異なる。本実施形態のファイル管理装置によるファイルの短縮処理について、同期制御の手順を図１１のフローチャートを基に説明する。
【００６７】
まず、ステップＳ１１０１においてディレクトリエントリのファイルサイズの変更を行う。解放されるデータブロックへの参照を防ぐため、更新したディレクトリエントリ領域は即座に記憶装置へフラッシュする。
【００６８】
次に、ステップＳ１１０２において指定されたファイルサイズが既存のデータブロックの解放を必要とするか確認する。必要がない場合はそこで「ファイルの短縮」は完了である。必要がある場合はファイルの解放を行うためにステップＳ１１０３に進む。
【００６９】
ステップＳ１１０３では空きデータブロックを元々のファイルから解放するために、ＦＡＴ領域をバッファキャッシュのみ更新する。最終的なフラッシュより前にＦＡＴチェーンの任意の箇所に対する更新が記憶装置へフラッシュされても良いように、短縮後のＦＡＴチェーンの終端を含むキャッシュだけは即時フラッシュする。
【００７０】
最後に、ステップＳ１１０４でＦＡＴ領域のフラッシュを行う。このとき、ステップＳ１１０３で短縮後のＦＡＴチェーンの終端を含むキャッシュは既にフラッシュされているため、残りのＦＡＴチェーンに対する更新がどのように記憶装置に書き込まれても問題が発生することはない。
【００７１】
＜ディレクトリの作成：Ｍｉｄｉｒ（）＞
「ディレクトリの作成」は新たなデータブロックの確保とディレクトリエントリの作成の２段階の手順から成り立つ。このような特性から、「ディレクトリの作成」においてはディレクトリエントリ領域およびＦＡＴ領域の領域単位でのフラッシュがそれぞれ２度発生することに注意が必要である。ディレクトリエントリの作成については「ファイルの作成」の場合とおなじステップを踏めば良いので、ここではデータブロックの確保を主眼とする。「ディレクトリの作成」における最適な同期制御の手順を図１２のフローチャートを基に説明する。
【００７２】
まず、ステップＳ１２０１において空きデータブロックを確保するために、ＦＡＴ領域をバッファキャッシュのみ更新する。この領域はディレクトリエントリが作成されない限りどこからも参照されないため、ディレクトリエントリの作成より前であればいつフラッシュされても良いが、できるだけ領域を無駄にしないために、確保したＦＡＴを含むキャッシュをリプレイスから保護してフラッシュを保留させる。
【００７３】
次にステップＳ１２０２では新たに獲得したデータブロックのゼロクリアを行う。データブロックのゼロクリアはたくさんのバッファキャッシュを消費するためキャッシュのリプレイスが頻発することがあるが、ステップＳ１２０１で保護したキャッシュだけはリプレイス対象から外れフラッシュされずに残るため、不定な領域が使用済みとなることはない。
【００７４】
ステップＳ１２０３ではディレクトリエントリ領域のフラッシュを行う。
【００７５】
ステップＳ１２０４ではＦＡＴ領域のフラッシュを行う。このステップでフラッシュされるのはステップＳ１２０２で確保したデータブロックの分だけであるが、Ｓ１２０４に到達した時点では保護されているので、その保護を解除してからフラッシュする。
最後にステップＳ１２０５では「ファイルの作成」と同じ記録手順でディレクトリエントリの作成処理を実施する。
【００７６】
＜ディレクトリの削除：Ｒｍｄｉｒ（）＞
削除対象のデータブロックがファイルであるかディレクトリであるかという点が異なるだけで、「ファイルの削除」と同様の処理であるためここではその詳細を省略する。
【００７７】
＜ファイル・ディレクトリの名前・アクセス権・タイムスタンプの変更：Ｒｅｎａｍｅ（），Ｃｈｍｏｄ（），Ｕｔｉｍｅ（）＞
これらのＡＰＩについては更新する領域がディレクトリエントリ領域のみであるため、複雑な同期制御は不要である。
【００７８】
＜その他の実施形態＞
前述した実施形態はＦＡＴファイルシステムを前提として説明を行ったが、本発明はＦＡＴのようなデータ領域、ディレクトリエントリ領域、ＦＡＴ領域（ここでは、データブロックのチェ−ンを表現する領域とする）を持つファイルシステムにも適用することができる。また、本発明はバッファキャッシュを管理する際のアルゴリズムもＬＲＵに限定されない。
【００７９】
また、前述した実施形態では代表的なファイルシステムＡＰＩについて説明したが、「ファイルの連結」や「ファイルの分割」などのＡＰＩにおいても本発明を適用してファイルシステムの安全性を向上させることができる。
【００８０】
また、前述した実施形態では代表的なファイルシステムのＡＰＩの其々について、対応する処理（対応する、領域の更新順序に従って更新する処理）を示したが、少なくとも２つ以上の領域の更新順序が異なる２つ以上のＡＰＩを実施する構成であれば、本発明を適用することでファイルシステムの堅牢性を高めることができる。
【００８１】
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【技術分野】
【０００１】
本発明は、コンピュータシステムのファイルシステムおよびファイリング装置に関し、特に電子記憶装置におけるファイル管理装置、ファイル管理方法およびプログラムに関する。
【背景技術】
【０００２】
近年、ＣＰＵの高速化やメモリ容量の増大に伴い、組み込みシステムにも高い機能が要求されている。例えば、記憶装置にデータを格納する際も大量のデータの蓄積やＰＣとのデータのやり取りを行うためにファイルシステムを用いることが当然とされるようになってきている。
【０００３】
組み込みシステムでは、標準フォーマットと互換性があるファイルシステムを利用することが多い。ＰＣの事実上の標準と言えるファイルシステムが、マイクロソフト社製のＦＡＴファイルシステムである。ＦＡＴファイルシステムはＭＳ−ＤＯＳやＷｉｎｄｏｗｓ（登録商標）を筆頭に、多くの組み込みＯＳ用ファイルシステムにおいてもサポートされている。
【０００４】
ＦＡＴファイルシステムは、ファイルの実データと、ＦＡＴ（Ｆｉｌｅ−Ａｌｌｏｃａｔｉｏｎ−Ｔａｂｌｅ）と呼ばれるデータブロックの管理情報およびディレクトリエントリと呼ばれるファイルのインデックス情報などのメタデータと、から構成される。
【０００５】
一般的にファイルシステムにおいて、メタデータの整合性を維持することは重要な課題である。例えば、ファイル操作中に停電などによる電源断や記憶装置の抜き取りが発生した場合、ファイル操作の処理が完了しないままメタデータの一部が欠損し、メタデータ間の整合性が取れなくなってしまうことがある。このようなメタデータの整合性が取れていないファイルに対してファイル操作を行うと、正しく操作が完了できないだけでなく、場合によっては正常なデータ領域に格納されているデータを破壊してしまうこともある。
【０００６】
ファイルシステムとしての整合性を保つ方法には、ジャーナリングファイルシステムのようなファイルシステムの整合性が損なわれたことを検出した後に、ファイルシステムを復旧する方法がある。他にも、特許文献１に示されるようなファイルシステムの整合性が損なわれる前に未然に抑制する方法がある。
【０００７】
特許文献１では、ファイルシステムの領域をデータ領域、ディレクトリスロット領域、クラスタチェーン領域に区分している。ディレクトリスロットが前述のディレクトリエントリに当たり、クラスタチェーンが前述のＦＡＴに当たる。そして、ファイルシステムのキャッシュ機構であるバッファキャッシュに即時記録、遅延記録の機能を持たせることで、ファイルへのデータ書き込み時に各領域を（１）データ領域（２）ディレクトリスロット領域（３）クラスタチェーン領域の順番に記録する。このように、重要なメタデータの記録は後回しにすることで、データ書き込み中の電源断についてファイルシステムへのダメージを抑えようとしている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００４−２７２６０８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
前述のジャーナリングファイルシステムでは、バックアップ情報を余分に記憶しておく領域を確保する必要があり、また、復旧処理の負荷も大きい。一方で、特許文献１に示す方法では、ファイル操作の種類であるＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ−Ｐｒｏｇｒａｍｍｉｎｇ−Ｉｎｔｅｒｆａｃｅ）を考慮しておらず、データ書込み（ｗｒｉｔｅ（））ＡＰＩ以外のＡＰＩを利用する際にファイルシステムの整合性を保つ機能が著しく損なわれてしまう。
そこで、本発明はこれらの問題を鑑みて、電源断によるファイルシステムの不整合に起因する不具合などをファイル操作の種類（ＡＰＩ種別など）に応じて好ましく抑制するファイルシステムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記目的を達成するための本発明に係るファイル管理装置は、ファイルに含まれるデータを格納するデータ領域と、前記データ領域の使用状態および連結状態を示す管理情報を格納する第１メタデータ領域と、前記ファイルのサイズを示すインデックス情報を格納する第２メタデータ領域と、を記憶装置に設けてファイルを管理するファイル管理装置であって、ファイル操作指示を受け付ける受け付け手段と、前記データ領域と、前記第１メタデータ領域と、前記第２メタデータ領域と、の少なくとも２つ以上の領域について、前記受け付け手段で受け付けたファイル操作指示の種類に応じた順番で更新する制御手段と、を有することを特徴とする。
【発明の効果】
【００１１】
本発明のファイルシステムによれば、ファイル操作種別を考慮して、電源断などによってファイルシステムに生じる不整合による問題を低減させることができる。
【図面の簡単な説明】
【００１２】
【図１】ハードウェア構成の概略を示すブロック図である。
【図２】ソフトウェア構成の概略を示す概念図である。
【図３】実施形態１のファイルシステムの機能構成の概略を示すブロック図である。
【図４】ソフトウェア構成の概略を示す概念図である。
【図５】ファイルサイズとＦＡＴチェーンとが整合していない状態を示す。
【図６】完結していないＦＡＴチェーンの例である。
【図７】「ファイルの作成」処理における安全な同期制御のフローチャートである。
【図８】「ファイルへのデータ書き込み」処理における安全な同期制御のフローチャートである。
【図９】「ファイルの削除」処理における安全な同期制御のフローチャートである。
【図１０】「ファイルの伸長」処理における安全な同期制御のフローチャートである。
【図１１】「ファイルの短縮」処理における安全な同期制御のフローチャートである。
【図１２】「ディレクトリの作成」処理における安全な同期制御のフローチャートである。
【図１３】ファイルシステムのＡＰＩの一覧を示す。
【図１４】ＡＰＩ毎のフラッシュ順序を示す。
【発明を実施するための形態】
【００１３】
＜実施形態１＞
本発明の一実施形態である実施形態１を、ＦＡＴファイルシステムを例に用いて説明する。なお、ＦＡＴファイルシステムをＦＡＴとして呼称されることも多いが、本実施形態の説明ではＦＡＴはファイルアロケーションテーブルそのものとして説明する。
【００１４】
本実施形態におけるファイルシステムの構成を、図１および図２を参照して説明する。
【００１５】
図１は本実施形態のハードウェア構成の概略であり、組み込みコンピュータ１０１は、バス１０２、ＣＰＵ１０３、ＲＯＭ１０４、ＲＡＭ１０５、記憶装置１０６を有している。ここで、記憶装置１０６は組み込みコンピュータ１０１に対して着脱可能であってもよい。
【００１６】
図２は本実施形態のファイル管理装置の機能構成を示し、アプリケーションプログラム２０１、オペレーティングシステム２０２、ファイルシステム２０３、バッファキャッシュ２０４、記憶装置２０５、データブロック２０６を備えている。
【００１７】
組み込みコンピュータ１０１においてＣＰＵ１０３は、バス１０２によって相互に接続されたＲＯＭ１０４、ＲＡＭ１０５、記憶装置１０６の制御を行う。ＣＰＵ１０３はＲＯＭ１０４などに格納されたアプリケーションプログラム、ファイルシステムプログラムを実行することにより、記憶装置１０６に記録された論理ファイルの操作を行う。その際、ＲＡＭ１０５は作業領域として利用される。
【００１８】
アプリケーションプログラム２０１は、記憶装置２０５に対してアクセスを行う際、オペレーティングシステム２０２を通してファイルシステム２０３の各種ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ−Ｐｒｏｇｒａｍｍｉｎｇ−Ｉｎｔｅｒｆａｃｅ）を呼び出す。代表的なＡＰＩの一覧を図１３に示す。図１３では代表的なファイルシステムＡＰＩ、そのＡＰＩの機能の説明と、そのＡＰＩによって更新される領域との対応付けを図示している。
【００１９】
ファイルシステム２０３はアプリケーションプログラム２０１から呼び出されたＡＰＩに応じて記憶装置２０５に対するアクセスを行うが、その際、記憶装置２０５のデータブロック２０６の内アクセスのあったブロックをキャッシュ情報としてファイルシステム２０３のバッファキャッシュ２０４に一時的にキャッシュしておく。すると、次回、同じブロックにアクセスする際のＩ／Ｏ処理を省略し高速な動作を実現することができる。また、記憶装置に書き込む際も、同じブロックへの変更をまとめて処理することで効率化を図ることができる。このような機能は特に書き換え頻度の高いＦＡＴやディレクトリエントリの領域において有効である。ちなみに、図２においては一つのデータブロックの内容をキャッシュ情報として保持するために一つのバッファキャッシュを使用しているが、一つのデータブロックの内容を複数のバッファキャッシュを使用して記憶する形態にしてもよい。なお、バッファキャッシュはキャッシュ情報を複数保持できることが好ましい。
【００２０】
バッファキャッシュ２０４は従来の方式では、ＬＲＵ（Ｌｅａｓｔ−Ｒｅｃｅｎｔｌｙ−Ｕｓｅｄ）アルゴリズムで管理され、バッファキャッシュが不足した場合は、最も昔にアクセスしたブロックのキャッシュから記憶装置２０５に書き出され（フラッシュされ）、そのキャッシュが新たな領域のバッファリングに使用される。また、ＬＲＵにより自動的にフラッシュされる以外にもアプリケーション２０１が明示的に同期を発行することで、全てのキャッシュを一度に記録装置２０５にフラッシュする場合もある。
【００２１】
前述のようなファイルシステムにおいてメタデータの整合性を維持させる場合、ＡＰＩ実行ごとに記憶装置へのフラッシュを管理する必要がある。例えば、一度もキャッシュのフラッシュを行うことなく複数のＡＰＩを実行すると、それまでの操作によりアクセスのあった様々な領域に渡るキャッシュが混在する可能性がある。そして、混在したキャッシュをファイルシステムの整合性が維持されるように同期して一度にフラッシュすることは困難である。
【００２２】
本実施形態では、記憶装置へのフラッシュを実施するに当たって、書き込みＡＰＩ毎に適した更新領域の順序で記録する。図１３のＡＰＩ一覧に示す通り、書き込みＡＰＩはＡＰＩ毎に更新する領域が決まっている。図中のＤＡＴＡはデータ領域、ＤＩＲはディレクトリエントリ領域、ＦＡＴはＦＡＴ領域を表す。
【００２３】
ここで、一覧にあるＡＰＩのうち「Ｔｒｕｎｃａｔｅ（）（伸長）：ファイルの伸長」と「Ｔｒｕｎｃａｔｅ（）（短縮）：ファイルの短縮」に着目すると、どちらもディレクトリエントリ領域およびＦＡＴ領域を更新するが、本実施形態では、「ファイルの伸長」においてはＦＡＴの更新を先に実施し、「ファイルの短縮」においてはディレクトリエントリの更新を先に実施する。これは、それぞれの場合において、ディレクトリエントリのサイズが実際より大きい状態になりリンクされていないデータブロックを指し示す現象が発生することを防ぐためである。（なお、以降の説明ではファイル操作を単にカギ括弧で表記する。）
図４を用いて、「ファイルの伸長」処理を具体的に説明する。「ファイルの伸長」においてバッファキャッシュのフラッシュを実施する前の状態の例をバッファキャッシュ４０４として図示する。そして、データブロック４０７５がディレクトリエントリ領域として更新され、データブロック４０６１、４０６３、４０６４、４０６５がＦＡＴ領域として更新される。これらはバッファキャッシュ４０４１〜４０４５にキャッシュされているが、記憶装置へのフラッシュは、ＤＩＲ領域のバッファキャッシュ４０４３より先にＦＡＴ領域のバッファキャッシュである４０４１、４０４２、４０４４、４０４５から実施する。
【００２４】
この時のディレクトリエントリ、ＦＡＴ、データブロックの状態について図５を用いて説明する。図５の初期状態５０１はエントリのファイルサイズが１ブロック分であるのに対して、５番のデータブロックのみが割り当たっている。この状態から５１番、９１番のデータブロックを割り当て、ファイルサイズを３ブロック分に伸長する処理を行う。
【００２５】
この時、点線で示すＦＡＴ領域・ＤＩＲ領域がフラッシュされる必要がある。ここで、ＦＡＴ領域からフラッシュした場合は途中状態５０２を通過する。なお、以降の説明で登場する途中状態とは、正常なファイル操作をした場合にも遷移すると考えられる状態であるが、電源断や記憶装置へのアクセス不能の発生などの不慮の事態が生じない限りこの途中状態が露呈する可能性は低い。この途中状態５０２では、エントリのファイルサイズが１ブロック分であるのに対して、５番、５１番、９１番のデータブロックが割り当たっている。エントリのファイルサイズと実際のファイルサイズに不整合が生じているが、実際にアクセスする領域であるエントリのサイズ（１ブロック分）に相当するデータブロックは割り当たっているため問題とならない。この状態から更にＤＩＲ領域をフラッシュすることで、安全にファイルサイズと実際のデータブロック数の整合性をとることができるためである。
【００２６】
一方で、初期状態５０１からＤＩＲ領域を先にフラッシュすると途中状態５０３を通過する。この途中状態５０３ではエントリのファイルサイズが３ブロック分であるのに対して、５番のデータブロックのみが割り当たっている。すると、実際にアクセスするエントリのサイズ（３ブロック分）に相当するデータブロックに存在しない領域が含まれるため問題になる。例えば、ファイルの読み込みなどにおける特定のサイズに対応するデータブロックの検索を行うような処理においてエラーを引き起こす恐れがある。
【００２７】
また、「ファイルの短縮」の場合、ＤＩＲ領域のバッファキャッシュからフラッシュして先にファイルサイズを小さくしておくことで、「ファイルの伸長」の場合と同様に実際にリンクされていない領域を指し示す状態を防ぐことができる。
【００２８】
このように、記憶装置に対する各領域の記録順序はファイル操作の種類（例えば、上述のファイル伸長とファイル短縮）もしくはＡＰＩごとに異なるので、ＡＰＩごとに正しい更新領域の記録順序を定義することで、より安全なファイルシステムを実現することができる。
【００２９】
さらに本実施形態では、特定領域のフラッシュ制御も実施する。例えば、「ファイルの伸長」では、（１）ＦＡＴ領域のフラッシュ（２）ディレクトリエントリ領域のフラッシュという順序で記憶装置への記録処理を行うことになっている。このとき、（１）でフラッシュするＦＡＴ領域は複数個所にまたがることも多い。これらが不規則な順番でフラッシュされていくと一時的にＦＡＴクラスタチェーンが断裂した状態になり、その状態で電源断などに陥るとファイルシステムに矛盾が発生する可能性がある。
【００３０】
従って、本実施形態ではこのような状況を防ぐために、「ファイルの伸長」においては、記憶装置に元々記憶されているＦＡＴクラスタチェーン（ファイルの連結状態）の終端（末尾）を含むバッファキャッシュは保護することでフラッシュ対象から除外し、（１）ＦＡＴ領域のフラッシュの最後で保護を解除しフラッシュするようにしておく。すると、保護した領域以外の箇所を先にフラッシュすることで、延長する部分のＦＡＴクラスタチェーンを完成させてから、ＦＡＴクラスタチェーンの終端をフラッシュし完成したチェーンに接続することができるため、より安全に「ファイルの伸長」処理を実行することができる。なお、ＦＡＴクラスタチェーンの終端とは、ＦＡＴの中でファイル末尾（第１の情報、第３の情報）を示す情報に相当し、それ以外のＦＡＴに含まれる情報（第２の情報）と区別している。
【００３１】
具体的に図４を用いて、「ファイルの伸長」においてバッファキャッシュのフラッシュを実施する前の状態がバッファキャッシュ４０４だとする。このとき、ディレクトリエントリ領域として更新があったのがデータブロック４０７５でＦＡＴ領域として更新があったのがデータブロック４０６１、４０６３、４０６４、４０６５である。ＦＡＴ領域はバッファキャッシュ４０４１、４０４２、４０４４、４０４５にキャッシュされ、ＦＡＴクラスタチェーンの終端を含むバッファキャッシュが４０４１であるとする。本実施形態ではバッファキャッシュ４０４１に変更が加えられた時点でこのバッファキャッシュを保護し、ＦＡＴ領域の更新は４０４２、４０４４、４０４５から実施する。
【００３２】
この時のディレクトリエントリ、ＦＡＴ、データブロックの状態について図６を用いて説明する。図６の初期状態６０１はエントリのファイルサイズが１ブロック分であるのに対して、５番のデータブロックのみが割り当たっている。この状態から５１番、９１番のデータブロックを割り当て、ファイルサイズを３ブロック分に伸長する処理を行う。この時、ＦＡＴのフラッシュは点線で示す単位で３箇所に渡って行われる。
【００３３】
元々のＦＡＴの末尾（５番を含むＦＡＴ領域）を保護した状態でフラッシュすると記憶装置に元々記憶されているファイルの末尾（ＦＡＴクラスタチェーンの終端）を保護した場合は途中状態６０２のようになる。この途中状態６０２状態では、エントリのファイルサイズが１ブロック分であるのに対して、５番のデータブロックが割り当たっている。さらに、５１番と９１番のデータブロックがチェーン（連結）しているが、これらのブロックはアクセスされる領域として残っていないため問題とならない。この途中状態６０２から元々のＦＡＴの末尾の保護を解除しフラッシュすることで、５番と５１番を正常にチェーンすることができる。
【００３４】
一方で、無秩序にフラッシュされた場合途中状態６０３のようになることがある。この途中状態６０３では、エントリのファイルサイズが１ブロック分であるのに対して、５番、５１番のデータブロックのみが割り当たっている。一見、実際にアクセスする領域であるエントリのサイズ（１ブロック分）に相当するデータブロックは存在するので問題ないように見えるが、５１番のデータブロックはＦＡＴ上では未使用状態（ＦＡＴの値が０）であるため、例えばファイルの削除などにおける順次ＦＡＴを辿るような処理においてエラーを引き起こす恐れがある。
【００３５】
また、前述のように「ファイルの延長」においてはバッファキャッシュのフラッシュを一時的に保留させることでファイルシステムの安全性を高めることができるが、逆に「ファイルの短縮」においてはバッファキャッシュのフラッシュを即座に実施することでそれが可能となる（詳細は後述する）。このように、バッファキャッシュのフラッシュを一時的に保留させる（もしくは即座にフラッシュする）ことで、より安全なファイルシステムを実現することができる。
【００３６】
次に、図３に本実施形態のファイルシステム（ファイル管理装置）の概念的な機能構成を示す。
【００３７】
図３に示す様にファイルシステム３００はＡＰＩ制御部３０１、フラッシュ順序制御部３０２、バッファキャッシュ制御部３０３を有する。記憶装置３１０は予め本実施形態のファイルシステムを利用できるようにフォーマットされ、インデックス情報を含むディレクトリエントリを格納するＤＩＲ領域（第２メタデータ領域）３１１、データ領域の使用状態と連結状態を示す管理情報を含むファイルアロケーションテーブルを格納するＦＡＴ領域（第１メタデータ領域）３１２、ＤＡＴＡ領域３１３を設けられている。
【００３８】
バッファキャッシュ制御部３０３のバッファキャッシュ（不図示）はファイルシステムが管理するＲＡＭ１０５の記憶領域であればよい。記憶装置３１０のＤＩＲ領域３１１、ＦＡＴ領域３１２、ＤＡＴＡ領域３１３に記録すべき内容をキャッシュする。バッファキャッシュはバッファとしても機能し、詳細には、ＡＰＩ制御部３０１が判別した記憶装置のアクセス対象の内容をバッファキャッシュに読み出し、その内容をＡＰＩ３０１のファイル操作に応じて更新し、アクセス対象に更新した内容を書き戻す。
【００３９】
フラッシュ順序制御部３０２は図１４に示すテーブルのように各ＡＰＩのフラッシュ順序（ＦＡＴ内のフラッシュ順序含む）を規定する情報を有している。ただし、実際にテーブルとして保持する必要はなく、ライブラリとしてファイルシステムから参照できるように構成してもよいし、ファイルシステム内の各ＡＰＩのコードの中に埋め込んでしまってもよい。
【００４０】
ＡＰＩ制御部３０１はアプリケーションやオペレーションプログラム側からＡＰＩ呼び出し（第１ファイル操作指示、第２ファイル操作指示）を受けると、フラッシュ順序制御部３０２にアクセスしフラッシュ順序が保持されているＡＰＩであれば、そのフラッシュ順序に従ってバッファキャッシュ３０３のバッファしているデータを記憶装置３１０に書き出す。なお、フラッシュ順序が保持されていないＡＰＩについて簡易的にＤＡＴＡ、ディレクトリ、ＦＡＴなどの固定順にフラッシュするようにしてもよいし、無秩序にフラッシュしてもよい。また、本実施形態ではバッファキャッシュを用いて説明しているが、バッファキャッシュを用いなくても、ファイル操作指示の種類に応じた順序で、ＤＩＲ領域３１１、ＦＡＴ領域３１２、ＤＡＴＡ領域３１３のうちの少なくとも２つ以上を更新できればよい。
【００４１】
また、ＡＰＩ制御部３０１は、ＦＡＴ領域の中のフラッシュ順序として、「保留」が示されていればデータブロックを他のＦＡＴ領域を全て書き出してから最後に書き出すように制御する。一方で、「即時」がしめされていればデータブロックを他のＦＡＴ領域よりも最初に（優先的に）書き出すように制御する。
【００４２】
以降の説明では、図３に示す本実施形態のファイル管理装置が図１４に示すフラッシュ順序（およびＦＡＴ末尾保護の有無）に基づいて、ファイル操作種類ごと（以下の説明ではＡＰＩごと）に適する順序でバッファキャッシュを記録するためのＡＰＩ制御部３０１による制御フローについて具体的に説明する。
【００４３】
＜ファイルの作成：Ｏｐｅｎ（），Ｃｒｅａｔ（）＞
通常、ファイルを作成するときに書込みが発生する領域は、新たに作成されるディレクトリエントリを書き込む領域のみである。しかし、ディレクトリエントリを書き込むディレクトリに空き領域がない場合はディレクトリの拡張が行われる。この場合、ディレクトリエントリの領域に加えてＦＡＴ領域にも書込みが発生する。本実施形態のファイル管理装置によるファイルの作成処理にについて、同期制御の手順を図７のフローチャートを基に説明する。
【００４４】
まず、ステップＳ７０１においてファイルを作成するディレクトリに十分な空き領域があるか確認する。空きがある場合はステップＳ７０３に飛んでディレクトリエントリの作成を行う。空きがない場合はディレクトリの拡張を行うためにステップＳ７０２に進む。
【００４５】
ステップＳ７０２では空きデータブロックを元々のディレクトリと連結するために、ＦＡＴ領域をバッファキャッシュのみ更新する。不定な領域にディレクトリがリンクするのを防ぐため、ディレクトリエントリ領域がフラッシュされるまで記憶装置へのフラッシュは行わないようにする。さらに、最終的なフラッシュより前に元々のＦＡＴチェーンの終端が記憶装置へ書き込まれないよう、元々のＦＡＴチェーンの終端を含むキャッシュをリプレイスから保護してフラッシュを保留させる。
【００４６】
ステップＳ７０３では新たに獲得したデータブロックのゼロクリアおよびディレクトリエントリの作成を行う。データブロックのゼロクリアはたくさんのバッファキャッシュを消費するためキャッシュのリプレイスが頻発することがあるが、ステップＳ７０２で保護したキャッシュだけはリプレイス対象から外れフラッシュされずに残るため、不定な領域がリンクされることはない。ステップＳ７０１からこのステップに飛んだ場合、ゼロクリアは不要で、ディレクトリエントリの作成のみ行う。
【００４７】
ステップＳ７０４ではディレクトリエントリ領域のみフラッシュを行う。ステップＳ７０３において発生したバッファキャッシュのリプレイスにより既にいくつかのキャッシュはフラッシュされている可能性があるため、残りの領域が対象となる。
【００４８】
最後に、ステップＳ７０５でＦＡＴ領域のフラッシュを行う。このとき、ステップＳ７０２で保護したバッファキャッシュはそのままでＦＡＴ領域のフラッシュを行う。その後でステップＳ７０２で保護したキャッシュの保護を解除しフラッシュする。ステップＳ７０１からステップＳ７０３に飛んだ後このステップに到達した場合、このステップで実施する処理は不要である。
【００４９】
＜ファイルへのデータ書き込み：Ｗｒｉｔｅ（）＞
ファイルへのデータの書込みにおいても新たに領域を確保する場合はデータ領域、ディレクトリエントリ領域に加えてＦＡＴ領域への書き込みが必要となる。「ファイルへのデータ書き込み」における最適な同期制御の手順を図８のフローチャートを基に説明する。
まず、ステップＳ８０１においてデータを書き込む領域に十分な空き領域があるか確認する。空きがある場合はステップＳ８０３に飛んでデータの書き込みを行う。空きがない場合はファイルの拡張を行うためにステップＳ８０２に進む。
【００５０】
ステップＳ８０２では空きデータブロックを元々のファイルと連結するために、ＦＡＴ領域をバッファキャッシュのみ更新する。不定な領域にファイルがリンクするのを防ぐため、データ領域がフラッシュされるまで記憶装置へのフラッシュは行うことはできない。さらに、最終的なフラッシュより前に元々のＦＡＴチェーンの終端が記憶装置へ書き込まれないよう、元々のＦＡＴチェーンの終端を含むキャッシュをリプレイスから保護してフラッシュを保留させる。
【００５１】
ステップＳ８０３ではデータの書き込みを行う。データの書き込みはたくさんのバッファキャッシュを消費するためキャッシュのリプレイスが頻発することがあるが、ステップＳ８０２で保護したキャッシュだけはリプレイス対象から外れフラッシュされずに残るため、不定な領域がリンクされることはない。ちなみに、データ領域はアクセス頻度が低く、かつ、「ファイルへのデータ書き込み」において最初に記憶装置にフラッシュされる領域であるため、この時点でバッファを通さず直接記憶装置にフラッシュしても良い。
【００５２】
ステップＳ８０４ではファイルのサイズを変更するために、ディレクトリエントリ領域をバッファキャッシュのみ更新する。リンクされていない領域をディレクトリエントリが指し示すのを防ぐため、ＦＡＴ領域がフラッシュされるまで記憶装置へのフラッシュは行うことはできない。ここでも、ステップＳ８０２で保護したキャッシュだけはリプレイス対象から外れフラッシュされずに残るため、不定な領域がリンクされることはない。
【００５３】
ステップＳ８０５ではデータ領域のみフラッシュを行う。ステップＳ８０３でデータ領域を直接記憶装置に書き込んでいる場合はこのステップは不要である。
ステップＳ８０６ではＦＡＴ領域のみフラッシュを行う。このとき、ステップＳ８０２で保護したバッファキャッシュはそのままでＦＡＴ領域のフラッシュを行う。その後でステップＳ８０２で保護したキャッシュの保護を解除しフラッシュする。ステップＳ８０１からステップＳ８０３に飛んだ後このステップに到達した場合、このステップで実施する処理は不要である。
【００５４】
最後に、ステップＳ８０７でディレクトリ領域のフラッシュを行う。
【００５５】
＜ファイルの削除：Ｕｎｌｉｎｋ（）＞
データブロックが割り当てられているファイルを削除する場合は、ディレクトリエントリ領域とＦＡＴ領域への書込みが必要となる。データブロックの割り当てがないファイルではディレクトリエントリ領域への書き込みのみである。本実施形態のファイル管理装置によるファイルの削除処理における同期制御の手順を図９のフローチャートを基に説明する。
【００５６】
まず、ステップＳ９０１においてディレクトリエントリの削除を行う。解放されるデータブロックへの参照を防ぐため、更新したディレクトリエントリ領域は即座に記憶装置へフラッシュする。
【００５７】
次に、ステップＳ９０２において削除するファイルにデータブロックの割り当てがあるか確認する。割り当てがない場合はそこで「ファイルの削除」は完了である。割り当てがある場合はデータブロックの解放を行うためにステップＳ９０３に進む。
【００５８】
ステップＳ９０３ではファイルに割り当てられたデータブロックを解放するために、ＦＡＴ領域のバッファキャッシュを更新する。既にディレクトリエントリが削除され、割り当てられたデータブロックを参照するものはないので、キャッシュのリプレイスによる不測のタイミングにおけるフラッシュを心配する必要もない。
【００５９】
最後に、ステップＳ９０４でＦＡＴ領域のフラッシュを行う。ステップＳ９０３においてバッファキャッシュのリプレイスにより既にいくつかのキャッシュはフラッシュされている可能性があるため、残りの領域が対象となる。
【００６０】
＜ファイルの伸長：Ｔｒｕｎｃａｔｅ（）（伸長）＞
データの書き込みが発生しない点以外は「ファイルへのデータ書き込み」と同じである。よって、更新領域はディレクトリエントリ領域およびＦＡＴ領域である。ただし、伸長した領域にゼロを書き込む実装においては「ファイルへのデータ書き込みと」全く同じ記録手順となる。本実施形態のファイル管理装置による伸長処理について同期制御の手順を図１０のフローチャートを基に説明する。
【００６１】
まず、ステップＳ１００１において指定されたファイルサイズが新たなデータブロックの連結を必要とするか確認する。必要がない場合はステップＳ１００３に飛んでディレクトリエントリの更新を行う。必要がある場合はファイルの拡張を行うためにステップＳ１００２に進む。
【００６２】
ステップＳ１００２では空きデータブロックを元々のファイルと連結するために、ＦＡＴ領域をバッファキャッシュのみ更新する。最終的なフラッシュより前に元々のＦＡＴチェーンの終端に対する更新が記憶装置へフラッシュされないよう、元々のＦＡＴチェーンの終端を含むキャッシュをリプレイスから保護してフラッシュを保留させる。
【００６３】
ステップＳ１００３ではファイルのサイズを変更するために、ディレクトリエントリ領域をバッファキャッシュのみ更新する。リンクされていない領域をディレクトリエントリが指し示すのを防ぐため、ＦＡＴ領域がフラッシュされるまで記憶装置へのフラッシュは行うことはできない。ステップＳ１００２で保護したキャッシュだけはリプレイス対象から外れフラッシュされずに残るため、キャッシュのリプレイスが発生しても不定な領域がリンクされることはない。
【００６４】
ステップＳ１００４ではＦＡＴ領域のみフラッシュを行う。このとき、ステップＳ１００２で保護したバッファキャッシュはそのままでＦＡＴ領域のフラッシュを行う。その後、ステップＳ１００２で保護したキャッシュの保護を解除しフラッシュする。ステップＳ１００１からステップＳ１００３に飛んだ後このステップに到達した場合、このステップで実施する処理は不要である。
【００６５】
最後に、ステップＳ１００５でディレクトリ領域のフラッシュを行う。
【００６６】
＜ファイルの短縮：Ｔｒｕｎｃａｔｅ（）（短縮）＞
基本的には「ファイルの伸長」の逆順である。ただし、短縮という性質上、ディレクトリエントリ領域のゼロクリアはないので、その点も伸長の場合と異なる。本実施形態のファイル管理装置によるファイルの短縮処理について、同期制御の手順を図１１のフローチャートを基に説明する。
【００６７】
まず、ステップＳ１１０１においてディレクトリエントリのファイルサイズの変更を行う。解放されるデータブロックへの参照を防ぐため、更新したディレクトリエントリ領域は即座に記憶装置へフラッシュする。
【００６８】
次に、ステップＳ１１０２において指定されたファイルサイズが既存のデータブロックの解放を必要とするか確認する。必要がない場合はそこで「ファイルの短縮」は完了である。必要がある場合はファイルの解放を行うためにステップＳ１１０３に進む。
【００６９】
ステップＳ１１０３では空きデータブロックを元々のファイルから解放するために、ＦＡＴ領域をバッファキャッシュのみ更新する。最終的なフラッシュより前にＦＡＴチェーンの任意の箇所に対する更新が記憶装置へフラッシュされても良いように、短縮後のＦＡＴチェーンの終端を含むキャッシュだけは即時フラッシュする。
【００７０】
最後に、ステップＳ１１０４でＦＡＴ領域のフラッシュを行う。このとき、ステップＳ１１０３で短縮後のＦＡＴチェーンの終端を含むキャッシュは既にフラッシュされているため、残りのＦＡＴチェーンに対する更新がどのように記憶装置に書き込まれても問題が発生することはない。
【００７１】
＜ディレクトリの作成：Ｍｉｄｉｒ（）＞
「ディレクトリの作成」は新たなデータブロックの確保とディレクトリエントリの作成の２段階の手順から成り立つ。このような特性から、「ディレクトリの作成」においてはディレクトリエントリ領域およびＦＡＴ領域の領域単位でのフラッシュがそれぞれ２度発生することに注意が必要である。ディレクトリエントリの作成については「ファイルの作成」の場合とおなじステップを踏めば良いので、ここではデータブロックの確保を主眼とする。「ディレクトリの作成」における最適な同期制御の手順を図１２のフローチャートを基に説明する。
【００７２】
まず、ステップＳ１２０１において空きデータブロックを確保するために、ＦＡＴ領域をバッファキャッシュのみ更新する。この領域はディレクトリエントリが作成されない限りどこからも参照されないため、ディレクトリエントリの作成より前であればいつフラッシュされても良いが、できるだけ領域を無駄にしないために、確保したＦＡＴを含むキャッシュをリプレイスから保護してフラッシュを保留させる。
【００７３】
次にステップＳ１２０２では新たに獲得したデータブロックのゼロクリアを行う。データブロックのゼロクリアはたくさんのバッファキャッシュを消費するためキャッシュのリプレイスが頻発することがあるが、ステップＳ１２０１で保護したキャッシュだけはリプレイス対象から外れフラッシュされずに残るため、不定な領域が使用済みとなることはない。
【００７４】
ステップＳ１２０３ではディレクトリエントリ領域のフラッシュを行う。
【００７５】
ステップＳ１２０４ではＦＡＴ領域のフラッシュを行う。このステップでフラッシュされるのはステップＳ１２０２で確保したデータブロックの分だけであるが、Ｓ１２０４に到達した時点では保護されているので、その保護を解除してからフラッシュする。
最後にステップＳ１２０５では「ファイルの作成」と同じ記録手順でディレクトリエントリの作成処理を実施する。
【００７６】
＜ディレクトリの削除：Ｒｍｄｉｒ（）＞
削除対象のデータブロックがファイルであるかディレクトリであるかという点が異なるだけで、「ファイルの削除」と同様の処理であるためここではその詳細を省略する。
【００７７】
＜ファイル・ディレクトリの名前・アクセス権・タイムスタンプの変更：Ｒｅｎａｍｅ（），Ｃｈｍｏｄ（），Ｕｔｉｍｅ（）＞
これらのＡＰＩについては更新する領域がディレクトリエントリ領域のみであるため、複雑な同期制御は不要である。
【００７８】
＜その他の実施形態＞
前述した実施形態はＦＡＴファイルシステムを前提として説明を行ったが、本発明はＦＡＴのようなデータ領域、ディレクトリエントリ領域、ＦＡＴ領域（ここでは、データブロックのチェ−ンを表現する領域とする）を持つファイルシステムにも適用することができる。また、本発明はバッファキャッシュを管理する際のアルゴリズムもＬＲＵに限定されない。
【００７９】
また、前述した実施形態では代表的なファイルシステムＡＰＩについて説明したが、「ファイルの連結」や「ファイルの分割」などのＡＰＩにおいても本発明を適用してファイルシステムの安全性を向上させることができる。
【００８０】
また、前述した実施形態では代表的なファイルシステムのＡＰＩの其々について、対応する処理（対応する、領域の更新順序に従って更新する処理）を示したが、少なくとも２つ以上の領域の更新順序が異なる２つ以上のＡＰＩを実施する構成であれば、本発明を適用することでファイルシステムの堅牢性を高めることができる。
【００８１】
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【特許請求の範囲】
【請求項１】
ファイルに含まれるデータを格納するデータ領域と、前記データ領域の使用状態および連結状態を示す管理情報を格納する第１メタデータ領域と、前記ファイルのサイズを示すインデックス情報を格納する第２メタデータ領域と、を記憶装置に設けてファイルを管理するファイル管理装置であって、
ファイル操作指示を受け付ける受け付け手段と、
前記データ領域と、前記第１メタデータ領域と、前記第２メタデータ領域と、の少なくとも２つ以上の領域について、前記受け付け手段で受け付けたファイル操作指示の種類に応じた順番で更新する制御手段と、
を有することを特徴とするファイル管理装置。
【請求項２】
データを格納する複数のブロックと、前記複数のブロックの使用状態および連結状態を示す管理情報を格納するファイルアロケーションテーブルと、前記ファイルのサイズを示すインデックス情報を格納するディレクトリエントリと、を記憶装置に設けてファイルを管理するファイル管理装置であって、
ファイル操作指示を受け付ける受け付け手段と、
少なくとも１つ以上の前記ブロックと、前記ファイルアロケーションテーブルと、前記ディレクトリエントリと、の少なくとも２つ以上について、前記受け付け手段で受け付けたファイル操作指示の種類に応じた順番で更新するように制御する制御手段と、
を有することを特徴とするファイル管理装置。
【請求項３】
前記受け付け手段は第１ファイル操作指示と第２ファイル操作指示を受け付け、前記制御手段は前記第１ファイル操作指示と前記第２ファイル操作指示について、異なる順番で前記データと、前記管理情報と、前記インデックス情報と、の少なくとも２つ以上について更新するように制御することを特徴とする請求項請求項１又は２に記載のファイル管理装置。
【請求項４】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルの作成処理に対応する場合、前記制御手段は前記記憶装置のインデックス情報を更新してから前記記憶装置の管理情報を更新するように制御することを特徴とする請求項１乃至３のいずれか１項に記載のファイル管理装置。
【請求項５】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルへのデータ書き込み処理に対応する場合、前記制御手段は前記記憶装置について、前記データを更新してから前記管理情報を更新し、次に前記インデックス情報を更新するように制御することを特徴とする請求項１乃至４のいずれか１項に記載のファイル管理装置。
【請求項６】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルの削除処理に対応する場合、前記制御手段は前記記憶装置のインデックス情報を更新してから前記記憶装置の管理情報を更新するように制御することを特徴とする請求項１乃至５のいずれか１項に記載のファイル管理装置。
【請求項７】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルの伸長処理に対応する場合、前記制御手段は前記記憶装置の管理情報を更新してから前記記憶装置のインデックス情報を更新するように制御することを特徴とする請求項１乃至６のいずれか１項に記載のファイル管理装置。
【請求項８】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルの短縮処理に対応する場合、前記制御手段は前記記憶装置のインデックス情報を更新してから前記記憶装置の管理情報を更新するように制御することを特徴とする請求項１乃至７のいずれか１項に記載のファイル管理装置。
【請求項９】
前記ファイル操作指示に関して前記記憶装置のアクセス対象の内容をキャッシュ情報として複数保持するバッファキャッシュを更に備え、
前記制御手段は、前記バッファキャッシュにキャッシュされているキャッシュ情報を前記ファイル操作指示の内容に応じて更新する更新手段と、前記更新手段の更新したキャッシュ情報を前記ファイル操作指示の種類の応じた順番で前記記憶装置のアクセス対象に書き出す書き出し手段とを備えていることを特徴とする請求項１乃至８のいずれか１項に記載のファイル管理装置。
【請求項１０】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルの作成処理に対応する場合、前記制御手段は、前記作成処理により作成するファイルについて前記記憶装置に記憶されているファイル末尾の管理情報の更新を、前記作成処理に関する他の管理情報を前記記憶装置へ書き出した後にするように制御することを特徴とする請求項１乃至９のいずれか１項に記載のファイル管理装置。
【請求項１１】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルへの書き込み処理に対応する場合、前記制御手段は、前記記憶装置に記憶されているファイル末尾の管理情報の更新を、前記書き込み処理に関して他の管理情報を前記書き出した後にするように制御することを特徴とする請求項１乃至１０のいずれか１項に記載のファイル管理装置。
【請求項１２】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルの伸長処理に対応する場合、前記制御手段は、前記記憶装置に記憶されているファイル末尾の管理情報の更新を、前記伸長処理に関して他の管理情報を前記記憶装置へ書き出した後にするように制御することを特徴とする請求項１乃至１１のいずれか１項に記載のファイル管理装置。
【請求項１３】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルの短縮処理に対応する場合、前記制御手段は、前記短縮処理で短縮するファイルに関するＦＡＴチェーンの終端を含むキャッシュ情報を、前記管理情報に関する他のキャッシュ情報を書き出す前に前記記憶装置へ書き出すように制御することを特徴とする請求項１乃至１２のいずれか１項に記載のファイル管理装置。
【請求項１４】
前記受け付け手段の受け付けたファイル操作指示の種類がディレクトリの作成処理に対応する場合、
前記制御手段は、前記ディレクトリエントリを作成するデータ領域を確保するために、確保するデータ領域に関するＦＡＴのキャッシュを保護し、データ領域を確保するためにインデックス情報と他のＦＡＴに関するキャッシュ情報とを書き出した後に保護したＦＡＴのキャッシュ情報を書き出すように制御し、
次に前記ディレクトリエントリに関するファイルを作成するために、前記制御手段は前記記憶装置の管理情報を更新してから前記記憶装置のインデックス情報を更新し、作成するファイルについて前記記憶装置に記憶されているファイル末尾の管理情報の更新を、前記作成処理に関する他の管理情報を前記記憶装置へ書き出した後にするように制御することを特徴とする請求項１乃至１３のいずれか１項に記載のファイル管理装置。
【請求項１５】
前記受け付け手段の受け付けたファイル操作指示の種類がディレクトリの削除処理に対応する場合、前記制御手段は前記記憶装置のインデックス情報を更新してから前記記憶装置の管理情報を更新するように制御することを特徴とする請求項１乃至１４のいずれか１項に記載のファイル管理装置。
【請求項１６】
前記ディレクトリエントリはファイル又はディレクトリの名前、およびファイル又はディレクトリのサイズ、タイムスタンプを示す情報を含んでいることを特徴とする請求項２に記載のファイル管理装置。
【請求項１７】
前記制御手段は、前記ファイル操作指示の種類に応じて、前記複数の領域のいずれかに属し前記記憶装置に記憶されている第１の情報の更新を、当該第１の情報と同じ領域に属している第２の情報を前記記憶装置に書き出した後にするように制御することを特徴とする請求項１に記載のファイル管理装置。
【請求項１８】
前記制御手段は、前記ファイル操作指示の種類に応じて、前記複数の領域のいずれかに属する第３の情報を、当該第３の情報と同じ領域に属している第２の情報よりも優先的に前記記憶装置に書き出すように制御することを特徴とする請求項１に記載のファイル管理装置。
【請求項１９】
前記ファイル操作指示の種類はＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ−Ｐｒｏｇｒａｍｍｉｎｇ−Ｉｎｔｅｒｆａｃｅ）の種類であることを特徴とする請求項１乃至１８のいずれか１項に記載のファイル管理装置。
【請求項２０】
ファイルに含まれるデータを格納するデータ領域と、前記データ領域の使用状態および連結状態を示す管理情報を格納する第１メタデータ領域と、前記ファイルのサイズを示すインデックス情報を格納する第２メタデータ領域と、を設けられた記憶装置を管理するファイル管理方法であって、
操作指示を受け付ける受け付け工程と、
前記データ領域と、前記第１メタデータ領域と、前記第２メタデータ領域と、の少なくとも２つ以上の領域について、前記受け付け工程で受け付けたファイル操作指示の種類に応じた順番で更新する更新工程と、
を有することを特徴とするファイル管理方法。
【請求項２１】
データを格納する複数のブロックと、前記複数のブロックの使用状態および連結状態を示す管理情報を格納するファイルアロケーションテーブルと、前記ファイルのサイズを示すインデックス情報を格納するディレクトリエントリと、を有する記憶装置を管理するファイル管理方法であって、
操作指示を受け付ける受け付け工程と、
少なくとも１つ以上の前記ブロックと、前記ファイルアロケーションテーブルと、前記ディレクトリエントリと、の少なくとも２つ以上について、前記受け付け工程で受け付けたファイル操作指示の種類に応じた順番で更新する更新工程と、
を有することを特徴とするファイル管理方法。
【請求項２２】
コンピュータを、
ファイルに含まれるデータを格納するデータ領域と、前記データ領域の使用状態および連結状態を示す管理情報を格納する第１メタデータ領域と、前記ファイルのサイズを示すインデックス情報を格納する第２メタデータ領域と、を記憶装置に設けてファイルを管理するファイル管理装置であって、
ファイル操作指示を受け付ける受け付け手段と、
前記データ領域と、前記第１メタデータ領域と、前記第２メタデータ領域と、の少なくとも２つ以上の領域について、前記受け付け手段で受け付けたファイル操作指示の種類に応じた順番で更新する制御手段と、
を有するファイル管理装置として機能させることを特徴とするプログラム
【請求項２３】
コンピュータを、
データを格納する複数のブロックと、前記複数のブロックの使用状態および連結状態を示す管理情報を格納するファイルアロケーションテーブルと、前記ファイルのサイズを示すインデックス情報を格納するディレクトリエントリと、を記憶装置に設けてファイルを管理するファイル管理装置であって、
ファイル操作指示を受け付ける受け付け手段と、
少なくとも１つ以上の前記ブロックと、前記ファイルアロケーションテーブルと、前記ディレクトリエントリと、の少なくとも２つ以上について、前記受け付け手段で受け付けたファイル操作指示の種類に応じた順番で更新する制御手段と、
を有するファイル管理装置として機能させることを特徴とするプログラム。
【請求項１】
ファイルに含まれるデータを格納するデータ領域と、前記データ領域の使用状態および連結状態を示す管理情報を格納する第１メタデータ領域と、前記ファイルのサイズを示すインデックス情報を格納する第２メタデータ領域と、を記憶装置に設けてファイルを管理するファイル管理装置であって、
ファイル操作指示を受け付ける受け付け手段と、
前記データ領域と、前記第１メタデータ領域と、前記第２メタデータ領域と、の少なくとも２つ以上の領域について、前記受け付け手段で受け付けたファイル操作指示の種類に応じた順番で更新する制御手段と、
を有することを特徴とするファイル管理装置。
【請求項２】
データを格納する複数のブロックと、前記複数のブロックの使用状態および連結状態を示す管理情報を格納するファイルアロケーションテーブルと、前記ファイルのサイズを示すインデックス情報を格納するディレクトリエントリと、を記憶装置に設けてファイルを管理するファイル管理装置であって、
ファイル操作指示を受け付ける受け付け手段と、
少なくとも１つ以上の前記ブロックと、前記ファイルアロケーションテーブルと、前記ディレクトリエントリと、の少なくとも２つ以上について、前記受け付け手段で受け付けたファイル操作指示の種類に応じた順番で更新するように制御する制御手段と、
を有することを特徴とするファイル管理装置。
【請求項３】
前記受け付け手段は第１ファイル操作指示と第２ファイル操作指示を受け付け、前記制御手段は前記第１ファイル操作指示と前記第２ファイル操作指示について、異なる順番で前記データと、前記管理情報と、前記インデックス情報と、の少なくとも２つ以上について更新するように制御することを特徴とする請求項請求項１又は２に記載のファイル管理装置。
【請求項４】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルの作成処理に対応する場合、前記制御手段は前記記憶装置のインデックス情報を更新してから前記記憶装置の管理情報を更新するように制御することを特徴とする請求項１乃至３のいずれか１項に記載のファイル管理装置。
【請求項５】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルへのデータ書き込み処理に対応する場合、前記制御手段は前記記憶装置について、前記データを更新してから前記管理情報を更新し、次に前記インデックス情報を更新するように制御することを特徴とする請求項１乃至４のいずれか１項に記載のファイル管理装置。
【請求項６】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルの削除処理に対応する場合、前記制御手段は前記記憶装置のインデックス情報を更新してから前記記憶装置の管理情報を更新するように制御することを特徴とする請求項１乃至５のいずれか１項に記載のファイル管理装置。
【請求項７】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルの伸長処理に対応する場合、前記制御手段は前記記憶装置の管理情報を更新してから前記記憶装置のインデックス情報を更新するように制御することを特徴とする請求項１乃至６のいずれか１項に記載のファイル管理装置。
【請求項８】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルの短縮処理に対応する場合、前記制御手段は前記記憶装置のインデックス情報を更新してから前記記憶装置の管理情報を更新するように制御することを特徴とする請求項１乃至７のいずれか１項に記載のファイル管理装置。
【請求項９】
前記ファイル操作指示に関して前記記憶装置のアクセス対象の内容をキャッシュ情報として複数保持するバッファキャッシュを更に備え、
前記制御手段は、前記バッファキャッシュにキャッシュされているキャッシュ情報を前記ファイル操作指示の内容に応じて更新する更新手段と、前記更新手段の更新したキャッシュ情報を前記ファイル操作指示の種類の応じた順番で前記記憶装置のアクセス対象に書き出す書き出し手段とを備えていることを特徴とする請求項１乃至８のいずれか１項に記載のファイル管理装置。
【請求項１０】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルの作成処理に対応する場合、前記制御手段は、前記作成処理により作成するファイルについて前記記憶装置に記憶されているファイル末尾の管理情報の更新を、前記作成処理に関する他の管理情報を前記記憶装置へ書き出した後にするように制御することを特徴とする請求項１乃至９のいずれか１項に記載のファイル管理装置。
【請求項１１】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルへの書き込み処理に対応する場合、前記制御手段は、前記記憶装置に記憶されているファイル末尾の管理情報の更新を、前記書き込み処理に関して他の管理情報を前記書き出した後にするように制御することを特徴とする請求項１乃至１０のいずれか１項に記載のファイル管理装置。
【請求項１２】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルの伸長処理に対応する場合、前記制御手段は、前記記憶装置に記憶されているファイル末尾の管理情報の更新を、前記伸長処理に関して他の管理情報を前記記憶装置へ書き出した後にするように制御することを特徴とする請求項１乃至１１のいずれか１項に記載のファイル管理装置。
【請求項１３】
前記受け付け手段の受け付けたファイル操作指示の種類がファイルの短縮処理に対応する場合、前記制御手段は、前記短縮処理で短縮するファイルに関するＦＡＴチェーンの終端を含むキャッシュ情報を、前記管理情報に関する他のキャッシュ情報を書き出す前に前記記憶装置へ書き出すように制御することを特徴とする請求項１乃至１２のいずれか１項に記載のファイル管理装置。
【請求項１４】
前記受け付け手段の受け付けたファイル操作指示の種類がディレクトリの作成処理に対応する場合、
前記制御手段は、前記ディレクトリエントリを作成するデータ領域を確保するために、確保するデータ領域に関するＦＡＴのキャッシュを保護し、データ領域を確保するためにインデックス情報と他のＦＡＴに関するキャッシュ情報とを書き出した後に保護したＦＡＴのキャッシュ情報を書き出すように制御し、
次に前記ディレクトリエントリに関するファイルを作成するために、前記制御手段は前記記憶装置の管理情報を更新してから前記記憶装置のインデックス情報を更新し、作成するファイルについて前記記憶装置に記憶されているファイル末尾の管理情報の更新を、前記作成処理に関する他の管理情報を前記記憶装置へ書き出した後にするように制御することを特徴とする請求項１乃至１３のいずれか１項に記載のファイル管理装置。
【請求項１５】
前記受け付け手段の受け付けたファイル操作指示の種類がディレクトリの削除処理に対応する場合、前記制御手段は前記記憶装置のインデックス情報を更新してから前記記憶装置の管理情報を更新するように制御することを特徴とする請求項１乃至１４のいずれか１項に記載のファイル管理装置。
【請求項１６】
前記ディレクトリエントリはファイル又はディレクトリの名前、およびファイル又はディレクトリのサイズ、タイムスタンプを示す情報を含んでいることを特徴とする請求項２に記載のファイル管理装置。
【請求項１７】
前記制御手段は、前記ファイル操作指示の種類に応じて、前記複数の領域のいずれかに属し前記記憶装置に記憶されている第１の情報の更新を、当該第１の情報と同じ領域に属している第２の情報を前記記憶装置に書き出した後にするように制御することを特徴とする請求項１に記載のファイル管理装置。
【請求項１８】
前記制御手段は、前記ファイル操作指示の種類に応じて、前記複数の領域のいずれかに属する第３の情報を、当該第３の情報と同じ領域に属している第２の情報よりも優先的に前記記憶装置に書き出すように制御することを特徴とする請求項１に記載のファイル管理装置。
【請求項１９】
前記ファイル操作指示の種類はＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ−Ｐｒｏｇｒａｍｍｉｎｇ−Ｉｎｔｅｒｆａｃｅ）の種類であることを特徴とする請求項１乃至１８のいずれか１項に記載のファイル管理装置。
【請求項２０】
ファイルに含まれるデータを格納するデータ領域と、前記データ領域の使用状態および連結状態を示す管理情報を格納する第１メタデータ領域と、前記ファイルのサイズを示すインデックス情報を格納する第２メタデータ領域と、を設けられた記憶装置を管理するファイル管理方法であって、
操作指示を受け付ける受け付け工程と、
前記データ領域と、前記第１メタデータ領域と、前記第２メタデータ領域と、の少なくとも２つ以上の領域について、前記受け付け工程で受け付けたファイル操作指示の種類に応じた順番で更新する更新工程と、
を有することを特徴とするファイル管理方法。
【請求項２１】
データを格納する複数のブロックと、前記複数のブロックの使用状態および連結状態を示す管理情報を格納するファイルアロケーションテーブルと、前記ファイルのサイズを示すインデックス情報を格納するディレクトリエントリと、を有する記憶装置を管理するファイル管理方法であって、
操作指示を受け付ける受け付け工程と、
少なくとも１つ以上の前記ブロックと、前記ファイルアロケーションテーブルと、前記ディレクトリエントリと、の少なくとも２つ以上について、前記受け付け工程で受け付けたファイル操作指示の種類に応じた順番で更新する更新工程と、
を有することを特徴とするファイル管理方法。
【請求項２２】
コンピュータを、
ファイルに含まれるデータを格納するデータ領域と、前記データ領域の使用状態および連結状態を示す管理情報を格納する第１メタデータ領域と、前記ファイルのサイズを示すインデックス情報を格納する第２メタデータ領域と、を記憶装置に設けてファイルを管理するファイル管理装置であって、
ファイル操作指示を受け付ける受け付け手段と、
前記データ領域と、前記第１メタデータ領域と、前記第２メタデータ領域と、の少なくとも２つ以上の領域について、前記受け付け手段で受け付けたファイル操作指示の種類に応じた順番で更新する制御手段と、
を有するファイル管理装置として機能させることを特徴とするプログラム
【請求項２３】
コンピュータを、
データを格納する複数のブロックと、前記複数のブロックの使用状態および連結状態を示す管理情報を格納するファイルアロケーションテーブルと、前記ファイルのサイズを示すインデックス情報を格納するディレクトリエントリと、を記憶装置に設けてファイルを管理するファイル管理装置であって、
ファイル操作指示を受け付ける受け付け手段と、
少なくとも１つ以上の前記ブロックと、前記ファイルアロケーションテーブルと、前記ディレクトリエントリと、の少なくとも２つ以上について、前記受け付け手段で受け付けたファイル操作指示の種類に応じた順番で更新する制御手段と、
を有するファイル管理装置として機能させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１３−９７５５６（Ｐ２０１３−９７５５６Ａ）
【公開日】平成２５年５月２０日（２０１３．５．２０）
【国際特許分類】
【出願番号】特願２０１１−２３９４６１（Ｐ２０１１−２３９４６１）
【出願日】平成２３年１０月３１日（２０１１．１０．３１）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【公開日】平成２５年５月２０日（２０１３．５．２０）
【国際特許分類】
【出願日】平成２３年１０月３１日（２０１１．１０．３１）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
[ Back to top ]