WO2004017205A1

WO2004017205A1 - Log recording method, file management program, and information device

Info

Publication number: WO2004017205A1
Application number: PCT/JP2003/010329
Authority: WO
Inventors: Kazunobu Kashiwabuchi
Original assignee: Access Co., Ltd.
Priority date: 2002-08-14
Filing date: 2003-08-13
Publication date: 2004-02-26
Also published as: AU2003257842A1; JP2004078461A

Abstract

A journal file is created as a file under management of a file system as an object of log recording. When a file operation is requested from an application program, processing of the file operation request is started and update information on meta data accompanying the processing of the file operation request for the object file is recorded in the journal file. The journal file is checked upon system start and if a file operation processing not completed is found, the file operation recovery processing is performed according to the information recorded in the journal file.

Description

Description Logging method, file management program, and information equipment

The present invention relates to a failure recovery function for recovering processing of an interrupted file operation on a file device. Background 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 how to create files, how to manage files on file devices, and the storage areas for the management area and the storage area, are determined by the type of file system. Have been.

For example, in a file system called a FAT file system, a file device is divided into an area for storing file management information (hereinafter, referred to as a management area in this specification) and a temporary area for storing file contents. Manage separately. The management area includes a file allocation table (FAT) and information called a directory entry. Therefore, the file system manages the storage location of the data constituting the file by the FAT. File names, directory names, attributes, etc. are managed by directory entries.

On the other hand, a file system is required to have a failure recovery function so that when a file operation process is interrupted due to a system crash, etc., and the contents of the file device become defective, it can be recovered immediately. For example, a file device failure occurs in the following situations. In general, a file system has a cache area to provide high-speed file operation processing to application programs. Therefore, if the system suddenly goes down, The contents of the file operation that has been performed are not reflected on the file device, or the so-called metadata, which is the information of the management area on the file device, and the data content of the file in the data storage area Inconsistency may occur between them.

In order to be able to cope with such a failure, a file system that is configured to realize a disaster recovery function is being proposed. Disclosure of the invention

Generally, it can be considered that the failure recovery function can be realized by recording the contents related to file operations from application programs as logs. However, the failure recovery function causes an increase in the load on normal file operation processing. Therefore, the log contents, such as what contents are to be recorded as a log, what format the log is to be recorded in, and where, etc. Various logging issues affect the performance of disaster recovery and the performance of normal file operations (that is, the processing load increases with logging, and how much the performance of processing for normal file operations decreases). Therefore, a file system that does not affect the performance of normal file operations as much as possible and realizes necessary and sufficient disaster recovery functions is desired.

In addition, in many cases, when a file system having a disaster recovery function is to be constructed, the failure recovery function is added to an already completed file system. Therefore, it is required that the disaster recovery function has a configuration that can be added to the existing file system in the simplest possible format so as not to affect the performance and reliability of the existing file system.

The present invention has been made in view of the above circumstances. That is, the present invention provides a method for realizing 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. The purpose of the present invention is to provide an information device equipped with a disaster recovery function.

In order to achieve the above object, in the log recording method according to the present invention, recording of a log relating to a file operation request is performed by a file for managing a file targeted for the file operation request. This is performed for a log file that is a predetermined file created under the control of the file system. Log files can be manipulated as files under the control of the file system, which simplifies logging. When a file operation request is received from the abbreviated program, the type of the file operation request and further update information regarding the update of the management area on the file device for the file targeted for the file operation request are recorded in a log file. Will be recorded. In other words, only the contents of the update of the management area (so-called “me / day / night”) accompanying the processing of the file operation request are recorded in the log. This suppresses an increase in the load of file operation processing associated with log recording. Further, the writing of information to the log file is performed under a predetermined condition that the update of the ^ _ management area does not occur for the log file on the file device where the log file is stored. In the normal file write process, at least two writes, a write to the management area and a write to the data area, occur. However, according to the above configuration, the write for log recording to the log file involves data —Since writing is performed only in the evening area, the processing speed of log recording can be increased.

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 related to one file operation request. That is, the plurality of entries are used cyclically.

In addition, as a predetermined condition, it is preferable to release a used entry and use it by forcibly completing a file operation regarding a used entry among a plurality of entries. preferable.

Alternatively, the predetermined condition may be that the log file is used as a fixed size.

Preferably, the sizes of the multiple entries in the log file are all equal and of a predetermined size. This makes it possible to search for entries at high speed. Also, it is possible to avoid entry flagging in the log file and efficiently use the entries cyclically.

Alternatively, each of the plurality of entries has a size that is an integral multiple of a predetermined unit size. You can use it.

In addition, it is preferable that the predetermined size of the entry is a size corresponding to one indivisible access to the file device storing the log file so that writing of the entry to the file device can be speeded up. The predetermined size of the entry is preferably equal to the size of one sector of the file device in which the log file is stored.

Alternatively, the predetermined size of the entry is equal to or smaller than the size of one sector of the file device, and a plurality of entries are stored in a log file so that only one entry is stored in one sector. It may be stored in a file device.

Note that the file system may be an FAT type file system, and the management area may be configured to include information on FAT and directories.

The file device that stores the file device of the file that is the target of the file operation request and the file device that stores the log file may be the same.

Alternatively, the file device in which the file to be requested for the file operation is stored may be different from the file device in which the log file is stored.

In order to achieve the above object, a log recording method according to the present invention provides a method for logging a predetermined file created under the control of a file system that manages a file to be requested for a file operation. Shall be recorded. When a file operation request is received from the application program, the type of the file operation request and the update information on the update of the management area on the file device for the file targeted for the file operation request are transmitted. Write to the log file so that the number of writes to the log file is one. In this case, the processing speed of log recording can be increased.

In order to achieve the above object, in the log recording method according to the present invention, a log is recorded in a log file which is a predetermined file created under the management of the first file system. Then, when a file operation request is made from the application program to the second file system to be recorded in the log (that is, to which the failure recovery function is added), the type of the file operation request and The second file system management for the file for which the file operation is requested Update information relating to the update of the management area on the managed file device is recorded in a log file. That is, only the update information of the management area (so-called meta data) associated with the processing of the file operation request in the second file system is targeted for log recording. Then, the writing of information to the log file is performed under predetermined conditions that do not cause the update of the management area on the file device under the first file system management for the log file. With the above configuration, the file system to be subjected to log recording and the file system that manages a predetermined file for recording a log can be separated.

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 the log file by the above-described log recording method, and a log file is checked at a predetermined timing, and the process is completed. When there is a file operation request that has not been performed, a file management program including a recovery program that performs a recovery process for the file operation request can be configured. In this case, the predetermined timing may be when the system is started.

In order to achieve the above object, according to the present invention, there is provided a file management program having the following functions, a log recording program, and a program for realizing a failure recovery function of a file device, comprising a recovery program. Provided.

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 processing of the file operation request has started, and the type of the file operation request is notified. A function of providing first update information on updating a management area on a file device for a file to be requested for the file operation,

(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 obtained file operation request and the type of the obtained file operation request are added to the log file created in advance as a file under the management of the file management program. File operation request with first update information A function that records that the process has started,

(2) A function that records the specified completion in a log file when it is notified that the processing of the file operation request has been completed.

The recovery program is configured to have the following functions.

(1) A function that examines a log file at a predetermined timing and, if there is a file operation request that has not been completed, recovers the file operation request based on the contents of the log file.

Since the above functions may be added to the file management program to realize the file device failure recovery function, the failure recovery function can be added to the file management program in a simple format. Therefore, with the addition of the failure recovery function to the file management program, it is possible to prevent the reliability and performance of the processing of the normal file operation request from deteriorating.

In this case, the predetermined timing may be when the system is started.

It is preferable that the writing of 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 on the file device for the log file. BRIEF DESCRIPTION OF THE FIGURES

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 configuration for managing a disk device using the 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.

FIG. 4 is a diagram showing a configuration of a transaction entry in the journal file of FIG.

Figure 5 is a flowchart showing the log recording operation when a file is created.

Fig. 6 is a diagram showing the case where the process was interrupted in the file creation process of Fig. 5. It is.

FIG. 7 is a flowchart showing the recovery processing operation after the file creation processing is interrupted as shown in FIG.

FIG. 8 is a flowchart showing a log recording operation when writing to a file is performed.

FIG. 9 is a diagram illustrating a case where the process is interrupted in the process of writing to the file in FIG.

FIG. 10 is a flowchart showing the recovery processing operation after the file creation processing is interrupted as shown in FIG. BEST MODE FOR CARRYING OUT THE INVENTION

FIG. 1 is a block diagram showing 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 that realizes a function as a file system, the log recording system 5 is a program that realizes a log recording function, and the recovery processing manager 7 is a recovery program. Corresponds to the program that implements the function. The file system 10 with a disaster recovery function must be implemented on various information devices such as computers, PDAs, and mobile phones, and function to manage files on various types of file devices such as disk devices and flash memory. Can be. Here, as an example, a disk device is used as a file device.

Hereinafter, the details of the file system 10 with a failure recovery function will be described in the following order.

1. Overall configuration of file system 10 with failure recovery function

2. Organization of Journal File J F

3. Details of the operation of the logging system 5 and the recovery manager 7

1. Overall configuration of file system with disaster recovery function

In the file system 10 with the failure recovery function, the file system 3 It has a general function as a FAT type file system that accepts a file operation request from a pre-installation program (hereinafter referred to as an application) and executes file operation processing. The file system 3 manages the disk device HD 1 as a file device. The file system 3 stores the file operation request from the application in the cache area on the main memory in response to the file operation request from the application, as in the processing in the general file system. 2) When a file close request is received from the application, or when the cache area becomes full, the contents of the cache area are reflected on the disk device HD1.

The file system 3 is an FAT type file system that manages file storage locations using FAT (file allocation table). As in the case of a general FAT type file system, the file system 3 stores the disk device HD 1 in the FAT areas 11 and 12, the directory area 13, and the data in which the data of the file contents are stored. It is managed as a configuration consisting of areas 15 (see Fig. 2). FAT is duplexed to FAT11 and FAT12 in order to improve the reliability as a file system.

The file system 3 has a function to operate in cooperation with the log recording system 5 and the recovery manager 7. As a result, when a file operation request is generated from the application, the information on the type of the file operation request and the file operation request processing target Update information relating to the update of the management area on the disk device HD 1 and these information (hereinafter, referred to as transaction information) are recorded in a predetermined file in the disk device HD 1. 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.

• Create files and directories

• Writing to a file • File 'Delete Directory

• File 'Rename directory

• File directory information settings

Hereinafter, the processing of these individual file operations is called a transaction. When a transaction occurs, the file system 3 notifies the logging system 5 that the transaction has started. Further, when the transaction is completed, the fact is notified to the log recording system 5.

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 J F is created in the disk drive H D1 as a normal file under the management of the file system 3. When the processing of a file operation request is interrupted due to a power failure or the like, the recovery manager 7 operates at a predetermined timing such as when the system is started, and becomes incomplete using the journal file JF. Works to recover transactions that are

The failure recovery function provided by the file system 10 with the failure recovery function has the following contents according to the type of transaction.

(a) Interruption of "Create File Directory", "Delete File Directory", "Rename File Directory", and "Set File Directory Information" Re-execute the restored process to restore it.

(b) For “writing to a file”, cancel the suspended processing and restore the state before the “writing to a file” was performed.

Therefore, for the “write to file” transaction, the log is not recorded for the entire write operation, and only the management information (FAT and contents of the directory entry) is recorded. This makes it possible to keep the journal file JF to a small size and to prevent the write processing speed of the file system from being reduced due to the addition of the failure recovery function. 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.

Figure 3 shows the structure of the journal file JF. The journal file JF is created as a normal file under the management of the file system 3 if it has not been created when an application makes an initialization request to the file system 3 such as when the system is started. You. Transaction information on one transaction is recorded in one transaction entry 17. Each transaction entry 17 has an equal size.

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.

(1) 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. In other words, each time a transaction occurs, it uses the first transaction entry in order, and after using the Nth transaction entry, returns to the beginning and searches for an empty transaction entry. To use.

(2) One of the other predetermined conditions is that if the transaction entry is full in the journal file JF, any transaction entry (for example, the oldest transaction is recorded) The transaction entry is completed by reflecting the contents of the cache area managed by the file system 3 on the disk drive HD1, thereby releasing the transaction entry.

The prescribed conditions for handling the above journal file JF, (1) Journal (2) Forcibly releasing and using the journal file when it becomes full depends on the conditions for realizing the fixed size of the journal file JF. I have.

When writing the transaction information to the journal file JF, the log recording system 5 writes the transaction information directly to the data area (that is, the transaction entry) of the journal file JF based on the storage location of the journal file JF which can be known in advance. Writing can be performed. This means that writing of information to a normal file involves at least two writes: writing for updating the management area (metadata) and writing for updating the data area. Writing a log to the journal file JF by the system 5 means that only one write to the temporary area occurs. This has the effect of suppressing a reduction in the processing speed of file operation processing due to the addition of the failure recovery function to the file system.

The size of the transaction entry 17 is equal to one sector size (for example, 512 bytes) of the disk drive HD1. . One sector size is an indivisible unit of access when accessing a disk device. Therefore, writing to the transaction entry 17 can be completed by one writing to the disk drive HD1. This has the effect that if a write to one transaction entry is interrupted, only one transaction entry will be corrupted. It does not affect other transaction entries.

Even if the size of the transaction entry 17 is smaller than one sector, the same effect as above can be obtained if the condition that only one transaction entry is stored in one sector is satisfied.

In addition, the fact that the size of the transaction entry 17 is constant means that the transaction entry 17 can be searched at high speed, and the fragmentation (fragmentation) of the journal file JF can be avoided, and the journal file JF can be used cyclically. Can be performed efficiently. The effect of speeding up transaction entry search and avoiding fragmentation is described in Transaction If the size of entry 17 is constant, it can also be obtained if the size of the transaction entry is not equal to one sector. Even if the size of all transaction entries is not fixed, if the transaction size is an integral multiple of the unit size, the effect of speeding up the search for transaction entries and avoiding fragmentation Can be obtained.

FIG. 4 shows the 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" (symbol 21)

In "Status", one of three statuses of "unused", "started" and "completed" is recorded as the status of the transaction. Each has the following meaning.

"Unused": This transaction entry is not used

"Start": The transaction for this entry has started

"Completed": The transaction for this entry has been completed

(b) “Sequence number” (22)

Transaction serial number given to the transaction by the logging system 5. Indicates that the smallest value is the earliest started transaction ₍ (c) "Transaction type" (code 23)

Enter the name indicating the type of transaction.

(d) "Transaction ID" (reference numeral 24)

Transaction identification number that logging system 5 gives to the transaction.

(e) File ID (code 25)

(f) "Size of transaction individual information" (reference 26)

(g) “Individual transaction information” (reference 27)

This is the individual information of the transaction. The recorded contents differ depending on the type of transaction.

The log recording system 5 manages a sequence number and a transaction ID for a transaction. Logging system 5 is a file system When the transaction 3 is notified from the program 3 that the transaction has been started, the sequence number and the transaction ID are given to the transaction, the transaction information is obtained, and the transaction information is recorded in the transaction entry 17. 3. Details of the operation of the logging 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. 3.1 File and directory creation

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 informs the logging system 5 of the start of the file 'directory creation transaction and the transaction information about this transaction before starting processing. I will provide a.

Next, the log recording system 5 assigns a sequence number and a transaction ID to this transaction, and records this in the transaction entry. In addition, the file ID given by the file system 3 is also 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 that the file is being created)

'Sequence number, file ID, transaction ID

• Transaction individual information ((a)-(e) below)

(a) SFN (short file name) of the file to be created 0329

(b) Attributes of the file to be created

(c) Cluster number of parent directory

(d) Attributes of parent directory

(e) The name of the file to be created.

a-1. Completion of processing of file close request from application

a-2. Completion of file flush

b. Completion of file creation process

It is performed along with.

Note that flash is one of the functions that a file system generally has, and represents a process of reflecting the contents of a cache area managed by the file system on a file device. The flush process is executed by a request from the application to commit a file or a factor in the file system such as when the cache area managed by the file system becomes full. While the log recording system 5 records the start and completion of the transaction as described above, the recovery manager 7 operates when the system starts up, etc., and creates a `` file '' directory in the journal file JF. If an uncompleted transaction is found, recovery processing is performed in the following procedure.

(Recovery procedure)

(1) Check whether the file to be recovered has been created in the parent directory. (If the file to be recovered has been created here, there is no need to perform recovery processing, so the recovery processing can be terminated.)

(2) Next, check and repair the parent directory. Specifically, delete any abnormal directory entries.

(3) Next, create files to be recovered in the parent directory. As an example, assume that an application issues an operation request to create a file with the file name File A, 2003/010329

And the flow of the recovery process of the recovery manager 7. FIG. 5 is a flowchart showing the flow of log recording by the application, the file system 3, and the log recording system 5 in this case. When the application requests “create file A” to file system 3 (S1), file system 3 notifies logging system 5 that a transaction called “create file A” has occurred. Yes (S2). At this time, the transaction information on “creation of file A” is provided from the file system 3 to the log recording system 5 _c. Next, the log recording system 5 stores the transaction information in a predetermined transaction entry of the journal file JF. At the same time, the fact that "creation of file A" has been started is written (S3). On the other hand, the file system 3 processes “creation of file A” (S4). Then, when the “creation of file A” is completed (S 5), the notification from the file system 3 causes the logging system 5 to search for the transaction entry corresponding to “creation of file A” and complete the transaction state. (S6).

Fig. 6 shows a case where the process of "Create File A" (Fig. 5) 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 interrupted 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 an uncompleted transaction (S12). Since it is assumed that “Create File A” has been interrupted as shown in Fig. 6, the transaction of “Create File A” is incomplete here. S12: YE S). If no uncompleted transaction is found (S12: N0), the recovery processing ends.

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). "After re-executing the creation of file A, it is incomplete (that is," started " PT / JP2003 / 010329

The status of the transaction entry is set to "completed" (S14). Note that a transaction entry that is “completed” can be used to record a new transaction.

The record in the journal file JF that the transaction "Write to file" has started,

a. Write request to file from application

Is performed in response to the occurrence of

Upon receiving a “write to file” request from the application, the file system 3 notifies the logging system 5 of the start of the “write to file” transaction and starts this transaction before starting processing. Provides transaction information about the application.

· “Type” = “Wr iT e F i l e” (Information indicating that the file is being written) 'Sequence number, file ID, transaction ID

• Transaction individual information ((a)-(e) below)

(a) Identification information of the file to be written

-1) Class number of parent directory

(a-2) Parent directory attributes,

(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 the file to be written Note that the completion of this transaction is recorded as

a. Completion of file close request from application

b. Complete the file flush

It is performed along with.

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, etc., and stores “write to file” in the journal file JF. If an incomplete transaction is found, recovery is performed in the following procedure.

(Recovery procedure)

(1) Return unused class evenings (lost clusters) to unused as they are.

(2) For the cluster chain of the file to be written, copy the inconsistency among multiple FATs by copying the first FAT (FAT11) to the following FAT (FAT12).

— Do it.

(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. Note that returning the lost cluster in (1) above to unused is actually performed by the “assignment of class to file” executed as an internal process of the “write to file” transaction. This is achieved by logging the necessary transaction information for the transaction (see 3.2.1 “Assigning Classes to Files”).

As an example, assume that the application issues an operation request to write to the file with the file name of file B, 10329

And the flow of the recovery process by the recovery manager 7 will be described.

FIG. 8 is a flowchart showing the 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 the transaction “write to file B” has occurred. Notify (S32). At this time, the transaction information on “writing to file B” is provided from the file system 3 to the log recording system 5.

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). Then, when “writing to file B” is completed by a file close request from the application (S35), the log recording system 5 responds to “writing to file B” by the notification from the file system 3. A search is made for the transaction entry to be executed, and the state of the transaction is changed from "start" to "complete" (S36).

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 HD 1 is completed in an incomplete manner, and the disk device HD 1 is in an abnormal state. A typical example is a state in which only the management area of the disk device HD1 is updated and the data area is not updated, that is, a state in which inconsistency occurs 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 an uncompleted transaction (S42). Now, since the “write to file B” has been interrupted as shown in Fig. 9, it can be seen here that the “write to file B” transaction has not been completed (S42: YES). . In addition, 2003/010329

If no incomplete transaction is found (S42: NO), the recovery process ends.

Next, the recovery manager 7 cancels “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 “status” of the transaction entry that has not been completed is set to “completed” (S44).

3.2.1 Assigning clusters to files

“The assignment of class J to file J, the start of transaction J, is recorded in journal file J F.

a. Before allocating the first cluster of files

b. Before assigning a cluster for adding a class link

Done in

At such a timing, the file system 3 notifies the log recording system 5 of the start of the “assign cluster to file” transaction and provides the transaction information regarding this transaction.

Next, the log recording system 5 assigns a sequence number and a transaction ID to the transaction, and records the transaction in the transaction entry. In addition, the file ID given by the file system 3 is also 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" = "AllocCluster" (Information indicating that clusters are assigned to files)

'Sequence number, file ID, transaction ID

• Transaction individual information ((a)-(b) below)

(a) Identification information of the target file

(a-1) Parent directory cluster number

(a-2) Parent directory attributes, (a-3) Position of directory entry (within parent directory)

(a-4) First cluster number

(b) List of assigned cluster numbers The completion of this transaction is recorded in the following cases.

a-1. When the assigned cluster is set in the directory entry of the target file, and the directory entry and FAT are flushed.

a-2. When the file to which the assigned cluster belongs is closed. b-1. When the connection of the class is completed and the FAT is flushed.

b-2. When the file to which the assigned cluster belongs is closed. The following recovery processing is performed based on the transaction information as a part of the recovery processing of “writing to a file”.

(Recovery procedure)

(1) Return the allocated cluster to unused.

3.3 Deleting File Directory

The record in the journal file JF that the transaction `` File 'directory deletion' 'has started,

a. Request to delete a file from the application

b. Request for directory removal from the application

Is performed in response to the occurrence of Upon receiving a “delete file 'directory” request from the application, the file system 3 notifies the logging system 5 of the start of the “delete file' directory” transaction, and also executes this transaction. Provide transaction information about the application.

Next, the logging system 5 assigns a sequence number and a transaction ID to the transaction, and records the transaction ID in the transaction entry. Record. In addition, the file ID given by the file system 3 is also 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" = "Delet eFile" (information indicating deletion to file)

'Sequence number, file ID, transaction ID

• Transaction individual information ((a) below)

(a) Identification information of the file to be deleted

(a-1) Class 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 L F N (long file name) directory entries of the target file

(a-7) Checksum of alias (alias) of the target file The record that this transaction has been completed is

a. Completion of file directory deletion process

It is performed along with.

While the log recording system 5 records the start and completion of the transaction as described above, the recovery manager 7 is activated when the system is started, etc. If an uncompleted transaction is found, recovery is performed in the following procedure.

(Recovery procedure)

(1) Delete the file directory to be deleted again.

The operation flow when recovering the transaction of “file 'directory deletion” is to find the incomplete transaction and perform recovery by re-executing it. This is the same as the case described above with reference to FIGS. 5 to 7 regarding “creation of file directory”.

3.4 Renaming File Directory

The record in the journal file JF that the transaction of renaming the file directory has started,

a. File name change request from application

Is performed in response to the occurrence of

When the file system 3 receives a “rename file directory” request from the application, the file system 3 informs the logging system 5 of the start of the file directory renaming transaction, and Provides transaction information about the transaction.

Next, the log recording system 5 assigns a sequence number and a transaction ID to the transaction, and records the transaction in the transaction entry. The log recording system 5 also acquires and records the file ID given by the file system 3. Further, the log recording system 5 acquires the following individual transaction 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 specific information ((a), (b) below)

(a) Identification information of the file to be renamed

(a-1) Class number of parent directory

(a-2) Parent directory attributes

(a-3) Directory entry location

(a-4) Attributes of target file

(a-5) First cluster number of the target file

(a-6) LFN (long file name) directory of the target file Entries

(a-7) Checksum of alias of the target file

(b) The new file name of the file in question.

a. Completing the process of renaming the file directory

It is performed along with.

While the log recording system 5 records the start and completion of the transaction as described above, the recovery manager 7 is activated when the system is started, and the `` file '' directory name is stored in the journal file JF. If an incomplete transaction is found in the “change” transaction, recovery is performed in the following procedure.

(Recovery procedure)

(1) Rename the file / directory to be renamed again. The operation flow when recovering the transaction of “file directory rename” is to find the incomplete transaction and perform recovery by re-executing the transaction. This is the same as the case described above with reference to FIG. 3.5 File / directory information settings

The record in the journal file JF that the transaction of setting the file 'directory information

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 the “file directory information setting J” from the application, the file system 3 notifies the logging system 5 of the start of the “file directory information setting” transaction, and Provides transaction information about the transaction.

Next, logging system 5 determines the sequence number for this transaction. Assign a number and transaction ID, and record it in the transaction entry. The log recording system 5 also acquires and records the file ID given by the file system 3. Further, the log recording system 5 acquires the following individual transaction 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 that this is an 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

(The new attribute of the file in question.

a. Completing the process of setting file directory information

It is performed along with.

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, etc., and stores the `` file '' directory in the journal file JF. If an incomplete transaction is found in the information setting transaction, recovery processing is performed in the following procedure.

(Recovery procedure)

(1) Re-execute the information setting process for the target file / directory for information setting.

The operation flow for recovering the transaction of “File / directory information setting” is to find the incomplete transaction and perform recovery by re-executing the transaction. See above 9

The same is true.

As described above, the file system with a failure recovery function 10 realizes a function of recovering an interrupted file operation request. Various modifications can be made to the above-described file system 10 having the failure recovery function. For example, the above-mentioned transactions to be subjected to the log recording and recovery processing are shown by way of example, and the same applies to other transactions that involve a change in the contents of a disk device. Logging and recovery functions can be applied to

The record of the "state" of a transaction can have various forms of representation of the "state", since it is only necessary to know that the transaction has been started and completed. For example, the completion of a transaction may be expressed in a form that deletes the contents of a transaction entry, in addition to rewriting the status from start to completion.

Further, in the above embodiment, it is described that one disk device is managed by the file system 3, but the file system 3 manages a plurality of file devices as in a general file system. It can be configured to be under control. Therefore, it is possible to realize a configuration in which the file device to be recorded in the log (that is, the target of failure recovery) and the file device to store the journal file are separate. 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.

It is possible to mix different types of file systems in one computer system. Therefore, it is possible to realize a configuration in which the file system to be logged (that is, the object of failure recovery) and the file system for storing the journal file are different. That is, if file system A and file system B exist on one computer system and file system A is to be logged (that is, file system A is to be recovered from failure), the journal file is B 2003/010329

Put under the control of. In this case, the journal file is created as a normal file in the file system B, and the transaction information about the file system A is recorded in the journal file as a transaction occurs in the file system A.

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 file system 3 of the start of a transaction. The recovery function by the recovery manager 7 is configured to be performed in response to a file system initialization request from an application. This configuration makes it easy to add a disaster recovery function to an existing file system, and also avoids a decrease in the reliability of the existing file system due to the addition of the disaster recovery function.

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 an information device in which such functions are realized.

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 contents of the log record are related to the update of the file to be operated on. Information only. Therefore, log recording can be simplified, and a reduction in the processing speed of file operations associated with log recording can be avoided. The log is written to the journal file 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. The embodiments described above are merely examples, and the present invention is not limited by the contents of the above embodiments, but should be understood based on the contents described in the claims. It is.

Claims

The scope of the claims

1. A method of logging file operation requests,

The specified file created under the management of the file system that manages the file targeted for the file operation request is defined as a log file,

When a file operation request is received from an application program, the log file contains the type of the file operation request and the update information regarding the update of the management area on the file device for the file targeted for the file operation request. Writing to the log file under predetermined conditions that do not cause an update of the management area for the log file on the stored file device;

A log recording method characterized by the following.

2. 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 related to one file operation request, and the plurality of entries are used cyclically.

3. The predetermined condition further includes:

3. The log recording method according to claim 2, further comprising: forcibly completing a file operation relating to an in-use entry among the plurality of entries to release the in-use entry for use.

4. The log recording method according to claim 1, wherein the predetermined condition is to use the log file as a fixed size.

5. The log recording method according to claim 2, wherein the sizes of the plurality of entries are all equal predetermined sizes.

6. Each of the plurality of entries has a size that is an integral multiple of a predetermined unit size. 3. The logging method according to claim 2, wherein:

7. The log recording method according to claim 5, wherein the predetermined size of the entry is a size corresponding to one indivisible 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 a file device in which the log file is stored. 9. The predetermined size of the entry is equal to or less than one sector size of a file device in which the log file is stored, and the plurality of entries are stored such that only one entry is stored in one sector. The log recording method according to claim 7, wherein the log file is stored in a file device that stores the log file. 10. The recording method according to claim 1, wherein the file system is a FAT type file system, and the management area includes information on FAT and a directory.

11. The log recording method according to claim 1, wherein the file device storing the file to be requested by the file operation request is the same as the file device storing the log file.

12. The log recording method according to claim 1, wherein a file device storing the file to be requested by the file operation request is different from a file device storing the log file.

1 3. A method of logging file operation requests,

The specified file created under the management of the file system that manages the file targeted for the file operation request is defined as a log file, When a file operation request is received from the application program, the log information includes the type of the file operation request and the update information regarding the update of the management area on the file device for the file targeted for the file operation request. Writing to the log file so that the number of times of writing to the file is one;

A log recording method characterized by the following.

1 4. A method of logging file operation requests,

A prescribed file created under the control 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 file The update information on the update of the management area on the file device managed by the second file system is updated, and the update of the management area on the file device managed by the first file system for the log file occurs. Writing to the log file under no predetermined condition.

15. A program for managing files on a computer, the program according to any one of claims 1 to 12, when a file operation request is received from an application program running on the computer. A log recording program for writing a log relating to the file operation request to a log file using the described log recording method;

A recovery program that examines the log file at a predetermined timing and, when there is a file operation request that has not been completed, performs recovery processing of the file operation request.

16. The file management program according to claim 15, wherein the predetermined timing is at the time of system startup.

1 7. A file management program for managing files 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 running on the 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 is notified. 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 has been completed,

The log recording program comprises:

Upon receiving the notification that the processing of the file operation request has been started, the log file previously created as a file under the management of the file management program includes the type of the acquired file operation request and the A function for recording that the processing of the file operation request has been started, together with the update information of 1,

A function of recording a predetermined completion in the log file upon receiving a notification that the processing of the file operation request has been completed,

The recovery program,

Having a function of examining the log file at a predetermined timing 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;

A file management program with a failure recovery function, characterized in that:

18. The file management program with a failure recovery function according to claim 17, wherein the predetermined timing is at the time of system startup.

19. 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. With failure recovery function described in 17 File management program.

20. Software for executing the method according to any one of claims 1 to 14 on a computer.

21. A recording medium recording a method according to any one of claims 1 to 14 as a program readable by a computer.

22. An information device provided with control means for executing the method according to any one of claims 1 to 14.