JP2015103012A - File access system - Google Patents
File access system Download PDFInfo
- Publication number
- JP2015103012A JP2015103012A JP2013243024A JP2013243024A JP2015103012A JP 2015103012 A JP2015103012 A JP 2015103012A JP 2013243024 A JP2013243024 A JP 2013243024A JP 2013243024 A JP2013243024 A JP 2013243024A JP 2015103012 A JP2015103012 A JP 2015103012A
- Authority
- JP
- Japan
- Prior art keywords
- file
- identifier
- cache
- application
- close
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
本発明の実施形態は、ファイルアクセスシステムに関する。 Embodiments described herein relate generally to a file access system.
アプリケーションの動作モードは、ユーザ空間におけるユーザモードと、カーネル空間におけるカーネルモードに大別でき、両者はシステムコールで関係付けられる。 The operation mode of the application can be broadly classified into a user mode in the user space and a kernel mode in the kernel space, and both are related by a system call.
アプリケーションは、ユーザ空間にて機能するファイル識別子を介して、カーネル空間の管理情報にアクセスする。具体的なファイル操作は、個々のファイルの書込み開始位置などの細かいデータを管理する管理情報によって、カーネル空間で行われる。 The application accesses kernel space management information via a file identifier that functions in the user space. A specific file operation is performed in the kernel space by management information for managing fine data such as the write start position of each file.
一般的なファイルに対する入出力操作の流れは、ファイルのOpen⇒ファイルに対するRead/Write⇒ファイルのCloseである。アプリケーションはファイルのOpenで、ファイル識別子を取得して、ファイル操作に使用している。 The general flow of input / output operations for a file is: File Open → Read / Write to File → File Close. The application obtains the file identifier and opens it for file operation.
ファイルアクセスの特徴として、例えば、データベースサーバのデータ管理タスクなどの多数のファイルをランダムアクセスで扱うタスクでは、頻繁なファイルOpen/ファイルCloseがある。一方、例えば、ログファイル出力タスクなどの一定数のファイルをシーケンシャルアクセスで扱うタスクでは、あまり頻繁にファイルOpen/ファイルCloseを行わない。リアルタイム性が求められるアプリや組み込み系では、ファイルのOpen/Closeがオーバヘッドとなる。Open/Close処理では、処理に時間を要するシステムコールを伴う。従って、ファイルのOpen/Close処理も時間がかかる。 As a feature of file access, for example, in a task that handles a large number of files by random access such as a data management task of a database server, there are frequent file open / file close. On the other hand, for example, a task that handles a certain number of files with sequential access, such as a log file output task, does not frequently open / close files. For applications and embedded systems that require real-time performance, file open / close is an overhead. Open / Close processing involves a system call that takes time. Therefore, it takes time to open / close the file.
一般的に、システムコールの処理には、最低限、レジスタ退避及び復元、CPUの動作モードの変更(カーネル/ユーザモードスイッチ)、スケジューラの動作(他タスクが動くことがある)、その他システムコールの動作をトリガとしたカーネルの処理のコストが必要である。例えば、1処理周期を100μs以内で処理しなければならない場合には、このような処理のコストがレスポンスタイムに影響を与える。 In general, system call processing includes, at a minimum, register saving and restoration, CPU operation mode change (kernel / user mode switch), scheduler operation (other tasks may operate), and other system call Kernel processing costs triggered by actions are required. For example, if one processing cycle must be processed within 100 μs, the cost of such processing affects the response time.
そこで、一般的な対応策として、使用するファイルはアプリケーション開始時に全部Openしておくことがなされている。このようにして、ファイルOpen/Close処理をアプリケーションの動作中にしないようにすれば良い。 Therefore, as a general countermeasure, all the files to be used are opened at the start of the application. In this way, the file open / close process should not be performed during the operation of the application.
しかしながら、このような対応策は、使用するファイルが予め分かっている前提でないと難しい、との問題があった。例えば、データベースサーバのデータ管理タスクなど、不特定の数のファイルを扱うタスクでは、このような前提は置けないため、このような対応策を使うことはできない。本発明では使用するファイルが予めわからない状況下において、ファイルのOpen/Close処理の回数を削減する。 However, there is a problem that such a countermeasure is difficult unless the file to be used is known in advance. For example, such a precaution cannot be used in a task that handles an unspecified number of files, such as a data management task of a database server. In the present invention, the number of file open / close processes is reduced in a situation where the file to be used is not known in advance.
本発明が解決しようとする課題は、ファイル操作におけるOpen/Closeに要する処理時間を短縮できるファイルアクセスシステムを提供することである。 The problem to be solved by the present invention is to provide a file access system that can shorten the processing time required for Open / Close in file operation.
実施形態のファイルアクセスシステムは、アプリケーションからファイルの操作要求を受け付け、オペレーティングシステムとの間で、該当するファイル識別子の授受を行うファイル識別子制御部と、前記ファイル識別子、ファイル名、ファイルアクセスに関するデータから成るキャッシュエントリを登録するための識別子キャッシュとを備え、前記ファイル識別子制御部は、アプリケーションから、同一ファイルを同一ファイルアクセスで2回以上オープン処理する要求を受けた場合に、都度、新規に前記ファイル識別子を発行し、アプリケーションからのファイルクローズ要求に対して、前記ファイル識別子を再利用し、前記ファイルのクローズ処理を遅延させる。 The file access system of the embodiment receives a file operation request from an application, and transfers a corresponding file identifier to and from the operating system, and the file identifier, file name, and data related to file access. An identifier cache for registering the cache entry, and the file identifier control unit newly adds the file each time a request is received from an application to open the same file twice or more with the same file access. An identifier is issued, the file identifier is reused in response to a file close request from an application, and the file close process is delayed.
以下、本発明の一実施の形態について、図面を参照して説明する。尚、各図において同一箇所については同一の符号を付すとともに、重複した説明は省略する。 Hereinafter, an embodiment of the present invention will be described with reference to the drawings. In the drawings, the same portions are denoted by the same reference numerals, and redundant description is omitted.
まず、本実施形態で用いる主要な用語について説明する。 First, main terms used in the present embodiment will be described.
「ファイル識別子」とは、OSのファイル管理情報を指す。アプリケーションには、番号やアドレスなどの形で見えることが多い。ファイルの書き込み開始位置や、細かいデータを扱うのはカーネル内のことが多い。 “File identifier” refers to OS file management information. It is often visible to applications as numbers or addresses. It is often in the kernel that handles the start of file writing and fine data.
本実施形態においては、ユーザモードでのファイル識別子のキャッシュ機構を備えるものである。図1は、本実施形態におけるファイル識別子のキャッシュ機構を説明する図である。図1に示すように、ファイル名及びファイルアクセス毎に、ファイル識別子が付与される。さらに、同時期に、ファイル名及びファイルアクセスでアクセスがある場合には、別のファイル識別子が付与される。 In this embodiment, a file identifier cache mechanism in the user mode is provided. FIG. 1 is a diagram for explaining a file identifier cache mechanism according to the present embodiment. As shown in FIG. 1, a file identifier is assigned for each file name and file access. Furthermore, if there is access by file name and file access at the same time, another file identifier is assigned.
本実施形態においては、ファイルアクセスがランダムアクセスの場合に、アプリからファイルのCloseが要求されてもClose処理を遅延させ、できるだけOpenしたままとし、キャッシュ容量の不足に応じて、周知のキャッシュ管理アルゴリズムに従って、使わないものをCloseするものである。本実施形態では、シーケンシャルアクセスの場合は、ケアしない。 In this embodiment, when the file access is random access, even if the application requests close of the file, the close process is delayed and kept open as much as possible. To close unused ones. In this embodiment, care is not taken in the case of sequential access.
図2は、本発明の実施形態に係るファイルアクセスシステムの概略構成を示すブロック図である。この装置は汎用のコンピュータ(例えばパーソナルコンピュータ(PC)等)と、同コンピュータ上で動作するソフトウェアとを用いて実現される。コンピュータとしては、CAD(Computer Aided Design)やCAE(Computer Aided Engineering)に好適なエンジニアリングワークステーション(EWS)等も含む。本実施形態はこのようなコンピュータに、ファイルアクセスを制御するプログラムとして実施することもできる。 FIG. 2 is a block diagram showing a schematic configuration of the file access system according to the embodiment of the present invention. This apparatus is realized using a general-purpose computer (for example, a personal computer (PC) or the like) and software operating on the computer. The computer includes an engineering workstation (EWS) suitable for CAD (Computer Aided Design) and CAE (Computer Aided Engineering). The present embodiment can also be implemented as a program for controlling file access in such a computer.
図2に示すように、本実施形態に係るファイルアクセスシステム100は、主として、ファイル識別子制御部10、識別子キャッシュ11から構成されている。ファイルアクセスシステム100は、ユーザ空間のアプリケーション13からアクセスされるとともに、カーネル空間のオペレーティングシステム14とも情報のやりとりを行う。オペレーティングシステム14は、アプリケーションが用いるデータ(ファイル)を記憶する記憶装置15と接続している。例えば、本実施形態をデータベースシステムに適用する場合には、データベースシステムで用いるテーブルデータ(表データ)が記憶される。
As shown in FIG. 2, the
ファイル識別子制御部10は、アプリケーションからファイルの操作要求を受け付け、オペレーティングシステム(カーネル)との間で、該当するファイル識別子の授受を行う。詳細は後述する。
The file
識別子キャッシュ11は、オンメモリであって、0個以上のキャッシュエントリを持っている。図3は、キャッシュエントリの構造を説明する図である。図3に示すように、キャッシュエントリは、“属性”欄には、“ファイル名”、“ファイルアクセス”、“ファイル識別子リスト”、“有効識別子数”、“Sync必要フラグリスト”をそれぞれ“属性”とし、各属性について、“型”と“備考”が設けられている。“ファイル名”は、“文字列”で表され、“検索キー”として機能する。“ファイルアクセス”は、例えば、“READ”、“WRITE”、“CREATE”、“APPEND”、“RANDOM_ACCESS”、“検索キー”に分類される。“ファイル識別子リスト”は、識別子のリストであって、ファイル識別子そのものは、OSのファイル管理情報としてOSによって付与される。“有効識別子数”は、キャッシュエントリが保持する、現在有効な識別子の数を表す。“有効識別子数”は整数で表され、初期値はゼロ(0)である。0のときは、ファイル識別子リストの先頭が再利用可能であることを意味している。“Sync必要フラグリスト”は、真偽値のリストで表され、ファイルClose時にSyncが必要かどうかを示すものである。キャッシュエントリの数量は、記憶容量が過大とならずに、かつ、検索時間短縮の観点から、しきい値で管理するのが、好適である。例えば、キャッシュエントリの数がしきい値を超えた時にキャッシュ管理処理を実施し、古いキャッシュエントリを削除した後、できた空き領域へ新しいキャッシュエントリを格納する。この際、キャッシュ管理アルゴリズムとして、先入れ先だし方式(FIFO)やLeast Recently Used 方式などを採用することができる。
The
<ファイルアクセス制御の流れ>
次に、以上のように構成されたファイルアクセスシステム100におけるファイルアクセス制御の流れについて説明する。
<Flow of file access control>
Next, the flow of file access control in the
ファイル識別子制御部10は、アプリケーション13からファイルのOpen要求を受けると、識別子キャッシュ11にアクセスして、ランダムアクセス指定時であって、ファイル名及びファイルアクセスに対応する識別子があるかどうか検索する。ファイル識別子があれば、ファイル識別子制御部10は、ファイル識別子をアプリケーション13に返す。該当するファイル識別子がなければ、ファイル識別子制御部10は、オペレーティングシステム14に対して通常のOpen処理を実行する。これに対して、オペレーティングシステム14は、ファイル識別子をファイル識別子制御部10に返す。ファイル識別子制御部10は、識別子キャッシュ11にファイル識別子、ファイル名及びファイルアクセスを登録する。登録後、ファイル識別子制御部10は、ファイル識別子をアプリケーション13に返す。
Upon receiving a file open request from the
本実施形態では、上記のようにファイルアクセスを制御し、ファイル名とファイルアクセスが一致する場合に、ファイルに対する識別子を再利用し、ファイルのCloseを遅延させ、できるだけOpenしたままにする。単純にCloseを遅延すると、同じ識別子を使いまわすため、問題がでる可能性がある。例えば、アプリケーション内で同じファイルを2回Openした場合、異なるファイル識別子が必要であるが、同じファイル識別子しか付与されない、という問題であり、Close時にディスクとのSyncが必要であり、システムコールの処理になるという問題である。 In the present embodiment, the file access is controlled as described above, and when the file name and the file access match, the identifier for the file is reused to delay the close of the file and keep it open as much as possible. If you simply delay Close, it will cause problems because it uses the same identifier. For example, if the same file is opened twice in the application, a different file identifier is required, but only the same file identifier is assigned. Syncing with the disk is required at close time, and system call processing It is a problem that becomes.
そこで、本実施形態では、同じファイルを同じファイルアクセスで2回以上Openする場合には、都度、新規に識別子を発行し、残り識別子数が0になったら、Closeを遅延するようにする、さらに、Close時のSyncによる処理時間の短縮を図る、すなわち、システムコールの呼び出しを防止するために、Syncをする必要があるか否かを調べるものである。 Therefore, in this embodiment, when the same file is opened twice or more with the same file access, a new identifier is issued each time, and when the number of remaining identifiers becomes 0, Close is delayed. In order to shorten the processing time by the synchronization at the close time, that is, to prevent the system call from being called, it is checked whether or not the synchronization is necessary.
以下、アプリケーション13からの要求に応じたファイル識別子制御部10の動作について、詳述する。尚、Read処理については、ファイル識別子を利用した従来と同様の処理で実行することができるので、説明を割愛する。
Hereinafter, the operation of the file
<Open処理>
図4は、Open処理の流れを示すフローチャートである。
<Open processing>
FIG. 4 is a flowchart showing the flow of the Open process.
まず、アプリケーション13から渡されたファイルアクセスが、ランダムアクセスか否か判定する(ステップS401)。
First, it is determined whether or not the file access passed from the
ランダムアクセスであれば(ステップS401でYes)、識別子キャッシュ12にファイル名及びランダムアクセスに対応するキャッシュエントリが存在するか検索する(ステップS402)。
If the access is random access (Yes in step S401), the
キャッシュエントリが存在する場合(ステップS402でYes)には、続いて、キャッシュエントリ内の有効識別子数が0か否か判定する(ステップS403)。 If there is a cache entry (Yes in step S402), it is subsequently determined whether or not the number of valid identifiers in the cache entry is 0 (step S403).
有効識別子数が0であれば(ステップS403でYes)、キャッシュエントリ内の識別子リストにある識別子を再利用し、Openを呼び出さない(ステップS404)。 If the number of valid identifiers is 0 (Yes in step S403), the identifiers in the identifier list in the cache entry are reused and Open is not called (step S404).
次いで、キャッシュエントリ内の有効識別子数を1増やしてから、ファイル識別子をアプリケーション13に返して(ステップS405)、Open処理を終了する。すなわち、アプリケーション13が呼び出したOpen処理の結果として、ファイル識別子を出力する。
Next, after the number of valid identifiers in the cache entry is increased by 1, the file identifier is returned to the application 13 (step S405), and the Open process is terminated. That is, the file identifier is output as a result of the Open process called by the
一方、ステップS402でファイル名及びランダムアクセスに対応するキャッシュエントリが識別子キャッシュ11に存在しなければ(ステップS402でNo)、識別子キャッシュ11にアプリケーション13から渡されたファイル名及びランダムアクセスで、新規キャッシュエントリを作成する(ステップS406)。尚、キャッシュエントリの数がしきい値を超えた時にキャッシュ管理処理を実施し、古いキャッシュエントリを削除した後、できた空き領域へ新しいキャッシュエントリを格納する。
On the other hand, if the cache entry corresponding to the file name and random access does not exist in the
続いて、カーネルのopen()を呼び出し、新規にファイル識別子を得る(ステップS407)。 Subsequently, the kernel open () is called to obtain a new file identifier (step S407).
次に、カーネルから得られたファイル識別子をキャッシュエントリ内のファイル識別子リストへ追加(ステップS408)し、ステップS405に移行する。 Next, the file identifier obtained from the kernel is added to the file identifier list in the cache entry (step S408), and the process proceeds to step S405.
ステップS403でNo、すなわち、有効識別子数が0でなければ当該ファイルは使用中であることを意味しているので、ステップS407に移行する。本実施形態では、同じファイルを同じファイルアクセスで2回以上Openする場合に、都度、新規に識別子を発行する。 No in step S403, that is, if the number of valid identifiers is not 0, it means that the file is in use, and the process proceeds to step S407. In this embodiment, an identifier is newly issued each time the same file is opened twice or more with the same file access.
一方、ステップS401で、ランダムアクセスでなければ(ステップS401でNo)、カーネルのopen()を呼び出し、ファイル識別子を得る(ステップS409)。 On the other hand, if the access is not random access in step S401 (No in step S401), the kernel open () is called to obtain a file identifier (step S409).
続いて、カーネルから得られたファイル識別子をアプリケーション13に返して(ステップS410)、Open処理を終了する。 Subsequently, the file identifier obtained from the kernel is returned to the application 13 (step S410), and the Open process is terminated.
<Write処理>
図5は、Write処理の流れを示すフローチャートである。
<Write processing>
FIG. 5 is a flowchart showing the flow of the write process.
まず、カーネルのwrite()を呼び出す(ステップS501)。 First, kernel write () is called (step S501).
次に、識別子キャッシュ11にアプリケーション13から渡されたファイル識別子を識別子リストに含むキャッシュエントリが存在するか否か判定する(ステップS502)。
Next, it is determined whether or not there is a cache entry that includes the file identifier passed from the
キャッシュエントリが存在すれば(ステップS502でYes)、次に、今回のWrite時にSyncは行われたか否かを判定する(ステップS503)。ここで、Syncしたかどうかは様々な方法で検出可能である。例えば、カーネルのwrite()の所要時間から判定することができる。また、カーネルから教えてもらえるようにしても良い。 If there is a cache entry (Yes in step S502), it is next determined whether or not Sync has been performed at the time of writing this time (step S503). Here, it is possible to detect whether or not the synchronization has been performed by various methods. For example, it can be determined from the time required for kernel write (). You may also be taught from the kernel.
Syncが行われていなければ(ステップS503でNo)、キャッシュエントリのファイル識別子に対応するSync必要フラグを1にした後、Write処理を終了する(ステップS504)。 If Sync has not been performed (No in Step S503), the Sync required flag corresponding to the file identifier of the cache entry is set to 1, and then the Write process is terminated (Step S504).
Syncが行われていれば(ステップS503でYes)、ファイル識別子に対応するSync必要フラグを0にした後、Write処理を終了する(ステップS505)。 If Sync has been performed (Yes in Step S503), the Sync necessary flag corresponding to the file identifier is set to 0, and then the Write process is terminated (Step S505).
一方、ステップS502でキャッシュエントリが存在しなければ(ステップS502でNo)、直ちにWrite処理を終了する。 On the other hand, if there is no cache entry in step S502 (No in step S502), the write process is immediately terminated.
<Sync処理>
図6は、Sync処理の流れを示すフローチャートである。
<Sync processing>
FIG. 6 is a flowchart showing the flow of the Sync process.
まず、カーネルのsync()を呼び出す(ステップS601)。 First, the sync () of the kernel is called (step S601).
次に、識別子キャッシュ11にアプリケーション13から渡されたファイル識別子を識別子リストに含むキャッシュエントリが存在するか否か判定する(ステップS602)。
Next, it is determined whether or not there is a cache entry that includes the file identifier passed from the
キャッシュエントリが存在すれば(ステップS602でYes)、次に、キャッシュエントリのファイル識別子に対応するSync必要フラグを0にした後、Sync処理を終了する。 If there is a cache entry (Yes in step S602), the Sync necessary flag corresponding to the file identifier of the cache entry is set to 0, and then the Sync process is terminated.
一方、ステップS602でキャッシュエントリが存在しなければ(ステップS602でNo)、直ちにSync処理を終了する。 On the other hand, if there is no cache entry in step S602 (No in step S602), the Sync process is immediately terminated.
<Close処理>
図7は、Close処理の流れを示すフローチャートである。
<Close processing>
FIG. 7 is a flowchart showing the flow of the Close process.
まず、識別子キャッシュ11にCloseするファイル識別子を識別子リストに含むキャッシュエントリが存在するか否か判定する(ステップS701)。
First, it is determined whether or not there is a cache entry including a file identifier to be closed in the
キャッシュエントリが存在すれば(ステップS701でYes)、次に、キャッシュエントリのファイル識別子に対応するSync必要フラグが1か判定する(ステップS702)。 If there is a cache entry (Yes in step S701), it is next determined whether the Sync required flag corresponding to the file identifier of the cache entry is 1 (step S702).
Sync必要フラグが1であれば(ステップS702でYes)、続いて、カーネルのsync()を呼び出す(ステップS703)。 If the Sync necessary flag is 1 (Yes in Step S702), then the kernel sync () is called (Step S703).
次に、キャッシュエントリのファイル識別子に対応するsync必要フラグを0にする(ステップS704)。 Next, the sync necessity flag corresponding to the file identifier of the cache entry is set to 0 (step S704).
続いて、キャッシュエントリの有効識別子数を1減らす(ステップS705)。 Subsequently, the number of valid identifiers of the cache entry is reduced by 1 (step S705).
ステップS702でSync必要フラグが1でなければ(ステップS702でNo)、ステップS705に移行する。 If the Sync necessity flag is not 1 in step S702 (No in step S702), the process proceeds to step S705.
次に、キャッシュエントリの有効識別子数が0か否かを判定する(ステップS706)。 Next, it is determined whether or not the number of valid identifiers in the cache entry is 0 (step S706).
有効識別子数が0であれば(ステップS706でYes)、識別子を再利用できるよう取っておき(ステップS707)、その後、Close処理を終了する。したがって、close()を呼び出さない。本実施形態では、残りの有効識別子数が0になったら、Closeを遅延するようにする。 If the number of valid identifiers is 0 (Yes in step S706), the identifier is saved so that it can be reused (step S707), and then the Close process is terminated. Therefore, do not call close (). In this embodiment, when the number of remaining valid identifiers becomes 0, the Close is delayed.
一方、有効識別子数が0でなければ(ステップS706でNo)、キャッシュエントリの識別子リストからファイル識別子を除去する(ステップS708)。 On the other hand, if the number of valid identifiers is not 0 (No in step S706), the file identifier is removed from the cache entry identifier list (step S708).
次いで、カーネルのclose()を呼び出し(ステップS709)、Close処理を終了する。 Next, close () of the kernel is called (step S709), and the Close process is terminated.
<キャッシュ管理処理>
図8は、キャッシュ管理処理の流れを示すフローチャートである。
<Cache management processing>
FIG. 8 is a flowchart showing the flow of the cache management process.
まず、識別子キャッシュ11のキャッシュエントリの数がしきい値を超えているか否かを判定する(ステップS801)。
First, it is determined whether or not the number of cache entries in the
しきい値を越えていれば(ステップS801でYes)、キャッシュエントリで、有効識別子数が0のエントリを探す(ステップS802)。 If the threshold is exceeded (Yes in step S801), the cache entry is searched for an entry with the number of valid identifiers being 0 (step S802).
次に、有効識別子数が0のエントリが1つ以上あるか否かを判定する(ステップS803)。 Next, it is determined whether or not there is one or more entries with the number of valid identifiers 0 (step S803).
1つ以上あれば(ステップS803でYes)、キャッシュエントリを1つ選んで削除し、キャッシュエントリのファイル識別子リストが持つファイル識別子に対して、カーネルのclose()を呼び出す(ステップS804)。ここで、キャッシュエントリのファイル識別子リストの中身は必ず1つである。また、削除されたエントリのための領域は、新規領域用として即座に再利用される。 If there is one or more (Yes in step S803), one cache entry is selected and deleted, and the kernel close () is called for the file identifier included in the file identifier list of the cache entry (step S804). Here, the file identifier list of the cache entry is always one. Also, the area for the deleted entry is immediately reused for the new area.
ステップS804の後、キャッシュ管理処理を終了する。 After step S804, the cache management process ends.
ステップS801でしきい値を越えていなければ(ステップS801でNo)、何もせず(ステップS805)にキャッシュ管理処理を終了する。 If the threshold value is not exceeded in step S801 (No in step S801), the cache management process is terminated without doing anything (step S805).
同様に、ステップS803で有効識別子数が0のエントリがなければ(ステップS803でNo)、何もせず(ステップS805)にキャッシュ管理処理を終了する。 Similarly, if there is no entry whose number of valid identifiers is 0 in step S803 (No in step S803), the cache management process is terminated without doing anything (step S805).
<ファイル削除処理>
図9は、ファイル削除処理の流れを示すフローチャートである。ファイル削除処理としては、Delete処理やRename 処理が該当する。
<File deletion process>
FIG. 9 is a flowchart showing the flow of file deletion processing. The file deletion process corresponds to the Delete process and the Rename process.
まず、識別子キャッシュの中に、ファイル名に対応するキャッシュエントリが存在するか否かを判定する(ステップS901)。 First, it is determined whether or not a cache entry corresponding to the file name exists in the identifier cache (step S901).
存在するならば(ステップS901でYes)、キャッシュエントリの有効識別子数が0か否かを判定する(ステップS902)。 If it exists (Yes in step S901), it is determined whether or not the number of valid identifiers of the cache entry is 0 (step S902).
有効識別子数が0であれば(ステップS902でYes)、カーネルのclose()を呼び出した後、delete()あるいはrename()を呼び出し、キャッシュエントリの識別子リスト、Sync必要フラグを更新(ステップS903)した後、ファイル削除処理を終了する。 If the number of valid identifiers is 0 (Yes in step S902), after calling close () of the kernel, delete () or rename () is called to update the cache entry identifier list and the Sync required flag (step S903). After that, the file deletion process is terminated.
一方、有効識別子数が0でなければ(ステップS902でNo)、Delete又はRename不可能エラーと判断し(ステップS904)、ファイル削除処理を終了する。 On the other hand, if the number of valid identifiers is not 0 (No in step S902), it is determined that the error cannot be deleted or renamed (step S904), and the file deletion process is terminated.
ステップS901でファイル名に対応するキャッシュエントリが存在しなければ(ステップS901でNo)、カーネルのdelete()かrename()を呼び出し(ステップS905)た後、ファイル削除処理を終了する。 If there is no cache entry corresponding to the file name in step S901 (No in step S901), the kernel delete () or rename () is called (step S905), and the file deletion process is terminated.
<実施例>
本実施形態は、頻繁なOpen/Closeがあるランダムアクセスを行うものとして、データベース・マネジメント・システム(DBMS)で、実施することができる。
<Example>
This embodiment can be implemented by a database management system (DBMS) as a random access with frequent Open / Close.
図10は、データベース・マネジメント・システムで本実施形態を実施した実施例を説明する図である。DBMSはテーブルファイルやインデックスファイルへのランダムアクセスが主で、多くのOpen/Closeを伴うので、本実施形態の適用が好適である。 FIG. 10 is a diagram for explaining an example in which this embodiment is implemented in the database management system. The DBMS is mainly used for random access to table files and index files, and is accompanied by many Open / Close, so that the application of this embodiment is suitable.
以上説明したように、本実施形態によれば、システムコールの呼び出し回数を削減することにより、ファイル操作におけるOpen/Closeのコストを削減することができる。特に、同じファイルを多数のタスクで頻繁に開閉するときに有効である。 As described above, according to the present embodiment, the cost of Open / Close in file operations can be reduced by reducing the number of system call calls. This is especially effective when the same file is frequently opened and closed by many tasks.
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。 Although several embodiments of the present invention have been described, these embodiments are presented by way of example and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the scope of the invention. These embodiments and modifications thereof are included in the scope and gist of the invention, and are included in the invention described in the claims and the equivalents thereof.
100・・・ファイルアクセスシステム
10・・・ファイル識別子制御部
11・・・識別子キャッシュ
13・・・アプリケーション
14・・・オペレーティングシステム
15・・・記憶装置
DESCRIPTION OF
Claims (6)
前記ファイル識別子、ファイル名、ファイルアクセスに関するデータから成るキャッシュエントリを登録するための識別子キャッシュとを備え、
前記ファイル識別子制御部は、アプリケーションから、同一ファイルを同一ファイルアクセスで2回以上オープン処理する要求を受けた場合に、都度、新規に前記ファイル識別子を発行し、アプリケーションからのファイルクローズ要求に対して、前記ファイル識別子を再利用し、前記ファイルのクローズ処理を遅延させるファイルアクセスシステム。 A file identifier control unit that receives a file operation request from an application and exchanges a corresponding file identifier with the operating system;
An identifier cache for registering a cache entry consisting of data relating to the file identifier, file name, and file access;
When the file identifier control unit receives a request to open the same file twice or more with the same file access from the application, the file identifier control unit newly issues the file identifier and responds to a file close request from the application. A file access system that reuses the file identifier and delays the closing process of the file.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013243024A JP6293462B2 (en) | 2013-11-25 | 2013-11-25 | File access system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013243024A JP6293462B2 (en) | 2013-11-25 | 2013-11-25 | File access system |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2015103012A true JP2015103012A (en) | 2015-06-04 |
JP6293462B2 JP6293462B2 (en) | 2018-03-14 |
Family
ID=53378667
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013243024A Active JP6293462B2 (en) | 2013-11-25 | 2013-11-25 | File access system |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP6293462B2 (en) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH05233401A (en) * | 1992-02-25 | 1993-09-10 | Nec Commun Syst Ltd | Infinite virtually simultaneous file opening system |
JPH06175903A (en) * | 1992-12-11 | 1994-06-24 | Hitachi Ltd | File management system |
JP2000057039A (en) * | 1998-08-03 | 2000-02-25 | Canon Inc | Method and device for controlling access, file system and information processor |
-
2013
- 2013-11-25 JP JP2013243024A patent/JP6293462B2/en active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH05233401A (en) * | 1992-02-25 | 1993-09-10 | Nec Commun Syst Ltd | Infinite virtually simultaneous file opening system |
JPH06175903A (en) * | 1992-12-11 | 1994-06-24 | Hitachi Ltd | File management system |
JP2000057039A (en) * | 1998-08-03 | 2000-02-25 | Canon Inc | Method and device for controlling access, file system and information processor |
Also Published As
Publication number | Publication date |
---|---|
JP6293462B2 (en) | 2018-03-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10552372B2 (en) | Systems, methods, and computer-readable media for a fast snapshot of application data in storage | |
US11080260B2 (en) | Concurrent reads and inserts into a data structure without latching or waiting by readers | |
JP6998928B2 (en) | Methods, appliances, equipment, and media for storing and querying data | |
KR102311032B1 (en) | Database Synchronization | |
KR101805561B1 (en) | Method and apparatus of maintaining data for online analytical processing in a database system | |
EP3394759B1 (en) | Method for flash-friendly caching for cdm workloads | |
JP5652480B2 (en) | Database update notification method | |
WO2017013701A1 (en) | Computer system and database management method | |
CN109690522B (en) | Data updating method and device based on B+ tree index and storage device | |
CN110352410B (en) | Tracking access patterns of index nodes and pre-fetching index nodes | |
US9354923B2 (en) | Information processing apparatus, information processing method, and computer program product | |
JP6189266B2 (en) | Data processing apparatus, data processing method, and data processing program | |
JP6293462B2 (en) | File access system | |
JP2017167654A (en) | Data management device and management method for database | |
US10534790B2 (en) | Dynamic and predictive global temporary tables | |
JP6740719B2 (en) | Information processing apparatus, information processing method, and program | |
JP6477169B2 (en) | Database processing control method, processing control program and database server | |
US9864761B1 (en) | Read optimization operations in a storage system | |
JP5832592B1 (en) | Data management device | |
US20240028519A1 (en) | Data processing method, electronic device and computer program product | |
US11681662B2 (en) | Tracking users modifying a file | |
US20180225318A1 (en) | Data storing method using multi-version based data structure | |
JP2007156844A (en) | Data registration/retrieval system and data registration/retrieval method | |
CN116644415A (en) | Interrupt processing method, interrupt controller, electronic device and storage medium | |
JP2018181042A (en) | Record reflecting program, record reflecting device and record reflecting method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20160923 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20170710 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20170718 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20170830 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20180116 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20180214 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 6293462 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |