JP6293462B2 - File access system - Google Patents

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.

  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.

  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.

  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.

  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.

  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.

JP 2006-164111 A

  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.

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 a cache entry, and the file identifier control unit receives a request to open the same file twice or more with the same file access in an access mode with random access from an application Each time the file identifier is newly issued, the file identifier is reused in response to a file close request from the application, and the file close process is delayed.

It is a figure explaining the cache mechanism of the file identifier in this embodiment. 1 is a block diagram showing a schematic configuration of a file access system according to an embodiment of the present invention. It is a figure explaining the structure of a cache entry. It is a flowchart which shows the flow of Open processing. It is a flowchart which shows the flow of Write processing. It is a flowchart which shows the flow of a Sync process. It is a flowchart which shows the flow of Close processing. It is a flowchart which shows the flow of a cache management process. It is a flowchart which shows the flow of a file deletion process. It is a figure explaining the Example which implemented this embodiment with the database management system.

  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.

  “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.

  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.

  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.

  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.

  As shown in FIG. 2, the file access system 100 according to the present embodiment mainly includes a file identifier control unit 10 and an identifier cache 11. The file access system 100 is accessed by the application 13 in the user space and also exchanges information with the operating system 14 in the kernel space. The operating system 14 is connected to a storage device 15 that stores data (files) used by applications. For example, when this embodiment is applied to a database system, table data (table data) used in the database system is stored.

  The file identifier control unit 10 receives a file operation request from an application, and exchanges the corresponding file identifier with the operating system (kernel). Details will be described later.

The identifier cache 11 is on-memory and has zero or more cache entries. FIG. 3 is a diagram for explaining the structure of a cache entry. As shown in FIG. 3, in the “attribute” column, the cache entry includes “file name”, “file access”, “file identifier list”, “number of valid identifiers”, and “sync required flag list” as “attribute”. "Type" and "Remarks" are provided for each attribute. “File name” is represented by “character string” and functions as a “search key”. "File Access" is, for example, "READ", "WRITE" , "CREATE", "APPEND", are classified as "RANDOM_ACCESS", that acts as a "file name" along with the "Search key". The “file identifier list” is a list of identifiers, and the file identifier itself is given by the OS as OS file management information. “Number of valid identifiers” represents the number of currently valid identifiers held by the cache entry. “The number of valid identifiers” is represented by an integer, and the initial value is zero (0). When it is 0, it means that the head of the file identifier list is reusable. The “Sync required flag list” is represented by a list of true / false values, and indicates whether or not Sync is required when the file is closed. The number of cache entries is preferably managed with a threshold value from the viewpoint of reducing the search time without increasing the storage capacity. For example, cache management processing is performed when the number of cache entries exceeds a threshold value, and after deleting old cache entries, new cache entries are stored in the free space that is created. At this time, a first-in first-out method (FIFO), a least recently used method, or the like can be employed as a cache management algorithm.

<Flow of file access control>
Next, the flow of file access control in the file access system 100 configured as described above will be described.

  Upon receiving a file open request from the application 13, the file identifier control unit 10 accesses the identifier cache 11 and searches for a file name and an identifier corresponding to the file access when random access is designated. If there is a file identifier, the file identifier control unit 10 returns the file identifier to the application 13. If there is no corresponding file identifier, the file identifier control unit 10 executes a normal Open process for the operating system 14. In response to this, the operating system 14 returns a file identifier to the file identifier control unit 10. The file identifier control unit 10 registers the file identifier, file name, and file access in the identifier cache 11. After registration, the file identifier control unit 10 returns the file identifier to the application 13.

  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.

  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.

  Hereinafter, the operation of the file identifier control unit 10 in response to a request from the application 13 will be described in detail. Note that the Read process can be executed by a process similar to the conventional one using a file identifier, and therefore the description is omitted.

<Open processing>
FIG. 4 is a flowchart showing the flow of the Open process.

  First, it is determined whether or not the file access passed from the application 13 is random access (step S401).

  If the access is random access (Yes in step S401), the identifier cache 12 is searched for a cache entry corresponding to the file name and random access (step S402).

  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).

  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).

  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 application 13.

  On the other hand, if the cache entry corresponding to the file name and random access does not exist in the identifier cache 11 in step S402 (No in step S402), a new cache is created with the file name and random access passed from the application 13 to the identifier cache 11. An entry is created (step S406). Note that when the number of cache entries exceeds the threshold value, cache management processing is performed, old cache entries are deleted, and new cache entries are stored in the free space created.

  Subsequently, the kernel open () is called to obtain a new file identifier (step S407).

  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.

  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.

  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).

  Subsequently, the file identifier obtained from the kernel is returned to the application 13 (step S410), and the Open process is terminated.

<Write processing>
FIG. 5 is a flowchart showing the flow of the write process.

  First, kernel write () is called (step S501).

  Next, it is determined whether or not there is a cache entry that includes the file identifier passed from the application 13 in the identifier cache 11 in the identifier list (step S502).

  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.

  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).

  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).

  On the other hand, if there is no cache entry in step S502 (No in step S502), the write process is immediately terminated.

<Sync processing>
FIG. 6 is a flowchart showing the flow of the Sync process.

  First, the sync () of the kernel is called (step S601).

  Next, it is determined whether or not there is a cache entry that includes the file identifier passed from the application 13 in the identifier cache 11 in the identifier list (step S602).

  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.

  On the other hand, if there is no cache entry in step S602 (No in step S602), the Sync process is immediately terminated.

<Close processing>
FIG. 7 is a flowchart showing the flow of the Close process.

  First, it is determined whether or not there is a cache entry including a file identifier to be closed in the identifier cache 11 in the identifier list (step S701).

  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).

  If the Sync necessary flag is 1 (Yes in Step S702), then the kernel sync () is called (Step S703).

  Next, the sync necessity flag corresponding to the file identifier of the cache entry is set to 0 (step S704).

  Subsequently, the number of valid identifiers of the cache entry is reduced by 1 (step S705).

  If the Sync necessity flag is not 1 in step S702 (No in step S702), the process proceeds to step S705.

  Next, it is determined whether or not the number of valid identifiers in the cache entry is 0 (step S706).

  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.

  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).

  Next, close () of the kernel is called (step S709), and the Close process is terminated.

<Cache management processing>
FIG. 8 is a flowchart showing the flow of the cache management process.

  First, it is determined whether or not the number of cache entries in the identifier cache 11 exceeds a threshold value (step S801).

  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).

  Next, it is determined whether or not there is one or more entries with the number of valid identifiers 0 (step S803).

  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.

  After step S804, the cache management process ends.

  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).

  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).

<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.

  First, it is determined whether or not a cache entry corresponding to the file name exists in the identifier cache (step S901).

  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).

  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.

  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.

  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.

<Example>
This embodiment can be implemented by a database management system (DBMS) as a random access with frequent 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.

  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.

DESCRIPTION OF SYMBOLS 100 ... File access system 10 ... File identifier control part 11 ... Identifier cache 13 ... Application 14 ... Operating system 15 ... Storage device

Claims (5)

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;
The file identifier control unit issues a new file identifier each time an application receives a request to open the same file twice or more with the same file access in the random access mode. A file access system that reuses the file identifier in response to a file close request from the server and delays the file close process. The identifier cache has a cache entry for registering data of a valid identifier indicating the number of the currently valid file identifiers, and data of a Sync necessary flag indicating whether synchronization processing is necessary when a file is closed. Item 14. The file access system according to Item 1 . 3. The file access system according to claim 2 , wherein when the number of valid identifiers is reduced in response to a file close request from an application and the number of valid identifiers becomes zero, a system call for closing processing of an operating system is not performed. 4. The file access system according to claim 3 , wherein the number of the cache entries is managed with a predetermined threshold value, and cache management processing is performed when the threshold value is exceeded. When a write request from an application, the file access system according to claim 3 or claim 4 when accompanied by synchronization processing when writing to the file, resets the Sync required flag.

Images