JPH07175595A - File system - Google Patents

Abstract

PURPOSE:To access a file fast without any input/output processing and to guarantee the contents of a file when an application ends abnormally or a file system goes down. CONSTITUTION:This file system consists of the application part 1 consisting of an application part 11 as a space wherein application programs operate and a file management part 12, a disk 2 on which a file 21 is present, a nonvolatile memory 3 on which the data of the file on the disk are developed, and a file management part 4 for a system part; and a resident file 31 corresponding to the file on the disk is constituted on the nonvolatile memory 13 at a request made by the application program and the file management part 4 holds information, used to manage the nonvolatile memory, for data restoration in case of a system down, etc.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a file system, and more particularly to a file control system in a communication control processing device of a fault tolerant system, which has improved file access performance and reliability of file contents.

[0002] Generally, files such as application programs exist on a disc. When an application program accesses a file, the access is performed after a specific procedure called a file open process. As described above, when the file is accessed, the disk is accessed, that is, the input / output processing is involved.

[0003]

2. Description of the Related Art The conventional file system is basically based on placing a file on a disk and accessing the file. Input / output processing (I / O) is always required to access the file, but the time required for this input / output processing is extremely inferior to the processing speed of the CPU. I / O processing time has become a bottleneck, and performance improvement is no longer being achieved. Therefore, conventionally, there has been considered a method of avoiding the input / output processing to the disk at the time of accessing the file by expanding a part or all of the contents of the file on the memory.

In the method of expanding the file on the memory,
For example, when the system goes down, files in memory are deleted, so updated data and so on are also deleted. In order to avoid this, there has been a method in which the boot system periodically writes data to a medium such as a disk so that the content of the medium is as close to the latest state as possible.

[0005]

However, in the general disk access method, there is a problem that the access performance to the file deteriorates due to the input / output processing.

On the other hand, in the method of expanding the contents of the file in the memory, the access performance to the file can be improved because the input / output processing is avoided. However, the memory may be volatilized at the time of abnormal termination of the application or system down, and there is a problem that the reliability of the content of the file is lacking.

The present invention has been made in view of the above circumstances, and enables high-speed file access without input / output processing, and guarantees the contents of a file when an application terminates abnormally or the system goes down. The purpose is to provide a file system that can.

[0008]

FIG. 1 is a block diagram showing the principle of the present invention for achieving the above object. In the figure, a file system according to the present invention comprises an application section 1 which constitutes a part in which an application program operates, a disk 2 in which a file 21 exists, a non-volatile memory 3 in which data in the file 21 is expanded, and an operating system. And a file management unit 4 forming a part.

The application section 1 has an application section 11 consisting of an address space in which an application program actually operates, and a file management section 12 for mediating between this application section and the file management section 4. The non-volatile memory 3 has an area in which data is developed in the same image as the file 21 on the disk 2 (this is called resident), and a resident file 31 that can be accessed as the file 21 is created after resident.

[0010]

In the application section 11 of the application section 1, the application program operates, and the following requests are made: a request for expanding the data in the file 21 on the disk 2 to the nonvolatile memory, a file (a resident file 31 on the nonvolatile memory 3). ), And a request to reflect the data in the nonvolatile memory 3 to the file 21 on the disk 2 are issued. In the file management unit 12, a request issuance process to the file management unit 4, a data expansion process to the non-volatile memory 3, an access process to the non-volatile memory 3, and a process from the non-volatile memory 3 to the disk 2 are performed.
Data reflection processing to the upper file 21 is performed.

In the non-volatile memory 3, the area for expanding the data of the file 21 on the disk 2 is used by cutting out the area corresponding to the file 21 from the non-volatile memory 3, which is used for each application request. Done.

The file management unit 4 holds the management information for the nonvolatile memory in order to manage the nonvolatile memory 3 as a system. Further, while the contents of the file 21 on the disk 2 are being expanded in the non-volatile memory 3 or the data in the non-volatile memory 3 is being reflected in the file 21 on the disk 2, access to the corresponding file from other applications is suppressed. Fulfill the function of

[0013]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to the drawings. FIG. 2 is a diagram showing the configuration of the file system of the present invention when it is made resident in the nonvolatile memory. In the figure, the file management part 12 when the application part 11 of the application part 1 issues a request for expanding the data in the file 21 on the disk 2 into the nonvolatile memory 3
Is a cutout request processing unit 121 that requests the file management unit 4 to cut out a resident file area from the non-volatile memory 3, and prepares or releases an environment in which the area cut out from the non-volatile memory 3 can be accessed. Non-volatile memory access environment processing unit 122 and file 21
Data transfer processing unit 123 for transferring the data to the resident file 31, and a file access environment processing unit 124 for preparing and releasing an environment in which the file 21 can be accessed.

The file management unit 4 includes a file open / close processing unit 41 for performing open processing and close processing for the file 21 on the disk 2.
By a resident file area cut-out processing unit 42 that cuts out a resident file area from the non-volatile memory 3 and a resident file management information construction processing unit 43 that manages the cut-out area by information that can be uniquely identified in correspondence with the file 21. It is configured.

The data transfer processing section 123 of the file management section 12 has a buffer 1231 and stores the data of the file 21 on the disk 2 into the resident file 31 of the nonvolatile memory 3.
The data is not directly transferred when the data is written to, but is transferred via the buffer 1231 due to the limitation of hardware. The buffer 1231 is divided into two areas. One is used for reading data while the other is used for reading data, and the other is used for reading data. Used to export.

According to this configuration, an area corresponding to the file 21 on the designated disk 2 is first acquired from the non-volatile memory 3 according to the instruction of the application, and the data of the file 21 is expanded on the non-volatile memory 3. . At this time, the file management unit 4 holds the resident file management information for managing the non-volatile memory 3 to prepare for the non-volatile memory restoration process at the time of re-IPL (Initial Program Load) after the system goes down. Further, when the contents of the file 21 are expanded in the non-volatile memory 3, the access to the disk 2 and the data expansion in the non-volatile memory 3 are performed asynchronously in consideration of the performance. That is, when reading data from the file 21 on the disk 2, it is necessary to read in a fixed block unit according to the hardware specifications. Therefore, during the input / output processing, the processing of expanding the block read in the previous input / output processing in the nonvolatile memory 3 is executed asynchronously.

By expanding the data of the file 21 in the non-volatile memory 3 in this way, it becomes possible to suppress the input / output processing at the time of file access and improve the access performance.

In the following, the file 2 on the disk 2
Developing the data of No. 1 in the non-volatile memory 3 is called resident (or simply made resident) in the non-volatile memory, and reflecting the data in the non-volatile memory 3 to the file 21 on the disk 2 makes the non-volatile memory resident. It is called de-encryption (or simply de-residentization). Further, the data expanded on the non-volatile memory 3 is referred to as a resident file. Further, access to a file and access to a resident file mean update or store access unless otherwise specified.

FIG. 3 is a diagram showing a flowchart of the resident process in the nonvolatile memory. In the figure, the resident request for making the file on the disk resident in the nonvolatile memory is the application part 1 of the application part 1.
Issued from the application running in 1. At this time, the application specifies the target file name and the resident file name.

When the resident request is made, the file management section 12 of the application section 1 accepts the request (step S1) and requests the file management section 4 to cut out the nonvolatile memory for the resident file (step). S2).

The file management unit 4 receives the request for the non-volatile memory cutout request (step S3), and performs the file open process to construct the open environment of the target file (step S4). At this time, by opening for writing, access from other applications can be suppressed.

Generally, when accessing a file, the file management unit 4 is requested to open the file. The file management unit 4 distinguishes the reference-type read open from the update-type write open to construct a file open environment. In the case of open for reading, multiple applications can open the same file, and in case of open for writing, multiple applications cannot open the same file (this is called exclusive control at open time). .). Therefore, by opening the file for writing, it is possible to prevent access to the file from other applications while it is resident in the nonvolatile memory.

Next, the processing for cutting out the resident file area from the non-volatile memory is performed (step S5). The non-volatile memory can acquire an area by designating a name. Therefore, the file management unit 4 cuts out the area for the resident file based on the resident file name specified by the application.

Here, the file management section 4 returns to the file management section 12 of the application section 1 (step S6). At this time, the access information to the file on the disk is notified at the same time.

The file management section 12 of the application section 1 accepts the restoration (step S7) and constructs an access environment for the resident file area cut out by the file management section 4 (step S8). This access environment is used when writing the contents of a file on disk to a resident file.

Next, based on the access information for the file on the disk passed from the file management unit 4, an access environment for the file on the disk is constructed (step S).
9). This access environment is used to read data from files. Up to this point, it is a pre-process for transferring data from a file on the disk to a resident file.

Here, the data is transferred. First, two data of a certain block (the number of blocks determined by the hardware specifications) from the file on the disk are prepared in the buffer of the data transfer processing unit. It is read into one area (step S10). Then, the data is transferred from the one area of the buffer to the resident file (step S11). While writing data to the resident file, read the next fixed block of data from the file into the other area of the buffer, and while writing data from the other area of the buffer to the resident file, The operation of reading the next fixed block of data into one area of the buffer is repeated. In other words, step S10 and step S11 are looped asynchronously to maximize the processing performance.
Then, when all the data on the disc have been referred to, the data transfer process ends (step S12).

With this, the resident process is completed, and it becomes unnecessary to access the file and the resident file on the disk at the present time. Therefore, the process for releasing the environment is performed. First, the access environment to the file is released (step S13), and the access environment to the resident file is released (step S14). Then, the file management unit 4 is notified that the resident process is completed (step S1).
5) Issue a request to the file management unit 4 to close the file opened for the resident process.

Upon receiving the request (step S16), the file management unit 4 first constructs resident file management information (step S17). When the construction of the management information of the resident file is completed, the file management unit 4
Performs processing for holding resident file management information. Accordingly, thereafter, the file management unit 4 recognizes that the resident file exists. The resident file management information has a file identifier for identifying a file on the disk and a resident file identifier for identifying a resident file as basic information. The resident file management information is held in the memory in the file management unit 4 in the form of a control table, and the control table is held in the nonvolatile memory together with the memory in the file management unit 4.
In addition, the resident file management information is created every time a resident file is created. When there are a plurality of resident files, the plurality of resident file management information are held in a chain structure in the control table.

Since the resident process is completed, there is no need to suppress access from other applications. Therefore, the open environment of the file is released here (step S18), and access from other applications is permitted.

Thereafter, the file management section 4 is returned to the file management section 12 of the application section 1 (step S19), and the file management section 1 of the application section 1 is restored.
In step 2, the return is accepted (step S20), the application part 11 is returned (step S21), and the resident process is completed.

FIG. 4 is a diagram showing the structure of the file system of the present invention when a resident file is opened. In the figure,
When the application part 11 of the application part 1 issues a request to access a resident file in the non-volatile memory, the file management part 12 has a file open request processing part 125 which requests the file management part 4 to open the file, A resident file access environment construction processing unit 126 that prepares an environment for accessing the resident file. On the other hand, the file management unit 4 prepares an environment for opening a file in response to a request from the file open request processing unit 125 of the file management unit 12, and the requested file as resident file management information. And a management information search processing unit 45 that notifies the resident file access environment construction processing unit 126 of the identifier of the corresponding resident file. In the example of this figure, the two resident files 31 and 32 have already been created in the non-volatile memory 3, and therefore are stored in the memory of the file management unit 4 and the non-volatile memory 3 correspondingly. Two resident file management information 8 are also prepared.

In the above-mentioned configuration, when the file is accessed, not the file 21 on the disk but the file content expanded in the nonvolatile memory 3 is accessed, and the application determines that the file content is expanded in the nonvolatile memory. You can access files in the same sequence as if they were on disk without your knowledge. At this time, the system directs the access to the data on the nonvolatile memory.

As a result, the system manages the non-volatile memory in which the data is expanded, and manages it by the IP after system down.
Restoring at the time of L makes it possible to retain the data in the nonvolatile memory beyond the system down.

FIG. 5 is a flowchart showing a process of opening a resident file. When a file open request is issued from the application section 11 of the application section 1, the file management section 12 receives this request (step S31). At this time, the application specifies the name of the file on the disk and requests the opening of the file. Then, the file management unit 12 requests the file management unit 4 to open the file (step S32).

The file management unit 4 accepts a file open request (step S33), and constructs a file open environment similar to the file on the disk (step S34). Next, the chain of the resident file management information 8 is searched using the file identifier of the corresponding file as a keyword (step S35). Here, it is determined whether or not the file is found (step S3
6) If not found, the corresponding file is not made resident in the non-volatile memory, and therefore the process proceeds as a file on the disk. If found, the file is resident in the non-volatile memory, so the resident file identifier is retrieved (step S37). Then, it returns to the application section 1 (step S38) and notifies the file management section 12 of the application section 1 of the retrieved resident file identifier.

The file management section 12 of the application section 1 accepts restoration (step S39), and if the file is a resident file, accesses the resident file based on the resident file identifier notified from the file management section 4. Build an environment (step S40). After that, the application part 11 of the application part 1
To complete the open process.

Regarding the process of closing the file,
Processing that is the reverse of this open processing is performed.
Here, the access performance to the nonvolatile memory will be described. The access performance to the non-volatile memory 3 is different from the access performance to the volatile memory, and it is better to transfer a specified data length up to a certain data length (referred to as byte-unit data transfer). In this case, it is better to access the data in blocks (called data transfer in blocks).

FIG. 6 is a diagram showing the relation of the access performance to the non-volatile memory. According to this figure, when the data transfer amount is α bytes, the data transfer in byte units is faster when α or less, and the data transfer in block units is faster when α or more. Therefore, depending on the specified data amount, the system divides the byte-unit data transfer and the block-unit data transfer to access the nonvolatile memory.

FIG. 7 is a diagram showing the internal structure of a resident file. The resident file 3 basically has the same structure as the file on the disk. That is, resident file 3
The inside is divided in units of management blocks, and in each block, management units 301 and 302 are provided at the beginning and the back, respectively, to manage the data structure in the block. In each block, the portion excluding the management units 301 and 302 is a portion that can store application data. The application data is further divided into units called records. This record serves as a unit for reading and writing with one access command. A management unit 31 for controlling each record
1 and 312 are added, and basically have information indicating the length of the record and information indicating whether the record is updated.

In the access to the resident file, the data transfer in byte units and the data transfer in block units are automatically separated depending on the data length of the application for the reason explained in FIG. The operation for data transfer in byte units and the operation for data transfer in block units will be described below.

FIG. 8 is a diagram showing the first stage of data transfer in byte units. When the application requests the storage of the data 6, the data 6 of the application is normally transferred to the system buffer 7 developed in the memory of the file management portion 12 in units of 4 bytes, for example. At this time, a management unit is added to the head of the data 6.

FIG. 9 is a diagram showing a second stage at the time of byte-unit data transfer. When the access completion declaration represented by file closing is issued, the application unit 1
The file management part 12 transfers the data 6 from the system buffer 7 to the resident file 31 in bytes. The data transfer position is notified from the application in the form of a record number as the data position in the file. When the data 6 is transferred to the resident file 31, a flag indicating that the data is accessed is set in the management unit (system control data). This flag is indicated by an asterisk in the illustrated example.

FIG. 10 is a diagram showing the first stage of data transfer in block units. When the application requests data storage, the file management part 12 of the application part 1 transfers the block in which the specified application data is stored, from the resident file 31 to the system buffer 7 having a capacity of one block. . This is because different application data may be stored in the same block, and if the data is transferred in block units, the application data of records other than the target record will be destroyed.

FIG. 11 is a diagram showing the second stage of data transfer in block units. Next, the data 6 of the designated application is transferred to the system buffer 7. The data transfer position is notified from the application in the form of a record number as the data position within the block.

FIG. 12 is a diagram showing a third stage of data transfer in block units. When the application issues an access completion declaration represented by file closing, the file management section 12 of the application section 1
The system buffer 7 is block-transferred to the original block position of the resident file 31. When transferring data to the resident file 31, a flag indicating that the block has been accessed is set in the management unit (system control data). In the illustrated example, this flag is indicated by an asterisk in the management section at the beginning of the block.

FIG. 13 is a diagram showing a flowchart of access processing to a resident file. When the application issues a data access request for data storage, first, the data access is accepted (step S
51), the data length is determined from the length of the record stored in the record management unit (step S52). If the data transfer is in byte units due to the data length, the data is transferred to the system buffer (step S53), and further transferred from the system buffer to the resident file (step S54).

According to the data length judgment, if the data is transferred in block units, the corresponding block of the resident file is read into the system buffer (step S55), the data is transferred to the system buffer (step S56), and the block of the system buffer is transferred. Is transferred to the original block position of the resident file (step S57). Then, the process returns to the file management part 12 (step S58).

FIG. 14 is an explanatory diagram showing data transfer in consideration of abnormal termination of an application. In the figure, with respect to access (storage) to a resident file, the resident file has a dual structure in consideration of abnormal termination of an application during data transfer. That is, the sub area 301 is newly prepared on the nonvolatile memory 3. The sub-area 301 is also provided with a management unit 302 that stores control information indicating which record position (or block position) of the resident file the data in the sub-region 301 is in. In addition,
The illustrated example shows the case of data transfer in byte units.

When an access (storage) request to the resident file of the application data is issued, the application data 6 is transferred to the system buffer 7. Here, when the access completion declaration of the application is issued, the data 6 in the system buffer 7 is temporarily stored in the sub area 3
Written on 01. At this time, a flag indicating that there is data is set in the management unit 302, and the record number written in the resident file 31 is written.
Next, the same data is written to the resident file 31. Finally, the flag of the management unit 302 is lowered, and the data in the sub area 301 is invalidated.

Due to this dual structure, if
If the application abnormally terminates during the data transfer to the resident file and the file management unit 4 recognizes this, the file management unit 4 determines from the sub-region 301 to the management unit 30.
Data can be transferred to a predetermined record position (or block position) of the resident file based on the control information held in 2, and the resident file can be restored. That is, if a flag is set in the control information held in the management unit 302, it is determined that the data transfer to the resident file is not completed, and the data stored in the sub area 301 is transferred to the resident file. Well, if the flag is not set, the restoration process is not performed because the data transfer to the resident file is completed.

Although the illustrated example shows the case of byte-unit data transfer, in the case of block-unit transfer, the block itself stored in the resident file is prepared as a sub area. In this case, the control information held in the management unit 302 of the sub area 301 is the block number.

FIG. 15 is a diagram showing a flow chart of access processing to a resident file having a duplicated structure. When the application issues a data access request for data storage, first, the data access is accepted (step S61), and the data length is determined from the length of the record stored in the record management unit ( Step S
62). Depending on the data length, if the data transfer is in bytes, the data is transferred to the system buffer (step S63).

If the data length is judged and the data is transferred in block units, the corresponding block of the resident file is read into the system buffer (step S64), and the data is transferred to the system buffer (step S65). Here, the application is temporarily restored (step S6).
6).

Then, when an access completion declaration is issued from the application, the data completion declaration is accepted (step S67), and the data length is judged from the length of the record held in the record management section (step S67). S
68). If the data transfer is in byte units due to the data length, the accessed flag is set in the management section of the record to which the data in the system buffer has been transferred (step S6).
9). Next, the data in the system buffer is transferred to the sub area of the non-volatile memory (step S70), the same data is transferred to the resident file (step S71), and the accessed flag set in the management section of the sub area is cleared. The data held in the sub area is invalidated (step S7).
2).

If the data length is judged and the data is transferred in block units, the accessed flag is set in the management unit of the block on the system buffer (step S7).
3). Next, the data in the system buffer is transferred to the sub area of the non-volatile memory (step S74), the same data is transferred to the resident file (step S75), and the accessed flag set in the management section of the sub area is cleared. Invalidates the data stored in the sub area (step S7)
6). Then, it returns to the application (step S77).

FIG. 16 is a diagram showing the structure of the file system of the present invention when the non-volatile memory is made resident. In the figure, the file management part 12 of the application part 1 when the application part issues a request for releasing the non-volatile memory from being made resident and reflecting the data in the non-volatile memory 3 on the file 21 on the disk 2 is the file management part. 4, a resident release request processing unit 127 for notifying the start of resident release to the non-volatile memory 3, and an access environment of the non-volatile memory 3 for preparing and releasing an environment for accessing the resident file 31 of the non-volatile memory 3. Processing unit 12
8, a data transfer processing unit 129 that writes the data of the resident file 31 to the file 21, and a file access environment processing unit 130 that prepares or releases an environment in which the file 21 can be accessed.

On the other hand, the file management section 4 has a file open / close processing section 46 for performing open and close processing for exclusive control of the resident file 21 in the non-volatile memory 3, and a resident file in the non-volatile memory 3. It is composed of a resident file area release processing section 47 for releasing the area for the file and a resident file management information deletion processing section 48 for deleting the management information of the corresponding resident file 31.

The data transfer processing section 129 of the file management section 12 has a buffer 1291 used when writing the data of the resident file 31 in the non-volatile memory 3 to the file 21 on the disk 2. The buffer 1291 is divided into two areas. One is used for writing data while the other is used for reading data, and the other is used for reading data. The data transfer from the non-volatile memory 3 and the input / output processing are asynchronously performed, such as used for writing. Further, the data transfer processing unit 129 uses the buffer 1291 to transfer the file 21
The writing of data to the block is performed only for the block including the updated data, that is, only for the block having the accessed flag set in the management unit for the block or the record in the block. In this way, by not reflecting the blocks in the non-volatile memory that are not accessed to the file on the disk, the processing performance in reflecting the data in the non-volatile memory to the file on the disk is improved.

FIG. 17 is a diagram showing a flow chart of the process for canceling the residence of the nonvolatile memory. The resident release request is issued from the application section 11 of the application section 1, and the file management section 12 receives the request (step S81). When the application requests the non-residentization of the nonvolatile memory, the application specifies the target file name. Next, the file management unit 12 requests the file management unit 4 to release the resident status (step S82).

The file management unit 4 receives the request for releasing the residence (step S83), and performs the file open process, that is, the open environment of the target file (step S84). At this time, by opening for writing, access from other applications can be suppressed. Then, it returns to the file management part 12 of the application part 1 (step S85). On this occasion,
The access information to the file on the disk and the resident file identifier are notified at the same time.

The file management section 12 of the application section 1 accepts the restoration (step S86) and constructs an access environment for the nonvolatile memory (step S8).
7) That is, the access environment for the resident file is constructed by the resident file identifier notified from the file management unit 4. This access environment is used to read the data in the resident file. Then, a file access environment is constructed (step S88). Based on the access information to the file 21 on the disk 2 delivered from the file management unit 4, an access environment to the file on the disk is constructed. This access environment is used to write data to the file 21.

Next, data transfer processing is performed. First,
A certain block that can be written to the file 21 on the disk 2 is read from the resident file 31 (step S89), and the accessed flag is checked to check whether the accessed flag is set at the beginning of the block. Perform (step S90). If it is set, the file is written on the disk because it is accessed by data transfer in block units. If the accessed flag is not set, it is checked whether the accessed flag is set in the management unit (system control data) of the record added to each application data. If it is set, the target block is still written to the file on the disk because it is accessed by data transfer in byte units. As a result, if the accessed flag is not set, writing of the target block to a file on the disk is suppressed. Then, the blocks that are the write targets in the inspection of the accessed flag are written in a file on the disk in a lump (step S91). In this way, only the data that needs to be written out is reflected on the disk to make the resident release efficient.

The processing of steps S89 to S91 is repeated until all the data on the resident file has been processed. In addition, in the processing of steps S89 to S91, in order to maximize the processing performance, an asynchronous processing of reading the data from the resident file during the input / output processing and checking the accessed flag is executed.

When all the data on the resident file have been processed (step S92), access to the file on the disk is no longer necessary, so the environment for accessing the file is released (step S93), and the resident file is restored. The access environment is released (step S94). Then, the completion of the resident process is notified to the file management unit 4 (step S95).

The file management unit 4 receives the completion notice (step S96), then releases the area for the resident file from the nonvolatile memory 3 (step S97), deletes the resident file management information (step S98), and Since the resident release processing is completed, there is no need to suppress access from other applications, so the open environment of the file is also released (step S9).
9).

Thereafter, the file management section 4 returns to the file management section 12 of the application section 1 (step S100), and the file management section 12 accepts the restoration (step S101).
(Step S102), the resident removal processing is completed.

FIG. 18 is a diagram showing the structure of a file system of the present invention when a resident file is restored. In the figure,
In the non-volatile memory 3, in addition to the resident file 31 and the resident file management information 8, data is held in the sub area 301 when the application data is stored when the system is down. That is, there is a case where a flag indicating that the transfer of the application data 6 from the system buffer 7 to the resident file 31 is not completed may be set. The file management unit 4 is composed of a resident file management information restoration processing unit 49 for performing restoration processing of the resident file management information 8 and a resident file restoration processing unit 50 for performing restoration processing of resident files.

The non-volatile memory can hold data even when the system goes down. Therefore, the data of the non-volatile memory 3 in which the data of the file is expanded is also retained beyond the system down. Therefore, the resident file of the nonvolatile memory 3 can exist beyond the IPL after the system goes down. However, in this state, since the file management unit 4 does not recognize the resident file, the resident file 3 is a meaningless area (dead space).

The file management unit 4 restores the resident file management information 8 created at the time of making it resident in the non-volatile memory 3 to the memory by the resident file management information restoration processing unit 49 at the time of IPL after the system goes down. The resident file 31 remaining in the memory is restored so that it can be recognized as existing. At this time, the application may transfer the data to the resident file and the system may go down, and the data in the resident file may be destroyed. Therefore, the file management unit 4 uses the resident file restoration processing unit 50 as necessary. The resident file 31 is restored by transferring data from the sub area 301 to the resident file 31.

FIG. 19 is a diagram showing a flowchart of a resident file restoration process. When an activation request is issued to the file management unit 4 at the time of IPL after the system goes down,
The file management unit 4 accepts this (step S11
1), start the file management unit 4 (step S11)
2). The resident file management information restoration processing unit 49 searches the nonvolatile memory 3 for the resident file management information 8 (step S113). If the resident file management information 8 does not exist in the non-volatile memory 3, the process is terminated assuming that the resident file 31 does not exist in the non-volatile memory. If the resident file management information 8 exists, the resident file management information 8 exists in the non-volatile memory. Recognizing that the resident file 31 exists, the resident file management information 8 is transferred from the nonvolatile memory to the memory of the file management unit 4 and restored (step S114).

Next, the resident file restoration processing unit 50 searches whether the flag is set in the management unit 302 of the sub-region 301 on the non-volatile memory (step S).
115), if the flag is not set, the processing ends, assuming that the transfer of the application data to the resident file 31 is completed, and if the flag is set, the data in the sub area 301 is written to the resident file 31. Transfer and restore (step S116). This completes the restoration of the resident file after the system goes down, and returns to the initial setting procedure at system startup (step S117).

[0073]

As described above, in the present invention, the file is resident in the non-volatile memory. Therefore, the file can be accessed at high speed without the input / output processing.

Further, since it is possible to maintain the contents of the resident file without losing the contents beyond the abnormal termination of the application or the system down, it is necessary to retain the management information of the non-volatile memory in the system and restore it. Can guarantee the contents of the file even if the system goes down.

By having resident file management information,
Files on non-volatile memory can be accessed while maintaining the same user interface as accessing files on disk.

By changing the method of accessing the non-volatile memory depending on the data amount of the application, it is possible to access the non-volatile memory in the optimum state for performance.

Since the structure of the non-volatile memory is duplicated and the data is written to both the sub area and the main area when the non-volatile memory is accessed, it is possible to prevent the data in the resident file from being destroyed when the application terminates abnormally. .

Since the access to the non-volatile memory and the input / output processing are performed asynchronously when the non-volatile memory is made resident and the non-volatile memory is made non-resident, the processing speed can be improved. Further, when the non-volatile memory is made resident, the blocks in the non-volatile memory that are not accessed are not reflected in the file on the disk, so that the resident release process can be performed efficiently.

[Brief description of drawings]

FIG. 1 is a configuration diagram showing the principle of the present invention.

FIG. 2 is a diagram showing a configuration of a file system of the present invention when it is made resident in a nonvolatile memory.

FIG. 3 is a diagram showing a flowchart of a resident process in a non-volatile memory.

FIG. 4 is a diagram showing a configuration of a file system of the present invention when a resident file is opened.

FIG. 5 is a diagram showing a flowchart of resident file open processing.

FIG. 6 is a diagram showing a relation of access performance to a nonvolatile memory.

FIG. 7 is a diagram showing an internal structure of a resident file.

FIG. 8 is a diagram showing a first stage at the time of byte-unit data transfer.

FIG. 9 is a diagram showing a second stage at the time of byte-based data transfer.

FIG. 10 is a diagram showing a first stage at the time of data transfer in block units.

FIG. 11 is a diagram showing a second stage at the time of data transfer in block units.

FIG. 12 is a diagram showing a third stage at the time of data transfer in block units.

FIG. 13 is a diagram showing a flowchart of access processing to a resident file.

FIG. 14 is an explanatory diagram showing data transfer in consideration of abnormal termination of an application.

FIG. 15 is a diagram showing a flowchart of access processing to a resident file having a duplex structure.

FIG. 16 is a diagram showing a configuration of a file system of the present invention when a non-volatile memory is made resident.

FIG. 17 is a diagram showing a flowchart of a process for canceling residence of a nonvolatile memory.

FIG. 18 is a diagram showing a configuration of a file system of the present invention when a resident file is restored.

FIG. 19 is a diagram showing a flowchart of resident file restoration processing.

[Explanation of symbols]

 1 Application Part 11 Application Part 12 File Management Part 2 Disk 21 File 3 Nonvolatile Memory 31 Resident File 4 File Management Part

Claims (13)

[Claims] 1. In a file system that speeds up access to a file and guarantees the contents of the file in the event of an abnormality, an application part (11) comprising an address space in which an application program operates and a process for a request from the application part are provided. An application section (1) including a file management section (12) to perform, a disk (2) in which the file (21) exists, and an area corresponding to the file on the disk is cut out for each request of the application, and the area is cut out. Data of the file on the disk is expanded into a resident file (3
The nonvolatile memory (3) constituting 1) and management information for managing the nonvolatile memory as a system are held, and data of a file on the disk is being developed in the nonvolatile memory or data in the nonvolatile memory. A file management unit (4) for suppressing access to the file from other applications while the above is being reflected in the file on the disk, and a file system. 2. The file management part (12) of the application part (1) sends to the file management part (4) when the application part issues a request to expand the in-file data on the disk to a non-volatile memory. On the other hand, a cutout request processing unit that requests cutting out of the resident file area from the non-volatile memory, and an access environment processing unit of the non-volatile memory that prepares or releases an environment accessible to the area cut out from the non-volatile memory, 2. A data transfer processing unit that transfers the data of the file to the resident file, and an access environment processing unit of the file that prepares and releases an environment in which the file can be accessed. File system. 3. The file management unit (4) includes a file open / close processing unit for performing an open process and a close process for a file on the disk, and a resident file for cutting out a resident file area from the non-volatile memory. 3. The file system according to claim 2, further comprising an area cutout processing unit and a resident file management information construction processing unit that manages the cutout area with information that can be uniquely identified in correspondence with the file. 4. The data transfer processing unit of the file management unit (12) asynchronously performs a process of reading a fixed block of data from the file and writing the read data to the resident file at least twice. The file system according to claim 2, further comprising a buffer having a data capacity. 5. The file management part (12) of the application part (1) is the application part (1).
When 1) issues a request to access a resident file in the non-volatile memory, the file management unit (4)
2. The file system according to claim 1, further comprising a file open request processing unit for requesting the opening of a file and an access environment construction processing unit for a resident file that prepares an environment for accessing the resident file. 6. The file management unit (4) is requested by a file open environment construction processing unit that prepares an environment for opening a file in response to a request from the file open request processing unit of the file management unit (12). 6. The file system according to claim 5, further comprising a management information search processing unit that searches the resident file management information for a corresponding file and notifies the access environment construction processing unit of the resident file of the identifier of the corresponding resident file. . 7. An application data access to the resident file is performed in byte units or block units according to the amount of data.
File system described. 8. The non-volatile memory further comprises a sub-area in which transferred data is first written, the same data is written in the resident file, and then the written data is erased when an application access is completed. The file system according to claim 5, further comprising: 9. The file management part (12) of the application part (1) comprises the application part (1).
When 1) issues a request to reflect the data in the non-volatile memory to a file on the disk, a resident release request processing section that notifies the file management section (4) of the start of resident release to the non-volatile memory. An access environment processing unit of the non-volatile memory that prepares and releases an environment for accessing the resident file of the non-volatile memory, a data transfer processing unit that writes data of the resident file to the file, and The file system according to claim 1, further comprising a file access environment processing unit that prepares and releases an accessible environment. 10. The file management unit (4) includes a file open / close processing unit that performs open processing and close processing of a target file, and a resident file that releases a resident file area of the nonvolatile memory. The file system according to claim 9, further comprising an area release processing unit and a resident file management information deletion processing unit that deletes management information of the corresponding resident file. 11. The data transfer processing unit of the file management unit (12) asynchronously performs a process of reading data of a fixed block from the resident file and writing the read data to the file at least 2.
The file system according to claim 9, further comprising a buffer having a double data capacity. 12. The data transfer processing section of the file management section (12) transfers only the block containing updated data when writing data from the buffer to the file. File system. 13. The file management unit (4) restores the resident file management information from the resident file management information in the non-volatile memory at the time of IPL after the system goes down, and the resident file data. The file system according to claim 1, further comprising a resident file restoration processing unit that restores data from a sub area of the nonvolatile memory.