(57)【要約】【課題】ファイル操作におけるOpen/Closeに要する処理時間を短縮することのできるファイルアクセスシステムを提供する。【解決手段】アプリケーションからファイルの操作要求を受け付け、オペレーティングシステムとの間で、該当するファイル識別子の授受を行うファイル識別子制御部と、ファイル識別子、ファイル名、ファイルアクセスに関するデータから成るキャッシュエントリを登録するための識別子キャッシュとを備え、ファイル識別子制御部は、アプリケーションから、同一ファイルを同一ファイルアクセスで２回以上オープン処理する要求を受けた場合に、都度、新規にファイル識別子を発行し、アプリケーションからのファイルクローズ要求に対して、ファイル識別子を再利用し、ファイルのクローズ処理を遅延させるファイルアクセスシステム。【選択図】図１
2015103012.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションからファイルの操作要求を受け付け、オペレーティングシステムとの間で、該当するファイル識別子の授受を行うファイル識別子制御部と、
前記ファイル識別子、ファイル名、ファイルアクセスに関するデータから成るキャッシュエントリを登録するための識別子キャッシュとを備え、
前記ファイル識別子制御部は、アプリケーションから、同一ファイルを同一ファイルアクセスで２回以上オープン処理する要求を受けた場合に、都度、新規に前記ファイル識別子を発行し、アプリケーションからのファイルクローズ要求に対して、前記ファイル識別子を再利用し、前記ファイルのクローズ処理を遅延させるファイルアクセスシステム。
【請求項２】
前記ファイルアクセスは、ランダムアクセスである請求項１に記載のファイルアクセスシステム。
【請求項３】
前記識別子キャッシュは、現在有効な前記ファイル識別子の数を表す有効識別子数、ファイルのクローズ処理の際に同期処理が必要かどうかを示すSync必要フラグのデータを登録するキャッシュエントリを有している請求項１又は請求項２に記載のファイルアクセスシステム。
【請求項４】
アプリケーションからのファイルクローズ要求に応じて、前記有効識別子数を減らし、前記有効識別子数がゼロになったら、オペレーティングシステムのクローズ処理のシステムコールをしない請求項１乃至請求項３のいずれか1項に記載のファイルアクセスシステム。
【請求項５】
前記キャッシュエントリの数は、所定のしきい値で管理し、該しきい値を超えた場合には、キャッシュ管理処理を行う請求項３又は請求項４に記載のファイルアクセスシステム。
【請求項６】
アプリケーションからの書込み要求の際に、前記ファイルへの書込み時に同期処理を伴った場合には、Sync必要フラグをセットする請求項３乃至請求項５のいずれか1項に記載のファイルアクセスシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、ファイルアクセスシステムに関する。
【背景技術】
【０００２】
アプリケーションの動作モードは、ユーザ空間におけるユーザモードと、カーネル空間におけるカーネルモードに大別でき、両者はシステムコールで関係付けられる。
【０００３】
アプリケーションは、ユーザ空間にて機能するファイル識別子を介して、カーネル空間の管理情報にアクセスする。具体的なファイル操作は、個々のファイルの書込み開始位置などの細かいデータを管理する管理情報によって、カーネル空間で行われる。
【０００４】
一般的なファイルに対する入出力操作の流れは、ファイルのOpen⇒ファイルに対するRead/Write⇒ファイルのCloseである。アプリケーションはファイルのOpenで、ファイル識別子を取得して、ファイル操作に使用している。
【０００５】
ファイルアクセスの特徴として、例えば、データベースサーバのデータ管理タスクなどの多数のファイルをランダムアクセスで扱うタスクでは、頻繁なファイルOpen/ファイルCloseがある。一方、例えば、ログファイル出力タスクなどの一定数のファイルをシーケンシャルアクセスで扱うタスクでは、あまり頻繁にファイルOpen/ファイルCloseを行わない。リアルタイム性が求められるアプリや組み込み系では、ファイルのOpen/Closeがオーバヘッドとなる。Open/Close処理では、処理に時間を要するシステムコールを伴う。従って、ファイルのOpen/Close処理も時間がかかる。
【０００６】
一般的に、システムコールの処理には、最低限、レジスタ退避及び復元、ＣＰＵの動作モードの変更(カーネル/ユーザモードスイッチ)、スケジューラの動作(他タスクが動くことがある)、その他システムコールの動作をトリガとしたカーネルの処理のコストが必要である。例えば、１処理周期を１００μｓ以内で処理しなければならない場合には、このような処理のコストがレスポンスタイムに影響を与える。
【０００７】
そこで、一般的な対応策として、使用するファイルはアプリケーション開始時に全部Openしておくことがなされている。このようにして、ファイルOpen／Close処理をアプリケーションの動作中にしないようにすれば良い。
【０００８】
しかしながら、このような対応策は、使用するファイルが予め分かっている前提でないと難しい、との問題があった。例えば、データベースサーバのデータ管理タスクなど、不特定の数のファイルを扱うタスクでは、このような前提は置けないため、このような対応策を使うことはできない。本発明では使用するファイルが予めわからない状況下において、ファイルのOpen／Close処理の回数を削減する。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００６−１６４２１１号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
本発明が解決しようとする課題は、ファイル操作におけるOpen/Closeに要する処理時間を短縮できるファイルアクセスシステムを提供することである。
【課題を解決するための手段】
【００１１】
実施形態のファイルアクセスシステムは、アプリケーションからファイルの操作要求を受け付け、オペレーティングシステムとの間で、該当するファイル識別子の授受を行うファイル識別子制御部と、前記ファイル識別子、ファイル名、ファイルアクセスに関するデータから成るキャッシュエントリを登録するための識別子キャッシュとを備え、前記ファイル識別子制御部は、アプリケーションから、同一ファイルを同一ファイルアクセスで２回以上オープン処理する要求を受けた場合に、都度、新規に前記ファイル識別子を発行し、アプリケーションからのファイルクローズ要求に対して、前記ファイル識別子を再利用し、前記ファイルのクローズ処理を遅延させる。
【図面の簡単な説明】
【００１２】
【図１】本実施形態におけるファイル識別子のキャッシュ機構を説明する図である。
【図２】本発明の実施形態に係るファイルアクセスシステムの概略構成を示すブロック図である。
【図３】キャッシュエントリの構造を説明する図である。
【図４】Open処理の流れを示すフローチャートである。
【図５】Write処理の流れを示すフローチャートである。
【図６】Sync処理の流れを示すフローチャートである。
【図７】Close処理の流れを示すフローチャートである。
【図８】キャッシュ管理処理の流れを示すフローチャートである。
【図９】ファイル削除処理の流れを示すフローチャートである。
【図１０】データベース・マネジメント・システムで本実施形態を実施した実施例を説明する図である。
【発明を実施するための形態】
【００１３】
以下、本発明の一実施の形態について、図面を参照して説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。
【００１４】
まず、本実施形態で用いる主要な用語について説明する。
【００１５】
「ファイル識別子」とは、OSのファイル管理情報を指す。アプリケーションには、番号やアドレスなどの形で見えることが多い。ファイルの書き込み開始位置や、細かいデータを扱うのはカーネル内のことが多い。
【００１６】
本実施形態においては、ユーザモードでのファイル識別子のキャッシュ機構を備えるものである。図１は、本実施形態におけるファイル識別子のキャッシュ機構を説明する図である。図１に示すように、ファイル名及びファイルアクセス毎に、ファイル識別子が付与される。さらに、同時期に、ファイル名及びファイルアクセスでアクセスがある場合には、別のファイル識別子が付与される。
【００１７】
本実施形態においては、ファイルアクセスがランダムアクセスの場合に、アプリからファイルのCloseが要求されてもClose処理を遅延させ、できるだけOpenしたままとし、キャッシュ容量の不足に応じて、周知のキャッシュ管理アルゴリズムに従って、使わないものをCloseするものである。本実施形態では、シーケンシャルアクセスの場合は、ケアしない。
【００１８】
図２は、本発明の実施形態に係るファイルアクセスシステムの概略構成を示すブロック図である。この装置は汎用のコンピュータ（例えばパーソナルコンピュータ（ＰＣ）等）と、同コンピュータ上で動作するソフトウェアとを用いて実現される。コンピュータとしては、ＣＡＤ（Computer Aided Design）やＣＡＥ（Computer Aided Engineering）に好適なエンジニアリングワークステーション（ＥＷＳ）等も含む。本実施形態はこのようなコンピュータに、ファイルアクセスを制御するプログラムとして実施することもできる。
【００１９】
図２に示すように、本実施形態に係るファイルアクセスシステム１００は、主として、ファイル識別子制御部１０、識別子キャッシュ１１から構成されている。ファイルアクセスシステム１００は、ユーザ空間のアプリケーション１３からアクセスされるとともに、カーネル空間のオペレーティングシステム１４とも情報のやりとりを行う。オペレーティングシステム１４は、アプリケーションが用いるデータ(ファイル)を記憶する記憶装置１５と接続している。例えば、本実施形態をデータベースシステムに適用する場合には、データベースシステムで用いるテーブルデータ(表データ)が記憶される。
【００２０】
ファイル識別子制御部１０は、アプリケーションからファイルの操作要求を受け付け、オペレーティングシステム（カーネル）との間で、該当するファイル識別子の授受を行う。詳細は後述する。
【００２１】
識別子キャッシュ１１は、オンメモリであって、０個以上のキャッシュエントリを持っている。図３は、キャッシュエントリの構造を説明する図である。図３に示すように、キャッシュエントリは、“属性”欄には、“ファイル名”、“ファイルアクセス”、“ファイル識別子リスト”、“有効識別子数”、“Sync必要フラグリスト”をそれぞれ“属性”とし、各属性について、“型”と“備考”が設けられている。“ファイル名”は、“文字列”で表され、“検索キー”として機能する。“ファイルアクセス”は、例えば、“READ”、“WRITE”、“CREATE”、“APPEND”、“RANDOM_ACCESS”、“検索キー”に分類される。“ファイル識別子リスト”は、識別子のリストであって、ファイル識別子そのものは、ＯＳのファイル管理情報としてＯＳによって付与される。“有効識別子数”は、キャッシュエントリが保持する、現在有効な識別子の数を表す。“有効識別子数”は整数で表され、初期値はゼロ（０）である。０のときは、ファイル識別子リストの先頭が再利用可能であることを意味している。“Sync必要フラグリスト”は、真偽値のリストで表され、ファイルClose時にSyncが必要かどうかを示すものである。キャッシュエントリの数量は、記憶容量が過大とならずに、かつ、検索時間短縮の観点から、しきい値で管理するのが、好適である。例えば、キャッシュエントリの数がしきい値を超えた時にキャッシュ管理処理を実施し、古いキャッシュエントリを削除した後、できた空き領域へ新しいキャッシュエントリを格納する。この際、キャッシュ管理アルゴリズムとして、先入れ先だし方式(FIFO)やLeast Recently Used 方式などを採用することができる。
【００２２】
＜ファイルアクセス制御の流れ＞
次に、以上のように構成されたファイルアクセスシステム１００におけるファイルアクセス制御の流れについて説明する。
【００２３】
ファイル識別子制御部１０は、アプリケーション１３からファイルのOpen要求を受けると、識別子キャッシュ１１にアクセスして、ランダムアクセス指定時であって、ファイル名及びファイルアクセスに対応する識別子があるかどうか検索する。ファイル識別子があれば、ファイル識別子制御部１０は、ファイル識別子をアプリケーション１３に返す。該当するファイル識別子がなければ、ファイル識別子制御部１０は、オペレーティングシステム１４に対して通常のOpen処理を実行する。これに対して、オペレーティングシステム１４は、ファイル識別子をファイル識別子制御部１０に返す。ファイル識別子制御部１０は、識別子キャッシュ１１にファイル識別子、ファイル名及びファイルアクセスを登録する。登録後、ファイル識別子制御部１０は、ファイル識別子をアプリケーション１３に返す。
【００２４】
本実施形態では、上記のようにファイルアクセスを制御し、ファイル名とファイルアクセスが一致する場合に、ファイルに対する識別子を再利用し、ファイルのCloseを遅延させ、できるだけOpenしたままにする。単純にCloseを遅延すると、同じ識別子を使いまわすため、問題がでる可能性がある。例えば、アプリケーション内で同じファイルを２回Openした場合、異なるファイル識別子が必要であるが、同じファイル識別子しか付与されない、という問題であり、Close時にディスクとのSyncが必要であり、システムコールの処理になるという問題である。
【００２５】
そこで、本実施形態では、同じファイルを同じファイルアクセスで２回以上Openする場合には、都度、新規に識別子を発行し、残り識別子数が０になったら、Closeを遅延するようにする、さらに、Close時のSyncによる処理時間の短縮を図る、すなわち、システムコールの呼び出しを防止するために、Syncをする必要があるか否かを調べるものである。
【００２６】
以下、アプリケーション１３からの要求に応じたファイル識別子制御部１０の動作について、詳述する。尚、Read処理については、ファイル識別子を利用した従来と同様の処理で実行することができるので、説明を割愛する。
【００２７】
＜Open処理＞
図４は、Open処理の流れを示すフローチャートである。
【００２８】
まず、アプリケーション１３から渡されたファイルアクセスが、ランダムアクセスか否か判定する（ステップＳ４０１）。
【００２９】
ランダムアクセスであれば（ステップＳ４０１でＹｅｓ）、識別子キャッシュ１２にファイル名及びランダムアクセスに対応するキャッシュエントリが存在するか検索する（ステップＳ４０２）。
【００３０】
キャッシュエントリが存在する場合（ステップＳ４０２でＹｅｓ）には、続いて、キャッシュエントリ内の有効識別子数が０か否か判定する（ステップＳ４０３）。
【００３１】
有効識別子数が０であれば（ステップＳ４０３でＹｅｓ）、キャッシュエントリ内の識別子リストにある識別子を再利用し、Openを呼び出さない（ステップＳ４０４）。
【００３２】
次いで、キャッシュエントリ内の有効識別子数を１増やしてから、ファイル識別子をアプリケーション１３に返して（ステップＳ４０５）、Open処理を終了する。すなわち、アプリケーション１３が呼び出したOpen処理の結果として、ファイル識別子を出力する。
【００３３】
一方、ステップＳ４０２でファイル名及びランダムアクセスに対応するキャッシュエントリが識別子キャッシュ１１に存在しなければ（ステップＳ４０２でＮｏ）、識別子キャッシュ１１にアプリケーション１３から渡されたファイル名及びランダムアクセスで、新規キャッシュエントリを作成する（ステップＳ４０６）。尚、キャッシュエントリの数がしきい値を超えた時にキャッシュ管理処理を実施し、古いキャッシュエントリを削除した後、できた空き領域へ新しいキャッシュエントリを格納する。
【００３４】
続いて、カーネルのopen()を呼び出し、新規にファイル識別子を得る（ステップＳ４０７）。
【００３５】
次に、カーネルから得られたファイル識別子をキャッシュエントリ内のファイル識別子リストへ追加（ステップＳ４０８）し、ステップＳ４０５に移行する。
【００３６】
ステップＳ４０３でＮｏ、すなわち、有効識別子数が０でなければ当該ファイルは使用中であることを意味しているので、ステップＳ４０７に移行する。本実施形態では、同じファイルを同じファイルアクセスで２回以上Openする場合に、都度、新規に識別子を発行する。
【００３７】
一方、ステップＳ４０１で、ランダムアクセスでなければ（ステップＳ４０１でＮｏ）、カーネルのopen()を呼び出し、ファイル識別子を得る（ステップＳ４０９）。
【００３８】
続いて、カーネルから得られたファイル識別子をアプリケーション１３に返して（ステップＳ４１０）、Open処理を終了する。
【００３９】
＜Write処理＞
図５は、Write処理の流れを示すフローチャートである。
【００４０】
まず、カーネルのwrite()を呼び出す（ステップＳ５０１）。
【００４１】
次に、識別子キャッシュ１１にアプリケーション１３から渡されたファイル識別子を識別子リストに含むキャッシュエントリが存在するか否か判定する（ステップＳ５０２）。
【００４２】
キャッシュエントリが存在すれば（ステップＳ５０２でＹｅｓ）、次に、今回のWrite時にSyncは行われたか否かを判定する（ステップＳ５０３）。ここで、Syncしたかどうかは様々な方法で検出可能である。例えば、カーネルのwrite()の所要時間から判定することができる。また、カーネルから教えてもらえるようにしても良い。
【００４３】
Syncが行われていなければ（ステップＳ５０３でＮｏ）、キャッシュエントリのファイル識別子に対応するSync必要フラグを１にした後、Write処理を終了する（ステップＳ５０４）。
【００４４】
Syncが行われていれば（ステップＳ５０３でＹｅｓ）、ファイル識別子に対応するSync必要フラグを０にした後、Write処理を終了する（ステップＳ５０５）。
【００４５】
一方、ステップＳ５０２でキャッシュエントリが存在しなければ（ステップＳ５０２でＮｏ）、直ちにWrite処理を終了する。
【００４６】
＜Sync処理＞
図６は、Sync処理の流れを示すフローチャートである。
【００４７】
まず、カーネルのsync()を呼び出す（ステップＳ６０１）。
【００４８】
次に、識別子キャッシュ１１にアプリケーション１３から渡されたファイル識別子を識別子リストに含むキャッシュエントリが存在するか否か判定する（ステップＳ６０２）。
【００４９】
キャッシュエントリが存在すれば（ステップＳ６０２でＹｅｓ）、次に、キャッシュエントリのファイル識別子に対応するSync必要フラグを０にした後、Sync処理を終了する。
【００５０】
一方、ステップＳ６０２でキャッシュエントリが存在しなければ（ステップＳ６０２でＮｏ）、直ちにSync処理を終了する。
【００５１】
＜Close処理＞
図７は、Close処理の流れを示すフローチャートである。
【００５２】
まず、識別子キャッシュ１１にCloseするファイル識別子を識別子リストに含むキャッシュエントリが存在するか否か判定する（ステップＳ７０１）。
【００５３】
キャッシュエントリが存在すれば（ステップＳ７０１でＹｅｓ）、次に、キャッシュエントリのファイル識別子に対応するSync必要フラグが1か判定する（ステップＳ７０２）。
【００５４】
Sync必要フラグが1であれば（ステップＳ７０２でＹｅｓ）、続いて、カーネルのsync()を呼び出す（ステップＳ７０３）。
【００５５】
次に、キャッシュエントリのファイル識別子に対応するsync必要フラグを0にする（ステップＳ７０４）。
【００５６】
続いて、キャッシュエントリの有効識別子数を1減らす（ステップＳ７０５）。
【００５７】
ステップＳ７０２でSync必要フラグが1でなければ（ステップＳ７０２でＮｏ）、ステップＳ７０５に移行する。
【００５８】
次に、キャッシュエントリの有効識別子数が０か否かを判定する（ステップＳ７０６）。
【００５９】
有効識別子数が０であれば（ステップＳ７０６でＹｅｓ）、識別子を再利用できるよう取っておき（ステップＳ７０７）、その後、Close処理を終了する。したがって、close()を呼び出さない。本実施形態では、残りの有効識別子数が０になったら、Closeを遅延するようにする。
【００６０】
一方、有効識別子数が０でなければ（ステップＳ７０６でＮｏ）、キャッシュエントリの識別子リストからファイル識別子を除去する（ステップＳ７０８）。
【００６１】
次いで、カーネルのclose()を呼び出し（ステップＳ７０９）、Close処理を終了する。
【００６２】
＜キャッシュ管理処理＞
図８は、キャッシュ管理処理の流れを示すフローチャートである。
【００６３】
まず、識別子キャッシュ１１のキャッシュエントリの数がしきい値を超えているか否かを判定する（ステップＳ８０１）。
【００６４】
しきい値を越えていれば（ステップＳ８０１でＹｅｓ）、キャッシュエントリで、有効識別子数が０のエントリを探す（ステップＳ８０２）。
【００６５】
次に、有効識別子数が０のエントリが1つ以上あるか否かを判定する（ステップＳ８０３）。
【００６６】
１つ以上あれば（ステップＳ８０３でＹｅｓ）、キャッシュエントリを１つ選んで削除し、キャッシュエントリのファイル識別子リストが持つファイル識別子に対して、カーネルのclose()を呼び出す（ステップＳ８０４）。ここで、キャッシュエントリのファイル識別子リストの中身は必ず1つである。また、削除されたエントリのための領域は、新規領域用として即座に再利用される。
【００６７】
ステップＳ８０４の後、キャッシュ管理処理を終了する。
【００６８】
ステップＳ８０１でしきい値を越えていなければ（ステップＳ８０１でＮｏ）、何もせず（ステップＳ８０５）にキャッシュ管理処理を終了する。
【００６９】
同様に、ステップＳ８０３で有効識別子数が０のエントリがなければ（ステップＳ８０３でＮｏ）、何もせず（ステップＳ８０５）にキャッシュ管理処理を終了する。
【００７０】
＜ファイル削除処理＞
図９は、ファイル削除処理の流れを示すフローチャートである。ファイル削除処理としては、Delete処理やRename 処理が該当する。
【００７１】
まず、識別子キャッシュの中に、ファイル名に対応するキャッシュエントリが存在するか否かを判定する（ステップＳ９０１）。
【００７２】
存在するならば（ステップＳ９０１でＹｅｓ）、キャッシュエントリの有効識別子数が０か否かを判定する（ステップＳ９０２）。
【００７３】
有効識別子数が０であれば（ステップＳ９０２でＹｅｓ）、カーネルのclose()を呼び出した後、delete()あるいはrename()を呼び出し、キャッシュエントリの識別子リスト、Sync必要フラグを更新（ステップＳ９０３）した後、ファイル削除処理を終了する。
【００７４】
一方、有効識別子数が０でなければ（ステップＳ９０２でＮｏ）、Delete又はRename不可能エラーと判断し（ステップＳ９０４）、ファイル削除処理を終了する。
【００７５】
ステップＳ９０１でファイル名に対応するキャッシュエントリが存在しなければ（ステップＳ９０１でＮｏ）、カーネルのdelete()かrename()を呼び出し（ステップＳ９０５）た後、ファイル削除処理を終了する。
【００７６】
＜実施例＞
本実施形態は、頻繁なOpen/Closeがあるランダムアクセスを行うものとして、データベース・マネジメント・システム(DBMS)で、実施することができる。
【００７７】
図１０は、データベース・マネジメント・システムで本実施形態を実施した実施例を説明する図である。DBMSはテーブルファイルやインデックスファイルへのランダムアクセスが主で、多くのOpen/Closeを伴うので、本実施形態の適用が好適である。
【００７８】
以上説明したように、本実施形態によれば、システムコールの呼び出し回数を削減することにより、ファイル操作におけるOpen/Closeのコストを削減することができる。特に、同じファイルを多数のタスクで頻繁に開閉するときに有効である。
【００７９】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００８０】
１００・・・ファイルアクセスシステム
１０・・・ファイル識別子制御部
１１・・・識別子キャッシュ
１３・・・アプリケーション
１４・・・オペレーティングシステム
１５・・・記憶装置
【図１】
2015103012.tif 000003
【図２】
2015103012.tif 000004
【図３】
2015103012.tif 000005
【図４】
2015103012.tif 000006
【図５】
2015103012.tif 000007
【図６】
2015103012.tif 000008
【図７】
2015103012.tif 000009
【図８】
2015103012.tif 000010
【図９】
2015103012.tif 000011
【図１０】
2015103012.tif 000012