特許 6053274 ファイル管理装置、ファイル管理方法およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6053274

(24)【登録日】2016年12月9日

(45)【発行日】2016年12月27日

(54)【発明の名称】ファイル管理装置、ファイル管理方法およびプログラム

(51)【国際特許分類】

   G06F 12/00 20060101AFI20161219BHJP

【ＦＩ】

   G06F12/00 514R

   G06F12/00 531M

【請求項の数】16

【全頁数】18

(21)【出願番号】特願2011-239461(P2011-239461)

(22)【出願日】2011年10月31日

(65)【公開番号】特開2013-97556(P2013-97556A)

(43)【公開日】2013年5月20日

【審査請求日】2014年10月31日

(73)【特許権者】

【識別番号】000001007

【氏名又は名称】キヤノン株式会社

(74)【代理人】

【識別番号】100126240

【弁理士】

【氏名又は名称】阿部 琢磨

(74)【代理人】

【識別番号】100124442

【弁理士】

【氏名又は名称】黒岩 創吾

(72)【発明者】

【氏名】正込 浩平

【審査官】 三坂 敏夫

(56)【参考文献】

【文献】 特開２００８−２６９５２０（ＪＰ，Ａ）

【文献】 特開２００６−１８４９７９（ＪＰ，Ａ）

【文献】 国際公開第２００８／１４６４７５（ＷＯ，Ａ１）

【文献】 国際公開第２００５／０５５０６４（ＷＯ，Ａ１）

【文献】 特開２００４−２７２６０８（ＪＰ，Ａ）

【文献】 長澤 恒也，「組み込み向けストレージ・デバイスとして注目されるフラッシュ・メモリの基礎と電源障害に強いファイル・システムの構築」，Ｉｎｔｅｒｆａｃｅ 第３０巻 第１２号，日本，ＣＱ出版株式会社，２００４年１２月 １日，第30巻 第12号

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １２／００

(57)【特許請求の範囲】

【請求項1】

ファイルに含まれるデータを格納する複数のブロックと、前記複数のブロックの使用状
態および連結状態を示す管理情報を格納するファイルアロケーションテーブルと、前記フ
ァイルのサイズを示すインデックス情報を格納するディレクトリエントリと、を記憶装置
に設けてファイルを管理するファイル管理装置であって、
ファイル操作指示を受け付ける受け付け手段と、
前記受け付け手段の受け付けたファイル操作指示の種類がディレクトリの作成処理に対
応する場合、前記ディレクトリエントリを作成するデータ領域に関するＦＡＴのキャッシュをリプレイスから保護し、インデックス情報と他のＦＡＴに関するキャッシュ情報とを書き出した後に保護したＦＡＴのキャッシュ情報を書き出すように制御し、前記記憶装置の管理情報を更新してから前記記憶装置のインデックス情報を更新し、作成するファイルについて前記記憶装置に記憶されているファイル末尾の管理情報の更新を、前記作成処理に関する他の管理情報を前記記憶装置へ書き出した後にするように制御する制御手段と、を有することを特徴とするファイル管理装置。

【請求項2】

前記受け付け手段は第１ファイル操作指示と第２ファイル操作指示を受け付け、前記制御手段は前記第１ファイル操作指示と前記第２ファイル操作指示について、異なる順番で前記データと、前記管理情報と、前記インデックス情報と、の少なくとも２つ以上について更新するように制御することを特徴とする請求項１に記載のファイル管理装置。

【請求項3】

前記受け付け手段の受け付けたファイル操作指示の種類がファイルの作成処理に対応する場合、前記制御手段は前記記憶装置のインデックス情報を更新してから前記記憶装置の管理情報を更新するように制御することを特徴とする請求項１または２に記載のファイル管理装置。

【請求項4】

前記受け付け手段の受け付けたファイル操作指示の種類がファイルへのデータ書き込み処理に対応する場合、前記制御手段は前記記憶装置について、前記データを更新してから前記管理情報を更新し、次に前記インデックス情報を更新するように制御することを特徴とする請求項１乃至３のいずれか１項に記載のファイル管理装置。

【請求項5】

前記受け付け手段の受け付けたファイル操作指示の種類がファイルの削除処理に対応する場合、前記制御手段は前記記憶装置のインデックス情報を更新してから前記記憶装置の管理情報を更新するように制御することを特徴とする請求項１乃至４のいずれか１項に記載のファイル管理装置。

【請求項6】

前記受け付け手段の受け付けたファイル操作指示の種類がファイルの伸長処理に対応する場合、前記制御手段は前記記憶装置の管理情報を更新してから前記記憶装置のインデックス情報を更新するように制御することを特徴とする請求項１乃至５のいずれか１項に記載のファイル管理装置。

【請求項7】

前記ファイル操作指示に関して前記記憶装置のアクセス対象の内容をキャッシュ情報として複数保持するバッファキャッシュを更に備え、
前記制御手段は、前記バッファキャッシュにキャッシュされているキャッシュ情報を前記ファイル操作指示の内容に応じて更新する更新手段と、前記更新手段の更新したキャッシュ情報を前記ファイル操作指示の種類の応じた順番で前記記憶装置のアクセス対象に書き出す書き出し手段とを備えていることを特徴とする請求項１乃至６のいずれか１項に記載のファイル管理装置。

【請求項8】

前記受け付け手段の受け付けたファイル操作指示の種類がファイルの作成処理に対応する場合、前記制御手段は、前記作成処理により作成するファイルについて前記記憶装置に記憶されているファイル末尾の管理情報の更新を、前記作成処理に関する他の管理情報を前記記憶装置へ書き出した後にするように制御することを特徴とする請求項１乃至７のいずれか１項に記載のファイル管理装置。

【請求項9】

前記受け付け手段の受け付けたファイル操作指示の種類がファイルへの書き込み処理に対応する場合、前記制御手段は、前記記憶装置に記憶されているファイル末尾の管理情報の更新を、前記書き込み処理に関して他の管理情報を前記書き出した後にするように制御することを特徴とする請求項７または８に記載のファイル管理装置。

【請求項10】

前記受け付け手段の受け付けたファイル操作指示の種類がファイルの伸長処理に対応する場合、前記制御手段は、前記記憶装置に記憶されているファイル末尾の管理情報の更新を、前記伸長処理に関して他の管理情報を前記記憶装置へ書き出した後にするように制御することを特徴とする請求項１乃至９のいずれか１項に記載のファイル管理装置。

【請求項11】

前記受け付け手段の受け付けたファイル操作指示の種類がファイルの短縮処理に対応する場合、前記制御手段は、前記短縮処理で短縮するファイルに関するＦＡＴチェーンの終端を含むキャッシュ情報を、前記管理情報に関する他のキャッシュ情報を書き出す前に前記記憶装置へ書き出すように制御することを特徴とする請求項１乃至１０のいずれか１項に記載のファイル管理装置。

【請求項12】

前記受け付け手段の受け付けたファイル操作指示の種類がディレクトリの削除処理に対応する場合、前記制御手段は前記記憶装置のインデックス情報を更新してから前記記憶装置の管理情報を更新するように制御することを特徴とする請求項１乃至１１のいずれか１項に記載のファイル管理装置。

【請求項13】

前記ディレクトリエントリはファイル又はディレクトリの名前、およびファイル又はディレクトリのサイズ、タイムスタンプを示す情報を含んでいることを特徴とする請求項１に記載のファイル管理装置。

【請求項14】

前記ファイル操作指示の種類はＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ−Ｐｒｏｇｒａｍｍｉｎｇ−Ｉｎｔｅｒｆａｃｅ）の種類であることを特徴とする請求項１乃至１３のいずれか１項に記載のファイル管理装置。

【請求項15】

ファイルに含まれるデータを格納する複数のブロックと、前記複数のブロックの使用状態および連結状態を示す管理情報を格納するファイルアロケーションテーブルと、前記ファイルのサイズを示すインデックス情報を格納するディレクトリエントリと、を有する記憶装置を管理するファイル管理方法であって、
操作指示を受け付ける受け付け工程と、
前記受け付け工程で受け付けたファイル操作指示の種類がディレクトリの作成処理に対
応する場合、前記ディレクトリエントリを作成するデータ領域に関するＦＡＴのキャッシュをリプレイスから保護し、インデックス情報と他のＦＡＴに関するキャッシュ情報とを書き出した後に保護したＦＡＴのキャッシュ情報を書き出すように制御し、前記記憶装置の管理情報を更新してから前記記憶装置のインデックス情報を更新し、作成するファイルについて前記記憶装置に記憶されているファイル末尾の管理情報の更新を、前記作成処理に関する他の管理情報を前記記憶装置へ書き出した後にするように制御する更新工程と、を有することを特徴とするファイル管理方法。

【請求項16】

コンピュータを、
ファイルに含まれるデータを格納する複数のブロックと、前記複数のブロックの使用状態および連結状態を示す管理情報を格納するファイルアロケーションテーブルと、前記ファイルのサイズを示すインデックス情報を格納するディレクトリエントリと、を記憶装置に設けてファイルを管理するファイル管理装置であって、
ファイル操作指示を受け付ける受け付け手段と、
前記受け付け手段の受け付けたファイル操作指示の種類がディレクトリの作成処理に対
応する場合、前記ディレクトリエントリを作成するデータ領域に関するＦＡＴのキャッシュをリプレイスから保護し、インデックス情報と他のＦＡＴに関するキャッシュ情報とを書き出した後に保護したＦＡＴのキャッシュ情報を書き出すように制御し、前記記憶装置の管理情報を更新してから前記記憶装置のインデックス情報を更新し、作成するファイルについて前記記憶装置に記憶されているファイル末尾の管理情報の更新を、前記作成処理に関する他の管理情報を前記記憶装置へ書き出した後にするように制御する制御手段と、を有するファイル管理装置として機能させることを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、コンピュータシステムのファイルシステムおよびファイリング装置に関し、特に電子記憶装置におけるファイル管理装置、ファイル管理方法およびプログラムに関する。

【背景技術】

【0002】

近年、ＣＰＵの高速化やメモリ容量の増大に伴い、組み込みシステムにも高い機能が要求されている。例えば、記憶装置にデータを格納する際も大量のデータの蓄積やＰＣとのデータのやり取りを行うためにファイルシステムを用いることが当然とされるようになってきている。

【0003】

組み込みシステムでは、標準フォーマットと互換性があるファイルシステムを利用することが多い。ＰＣの事実上の標準と言えるファイルシステムが、マイクロソフト社製のＦＡＴファイルシステムである。ＦＡＴファイルシステムはＭＳ−ＤＯＳやＷｉｎｄｏｗｓ（登録商標）を筆頭に、多くの組み込みＯＳ用ファイルシステムにおいてもサポートされている。

【0004】

ＦＡＴファイルシステムは、ファイルの実データと、ＦＡＴ（Ｆｉｌｅ−Ａｌｌｏｃａｔｉｏｎ−Ｔａｂｌｅ）と呼ばれるデータブロックの管理情報およびディレクトリエントリと呼ばれるファイルのインデックス情報などのメタデータと、から構成される。

【0005】

一般的にファイルシステムにおいて、メタデータの整合性を維持することは重要な課題である。例えば、ファイル操作中に停電などによる電源断や記憶装置の抜き取りが発生した場合、ファイル操作の処理が完了しないままメタデータの一部が欠損し、メタデータ間の整合性が取れなくなってしまうことがある。このようなメタデータの整合性が取れていないファイルに対してファイル操作を行うと、正しく操作が完了できないだけでなく、場合によっては正常なデータ領域に格納されているデータを破壊してしまうこともある。

【0006】

ファイルシステムとしての整合性を保つ方法には、ジャーナリングファイルシステムのようなファイルシステムの整合性が損なわれたことを検出した後に、ファイルシステムを復旧する方法がある。他にも、特許文献１に示されるようなファイルシステムの整合性が損なわれる前に未然に抑制する方法がある。

【0007】

特許文献１では、ファイルシステムの領域をデータ領域、ディレクトリスロット領域、クラスタチェーン領域に区分している。ディレクトリスロットが前述のディレクトリエントリに当たり、クラスタチェーンが前述のＦＡＴに当たる。そして、ファイルシステムのキャッシュ機構であるバッファキャッシュに即時記録、遅延記録の機能を持たせることで、ファイルへのデータ書き込み時に各領域を（１）データ領域（２）ディレクトリスロット領域（３）クラスタチェーン領域の順番に記録する。このように、重要なメタデータの記録は後回しにすることで、データ書き込み中の電源断についてファイルシステムへのダメージを抑えようとしている。

【先行技術文献】

【特許文献】

【0008】

【特許文献1】特開２００４−２７２６０８号公報

【発明の概要】

【発明が解決しようとする課題】

【0009】

前述のジャーナリングファイルシステムでは、バックアップ情報を余分に記憶しておく領域を確保する必要があり、また、復旧処理の負荷も大きい。一方で、特許文献１に示す方法では、ファイル操作の種類であるＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ−Ｐｒｏｇｒａｍｍｉｎｇ−Ｉｎｔｅｒｆａｃｅ）を考慮しておらず、データ書込み（ｗｒｉｔｅ（））ＡＰＩ以外のＡＰＩを利用する際にファイルシステムの整合性を保つ機能が著しく損なわれてしまう。
そこで、本発明はこれらの問題を鑑みて、電源断によるファイルシステムの不整合に起因する不具合などをファイル操作の種類（ＡＰＩ種別など）に応じて好ましく抑制するファイルシステムを提供することを目的とする。

【課題を解決するための手段】

【0010】

上記目的を達成するための本発明に係るファイル管理装置は、ファイルに含まれるデータを格納する複数のブロックと、前記複数のブロックの使用状態および連結状態を示す管理情報を格納するファイルアロケーションテーブルと、前記ファイルのサイズを示すインデックス情報を格納するディレクトリエントリと、を記憶装置に設けてファイルを管理するファイル管理装置であって、ファイル操作指示を受け付ける受け付け手段と、前記受け付け手段の受け付けたファイル操作指示の種類がディレクトリの作成処理に対応する場合、前記ディレクトリエントリを作成するデータ領域に関するＦＡＴのキャッシュをリプレイスから保護し、インデックス情報と他のＦＡＴに関するキャッシュ情報とを書き出した後に保護したＦＡＴのキャッシュ情報を書き出すように制御し、前記記憶装置の管理情報を更新してから前記記憶装置のインデックス情報を更新し、作成するファイルについて前記記憶装置に記憶されているファイル末尾の管理情報の更新を、前記作成処理に関する他の管理情報を前記記憶装置へ書き出した後にするように制御する制御手段と、を有することを特徴とする。

【発明の効果】

【0011】

本発明のファイルシステムによれば、ファイル操作種別を考慮して、電源断などによってファイルシステムに生じる不整合による問題を低減させることができる。

【図面の簡単な説明】

【0012】

【図1】ハードウェア構成の概略を示すブロック図である。

【図2】ソフトウェア構成の概略を示す概念図である。

【図3】実施形態１のファイルシステムの機能構成の概略を示すブロック図である。

【図4】ソフトウェア構成の概略を示す概念図である。

【図5】ファイルサイズとＦＡＴチェーンとが整合していない状態を示す。

【図6】完結していないＦＡＴチェーンの例である。

【図7】「ファイルの作成」処理における安全な同期制御のフローチャートである。

【図8】「ファイルへのデータ書き込み」処理における安全な同期制御のフローチャートである。

【図9】「ファイルの削除」処理における安全な同期制御のフローチャートである。

【図10】「ファイルの伸長」処理における安全な同期制御のフローチャートである。

【図11】「ファイルの短縮」処理における安全な同期制御のフローチャートである。

【図12】「ディレクトリの作成」処理における安全な同期制御のフローチャートである。

【図13】ファイルシステムのＡＰＩの一覧を示す。

【図14】ＡＰＩ毎のフラッシュ順序を示す。

【発明を実施するための形態】

【0013】

＜実施形態１＞
本発明の一実施形態である実施形態１を、ＦＡＴファイルシステムを例に用いて説明する。なお、ＦＡＴファイルシステムをＦＡＴとして呼称されることも多いが、本実施形態の説明ではＦＡＴはファイルアロケーションテーブルそのものとして説明する。

【0014】

本実施形態におけるファイルシステムの構成を、図１および図２を参照して説明する。

【0015】

図１は本実施形態のハードウェア構成の概略であり、組み込みコンピュータ１０１は、バス１０２、ＣＰＵ１０３、ＲＯＭ１０４、ＲＡＭ１０５、記憶装置１０６を有している。ここで、記憶装置１０６は組み込みコンピュータ１０１に対して着脱可能であってもよい。

【0016】

図２は本実施形態のファイル管理装置の機能構成を示し、アプリケーションプログラム２０１、オペレーティングシステム２０２、ファイルシステム２０３、バッファキャッシュ２０４、記憶装置２０５、データブロック２０６を備えている。

【0017】

組み込みコンピュータ１０１においてＣＰＵ１０３は、バス１０２によって相互に接続されたＲＯＭ１０４、ＲＡＭ１０５、記憶装置１０６の制御を行う。ＣＰＵ１０３はＲＯＭ１０４などに格納されたアプリケーションプログラム、ファイルシステムプログラムを実行することにより、記憶装置１０６に記録された論理ファイルの操作を行う。その際、ＲＡＭ１０５は作業領域として利用される。

【0018】

アプリケーションプログラム２０１は、記憶装置２０５に対してアクセスを行う際、オペレーティングシステム２０２を通してファイルシステム２０３の各種ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ−Ｐｒｏｇｒａｍｍｉｎｇ−Ｉｎｔｅｒｆａｃｅ）を呼び出す。代表的なＡＰＩの一覧を図１３に示す。図１３では代表的なファイルシステムＡＰＩ、そのＡＰＩの機能の説明と、そのＡＰＩによって更新される領域との対応付けを図示している。

【0019】

ファイルシステム２０３はアプリケーションプログラム２０１から呼び出されたＡＰＩに応じて記憶装置２０５に対するアクセスを行うが、その際、記憶装置２０５のデータブロック２０６の内アクセスのあったブロックをキャッシュ情報としてファイルシステム２０３のバッファキャッシュ２０４に一時的にキャッシュしておく。すると、次回、同じブロックにアクセスする際のＩ／Ｏ処理を省略し高速な動作を実現することができる。また、記憶装置に書き込む際も、同じブロックへの変更をまとめて処理することで効率化を図ることができる。このような機能は特に書き換え頻度の高いＦＡＴやディレクトリエントリの領域において有効である。ちなみに、図２においては一つのデータブロックの内容をキャッシュ情報として保持するために一つのバッファキャッシュを使用しているが、一つのデータブロックの内容を複数のバッファキャッシュを使用して記憶する形態にしてもよい。なお、バッファキャッシュはキャッシュ情報を複数保持できることが好ましい。

【0020】

バッファキャッシュ２０４は従来の方式では、ＬＲＵ（Ｌｅａｓｔ−Ｒｅｃｅｎｔｌｙ−Ｕｓｅｄ）アルゴリズムで管理され、バッファキャッシュが不足した場合は、最も昔にアクセスしたブロックのキャッシュから記憶装置２０５に書き出され（フラッシュされ）、そのキャッシュが新たな領域のバッファリングに使用される。また、ＬＲＵにより自動的にフラッシュされる以外にもアプリケーション２０１が明示的に同期を発行することで、全てのキャッシュを一度に記録装置２０５にフラッシュする場合もある。

【0021】

前述のようなファイルシステムにおいてメタデータの整合性を維持させる場合、ＡＰＩ実行ごとに記憶装置へのフラッシュを管理する必要がある。例えば、一度もキャッシュのフラッシュを行うことなく複数のＡＰＩを実行すると、それまでの操作によりアクセスのあった様々な領域に渡るキャッシュが混在する可能性がある。そして、混在したキャッシュをファイルシステムの整合性が維持されるように同期して一度にフラッシュすることは困難である。

【0022】

本実施形態では、記憶装置へのフラッシュを実施するに当たって、書き込みＡＰＩ毎に適した更新領域の順序で記録する。図１３のＡＰＩ一覧に示す通り、書き込みＡＰＩはＡＰＩ毎に更新する領域が決まっている。図中のＤＡＴＡはデータ領域、ＤＩＲはディレクトリエントリ領域、ＦＡＴはＦＡＴ領域を表す。

【0023】

ここで、一覧にあるＡＰＩのうち「Ｔｒｕｎｃａｔｅ（）（伸長）：ファイルの伸長」と「Ｔｒｕｎｃａｔｅ（）（短縮）：ファイルの短縮」に着目すると、どちらもディレクトリエントリ領域およびＦＡＴ領域を更新するが、本実施形態では、「ファイルの伸長」においてはＦＡＴの更新を先に実施し、「ファイルの短縮」においてはディレクトリエントリの更新を先に実施する。これは、それぞれの場合において、ディレクトリエントリのサイズが実際より大きい状態になりリンクされていないデータブロックを指し示す現象が発生することを防ぐためである。（なお、以降の説明ではファイル操作を単にカギ括弧で表記する。）
図４を用いて、「ファイルの伸長」処理を具体的に説明する。「ファイルの伸長」においてバッファキャッシュのフラッシュを実施する前の状態の例をバッファキャッシュ４０４として図示する。そして、データブロック４０７５がディレクトリエントリ領域として更新され、データブロック４０６１、４０６３、４０６４、４０６５がＦＡＴ領域として更新される。これらはバッファキャッシュ４０４１〜４０４５にキャッシュされているが、記憶装置へのフラッシュは、ＤＩＲ領域のバッファキャッシュ４０４３より先にＦＡＴ領域のバッファキャッシュである４０４１、４０４２、４０４４、４０４５から実施する。

【0024】

この時のディレクトリエントリ、ＦＡＴ、データブロックの状態について図５を用いて説明する。図５の初期状態５０１はエントリのファイルサイズが１ブロック分であるのに対して、５番のデータブロックのみが割り当たっている。この状態から５１番、９１番のデータブロックを割り当て、ファイルサイズを３ブロック分に伸長する処理を行う。

【0025】

この時、点線で示すＦＡＴ領域・ＤＩＲ領域がフラッシュされる必要がある。ここで、ＦＡＴ領域からフラッシュした場合は途中状態５０２を通過する。なお、以降の説明で登場する途中状態とは、正常なファイル操作をした場合にも遷移すると考えられる状態であるが、電源断や記憶装置へのアクセス不能の発生などの不慮の事態が生じない限りこの途中状態が露呈する可能性は低い。この途中状態５０２では、エントリのファイルサイズが１ブロック分であるのに対して、５番、５１番、９１番のデータブロックが割り当たっている。エントリのファイルサイズと実際のファイルサイズに不整合が生じているが、実際にアクセスする領域であるエントリのサイズ（１ブロック分）に相当するデータブロックは割り当たっているため問題とならない。この状態から更にＤＩＲ領域をフラッシュすることで、安全にファイルサイズと実際のデータブロック数の整合性をとることができるためである。

【0026】

一方で、初期状態５０１からＤＩＲ領域を先にフラッシュすると途中状態５０３を通過する。この途中状態５０３ではエントリのファイルサイズが３ブロック分であるのに対して、５番のデータブロックのみが割り当たっている。すると、実際にアクセスするエントリのサイズ（３ブロック分）に相当するデータブロックに存在しない領域が含まれるため問題になる。例えば、ファイルの読み込みなどにおける特定のサイズに対応するデータブロックの検索を行うような処理においてエラーを引き起こす恐れがある。

【0027】

また、「ファイルの短縮」の場合、ＤＩＲ領域のバッファキャッシュからフラッシュして先にファイルサイズを小さくしておくことで、「ファイルの伸長」の場合と同様に実際にリンクされていない領域を指し示す状態を防ぐことができる。

【0028】

このように、記憶装置に対する各領域の記録順序はファイル操作の種類（例えば、上述のファイル伸長とファイル短縮）もしくはＡＰＩごとに異なるので、ＡＰＩごとに正しい更新領域の記録順序を定義することで、より安全なファイルシステムを実現することができる。

【0029】

さらに本実施形態では、特定領域のフラッシュ制御も実施する。例えば、「ファイルの伸長」では、（１）ＦＡＴ領域のフラッシュ（２）ディレクトリエントリ領域のフラッシュという順序で記憶装置への記録処理を行うことになっている。このとき、（１）でフラッシュするＦＡＴ領域は複数個所にまたがることも多い。これらが不規則な順番でフラッシュされていくと一時的にＦＡＴクラスタチェーンが断裂した状態になり、その状態で電源断などに陥るとファイルシステムに矛盾が発生する可能性がある。

【0030】

従って、本実施形態ではこのような状況を防ぐために、「ファイルの伸長」においては、記憶装置に元々記憶されているＦＡＴクラスタチェーン（ファイルの連結状態）の終端（末尾）を含むバッファキャッシュは保護することでフラッシュ対象から除外し、（１）ＦＡＴ領域のフラッシュの最後で保護を解除しフラッシュするようにしておく。すると、保護した領域以外の箇所を先にフラッシュすることで、延長する部分のＦＡＴクラスタチェーンを完成させてから、ＦＡＴクラスタチェーンの終端をフラッシュし完成したチェーンに接続することができるため、より安全に「ファイルの伸長」処理を実行することができる。なお、ＦＡＴクラスタチェーンの終端とは、ＦＡＴの中でファイル末尾（第１の情報、第３の情報）を示す情報に相当し、それ以外のＦＡＴに含まれる情報（第２の情報）と区別している。

【0031】

具体的に図４を用いて、「ファイルの伸長」においてバッファキャッシュのフラッシュを実施する前の状態がバッファキャッシュ４０４だとする。このとき、ディレクトリエントリ領域として更新があったのがデータブロック４０７５でＦＡＴ領域として更新があったのがデータブロック４０６１、４０６３、４０６４、４０６５である。ＦＡＴ領域はバッファキャッシュ４０４１、４０４２、４０４４、４０４５にキャッシュされ、ＦＡＴクラスタチェーンの終端を含むバッファキャッシュが４０４１であるとする。本実施形態ではバッファキャッシュ４０４１に変更が加えられた時点でこのバッファキャッシュを保護し、ＦＡＴ領域の更新は４０４２、４０４４、４０４５から実施する。

【0032】

この時のディレクトリエントリ、ＦＡＴ、データブロックの状態について図６を用いて説明する。図６の初期状態６０１はエントリのファイルサイズが１ブロック分であるのに対して、５番のデータブロックのみが割り当たっている。この状態から５１番、９１番のデータブロックを割り当て、ファイルサイズを３ブロック分に伸長する処理を行う。この時、ＦＡＴのフラッシュは点線で示す単位で３箇所に渡って行われる。

【0033】

元々のＦＡＴの末尾（５番を含むＦＡＴ領域）を保護した状態でフラッシュすると記憶装置に元々記憶されているファイルの末尾（ＦＡＴクラスタチェーンの終端）を保護した場合は途中状態６０２のようになる。この途中状態６０２状態では、エントリのファイルサイズが１ブロック分であるのに対して、５番のデータブロックが割り当たっている。さらに、５１番と９１番のデータブロックがチェーン（連結）しているが、これらのブロックはアクセスされる領域として残っていないため問題とならない。この途中状態６０２から元々のＦＡＴの末尾の保護を解除しフラッシュすることで、５番と５１番を正常にチェーンすることができる。

【0034】

一方で、無秩序にフラッシュされた場合途中状態６０３のようになることがある。この途中状態６０３では、エントリのファイルサイズが１ブロック分であるのに対して、５番、５１番のデータブロックのみが割り当たっている。一見、実際にアクセスする領域であるエントリのサイズ（１ブロック分）に相当するデータブロックは存在するので問題ないように見えるが、５１番のデータブロックはＦＡＴ上では未使用状態（ＦＡＴの値が０）であるため、例えばファイルの削除などにおける順次ＦＡＴを辿るような処理においてエラーを引き起こす恐れがある。

【0035】

また、前述のように「ファイルの延長」においてはバッファキャッシュのフラッシュを一時的に保留させることでファイルシステムの安全性を高めることができるが、逆に「ファイルの短縮」においてはバッファキャッシュのフラッシュを即座に実施することでそれが可能となる（詳細は後述する）。このように、バッファキャッシュのフラッシュを一時的に保留させる（もしくは即座にフラッシュする）ことで、より安全なファイルシステムを実現することができる。

【0036】

次に、図３に本実施形態のファイルシステム（ファイル管理装置）の概念的な機能構成を示す。

【0037】

図３に示す様にファイルシステム３００はＡＰＩ制御部３０１、フラッシュ順序制御部３０２、バッファキャッシュ制御部３０３を有する。記憶装置３１０は予め本実施形態のファイルシステムを利用できるようにフォーマットされ、インデックス情報を含むディレクトリエントリを格納するＤＩＲ領域（第２メタデータ領域）３１１、データ領域の使用状態と連結状態を示す管理情報を含むファイルアロケーションテーブルを格納するＦＡＴ領域（第１メタデータ領域）３１２、ＤＡＴＡ領域３１３を設けられている。

【0038】

バッファキャッシュ制御部３０３のバッファキャッシュ（不図示）はファイルシステムが管理するＲＡＭ１０５の記憶領域であればよい。記憶装置３１０のＤＩＲ領域３１１、ＦＡＴ領域３１２、ＤＡＴＡ領域３１３に記録すべき内容をキャッシュする。バッファキャッシュはバッファとしても機能し、詳細には、ＡＰＩ制御部３０１が判別した記憶装置のアクセス対象の内容をバッファキャッシュに読み出し、その内容をＡＰＩ３０１のファイル操作に応じて更新し、アクセス対象に更新した内容を書き戻す。

【0039】

フラッシュ順序制御部３０２は図１４に示すテーブルのように各ＡＰＩのフラッシュ順序（ＦＡＴ内のフラッシュ順序含む）を規定する情報を有している。ただし、実際にテーブルとして保持する必要はなく、ライブラリとしてファイルシステムから参照できるように構成してもよいし、ファイルシステム内の各ＡＰＩのコードの中に埋め込んでしまってもよい。

【0040】

ＡＰＩ制御部３０１はアプリケーションやオペレーションプログラム側からＡＰＩ呼び出し（第１ファイル操作指示、第２ファイル操作指示）を受けると、フラッシュ順序制御部３０２にアクセスしフラッシュ順序が保持されているＡＰＩであれば、そのフラッシュ順序に従ってバッファキャッシュ３０３のバッファしているデータを記憶装置３１０に書き出す。なお、フラッシュ順序が保持されていないＡＰＩについて簡易的にＤＡＴＡ、ディレクトリ、ＦＡＴなどの固定順にフラッシュするようにしてもよいし、無秩序にフラッシュしてもよい。また、本実施形態ではバッファキャッシュを用いて説明しているが、バッファキャッシュを用いなくても、ファイル操作指示の種類に応じた順序で、ＤＩＲ領域３１１、ＦＡＴ領域３１２、ＤＡＴＡ領域３１３のうちの少なくとも２つ以上を更新できればよい。

【0041】

また、ＡＰＩ制御部３０１は、ＦＡＴ領域の中のフラッシュ順序として、「保留」が示されていればデータブロックを他のＦＡＴ領域を全て書き出してから最後に書き出すように制御する。一方で、「即時」がしめされていればデータブロックを他のＦＡＴ領域よりも最初に（優先的に）書き出すように制御する。

【0042】

以降の説明では、図３に示す本実施形態のファイル管理装置が図１４に示すフラッシュ順序（およびＦＡＴ末尾保護の有無）に基づいて、ファイル操作種類ごと（以下の説明ではＡＰＩごと）に適する順序でバッファキャッシュを記録するためのＡＰＩ制御部３０１による制御フローについて具体的に説明する。

【0043】

＜ファイルの作成：Ｏｐｅｎ（），Ｃｒｅａｔ（）＞
通常、ファイルを作成するときに書込みが発生する領域は、新たに作成されるディレクトリエントリを書き込む領域のみである。しかし、ディレクトリエントリを書き込むディレクトリに空き領域がない場合はディレクトリの拡張が行われる。この場合、ディレクトリエントリの領域に加えてＦＡＴ領域にも書込みが発生する。本実施形態のファイル管理装置によるファイルの作成処理にについて、同期制御の手順を図７のフローチャートを基に説明する。

【0044】

まず、ステップＳ７０１においてファイルを作成するディレクトリに十分な空き領域があるか確認する。空きがある場合はステップＳ７０３に飛んでディレクトリエントリの作成を行う。空きがない場合はディレクトリの拡張を行うためにステップＳ７０２に進む。

【0045】

ステップＳ７０２では空きデータブロックを元々のディレクトリと連結するために、ＦＡＴ領域をバッファキャッシュのみ更新する。不定な領域にディレクトリがリンクするのを防ぐため、ディレクトリエントリ領域がフラッシュされるまで記憶装置へのフラッシュは行わないようにする。さらに、最終的なフラッシュより前に元々のＦＡＴチェーンの終端が記憶装置へ書き込まれないよう、元々のＦＡＴチェーンの終端を含むキャッシュをリプレイスから保護してフラッシュを保留させる。

【0046】

ステップＳ７０３では新たに獲得したデータブロックのゼロクリアおよびディレクトリエントリの作成を行う。データブロックのゼロクリアはたくさんのバッファキャッシュを消費するためキャッシュのリプレイスが頻発することがあるが、ステップＳ７０２で保護したキャッシュだけはリプレイス対象から外れフラッシュされずに残るため、不定な領域がリンクされることはない。ステップＳ７０１からこのステップに飛んだ場合、ゼロクリアは不要で、ディレクトリエントリの作成のみ行う。

【0047】

ステップＳ７０４ではディレクトリエントリ領域のみフラッシュを行う。ステップＳ７０３において発生したバッファキャッシュのリプレイスにより既にいくつかのキャッシュはフラッシュされている可能性があるため、残りの領域が対象となる。

【0048】

最後に、ステップＳ７０５でＦＡＴ領域のフラッシュを行う。このとき、ステップＳ７０２で保護したバッファキャッシュはそのままでＦＡＴ領域のフラッシュを行う。その後でステップＳ７０２で保護したキャッシュの保護を解除しフラッシュする。ステップＳ７０１からステップＳ７０３に飛んだ後このステップに到達した場合、このステップで実施する処理は不要である。

【0049】

＜ファイルへのデータ書き込み：Ｗｒｉｔｅ（）＞
ファイルへのデータの書込みにおいても新たに領域を確保する場合はデータ領域、ディレクトリエントリ領域に加えてＦＡＴ領域への書き込みが必要となる。「ファイルへのデータ書き込み」における最適な同期制御の手順を図８のフローチャートを基に説明する。
まず、ステップＳ８０１においてデータを書き込む領域に十分な空き領域があるか確認する。空きがある場合はステップＳ８０３に飛んでデータの書き込みを行う。空きがない場合はファイルの拡張を行うためにステップＳ８０２に進む。

【0050】

ステップＳ８０２では空きデータブロックを元々のファイルと連結するために、ＦＡＴ領域をバッファキャッシュのみ更新する。不定な領域にファイルがリンクするのを防ぐため、データ領域がフラッシュされるまで記憶装置へのフラッシュは行うことはできない。さらに、最終的なフラッシュより前に元々のＦＡＴチェーンの終端が記憶装置へ書き込まれないよう、元々のＦＡＴチェーンの終端を含むキャッシュをリプレイスから保護してフラッシュを保留させる。

【0051】

ステップＳ８０３ではデータの書き込みを行う。データの書き込みはたくさんのバッファキャッシュを消費するためキャッシュのリプレイスが頻発することがあるが、ステップＳ８０２で保護したキャッシュだけはリプレイス対象から外れフラッシュされずに残るため、不定な領域がリンクされることはない。ちなみに、データ領域はアクセス頻度が低く、かつ、「ファイルへのデータ書き込み」において最初に記憶装置にフラッシュされる領域であるため、この時点でバッファを通さず直接記憶装置にフラッシュしても良い。

【0052】

ステップＳ８０４ではファイルのサイズを変更するために、ディレクトリエントリ領域をバッファキャッシュのみ更新する。リンクされていない領域をディレクトリエントリが指し示すのを防ぐため、ＦＡＴ領域がフラッシュされるまで記憶装置へのフラッシュは行うことはできない。ここでも、ステップＳ８０２で保護したキャッシュだけはリプレイス対象から外れフラッシュされずに残るため、不定な領域がリンクされることはない。

【0053】

ステップＳ８０５ではデータ領域のみフラッシュを行う。ステップＳ８０３でデータ領域を直接記憶装置に書き込んでいる場合はこのステップは不要である。
ステップＳ８０６ではＦＡＴ領域のみフラッシュを行う。このとき、ステップＳ８０２で保護したバッファキャッシュはそのままでＦＡＴ領域のフラッシュを行う。その後でステップＳ８０２で保護したキャッシュの保護を解除しフラッシュする。ステップＳ８０１からステップＳ８０３に飛んだ後このステップに到達した場合、このステップで実施する処理は不要である。

【0054】

最後に、ステップＳ８０７でディレクトリ領域のフラッシュを行う。

【0055】

＜ファイルの削除：Ｕｎｌｉｎｋ（）＞
データブロックが割り当てられているファイルを削除する場合は、ディレクトリエントリ領域とＦＡＴ領域への書込みが必要となる。データブロックの割り当てがないファイルではディレクトリエントリ領域への書き込みのみである。本実施形態のファイル管理装置によるファイルの削除処理における同期制御の手順を図９のフローチャートを基に説明する。

【0056】

まず、ステップＳ９０１においてディレクトリエントリの削除を行う。解放されるデータブロックへの参照を防ぐため、更新したディレクトリエントリ領域は即座に記憶装置へフラッシュする。

【0057】

次に、ステップＳ９０２において削除するファイルにデータブロックの割り当てがあるか確認する。割り当てがない場合はそこで「ファイルの削除」は完了である。割り当てがある場合はデータブロックの解放を行うためにステップＳ９０３に進む。

【0058】

ステップＳ９０３ではファイルに割り当てられたデータブロックを解放するために、ＦＡＴ領域のバッファキャッシュを更新する。既にディレクトリエントリが削除され、割り当てられたデータブロックを参照するものはないので、キャッシュのリプレイスによる不測のタイミングにおけるフラッシュを心配する必要もない。

【0059】

最後に、ステップＳ９０４でＦＡＴ領域のフラッシュを行う。ステップＳ９０３においてバッファキャッシュのリプレイスにより既にいくつかのキャッシュはフラッシュされている可能性があるため、残りの領域が対象となる。

【0060】

＜ファイルの伸長：Ｔｒｕｎｃａｔｅ（）（伸長）＞
データの書き込みが発生しない点以外は「ファイルへのデータ書き込み」と同じである。よって、更新領域はディレクトリエントリ領域およびＦＡＴ領域である。ただし、伸長した領域にゼロを書き込む実装においては「ファイルへのデータ書き込みと」全く同じ記録手順となる。本実施形態のファイル管理装置による伸長処理について同期制御の手順を図１０のフローチャートを基に説明する。

【0061】

まず、ステップＳ１００１において指定されたファイルサイズが新たなデータブロックの連結を必要とするか確認する。必要がない場合はステップＳ１００３に飛んでディレクトリエントリの更新を行う。必要がある場合はファイルの拡張を行うためにステップＳ１００２に進む。

【0062】

ステップＳ１００２では空きデータブロックを元々のファイルと連結するために、ＦＡＴ領域をバッファキャッシュのみ更新する。最終的なフラッシュより前に元々のＦＡＴチェーンの終端に対する更新が記憶装置へフラッシュされないよう、元々のＦＡＴチェーンの終端を含むキャッシュをリプレイスから保護してフラッシュを保留させる。

【0063】

ステップＳ１００３ではファイルのサイズを変更するために、ディレクトリエントリ領域をバッファキャッシュのみ更新する。リンクされていない領域をディレクトリエントリが指し示すのを防ぐため、ＦＡＴ領域がフラッシュされるまで記憶装置へのフラッシュは行うことはできない。ステップＳ１００２で保護したキャッシュだけはリプレイス対象から外れフラッシュされずに残るため、キャッシュのリプレイスが発生しても不定な領域がリンクされることはない。

【0064】

ステップＳ１００４ではＦＡＴ領域のみフラッシュを行う。このとき、ステップＳ１００２で保護したバッファキャッシュはそのままでＦＡＴ領域のフラッシュを行う。その後、ステップＳ１００２で保護したキャッシュの保護を解除しフラッシュする。ステップＳ１００１からステップＳ１００３に飛んだ後このステップに到達した場合、このステップで実施する処理は不要である。

【0065】

最後に、ステップＳ１００５でディレクトリ領域のフラッシュを行う。

【0066】

＜ファイルの短縮：Ｔｒｕｎｃａｔｅ（）（短縮）＞
基本的には「ファイルの伸長」の逆順である。ただし、短縮という性質上、ディレクトリエントリ領域のゼロクリアはないので、その点も伸長の場合と異なる。本実施形態のファイル管理装置によるファイルの短縮処理について、同期制御の手順を図１１のフローチャートを基に説明する。

【0067】

まず、ステップＳ１１０１においてディレクトリエントリのファイルサイズの変更を行う。解放されるデータブロックへの参照を防ぐため、更新したディレクトリエントリ領域は即座に記憶装置へフラッシュする。

【0068】

次に、ステップＳ１１０２において指定されたファイルサイズが既存のデータブロックの解放を必要とするか確認する。必要がない場合はそこで「ファイルの短縮」は完了である。必要がある場合はファイルの解放を行うためにステップＳ１１０３に進む。

【0069】

ステップＳ１１０３では空きデータブロックを元々のファイルから解放するために、ＦＡＴ領域をバッファキャッシュのみ更新する。最終的なフラッシュより前にＦＡＴチェーンの任意の箇所に対する更新が記憶装置へフラッシュされても良いように、短縮後のＦＡＴチェーンの終端を含むキャッシュだけは即時フラッシュする。

【0070】

最後に、ステップＳ１１０４でＦＡＴ領域のフラッシュを行う。このとき、ステップＳ１１０３で短縮後のＦＡＴチェーンの終端を含むキャッシュは既にフラッシュされているため、残りのＦＡＴチェーンに対する更新がどのように記憶装置に書き込まれても問題が発生することはない。

【0071】

＜ディレクトリの作成：Ｍｉｄｉｒ（）＞
「ディレクトリの作成」は新たなデータブロックの確保とディレクトリエントリの作成の２段階の手順から成り立つ。このような特性から、「ディレクトリの作成」においてはディレクトリエントリ領域およびＦＡＴ領域の領域単位でのフラッシュがそれぞれ２度発生することに注意が必要である。ディレクトリエントリの作成については「ファイルの作成」の場合とおなじステップを踏めば良いので、ここではデータブロックの確保を主眼とする。「ディレクトリの作成」における最適な同期制御の手順を図１２のフローチャートを基に説明する。

【0072】

まず、ステップＳ１２０１において空きデータブロックを確保するために、ＦＡＴ領域をバッファキャッシュのみ更新する。この領域はディレクトリエントリが作成されない限りどこからも参照されないため、ディレクトリエントリの作成より前であればいつフラッシュされても良いが、できるだけ領域を無駄にしないために、確保したＦＡＴを含むキャッシュをリプレイスから保護してフラッシュを保留させる。

【0073】

次にステップＳ１２０２では新たに獲得したデータブロックのゼロクリアを行う。データブロックのゼロクリアはたくさんのバッファキャッシュを消費するためキャッシュのリプレイスが頻発することがあるが、ステップＳ１２０１で保護したキャッシュだけはリプレイス対象から外れフラッシュされずに残るため、不定な領域が使用済みとなることはない。

【0074】

ステップＳ１２０３ではディレクトリエントリ領域のフラッシュを行う。

【0075】

ステップＳ１２０４ではＦＡＴ領域のフラッシュを行う。このステップでフラッシュされるのはステップＳ１２０２で確保したデータブロックの分だけであるが、Ｓ１２０４に到達した時点では保護されているので、その保護を解除してからフラッシュする。
最後にステップＳ１２０５では「ファイルの作成」と同じ記録手順でディレクトリエントリの作成処理を実施する。

【0076】

＜ディレクトリの削除：Ｒｍｄｉｒ（）＞
削除対象のデータブロックがファイルであるかディレクトリであるかという点が異なるだけで、「ファイルの削除」と同様の処理であるためここではその詳細を省略する。

【0077】

＜ファイル・ディレクトリの名前・アクセス権・タイムスタンプの変更：Ｒｅｎａｍｅ（），Ｃｈｍｏｄ（），Ｕｔｉｍｅ（）＞
これらのＡＰＩについては更新する領域がディレクトリエントリ領域のみであるため、複雑な同期制御は不要である。

【0078】

＜その他の実施形態＞
前述した実施形態はＦＡＴファイルシステムを前提として説明を行ったが、本発明はＦＡＴのようなデータ領域、ディレクトリエントリ領域、ＦＡＴ領域（ここでは、データブロックのチェ−ンを表現する領域とする）を持つファイルシステムにも適用することができる。また、本発明はバッファキャッシュを管理する際のアルゴリズムもＬＲＵに限定されない。

【0079】

また、前述した実施形態では代表的なファイルシステムＡＰＩについて説明したが、「ファイルの連結」や「ファイルの分割」などのＡＰＩにおいても本発明を適用してファイルシステムの安全性を向上させることができる。

【0080】

また、前述した実施形態では代表的なファイルシステムのＡＰＩの其々について、対応する処理（対応する、領域の更新順序に従って更新する処理）を示したが、少なくとも２つ以上の領域の更新順序が異なる２つ以上のＡＰＩを実施する構成であれば、本発明を適用することでファイルシステムの堅牢性を高めることができる。

【0081】

また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】