JP2004078461A - Log recording method, file management program, and information device - Google Patents

Abstract

An object of the present invention is to provide a file system with a failure recovery function that is configured so as not to affect the performance and reliability of a normal file operation of the file system and has a necessary and sufficient failure recovery performance.
A journal file is created as a file under the management of a file system for which a log is to be recorded. Then, when a file operation request is received from the application program, the processing of the file operation request is started, and the update information of the metadata accompanying the processing of the file operation request for the target file is recorded in the journal file. deep. When the system starts up, the journal file is checked, and if an incomplete file operation process is found, the file operation recovery process is performed based on the information recorded in the journal file.
[Selection diagram] Fig. 1

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a failure recovery function for recovering an interrupted file operation for a file device.
[0002]
[Prior art]
A method for managing files recorded in a file device on a computer and software for performing such management are called a file system. The file system has a function of receiving a file operation request from an application program and efficiently storing data in a file device. In general, various items related to file management including a method of creating a file, a method of managing a file on a file device, a storage area of a management area and a storage area of a data area, and the like are determined depending on the type of file system.
[0003]
For example, a file system called a FAT file system manages a file device by dividing it into an area for storing file management information (hereinafter, referred to as a management area in this specification) and a data area for storing file contents. I do. The management area includes a FAT (File Allocation Table; file allocation table) and information called a directory entry. The FAT manages the storage location of data constituting a file, and the directory entry uses a file name, a directory name, and an attribute. Manage etc.
[0004]
On the other hand, the file system is required to have a failure recovery function so that when a file operation process is interrupted at the time of a system crash or the like and a failure occurs in the contents of the file device, it can be recovered immediately. The failure of the file device occurs, for example, in the following situations. Generally, a file system has a cache area to provide high-speed file operation processing to an application program. Therefore, if the system suddenly goes down, the contents of the file operation stored in the cache area are not reflected on the file device, or so-called metadata, which is information on the management area on the file device, and the data area. Inconsistency with the data of the file contents in the file.
[0005]
In order to cope with such a failure, a file system configured to realize a failure recovery function is currently being proposed.
[0006]
[Problems to be solved by the invention]
Generally, it can be considered that the failure recovery function can be realized by recording the contents related to the file operation from the application program as a log. However, since the failure recovery function causes an increase in the load on the processing of normal file operations, log information such as what content is to be recorded as a log, what format the log is to be recorded in, and where is to be recorded. Various items related to recording affect the performance of failure recovery and the performance of normal file operations (that is, how much the processing load increases due to log recording and the performance of processing for normal file operations decreases). It must be noted that giving. Therefore, a file system that does not affect the performance of normal file operations as much as possible and realizes a necessary and sufficient failure recovery function is desired.
[0007]
In many cases, a file system having a failure recovery function is constructed by adding a failure recovery function to an already completed file system. Therefore, the failure recovery function is required to have a configuration that can be added to the existing file system in a format as simple as possible so as not to affect the performance and reliability of the existing file system.
[0008]
The present invention has been made in view of the above circumstances. That is, the present invention is a method for realizing a file system with a failure recovery function configured so as not to affect the performance and reliability of a normal file operation of the file system and having necessary and sufficient failure recovery performance. , A program, and an information device having such a failure recovery function.
[0009]
[Means for Solving the Problems]
In order to achieve the above object, first, recording of a log relating to a file operation request is performed on a log file which is a predetermined file created under the management of a file system that manages a file targeted for the file operation request. I will. Since the log file can be operated as a file under the management of the file system, log recording can be simplified. Then, when a file operation request is made from the application program, the type of the file operation request and the first update information relating to the update of the management area on the file device for the file targeted for the file operation request are stored in the log file. I will record it. That is, only the contents of the update of the management area (so-called metadata) associated with the processing of the file operation request are set as the log recording targets. This suppresses an increase in the load of the file operation processing accompanying the log recording. Further, the writing of the information to the log file is performed under a predetermined condition that does not cause the update of the management area of the log file on the file device. In the normal file writing process, at least two times of writing to the management area and writing to the data area occur. However, according to the above configuration, writing to the log file for log recording causes Since only writing is performed, the processing speed of log recording can be increased.
[0010]
The predetermined condition for preventing the management area from being updated when writing to the log file is, for example, a configuration in which the log file includes a plurality of entries for recording a log relating to one file operation request. That is, the plurality of entries are used cyclically (claim 2).
[0011]
Further, as a predetermined condition, it is preferable that a file operation relating to an in-use entry among a plurality of entries is forcibly completed, so that the in-use entry is released and used. 3).
[0012]
Alternatively, the predetermined condition may be that a log file is used as a fixed size.
[0013]
Preferably, the sizes of the plurality of entries in the log file are all equal to a predetermined size (claim 5). This makes it possible to search for an entry at high speed. In addition, it is possible to avoid fragmentation of entries in the log file and to efficiently use the entries cyclically.
[0014]
Alternatively, each of the plurality of entries may have a size that is an integral multiple of a predetermined unit size.
[0015]
Also, the predetermined size of the entry is preferably a size corresponding to one inseparable access to the file device storing the log file so that writing of the entry to the file device can be speeded up. 7). It is preferable that the predetermined size of the entry is configured to be equal to one sector size of the file device.
[0016]
Alternatively, the predetermined size of the entry may be smaller than one sector size of the file device, and only one entry may be stored in one sector.
[0017]
The file system may be a FAT type file system, and the management area may be configured to include information on the FAT and the directory.
[0018]
In order to achieve the above object, a log is recorded in a log file that is a predetermined file created under the management of a file system that manages a file to be requested for a file operation. Then, when a file operation request is made from the application program, the type of the file operation request and the first update information relating to the update of the management area on the file device for the file targeted for the file operation request are The log file is written to the log file so that the number of times the log file is written is completed once. In this case, the processing speed of log recording can be increased.
[0019]
In order to achieve the above object, a log is recorded in a log file which is a predetermined file created under the management of the first file system. When a file operation request is issued from an application program to a second file system to be logged (that is, to which a failure recovery function is added), the type of the file operation request and the file operation request Update information relating to the update of the management area on the file device managed by the second file system for the file to be requested is recorded in a log file. That is, only the update information of the management area (so-called metadata) associated with the processing of the file operation request in the second file system is targeted for log recording. Then, the writing of the information to the log file is performed under a predetermined condition that does not cause the update of the management area on the file device under the first file system management for the log file (claim 12). According to the above configuration, a file system to be subjected to log recording and a file system to manage a predetermined file for recording a log can be separated.
[0020]
When a file operation request is received from an application program, a log recording program that writes a log related to the file operation request to a log file using the log recording method described above, and a log file is checked at the time of system startup, and the log file is checked. It is possible to configure a file management program including a recovery program for performing a recovery process of a file operation request when there is a file operation request that has not been made (claim 13).
[0021]
In order to achieve the above object, a failure recovery function of a file device is realized from a file management program to which the following functions are added, a log recording program, and a recovery program.
That is, the file management program includes
(1) When a file operation request is received from an application program running on a computer, the log recording program is notified that the processing of the file operation request has started, and the type of the file operation request and A function of providing first update information relating to update of a management area on a file device for a file targeted for the file operation request;
(2) When the processing of the file operation request is completed, a function of notifying the log recording program that the file operation request has been completed is added.
The log recording program is configured to have the following functions.
(1) Upon receiving the notification that the processing of the file operation request has started, the type of the acquired file operation request and the first file are added to the log file created in advance as a file managed by the file management program. A function that records that the processing of the file operation request has started, together with the update information of
(2) A function of recording a predetermined completion in a log file upon receiving notification that the processing of the file operation request has been completed.
The recovery program is configured to have the following functions.
(1) A function of examining a log file at the time of system startup and, when there is a file operation request that has not been completed, recovering the file operation request based on the contents of the log file.
Since the above function may be added to the file management program in order to realize the failure recovery function of the file device, the failure recovery function can be added to the file management program in a simple format. Therefore, it is possible to prevent the reliability and performance of the processing of a normal file operation request from being reduced with the addition of the failure recovery function to the file management program.
[0022]
In this case, it is preferable that the writing of the information to the log file by the log recording program is performed under a predetermined condition that does not cause the update of the management area of the log file on the file device.
[0023]
BEST MODE FOR CARRYING OUT THE INVENTION
FIG. 1 is a block diagram illustrating a functional configuration of a file management program with a failure recovery function (hereinafter, referred to as a file system with a failure recovery function 10) according to an embodiment of the present invention. In the file system 10 with a failure recovery function, the file system 3 is a program for realizing a function as a file system, the log recording system 5 is a program for realizing a log recording function, and the recovery processing manager 7 is a realization of a recovery function. Corresponds to the program. The file system 10 with a failure recovery function can be mounted on various information devices such as a computer, a PDA, and a mobile phone, and can function to manage files of various types of file devices such as a disk device and a flash memory. Here, as an example, a disk device is used as a file device.
[0024]
Hereinafter, the details of the file system 10 with a failure recovery function will be described in the order of the following items.
1. Overall Configuration of File System 10 with Failure Recovery Function
2. Structure of journal file JF
3. Details of the operation of the log recording system 5 and the recovery manager 7
[0025]
1. Overall configuration of file system with disaster recovery function
In the file system 10 with a failure recovery function, the file system 3 has a general function as a FAT type file system that receives a file operation request from an application program (hereinafter, referred to as an application) and executes a file operation process. . The file system 3 manages the disk device HD1 as a file device. The file system 3 stores (1) the file operation request from the application in a cache area on the main storage in response to the file operation request from the application, and (2) the application in response to the file operation request from the application. When a file close request is issued from the server, or when the cache area becomes full, the contents of the cache area are reflected on the disk device HD1.
[0026]
The file system 3 is a FAT-type file system that manages file storage locations by using a FAT (file allocation table). Like the general FAT-type file system, the file system 3 stores the disk drive HD1 in the FAT areas 11 and 12 and the directory. It is managed as a configuration including an area 13 and a data area 15 in which data of file contents is stored (see FIG. 2). The FAT is duplexed into FATs 11 and 12 to improve the reliability as a file system.
[0027]
A function for operating in cooperation with the log recording system 5 and the recovery manager 7 is added to the file system 3. As a result, when a file operation request is issued from the application, the file operation is started, the information on the type of the file operation request, and the disk device for the file to be subjected to the file operation request accompanying the processing of the file operation request. Update information related to the update of the management area on the HD 1 and these information (hereinafter, referred to as transaction information) are recorded in a predetermined file in the disk device HD1. A predetermined file for recording transaction information is hereinafter referred to as a journal file JF. When the file operation request from the application is completed, the completion of the process is recorded in the journal file JF. The file operation request from the application includes the following.
File and directory creation
・ Write to file
File and directory deletion
File and directory name
・ File / directory information setting
Hereinafter, the processing of these individual file operations is called a transaction. When a transaction occurs, the file system 3 notifies the log recording system 5 that the transaction has started. Further, when the transaction is completed, the fact is notified to the log recording system 5.
[0028]
The log recording system 5 functions to record the transaction information in the log recording journal file JF created in the disk device HD1 together with the start of the transaction. The journal file JF is created in the disk device HD1 as a normal file managed by the file system 3. When the processing of the file operation request is interrupted due to a power failure or the like, the recovery manager 7 operates at the time of system startup or the like, and recovers an incomplete transaction using the journal file JF. Function.
[0029]
The failure recovery function provided by the file system 10 with a failure recovery function has the following contents according to the type of transaction.
(A) Regarding “create file directory”, “delete file directory”, “rename file directory”, and “set information of file directory”, execute the interrupted process again to recover .
(B) With regard to “writing to a file”, the interrupted process is canceled and the state before the “writing to the file” is performed is restored.
Therefore, regarding the transaction of “writing to a file”, log recording is not performed for write data, and log recording is performed only for management information (FAT and contents of directory entry). As a result, it is possible to keep the journal file JF to a small size and prevent the write processing speed of the file system from being reduced due to the addition of the failure recovery function.
[0030]
2. Structure of journal file JF
The configuration of the journal file JF and the management of the journal file JF by the log recording system 5 will be described. The log recording system 5 records the start of the transaction in the journal file JF together with the transaction information, and when the transaction is completed, records the completion of the transaction in the journal file JF.
[0031]
FIG. 3 shows the configuration of the journal file JF. The journal file JF is created as a normal file under the management of the file system 3 when the journal file JF is not yet created when an initialization request is issued from the application to the file system 3 such as when the system is started. . Transaction information on one transaction is recorded in one transaction entry 17. Each transaction entry 17 has an equal size.
[0032]
The write operation from the log recording system 5 to the journal file JF is performed so as to satisfy a predetermined condition that updating of information (that is, metadata) of the management area of the journal file JF itself does not occur. One of the predetermined conditions is to use N transaction entries cyclically, where N is the number of transaction entries in the journal file JF created as a predetermined size. That is, each time a transaction occurs, the transaction is used in order from the first transaction entry, and after using the Nth transaction entry, the process returns to the beginning again to search for and use an empty transaction entry. I do.
[0033]
One of the predetermined conditions is that if the transaction entries are full in use in the journal file JF, any one of the transaction entries (for example, the transaction entry in which the oldest transaction is recorded) The transaction is completed by reflecting the contents of the cache area managed by the file system 3 on the disk device HD1, thereby releasing the transaction entry.
[0034]
The above-mentioned predetermined conditions for handling the journal file JF, (1) cyclic use of the journal file, and (2) forced release of the journal file when the journal file becomes full, are used in the journal file JF. It corresponds to the condition for realizing the fixed size. When writing the transaction information to the journal file JF, the log recording system 5 directly writes to the data area (that is, transaction entry) of the journal file JF based on the storage position of the journal file JF that can be known in advance. be able to. This means that writing of information to a normal file involves at least two writes: writing for updating a management area (metadata) and writing for updating a data area. Writing a log to the journal file JF by No. 5 means that only one write to the data area occurs. This has the effect of suppressing a reduction in the processing speed of the file operation processing due to the addition of the failure recovery function to the file system.
[0035]
The size of the transaction entry 17 is equal to one sector size (for example, 512 bytes) of the disk device HD1. One sector size is an indivisible access unit when accessing the disk device. Therefore, writing to the transaction entry 17 can be completed by one writing to the disk device HD1. This has the effect that even if writing to one transaction entry is interrupted, only one transaction entry is corrupted. There is no damage to other transaction entries.
[0036]
Even if the size of the transaction entry 17 is smaller than one sector, the same effect as described above can be obtained if the condition that only one transaction entry is stored in one sector is satisfied.
[0037]
The fact that the size of the transaction entry 17 is constant means that the search of the transaction entry 17 is performed at high speed, the fragmentation (fragmentation) of the journal file JF is avoided, and the journal file JF is used cyclically efficiently. Make it possible. Note that the effects of speeding up the transaction entry search and avoiding fragmentation can be obtained even when the size of the transaction entry 17 is not equal to one sector if the size of the transaction entry 17 is constant. Even if the sizes of all transaction entries are not constant, if the transaction size is an integral multiple of the unit size, the effect of speeding up the search of transaction entries and avoiding fragmentation can be obtained. Can be.
[0038]
FIG. 4 shows details of the transaction information recorded in one transaction entry 17. The contents of the transaction information recorded in the transaction entry are shown below.
(A) “State” (reference numeral 21)
In the “state”, any one of three states of “unused”, “started”, and “completed” is recorded as the state of the transaction. Each has the following meaning.
"Unused": This transaction entry is not used
“Start”: Transaction of this entry has started
“Completed”: The transaction for this entry has been completed
(B) “Sequence number” (reference numeral 22)
Transaction serial number given to the transaction by the log recording system 5. The lowest value represents the earliest started transaction.
(C) “Transaction type” (reference numeral 23)
Enter the name indicating the type of transaction.
(D) “Transaction ID” (reference numeral 24)
Transaction identification number assigned to the transaction by the log recording system 5.
(E) File ID (reference numeral 25)
(F) “Size of transaction individual information” (reference numeral 26)
(G) “Transaction individual information” (reference numeral 27)
This is the individual information of the transaction. The recorded contents differ depending on the type of transaction.
[0039]
The log recording system 5 manages a sequence number and a transaction ID of a transaction. When the log recording system 5 knows that a transaction has been started by a notification from the file system 3, the log recording system 5 assigns a sequence number and a transaction ID to the transaction, acquires transaction information, and records it in the transaction entry 17. .
[0040]
3. Details of the operation of the log recording system 5 and the recovery manager 7
Hereinafter, the recording of transaction information by the log recording system 5 and the operation of the recovery processing by the recovery manager 7 will be described separately for each transaction.
[0041]
3.1 Creating files and directories
The record of the start of a transaction for a file or directory creation transaction is:
a. File creation request from application
b. Directory creation request from application
Is performed in response to the occurrence of
Upon receiving such a request from the application, the file system 3 notifies the log recording system 5 of the start of the file directory creation transaction and provides transaction information regarding the transaction before starting the processing. .
[0042]
Next, the log recording system 5 assigns a sequence number and a transaction ID to this transaction, and records this in the transaction entry. Also, a file ID given by the file system 3 is acquired and recorded. Further, the log recording system 5 acquires the following transaction individual information from the file system 3 and records it in the transaction entry. That is, the following contents are recorded as transaction information.
"Type" = "CreateFile" (information indicating file creation)
・ Sequence number, file ID, transaction ID
・ Individual transaction information ((a)-(e) below)
(A) SFN (short file name) of the file to be created
(B) Attributes of the file to be created
(C) Parent directory cluster number
(D) Attributes of parent directory
(E) File name to be created
[0043]
Note that the record of the completion of the transaction is
a-1. Processing of file close request from application completed
a-2. Completing the file flush
b. Completion of file creation process
It is performed along with.
Note that the flush is one of the functions that the file system generally has, and represents a process of reflecting the contents of the cache area managed by the file system on the file device. The flush processing is executed by a request for committing a file from an application or a factor in the file system such as when a cache area managed by the file system becomes full.
[0044]
While the log recording system 5 records the start and the completion of the transaction as described above, the recovery manager 7 operates at the time of system startup or the like, and stores the “file / directory creation” in the journal file JF. If an incomplete transaction is found, recovery processing is performed in the following procedure.
(Recovery procedure)
(1) Check whether a file to be recovered has been created in the parent directory. (If the file to be recovered has been created here, the recovery process does not need to be performed and the recovery process can be terminated.)
(2) Next, the parent directory is checked and repaired. Specifically, if there is an abnormal directory entry, it is deleted.
(3) Next, a file to be recovered is created in the parent directory.
[0045]
As an example, the flow of log recording by the log recording system 5 and the flow of recovery processing by the recovery manager 7 are shown assuming that the application has issued an operation request to create a file with the file name of file A. FIG. 5 is a flowchart showing a flow of log recording performed by the application, the file system 3, and the log recording system 5 in this case. When the application requests "creation of file A" to the file system 3 (S1), the file system 3 notifies the log recording system that a transaction of "creation of file A" has occurred (S2). . At this time, transaction information relating to “creation of file A” is provided from the file system 3 to the log recording system 5.
[0046]
Next, the log recording system 5 writes, in a predetermined transaction entry of the journal file JF, the start of "creation of file A" together with the transaction information (S3). On the other hand, the file system 3 processes "creation of file A" (S4). Then, when the "creation of file A" is completed (S5), the log recording system 5 searches for a transaction entry corresponding to "creation of file A" by the notification from the file system 3 and completes the transaction status. (S6).
[0047]
FIG. 6 shows a case where the process of “creating file A” is interrupted due to a power failure or the like. In this case, the file A is not actually created on the disk device HD1. FIG. 7 shows a flow of the operation of the recovery manager 7 when the system is started from the suspended state as shown in FIG. The application program initializes the file system 3 when the system is started (S11). In response to this, the recovery manager 7 operates, and first searches the journal file JF to check whether there is any incomplete transaction (S12). Since it is assumed that the "file A creation" is interrupted as shown in FIG. 6, it is found here that the "file A creation" transaction is incomplete (S12: YES). ). If no incomplete transaction is found (S12: NO), the recovery process ends.
[0048]
Next, the recovery manager 7 re-executes the "file A creation process" based on the transaction information according to the above-described recovery process procedure (S13). When the re-execution of “create file A” is completed, the status of the transaction entry that has not been completed (that is, remains “started”) is set to “completed” (S14). Note that the transaction entry that has been “completed” can be used to record a new transaction.
[0049]
3.2 Writing to File
The record in the journal file JF that the transaction "write to file" has started is
a. Request to write to file from application
Is performed in response to the occurrence of
Upon receiving the “write to file” request from the application, the file system 3 notifies the log recording system 5 of the start of the “write to file” transaction and starts the transaction before starting the processing. Provide transaction information for
[0050]
Next, the log recording system 5 assigns a sequence number and a transaction ID to this transaction, and records this in the transaction entry. Also, a file ID given by the file system 3 is acquired and recorded. Further, the log recording system 5 acquires the following transaction individual information from the file system 3 and records it in the transaction entry. That is, the following contents are recorded as transaction information.
"Type" = "WriteFile" (information indicating that writing to a file)
・ Sequence number, file ID, transaction ID
・ Individual transaction information ((a)-(e) below)
(A) Identification information of the file to be written
(A-1) Cluster number of parent directory
(A-2) Attributes of parent directory,
(A-3) Position of directory entry (within parent directory)
(B) Size of file to be written before writing
(C) Write size
(D) Last cluster number before writing the file to be written
(E) File position before writing of file to be written
[0051]
Please note that this transaction has been completed
a. Completion of file close request from application
b. Completing the file flush
It is performed along with.
[0052]
While the log recording system 5 records the start and completion of the transaction as described above, the recovery manager 7 operates at the time of system startup and the like, and writes a “write to file” transaction in the journal file JF. If an incomplete one is found, recovery processing is performed in the following procedure.
(Recovery procedure)
(1) Unused clusters (lost clusters) are returned to unused state while being allocated.
(2) Regarding the cluster chain of the file to be written, inconsistency among a plurality of FATs is solved by copying the first FAT (FAT11) to the subsequent FAT (FAT12).
(3) Terminate the unterminated cluster chain.
(4) Match the directory entry with the FAT. Specifically, the cluster chain to be written is truncated according to the directory entry, or the file size is truncated according to the number of cluster chains of the file to be written.
It should be noted that returning the lost cluster of (1) to unused is actually necessary for the transaction of “assignment of a cluster to a file” executed as an internal process of the transaction of “writing to a file”. (See 3.2.1 "Assigning clusters to files").
[0053]
As an example, the flow of log recording by the log recording system 5 and the flow of recovery processing by the recovery manager 7 will be described assuming that the application has issued an operation request for writing to a file with the file name of file B. FIG. 8 is a flowchart showing a flow of log recording by the application, the file system 3 and the log recording system 5 in this case. When the application requests "write to file B" to the file system 3 (S31), the file system 3 notifies the log recording system that a transaction "write to file B" has occurred (S32). . At this time, the file system 3 provides the log recording system 5 with transaction information relating to “writing to file B”.
[0054]
Next, the log recording system 5 writes, in a predetermined transaction entry of the journal file JF, the fact that "writing to the file B" has been started, together with the transaction information (S33). On the other hand, the file system 3 processes "writing to file B" (S34). When “writing to file B” is completed by a file close request or the like from the application (S35), the log recording system 5 responds to the notification from the file system 3 and the transaction entry corresponding to “writing to file B”. To change the transaction state from "start" to "complete" (S36).
[0055]
FIG. 9 shows a case where the process of “writing to file B” is interrupted due to a power failure or the like. In this case, the process of “writing to file B” on the disk device HD1 is halfway completed, and the disk device HD1 is in an abnormal state. A typical example is a state where only the management area of the disk device HD1 has been updated and the data area has not been updated, that is, a state where inconsistency has occurred between the management area and the data area. FIG. 10 shows a flow of the operation of the recovery manager 7 when the system is started from the interrupted state as shown in FIG. When the system is started, the application initializes the file system 3 (S41). With this as a trigger, the recovery manager 7 operates, and first searches the journal file JF to check whether there is any incomplete transaction (S42). Since the "write to file B" is interrupted as shown in FIG. 9, it is found that the "write to file B" transaction is not completed (S42: YES). If no uncompleted transaction is found (S42: NO), the recovery process ends.
[0056]
Next, the recovery manager 7 cancels the “writing to the file B” based on the transaction information and returns to the state before the start of the transaction according to the above-described recovery processing procedure (S43). When the cancellation processing is completed, the “state” of the transaction entry that has not been completed is set to “completed” (S44).
[0057]
3.2.1 Assigning clusters to files
The record in the journal file JF that the transaction "assign cluster to file" has started is:
a. Before allocating the first cluster of files
b. Before assigning clusters for adding cluster links
Done in
At such a timing, the file system 3 notifies the log recording system 5 of the start of the "assignment of clusters to files" transaction and provides transaction information on this transaction.
[0058]
Next, the log recording system 5 assigns a sequence number and a transaction ID to this transaction, and records this in the transaction entry. Also, a file ID given by the file system 3 is acquired and recorded. Further, the log recording system 5 acquires the following transaction individual information from the file system 3 and records it in the transaction entry. That is, the following contents are recorded as transaction information.
"Type" = "Allocluster" (information indicating that a cluster is assigned to a file)
・ Sequence number, file ID, transaction ID
・ Individual transaction information ((a)-(b) below)
(A) Identification information of the target file
(A-1) Cluster number of parent directory
(A-2) Attributes of parent directory,
(A-3) Position of directory entry (within parent directory)
(A-4) First cluster number
(B) List of assigned cluster numbers
[0059]
Please note that this transaction has been completed
a-1. When the assigned cluster is set in the directory entry of the target file, and the directory entry and the FAT are flushed.
a-2. When the file to which the assigned cluster belongs is closed.
b-1. When the cluster connection is completed and the FAT is flushed.
b-2. When the file to which the assigned cluster belongs is closed.
Done in
[0060]
The following recovery processing is performed based on the transaction information as part of the recovery processing of “writing to a file”.
(Recovery procedure)
(1) Return the allocated cluster to unused.
[0061]
3.3 Deleting files and directories
The record in the journal file JF that the transaction of file / directory deletion has started is:
a. Request to delete files from application
b. Request directory removal from application
Is performed in response to the occurrence of
When the file system 3 receives a request for “deletion of a file directory” from an application, the file system 3 notifies the log recording system 5 of the start of a transaction of “deletion of a file directory”, and transmits transaction information on this transaction. provide.
[0062]
Next, the log recording system 5 assigns a sequence number and a transaction ID to this transaction, and records this in the transaction entry. Also, a file ID given by the file system 3 is acquired and recorded. Further, the log recording system 5 acquires the following transaction individual information from the file system 3 and records it in the transaction entry. That is, the following contents are recorded as transaction information.
"Type" = "DeleteFile" (information indicating deletion to file)
・ Sequence number, file ID, transaction ID
・ Individual transaction information ((a) below)
(A) Identification information of the file to be deleted
(A-1) Cluster number of parent directory
(A-2) Attributes of parent directory
(A-3) Location of directory entry
(A-4) Attributes of target file
(A-5) First cluster number of the target file
(A-6) Number of directory entries of LFN (long file name) of target file
(A-7) Checksum of alias (alias) of target file
[0063]
Please note that this transaction has been completed
a. Completion of file / directory deletion processing
It is performed along with.
[0064]
While the log recording system 5 records the start and completion of the transaction as described above, the recovery manager 7 operates at the time of system startup or the like, and stores “delete file / directory” in the journal file JF. If an incomplete transaction is found, recovery processing is performed in the following procedure.
(Recovery procedure)
(1) The file / directory to be deleted is deleted again.
[0065]
The flow of the operation for recovering the “delete file directory” transaction is to find an incomplete transaction and perform recovery by re-executing the transaction. For “create file directory”, refer to FIGS. This is the same as the case described above.
[0066]
3.4 Renaming files and directories
The record in the journal file JF that the file / directory rename transaction has started is:
a. Request of file name change from application
Is performed in response to the occurrence of
When the file system 3 receives a request for "rename of a file directory" from the application, the file system 3 notifies the log recording system 5 of the start of the transaction for renaming the file directory, and transmits the transaction information on the transaction. provide.
[0067]
Next, the log recording system 5 assigns a sequence number and a transaction ID to this transaction, and records this in the transaction entry. Also, a file ID given by the file system 3 is acquired and recorded. Further, the log recording system 5 acquires the following transaction individual information from the file system 3 and records it in the transaction entry. That is, the following contents are recorded as transaction information.
"Type" = "RenameFile" (information indicating name change)
・ Sequence number, file ID, transaction ID
-Transaction individual information ((a), (b) below)
(A) Identification information of the file to be renamed
(A-1) Cluster number of parent directory
(A-2) Attributes of parent directory
(A-3) Location of directory entry
(A-4) Attributes of target file
(A-5) First cluster number of the target file
(A-6) Number of directory entries of LFN (long file name) of target file
(A-7) Check sum of alias of target file
(B) New file name of the target file
[0068]
Please note that this transaction has been completed
a. File / directory rename operation completed
It is performed along with.
[0069]
While the log recording system 5 records the start and the completion of the transaction as described above, the recovery manager 7 operates at the time of system startup or the like, and stores “file / directory name change” in the journal file JF. If an incomplete transaction is found in the transaction, recovery processing is performed in the following procedure.
(Recovery procedure)
(1) Re-execute the process of renaming the file / directory to be renamed.
[0070]
The flow of the operation for recovering the transaction of “file directory rename” is to find an incomplete transaction and perform recovery by re-executing the transaction, and refer to FIGS. This is the same as the case described above.
[0071]
3.5 File / directory information setting
The record in the journal file JF that the transaction of file / directory information setting has started is:
a. Request of file / directory information setting from application
Is performed in response to the occurrence of
When the file system 3 receives the request for “file directory information setting” from the application, the file system 3 notifies the log recording system 5 of the start of the “file directory information setting” transaction, and also executes a transaction related to this transaction. Provide information.
[0072]
Next, the log recording system 5 assigns a sequence number and a transaction ID to this transaction, and records this in the transaction entry. Also, a file ID given by the file system 3 is acquired and recorded. Further, the log recording system 5 acquires the following transaction individual information from the file system 3 and records it in the transaction entry. That is, the following contents are recorded as transaction information.
"Type" = "SetStatFile" (information indicating information setting)
・ Sequence number, file ID, transaction ID
-Transaction individual information ((a)-(d) below)
(A) Identification information of the file for which information is set
(A-1) Cluster number of parent directory
(A-2) Position of directory entry (within parent directory)
(B) Attributes of the target file
(C) Original attributes of the target file
(D) New attributes of the target file
[0073]
Please note that this transaction has been completed
a. Completion of file / directory information setting process
It is performed along with.
[0074]
While the log recording system 5 records the start and completion of the transaction as described above, the recovery manager 7 operates at the time of system startup and the like, and sets “file / directory information” in the journal file JF. If an incomplete transaction is found in the transaction, recovery processing is performed in the following procedure.
(Recovery procedure)
(1) Re-execute the information setting process for the file / directory to be set.
[0075]
The flow of operation when recovering the transaction of “file directory information setting” is to find an incomplete transaction and perform recovery by re-executing the transaction, and refer to FIGS. 5 to 7 regarding “file directory creation”. This is the same as the case described above.
[0076]
As described above, the file system 10 with a failure recovery function implements a function of recovering an interrupted file operation request. Various modifications can be made to the file system 10 with the above-described failure recovery function. For example, the transaction described above as a target of the log recording and recovery processing is shown as an example, and other transactions that involve a change in the contents of the disk device may be logged in the same manner as described above. Recording and recovery processing functions can be applied.
[0077]
Since it is only necessary to know that the transaction has been started and completed, the record of the “state” of the transaction may have various forms regarding the expression of the “state”. For example, the completion of the transaction may be expressed in a form of deleting the contents of the transaction entry, in addition to rewriting the state from the start to the completion.
[0078]
Further, in the above embodiment, it is described that one disk device is under the management of the file system 3, but the file system 3 manages a plurality of file devices in the same manner as a general file system. Since it can be configured as follows, it is possible to realize a configuration in which a file device for log recording (that is, a target for failure recovery) and a file device for storing a journal file are separate. You can also. For example, assuming that there is a disk device and a flash memory under the management of the file system 3 and the log recording target is a disk device, the journal file can be stored in the flash memory.
[0079]
It is possible to mix different types of file systems in one computer system. Therefore, it is also possible to realize a configuration in which a file system to be recorded in a log (that is, a target of failure recovery) and a file system to store a journal file are different from each other. That is, when the file system A and the file system B are present in one computer system and the file system A is to be recorded in a log (that is, the failure recovery is performed on the file system A), the journal file is stored in the file system A. Put under the control of B. In this case, the journal file is created as a normal file in the file system B, and transaction information on the file system A is recorded in the journal file as a transaction in the file system A occurs.
[0080]
As shown in FIG. 1, in the file system 10 with the failure recovery function, the log recording function by the log recording system 5 is performed by notifying the start of a transaction from the file system 3 and the recovery function by the recovery manager 7. Is performed in response to a file system initialization request from an application. This configuration makes it easy to add a failure recovery function to an existing file system, and makes it possible to avoid a decrease in the reliability of the existing file system due to the addition of the failure recovery function.
[0081]
The scope of the present invention includes a method and a program for realizing the functions of the file system with a failure recovery function described above, and information devices in which such functions are realized.
[0082]
【The invention's effect】
As described above, according to the present invention, the journal file JF is created as a file under the management of the file system, and the content of the log record is only information relating to the update of the metadata of the file to be operated. . Therefore, log recording can be simplified, and a reduction in the processing speed of file operations associated with log recording can be avoided. The writing of the log to the journal file is performed so that the metadata of the journal file itself is not updated. Therefore, the processing speed of writing the log to the journal file can be increased.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a functional configuration of a file management program with a failure recovery function according to an embodiment of the present invention.
FIG. 2 is a diagram showing a management structure of a disk device using an FAT type file system.
FIG. 3 is a diagram showing a configuration of a journal file managed by the file management program with a failure recovery function of FIG. 1;
FIG. 4 is a diagram showing a configuration of a transaction entry in the journal file of FIG. 3;
FIG. 5 is a flowchart illustrating an operation of recording a log when a file is created.
FIG. 6 is a diagram illustrating a case where processing is interrupted in the file creation processing of FIG. 5;
FIG. 7 is a flowchart showing the operation of the recovery process after the file creation process is interrupted as shown in FIG.
FIG. 8 is a flowchart illustrating an operation of recording a log when writing to a file is performed.
FIG. 9 is a diagram illustrating a case where the process of writing to the file in FIG. 8 is interrupted;
FIG. 10 is a flowchart showing the operation of the recovery process after the file creation process is interrupted as in FIG.
[Explanation of symbols]
3 File system
5 Log recording system
7 Recovery Manager
10 File system with failure recovery function
17 Transaction entry
21 states
22 Sequence number
23 Transaction Type
24 Transaction ID
25 File ID
27 Transaction individual information

Claims (18)

A method of recording a file operation request log,
A predetermined file created under the management of the file system that manages the file to be subjected to the file operation request is defined as a log file,
When a file operation request is received from an application program, the type of the file operation request and the first update information relating to the update of the management area on the file device for the file targeted for the file operation request are stored in the log. Writing to the log file under predetermined conditions that do not cause an update of the management area on the file device for a file,
A log recording method characterized by the following. The predetermined condition is:
2. The log recording method according to claim 1, wherein the log file includes a plurality of entries for recording a log relating to one file operation request, and the plurality of entries are used cyclically. The predetermined condition further includes:
3. The log recording method according to claim 2, further comprising: forcibly completing a file operation on an in-use entry among the plurality of entries to release and use the in-use entry. 4. The log recording method according to claim 1, wherein the predetermined condition is to use the log file as a fixed size. 4. The log recording method according to claim 2, wherein the sizes of the plurality of entries are all equal to a predetermined size. 4. The log recording method according to claim 2, wherein each of the plurality of entries has a size that is an integral multiple of a predetermined unit size. 6. The log recording method according to claim 5, wherein the predetermined size of the entry is a size corresponding to one inseparable access to a file device in which the log file is stored. 8. The log recording method according to claim 7, wherein the predetermined size of the entry is equal to one sector size of the file device. The predetermined size of the entry is equal to or less than one sector size of the file device, and the plurality of entries are stored in the file device so that only one entry is stored in one sector. The log recording method according to claim 7. The log recording method according to any one of claims 1 to 9, wherein the file system is a FAT type file system, and the management area includes information on a FAT and a directory. A method of recording a file operation request log,
A predetermined file created under the management of the file system that manages the file to be subjected to the file operation request is defined as a log file,
When a file operation request is received from an application program, the type of the file operation request and the first update information relating to the update of the management area on the file device for the file targeted for the file operation request are stored in the log. Writing to the log file such that the number of times of writing to the file is one, and
A log recording method characterized by the following. A method of recording a file operation request log,
A predetermined file created under the management of the first file system is defined as a log file,
When a file operation request is made from an application program to a second file system for which the log is to be recorded, the type of the file operation request and the second The update information relating to the update of the management area on the file device managed by the file system of the first file system, and updating the update information of the management area on the file device managed by the first file system for the log file. Writing to the log file under conditions,
A log recording method characterized by the following. A program for managing files on a computer,
13. A log recording program which, when receiving a file operation request from an application program operating on the computer, writes a log relating to the file operation request to a log file by the log recording method according to any one of claims 1 to 12. ,
A recovery program that examines the log file at the time of system startup, and performs a recovery process of the file operation request when there is an incomplete file operation request;
File management program with. A file management program for performing file management on a computer, comprising a log recording program and a recovery program,
The file management program includes:
Upon receiving a file operation request from an application program operating on the computer, the log recording program notifies the log recording program that the processing of the file operation request has started, and the type of the file operation request, A function of providing first update information relating to update of a management area on a file device for a file targeted for the file operation request;
Having a function of notifying the log recording program that the file operation request has been completed, when the processing of the file operation request is completed,
The log recording program comprises:
Upon receiving the notification that the processing of the file operation request has been started, the type of the acquired file operation request and the number of the obtained file operation request are added to a log file created in advance as a file under the management of the file management program. A function of recording that the processing of the file operation request has been started, together with the update information of No. 1;
When receiving a notification that the processing of the file operation request is completed, a function of recording a predetermined completion in the log file,
The recovery program,
Examining the log file at the time of system startup, having a function of performing a recovery process based on the content of the log file, if there is an incomplete file operation request,
A file management program with a failure recovery function, characterized in that: 15. The method according to claim 14, wherein the writing of information to the log file by the log recording program is performed under a predetermined condition that does not cause an update of a management area of the log file on the file device. File management program with disaster recovery function. Software for executing the method according to claim 1 on a computer. 13. A recording medium on which the method according to claim 1 is recorded as a program readable by a computer. An information device comprising control means for executing the method according to claim 1.

Images