JP3896077B2 - Computer system and file management method - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a computer system and a file management method used in the computer system, and more particularly to a computer system and a file management method capable of generating a snapshot showing an image of a file system at a predetermined point in the past.
[0002]
[Prior art]
Generally, in a computer system used as a server computer or the like, it is necessary to maintain the consistency of a file system even when a failure occurs in the computer system. Further, even when the capacity of the file system is large, it is required that it takes no time to recover from a failure.
[0003]
In recent years, several file systems that satisfy these requirements have been proposed. For example, conventionally, a file system is known that uses copy-on-write (COW) technology and logging technology to achieve file system consistency and fast recovery in the event of a system failure (eg, non-patented). Reference 1).
[0004]
In addition to copy-on-write (COW) and logging technologies, inodes can be recorded as arbitrary files on the disk to record the image of the file system at a specified time in addition to the features described above. The technique to do is also known (for example, refer patent document 1).
[0005]
In the copy-on-write technology used in these conventional methods, a new metadata block or data block is created when the metadata block or data block such as an i-node is changed, and the previous block is replaced with the created block. A method of copying the contents and changing the contents of the copied blocks is adopted.
[0006]
[Non-Patent Document 1]
“The Episode File System” Sailesh Chutani, Owen T. Anderson, Michael L. Kazar, Bruce W. Leverett, W. Anthony Mason, Robert N. Sidebotham Proceedings of the Winter USENIX 1992 Technical Conference, Jan 1992, p. 43-59
[0007]
[Patent Document 1]
Japanese National Patent Publication No. 8-511367
[0008]
[Problems to be solved by the invention]
However, with this method, the contents of the original block are kept unchanged, so snapshots from the past time can be easily saved, but a new block is generated during normal operation of the file system. And complicated processing such as data copying.
[0009]
Actually, it is necessary to copy not only the block to be updated but also the block of the upper directory in the hierarchical structure of the file or directory containing the block, and the overhead when writing the file is very large. It becomes.
[0010]
Further, not only information on the current file system directory / file but also information on directories / files corresponding to generations of file systems as the file system update process progresses exists on the disk. It will be. Therefore, there is a problem that many blocks on the file system are consumed to save the snapshot.
[0011]
The present invention has been made in consideration of the above-mentioned circumstances, and can reduce overhead during normal operation, and information on directories / files corresponding to file systems for generations can be stored in the file system. It is an object of the present invention to provide a computer system and a file management method capable of creating a snapshot at a specified arbitrary point of time without constructing the file system.
[0012]
[Means for Solving the Problems]
In order to solve the above-described problem, the present invention provides a computer system having a file system that manages a file in a hierarchical structure on a secondary storage device, log storage means for accumulating the update history of the file system, When updating the contents of the block on the secondary storage device used in the file system, the contents before updating the block are replaced with an identifier for identifying the file or directory including the block and the block number of the block. A pre-update image storage means for storing the pre-update image in the log storage means, a means for updating the block after storing the pre-update image in the log storage means, and an accumulation in the log storage means Based on the pre-update image and the current image of the file system, the update is performed. A snapshot showing an image of the file system at a predetermined point in the past by restoring the contents before the update of the file or directory including the block and the directory information of the upper directory including the file or directory before the update. Snapshot generating means for generating The snapshot generation means newly generates a first alternative block that retains the contents before the update of the updated block using a free block of the secondary storage device, and the updated Based on the content of the management information block on the current image on the file system that holds management information for managing the file or directory including the block, and the block number of the first alternative block, the management information is The management information is modified to have link information to the first substitution block instead of the updated block, and a second substitution block holding the revised management information is stored in the secondary storage device. Means for newly generating a free block, and a higher order file to which the file or directory of the updated block belongs. Based on the content of the block on the current image on the file system holding the file and the block number of the second alternative block, the upper directory moves to the second alternative block instead of the management information block. Means for modifying the directory information of the upper directory so as to have the link information, and newly generating a third alternative block holding the modified directory information by using the free block of the secondary storage device. Include It is characterized by that.
[0013]
In this computer system, when updating a block, the pre-update data of the block to be updated is written to the log storage means together with an identifier for identifying the file or directory including the block and the block number of the block. Then, the block to be updated is updated. In this way, each time a block of the file system is updated, the pre-update image including the management information indicating which file or which block in the directory has been updated and the contents before the update are sequentially written to the log storage means. Go.
[0014]
The file system block is updated, and only the file / directory block corresponding to the latest state exists in the file system. The snapshot is generated based on the pre-update image stored in the log storage means and the current image of the file system. The pre-update contents of the updated block and which block in which file or directory the block is in can be determined from each pre-update image, and the current block that constitutes the file or directory from the current image in the file system And the relationship between the file or directory and the upper directory. Therefore, based on the pre-update image stored in the log storage means and the current image of the file system, the pre-update contents of the file or directory including the updated block and the pre-update file or directory are included. By restoring the directory information of the upper directory, a snapshot showing the image of the file system at a predetermined past time can be generated.
[0015]
Therefore, it is possible to create a snapshot at a specified point in time only when necessary without building information on directories / files corresponding to each generation of file systems in the file system. Become.
[0018]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
FIG. 1 shows the configuration of a computer system according to the first embodiment of the present invention. This computer system is used as a computer system such as a server computer. Hereinafter, the file system of the computer system 11 will be described.
[0019]
The file management system 111 is for managing a file system on a secondary storage device 112 such as a disk storage device (DISK), and is realized by a computer program. Here, the file system means a data structure for managing files in a hierarchical structure on the secondary storage device 112. The storage area on the secondary storage device 112 is divided into physical blocks. The data size of each block is, for example, 512 bytes. In the following, the configuration of the UNIX (R) file system will be described as an example.
[0020]
In order to manage the file system, a boot block, a super block, an i-node list area, and a data area are allocated on the secondary storage device 112 as shown in the figure. The boot block is an area used for storing a boot loader program. The super block is used to store information such as a list of free blocks.
[0021]
The i-node list area is a block group for storing a set of i-nodes that hold information regarding individual files / directories in the file system. An i-node is a data structure for managing individual files / directories corresponding to the i-node. In the i-node, management information related to the corresponding file (directory is also a kind of file), 1) file type (normal file, directory file, etc.), 2) access right, and 3) individual files constituting the file Address information indicating the block number of the block, etc. are held.
[0022]
Each i-node block in which the i-node is stored is referred to by the corresponding i-node number. The i-node number is a file identifier for uniquely identifying each file / directory in the file system, and is used as an index for indexing the i-node of the corresponding file / directory.
[0023]
The data area is a group of blocks in which file / directory entities are held. The block holding the directory includes the i-node number corresponding to the directory and the i-node number corresponding to the upper directory, as well as the i-node number corresponding to each file or directory belonging to the directory, as directory information. It is.
[0024]
The file management system 111 manages files in a hierarchical structure using the data structure on the secondary storage device 112 as described above. The file management system 111 includes a pre-update information acquisition unit 201 and a snapshot generation unit 202 so that a snapshot that is an image of a file system at an arbitrary past time can be created as necessary. Yes.
[0025]
The pre-update information acquisition unit 201 sequentially accumulates the file system update history in the log storage area 113. The log storage area 113 is a non-volatile storage device, and the stored contents are not lost even when the computer system 11 is powered off. The log storage area 113 is realized by using, for example, a dedicated storage device different from the secondary storage device 112 or a storage area on the secondary storage device 112 that is not used as a file system. The log storage area 113 is divided into a management information storage area and a pre-update data image storage area.
[0026]
When the content of the block on the secondary storage device 112 is updated, the pre-update information acquisition unit 201 uses the content before update of the block as an identifier (i-node) for identifying the file or directory including the block. Number) and the block number of the block. In this case, the i-node number and the block number are stored as update management information in the management information storage area together with a flag indicating the block update type (change, deletion, addition, etc.), and the contents before the block update are the same as before the update. Stored in the data image storage area. In this way, each time the block of the file system is updated, the pre-update image including the update management information indicating which block in which file or directory has been updated and the data content before the update are sequentially stored in the log storage area 113. It will be written.
[0027]
The snapshot generation unit 202 generates a snapshot indicating the image of the file system at any specified past time based on the pre-update image stored in the log storage area 113 and the current image of the file system. To do. In this case, the pre-update image accumulated in the log storage area 113 from the time when the snapshot should be generated to the present is used. While referring sequentially from the last pre-update image in the log storage area 113, the contents before the update of the updated file / directory and the directory information of the upper directory including the file / directory before the update are restored. By going, it is possible to create a snapshot image at a specified point in the past.
[0028]
Although the snapshot image can be restored on the secondary storage device 112, the i-node list 203, which is a copy of the i-node list area, and information on each directory are usually stored on the main memory of the computer system 11. Directory information 204 that is a copy of the file system, and the current image of the fill system can be recognized from the information. Therefore, it is also possible to generate a snapshot of a file system image at an arbitrary past time on the main memory using the information on the main memory.
[0029]
Next, with reference to FIG. 2 and FIG. 3, a pre-update image writing process executed by the file management system 111 using the pre-update information acquisition unit 201 will be described.
[0030]
Here, a case will be described in which the content of the file b existing under the directory a is updated in the tree-structured file system as shown in FIG.
[0031]
FIG. 3 shows the data structure of the file system constructed on the secondary storage device 112.
The i-node list area includes the i-node of the root directory, the i-node of the directory a, the i-node of the file b, and the like, and the substance of the root directory, the directory a, and the file b is stored in the data area. Data block exists.
[0032]
Normally, a file is composed of one or more data blocks, and an i-node block, which is a management information block that holds management information of the file b, is a block of each data block that constitutes the substance of the data of the file b. A pointer having a link to a number (here, block numbers 98, 100, 110) is included as address information.
[0033]
Similarly, the i-node block of the root directory includes a block number indicating a data block holding the directory information of the root directory, and the i-node of the root directory which is the current directory is included in the data block of the root directory. Directory information includes an i-node number indicating a block (here, 3) and an i-node number indicating an i-node block of the directory a existing thereunder (here, 4).
[0034]
The i-node block that holds the management information of the directory a includes a block number indicating the data block of the directory a, and the i-node of the root directory that is the upper directory is included in the data block of the directory a. An i-node number (here, 3) indicating a block, an i-node number (here, 4) indicating an i-node block of the directory a which is the current directory, and an i-node block indicating the i-node block of the file b under the directory a A node number (here, 5) is included as directory information.
[0035]
Consider a case where the block 100 in the file b corresponding to the i-node number 5 is updated. In this case, prior to the update of the block 100, the update management information including the i-node number 5 of the file b, the block number 100 to be updated, and the flag information (M) indicating that the update type is a change, Pre-update data is stored in the log storage area 113.
[0036]
The flowchart of FIG. 4 shows a series of processing procedures executed by the file management system 111 when updating a file / directory.
[0037]
When the file management system 111 needs to update the contents of the file / directory in response to a file operation request from the operating system or an application program (YES in step S101), first, the file / directory of the file / directory to be updated The inode number corresponding to the directory name is searched from the directory name, and the inode block of the file / directory to be updated is acquired (step S102).
[0038]
Next, the file management system 111 recognizes each data block that holds the substance of the file / directory to be updated from the address information included in the acquired i-node block (step S103). Consider a case where the block 100 in the file b corresponding to the i-node number 5 is updated. In this case, the file management system 111 uses the pre-update information acquisition unit 201 to update the management information (i-node number = 5, block number = 100, flag information = M) and the block before updating the block with the block number 100. The contents are written in the log storage area 113 as a pre-update image (steps S104 and S105). In order to prevent the contents of the block 100 from being changed during the writing to the log storage area 113, the block 100 is locked before the writing to the log storage area 113 is executed. When the writing to the log storage area 113 is completed, the block 100 is unlocked.
[0039]
Thereafter, the file management system 111 updates the content of the block with the block number 100 from, for example, b to b ′ (step S106). By this update, the file system is always kept up-to-date.
[0040]
FIG. 5 shows a state where a large number of pre-update images (pre-update information) are accumulated in the log storage area 113.
[0041]
Let TIME1, TIME2, TIME3,... Be the time points at which snapshots can be created. For example, in a computer system that operates non-stop for 24 hours, when it is possible to generate a snapshot at 12:00 every day, TIME1, TIME2, and TIME3 are set at intervals of 24 hours. When generating a snapshot at 12:00 today, pre-update images (pre-update information) accumulated from TIME 3 onward until the current time are used in order from the end. In addition, when generating a snapshot at 12:00 yesterday, images before update (pre-update information) accumulated from TIME2 onward until the current time are used in order from the end, and 12:00 on the day before yesterday. When generating a snapshot at a point in time, the pre-update images (pre-update information) accumulated from TIME 1 onward until the current time are used in order from the end.
[0042]
Next, a process for creating a snapshot using the current image of the file system and the pre-update image of the log storage area 113 will be described with reference to FIG.
[0043]
From the update management information of the pre-update image stored in the log storage area 113, it can be seen that the block 100 of the file b corresponding to the i-node number 5 has been updated.
[0044]
(1) Creation of data block for file b before change
Here, in order to create a new block in place of the updated block 100, an empty block (in this case, block number 170) is secured in the data area, and the block 100 stored in the log storage area 113 is updated. The previous data b is copied to the block number 170.
[0045]
(2) Creation of inode block for file b before change
Next, in order to generate a new i-node block corresponding to the file b before the change, an empty block is secured in the i-node list area. Then, the contents of the current i-node block of the file b holding the management information for managing the updated file b are acquired from the current file system. Of the management information included in the i-node block of the acquired file b, the address information indicating the link to the updated block 100 is corrected and rewritten to indicate the link to the block number 170. The corrected management information is written in an empty block secured in the i-node list area, and thereby an i-node block for managing the file b before change composed of block numbers 98, 170, and 110, that is, Instead of the i-node block of the current file b, an i-node block corresponding to the file b (-) one generation before is generated. A new inode number (here, 30) is assigned to the file b (-) one generation before.
[0046]
(3) (4) Restoring directory information of upper directory including file b before change
Next, the directory information of the upper directory a including the file b before change is restored. First, in order to create a new data block in place of the data block of the current directory a holding the directory information of the upper directory a, an empty block is secured in the data area. Then, the contents of the current data block in directory a are acquired from the current file system. Address information indicating the link to the i-node block of the current file b existing under the directory information of the acquired directory a is corrected, and the link to the i-node block of the file b (−) before the change is made. Is rewritten to indicate That is, the i-node number 5 indicating the i-node block of the current file b is changed to the i-node number 30 indicating the i-node block of b (−) one generation before.
[0047]
The corrected directory information is written in an empty block in the data area, and thereby, a data block of the upper directory a (−) including the file b (−) before the change is generated.
[0048]
In addition, an i-node block of the upper directory a (−) is also generated using an empty block on the i-node list area. In this case, management information of the current i-node block in directory a is acquired from the current file system. Of the management information of the acquired directory a, the address information indicating the link to the block of the current directory a is corrected and rewritten to indicate the link to the data block of the directory a (−). The corrected management information is written in an empty block secured in the i-node list area, thereby generating an i-node block of the directory a (−) one generation before. A new i-node number (29 in this example) is assigned to the directory a (-) one generation before.
[0049]
The i-node number of the current directory held in the data block of the directory a (−) is changed from the i-node number 4 of the current directory a to the i-node number 29 of the directory a (−).
[0050]
(5) (6) Next, in order to create a data block of a new root directory in place of the current root directory which is the highest directory, an empty block is secured in the data area. Then, the contents of the current data block in the root directory are acquired from the current file system. Among the acquired directory information of the root directory, the address information indicating the link to the i-node block of the current directory a existing under the directory information is corrected, and the directory information of the previous generation a (-) is updated to the i-node block. Rewritten to indicate a link. That is, the i-node number 4 indicating the i-node block of the current directory a is changed to the i-node number 29 indicating the i-node block of a (−) one generation before. The corrected directory information is written in an empty block in the data area, thereby generating a block of the root directory (-) one generation before.
[0051]
Also, an i-node block of the root directory (-) one generation before is generated using an empty block in the i-node list area. In this case, the management information of the i-node block of the current root directory is acquired from the current file system. Among the acquired management information of the root directory, the address information indicating the link to the block of the current root directory is corrected and rewritten to indicate the link to the block of the root directory (−) one generation before. The corrected management information is written into an empty block in the i-node area, and thereby an i-node block of the root directory (−) one generation before is generated. A new i-node number (in this case, 28) is assigned to the root directory (-) one generation before. The i-node number of the current directory held in the data block of the root directory (-) is changed from the i-node number 3 of the current root directory to the i-node number 29 of the root directory (-).
[0052]
In this way, by creating a block corresponding to the file before the change using a free block and a block related to the upper directory, the contents before the update of the updated file and the upper file including the file before the change are created. By restoring the directory information of the directory, it is possible to generate a snapshot showing the image of the file system at an arbitrary point in the past while maintaining the current image of the file system.
[0053]
The flowchart in FIG. 7 shows a series of processing procedures executed by the snapshot generation unit 202 when generating a snapshot.
[0054]
The snapshot generation unit 202 acquires the pre-update images in order from the tail of the log storage area 113 (step S111), and performs each update until processing for all the pre-update images related to the snapshot at the specified time is completed. The following processing is recursively executed for each previous image (step S112).
[0055]
First, the snapshot generation unit 202 recognizes which block in which file / directory has been updated from the contents of the last pre-update image, and the file / before-change corresponding to the updated file / directory. A new data block for restoring the directory (pre-change file / directory data block) is created in the data area (step S113).
[0056]
For example, in the above example, it can be seen that the content of the block 100 of the file b related to the i-node number 5 has been updated, so that the pre-change file / directory data block instead of the updated block 100 is used as a free block. The contents of the pre-update data of the block 100 that are newly created and recorded in the log storage area 113 are copied to the newly created file / directory data file before change.
[0057]
Next, the snapshot generation unit 202 adds an i-node block for restoring the file / directory before change corresponding to the updated file / directory on the i-node list area. Is newly created (step S114).
[0058]
That is, the snapshot generation unit 202 uses the contents of the current i-node block of the file b and the block number 170 of the data block newly created in step S113 to obtain the management information of the i-node of the file b that has been changed. The file is corrected and copied to the inode block for the file / directory before change newly created in the i-node list area.
[0059]
The processes in steps S113 and S114 described above correspond to the processes (1) and (2) described above, whereby the contents of the file / directory before the change are restored.
[0060]
Thereafter, the snapshot generation unit 202 newly creates a data block for the upper directory a (−) including the pre-change file / directory on the data area (step S115). Here, based on the contents of the current data block in the upper directory a of the updated file b and the i-node number of the pre-change file / directory i-node block created in step S114, the snapshot generation unit 202 The contents of the current data block in the upper directory “a” are corrected and copied to the data block for the newly created directory “a (−)”.
[0061]
Then, the snapshot generation unit 202 newly creates an i-node block for the upper directory a (−) including the pre-change file / directory on the i-node list area (step S116). Here, the snapshot generation unit 202 is based on the contents of the current i-node block in the upper directory a of the updated file b and the block number of the data block for the upper directory a (−) created in step S115. Then, the contents of the current i-node block of the upper directory a are modified and copied to the newly created i-node block for the directory a (−).
[0062]
The processes in steps S115 and S116 described above correspond to the processes (3) and (4) described above, whereby the contents of the upper directory including the file / directory before the change are restored. The processes in steps S115 and S116 are executed for each upper directory until the root directory is traced back (step S117). As a result, a block (data block, i-node block) including information on each directory from the file / directory before update to the root directory is newly created, and the file or directory before change is referred to from the root directory. Link information is restored.
[0063]
Next, with reference to FIG. 8, the relationship between the time when a snapshot should be created and the pre-update image to be recorded in the log storage area 113 will be described.
[0064]
The time point at which a snapshot should be created may be set for each file update timing, but is usually set for every certain time interval. In this case, when updating the same block in the same file / directory, it is not necessary to sequentially collect the pre-update image in the log storage area 113, and the first time after that is based on each time point when the snapshot should be created. The pre-update image relating to the update may be collected in the log storage area 113 only when the update is performed.
[0065]
In FIG. 8, the update of the block 100 of the file b is indicated by ◯, the update of the block 98 of the file b is indicated by Δ, and the update of the block N of the file X is indicated by □. Assume that the update of the block 100 of the file b is repeated several times in the file update between the time point TIME1 when the snapshot is to be created and the next time point TIME2. Since the file image to be restored is TIME1, the pre-update image is collected in the log storage area 113 only at the first update after TIME1. This is because the contents of the block 100 of the file b can be restored to the time of the TIME 1 by collecting the contents of the block 100 of the file b in the log storage area 113 at the time of the TIME 1. The same applies to other files / blocks.
[0066]
Whether or not the pre-update image should be collected corresponds to, for example, identification information indicating whether or not the pre-update image corresponding to the update target block has been collected in the log storage area 113 after the previous time when the snapshot should be created. The determination can be made by holding the file / directory in the i-node structure of the file / directory or registering a list of blocks obtained by collecting the pre-update image in the log storage area 113 in the table. FIG. 9 shows a series of processing procedures when updating a file / directory. In the following, it is assumed that identification information is held in an i-node structure.
[0067]
When the file management system 111 needs to update the contents of the file / directory in response to a file operation request from the operating system or an application program (YES in step S121), first, the file / directory in the file / directory to be updated The i-node number corresponding to the directory name is searched from the directory name, and the i-node block of the file / directory to be updated is obtained (step S122).
[0068]
Next, the file management system 111 recognizes each data block that holds the substance of the file / directory to be updated from the address information included in the acquired i-node block (step S123). Consider a case where the block 100 in the file b corresponding to the i-node number 5 is updated. In this case, the file management system 111 uses the above-described identification information held in the i-node structure included in the i-node block, and the pre-update image related to the update target block already after the time immediately before the snapshot should be created. Is recorded in the log storage area 113 (step S124).
[0069]
If it has already been recorded (YES in step S124), since the update of the block is the second and subsequent updates, the pre-update image is not collected and the update process of the block is executed (step S128). .
[0070]
On the other hand, if not recorded (NO in step S124), the update of the block is the first update, so the following processing is executed.
[0071]
That is, the file management system 111 uses the pre-update information acquisition unit 201 to update the management information (i-node number = 5, block number = 100, flag information = M) and the content before updating the block with the block number 100. Are written in the log storage area 113 as a pre-update image (steps S125 and S126). Next, the file management system 111 records identification information indicating that the pre-update image relating to the block number 100 has been collected in the i-node structure of the file b (step S127).
[0072]
In order to prevent the contents of the block 100 from being changed during the writing to the log storage area 113, the block 100 is locked before the writing to the log storage area 113 is executed. When the writing to the log storage area 113 and the recording of the identification information are completed, the block 100 is unlocked. Thereafter, the file management system 111 updates the content of the block with the block number 100 from, for example, b to b ′ (step S128).
[0073]
Note that the recording of the identification information in the i-node structure may be performed on the i-node list 203 existing on the memory, for example. The content of the identification information on the i-node list 203 is cleared when the next snapshot is to be created.
[0074]
Next, with reference to FIGS. 10 to 12, a snapshot restoration operation when performing a file update process for deleting a file will be described.
[0075]
Here, a case will be described in which the entire file b existing under the directory a is deleted in the tree-structured file system as shown in FIG.
[0076]
FIG. 11 shows a data structure of a file system constructed on the secondary storage device 112. Here, for the sake of simplicity, the case where the entity of the file b is composed of one data block is illustrated.
[0077]
In the file update process for deleting the entire file b corresponding to the i-node number 5, the data block (block number 100) of the file b is deleted and the i-node block of the file b (here, the block number 7 is used). Are also deleted. Along with this, the directory information held in the data block of directory a (here, block number 90) is also updated from a to a ′, and the link information to the i-node block of file b is deleted. Prior to the execution of such a series of file update processing operations, the pre-update image registration processing in the log storage area 113 is performed as follows.
[0078]
First, as an image before update relating to the update of the data block (block number 100) of file b, i-node number 5 of file b, block number 100 to be updated, and flag information (D) indicating that the update type is deletion The update management information consisting of and the pre-update data of the block 100 are stored in the log storage area 113. Next, as the pre-update image related to the update of the inode block (block number 7) of the file b, the inode number 5 of the file b, the block number 7 to be updated, and flag information indicating that the update type is deletion ( The update management information consisting of D) and the pre-update data of block 7 are stored in the log storage area 113. Further, as a pre-update image related to the update of the directory a, update management information including an i-node number 4 of the directory a, a block number 90 to be updated, and flag information (M) indicating that the update type is changed, and a block 90 pre-update data are stored in the log storage area 113. These three pre-update images constitute a set of pre-update images related to the deletion of the file b.
[0079]
FIG. 12 shows how a snapshot is created using the current image of the file system and the pre-update image of the log storage area 113.
[0080]
From the update management information for each of the three pre-update images stored in the log storage area 113, it can be seen that the file b corresponding to the i-node number 5 has been deleted, and the contents of the directory a have been changed along with the file deletion. .
[0081]
The log storage area 113 stores the data content before the change of the file b, the content of the i-node before the change of the file b, and the data content of the directory a before the change as data before the update. From the contents of the data before the change and the current file system image, the data block and i-node block of the file b before the deletion and the data of the directory a including the file b before the deletion are processed in the same procedure as in FIG. By newly creating a block, an i-node block, and a data block and an i-node block of a root directory including the directory a in a free area, a snapshot before deletion of the file b can be restored.
[0082]
As described above, according to the first embodiment, it is possible to restore the snapshot image of the file system at a specific point in time by sequentially writing the pre-change file / directory image to the log area. . In addition, when updating a block during normal operation, it is not necessary to copy the contents of the upper directory of the tree structure of the block, thereby eliminating the overhead caused thereby.
[0083]
In the first embodiment, it is assumed that the snapshot image of the file system is restored on the secondary storage device 112. However, the pre-update image related to the block requested to be read or the current image in the file system is selectively selected. In addition, the contents before update of the file or directory including the updated block can be restored by reading the data on the main storage device. Hereinafter, an example of this case will be described as a second embodiment of the present invention. In the following, portions different from the first embodiment will be mainly described.
[0084]
In the second embodiment, as shown in FIG. 13, in order to be able to read out the pre-update image related to the block requested to be read from the log storage area 113 at high speed, A snapshot buffer management table 302 for managing the snapshot buffer 301 is used.
[0085]
The snapshot buffer 301 is a buffer area allocated on the main memory, and the pre-update image stored in the log storage area 113 is read out here.
[0086]
Here, the principle of the snapshot image generation process executed by the snapshot image generation unit 202 will be described.
[0087]
In the second embodiment, when generating a snapshot image at an arbitrary point in the past, the pre-update image necessary for creating the snapshot image is read from the log storage area 113 and used for the snapshot. Stored in the buffer 301. Each time a block read request is received, it is determined from the current file system or snapshot buffer 301 by determining whether or not a pre-update image corresponding to the block with the block number specified in the read request exists. Corresponding blocks are selectively read out.
[0088]
For example, as described above, it is assumed that the file b is composed of three data blocks having block numbers 98, 100, and 110, and the block having the block number 100 is updated.
[0089]
When it is designated by the user to restore the pre-update image of file b, read requests for block numbers 98, 100, and 110 are sequentially made based on the contents of the inode of file b managed by the current file system. publish. Since the block with the block number 98 has not been updated, the data of the block corresponding to the block number 98 is read from the current file system on the secondary storage device 112 onto the main memory. Since the block having the block number 100 has been updated, the pre-update data of the block having the block number 100 is read from the snapshot buffer 301 onto the main memory. Since the block having the block number 110 has not been updated, the data of the block corresponding to the block number 110 is read from the current file system on the secondary storage device 112 onto the main memory. In this way, the contents before the update of the file b are restored.
[0090]
Next, a specific configuration example of the snapshot buffer management table 302 will be described with reference to FIG.
[0091]
In the snapshot buffer management table 302, for each pre-update image read from the log storage area 113 to the snapshot buffer 301, the log storage area 113 including the i-node number, block number, buffer size, and pre-update data. There are entries for managing the offset, the address of the buffer containing the pre-update data, and the like.
[0092]
The size of the buffer corresponds to the data size of the pre-update data, and indicates the size of the buffer area for holding the pre-update data secured on the snapshot buffer 301 as shown in FIG. As shown in FIG. 16, the address of the buffer including the pre-update data indicates the address of the buffer area for holding the pre-update data secured on the snapshot buffer 301. The offset of the log storage area 113 indicates an offset value from the head address of the log storage area 113 in which the pre-update data is stored.
[0093]
Hereinafter, a specific processing procedure executed by using the snapshot buffer 301 and the snapshot buffer management table 302 will be described.
[0094]
The pre-update image writing process to the log storage area 113 executed by the pre-update information acquisition unit 201 is executed according to the procedure shown in the flowchart of FIG. 4 described above, as in the first embodiment.
[0095]
When generating a snapshot image, first, processing for creating the snapshot buffer management table 302 is executed. The flow chart of FIG. 17 shows the procedure.
[0096]
That is, the snapshot generation unit 202 sequentially acquires the pre-update images from the tail of the log storage area 113 (step S201), and until the processing for all the pre-update images related to the snapshot at the specified time is completed. The following processing is recursively executed for each pre-update image (step S202).
[0097]
First, the snapshot generation unit 202 stores the inode number of the updated block, the block number, the data size of the pre-update data, and the pre-update data from the content of the last pre-update image. The offset values of the area 113 are acquired and registered in the snapshot buffer management table 302 (step S203).
[0098]
At this time, the pre-update data in the log storage area 113 is not read. Then, the process of step S203 is sequentially executed while tracing back the pre-update images stored in the log storage area 113 one by one (step S204). As a result, management information regarding all pre-update images up to a predetermined past time point to be restored is registered in the snapshot buffer management table 302.
[0099]
Next, the procedure of the snapshot image generation process executed using the snapshot buffer management table 302 will be described with reference to the flowchart of FIG.
[0100]
The snapshot image generation process is executed each time a request for reading a past image of each file / directory is issued. That is, when a read request for a file or directory on the snapshot image occurs, the i-node of the file or directory managed by the current file system is referred to, so that each block constituting the file / directory is referred to. The block number is obtained. A data read request for the block number is issued to the snapshot generation unit 202.
[0101]
Upon receipt of the data read request (step S211), the snapshot generation unit 202 searches the snapshot buffer management table 302 and registers the block having the block number specified in the read request in the snapshot buffer management table 302. It is determined whether it has been performed (step S212). If the block having the block number designated by the read request is not registered in the snapshot buffer management table 302 (NO in step S212), the block has not been updated, and the snapshot generation unit 202 can read from the file system. The current block is read and returned to the request source (step S213).
[0102]
On the other hand, if the block having the block number designated by the read request is registered in the snapshot buffer management table 302 (YES in step S212), the snapshot generation unit 202 executes the following processing.
[0103]
In other words, the snapshot generation unit 202 checks whether or not the buffer address is registered in the corresponding entry of the snapshot buffer management table 302, so that the pre-update data of the block number specified in the read request is used for the snapshot. It is determined whether or not it already exists on the buffer 301 (step S214). If the data already exists in the snapshot buffer 301 (YES in step S214), the snapshot generation unit 202 immediately reads the corresponding pre-update data from the snapshot buffer 301 and returns it to the request source. (Step S218).
[0104]
If it does not exist on the snapshot buffer 301 (NO in step S214), the snapshot generation unit 202 secures a buffer area on the snapshot buffer 301 (step S215), and then stores the corresponding pre-update data. The data is read from the log storage area 113 and written on the buffer area (step S216). The snapshot generation unit 202 registers the buffer address in the corresponding entry of the snapshot buffer management table 302 (step S217), reads the pre-update data from the snapshot buffer 301, and returns it to the request source. (Step S218).
[0105]
As described above, in the second embodiment, the pre-update data related to the block requested to be read or the current data in the current file system is selectively read, so that the file or directory including the updated block is updated. The contents can be restored.
[0106]
In the first embodiment, since the block of pre-update data is restored using a new block prepared on the secondary storage device 112, the i-node number of the restored snapshot is the original i-node. In the second embodiment, the pre-update data is returned on demand in response to the block read request. Therefore, the snapshot image of the file system before the update is stored in the i-node. It is possible to restore without changing the number. In addition, when creating a snapshot image on the secondary storage device 112, it takes time to restore the snapshot image because a lot of disk I / O occurs, but according to the method of the second embodiment, The pre-update image of the file / directory requested to be read can be restored at high speed.
[0107]
In the above description of the second embodiment, the case where a block is changed has been described as an example. However, when a block is added or deleted, the restoration can be performed similarly. For example, when the file b is deleted, pre-update data relating to all data blocks and i-node blocks of the file b and pre-update data relating to data blocks of the upper directory a are accumulated in the log storage area 113. When a read request for the directory a is generated, the pre-update data of the directory a is read from the log storage area 113 through the snapshot buffer 301. The pre-update data of the directory a includes the i-node number of the deleted file b, and the block number of the i-node block of the file b can be determined from the i-node number. When a read request for the i-node block of file b occurs, the pre-update data related to the i-node block of file b is read from log storage area 113 through snapshot buffer 301. Since the pre-update data includes the block numbers of all the data blocks of the file b, the pre-update image of the file b is restored by issuing a read request for these block numbers.
[0108]
In the method of the second embodiment, a snapshot image can be generated without storing the i-node number corresponding to the block to be updated in the log storage area 113.
[0109]
Further, the snapshot buffer management table 302 can be realized using an array, or a link list, a hash table, or the like. Further, since the snapshot buffer management table 302 and the snapshot buffer 301 are provided to increase the data reading speed with respect to the log storage area 113, the snapshot buffer management table 302 and the snapshot buffer management table 302 are used. Even if the buffer 301 is not used, it is possible to generate a snapshot image by determining whether or not the block requested to be read exists in the log storage area 113.
[0110]
Further, since all functions of the file management system 111 according to the first embodiment and the second embodiment are realized by a computer program, the program is introduced into a normal computer through a computer-readable storage medium and executed. By simply doing, the same effects as those of the first embodiment and the second embodiment can be obtained.
[0111]
Further, the present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the scope of the invention in the implementation stage. Furthermore, the above embodiments include inventions at various stages, and various inventions can be extracted by appropriately combining a plurality of disclosed constituent elements. For example, even if some constituent requirements are deleted from all the constituent requirements shown in the embodiment, the problem described in the column of the problem to be solved by the invention can be solved, and the effect described in the column of the effect of the invention Can be obtained as an invention.
[0112]
【The invention's effect】
As described above in detail, according to the present invention, overhead during normal operation can be reduced, and information on directories / files corresponding to each generation of file systems can be created in the file system. It is possible to create a snapshot at a specified arbitrary point in time.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a configuration of a computer system according to a first embodiment of the present invention.
FIG. 2 is a view showing an example of a tree structure of a file system managed by the computer system of the first embodiment.
3 is a diagram for explaining a recording operation of an image before update when the file system in FIG. 2 is updated. FIG.
FIG. 4 is a flowchart showing a series of processing procedures executed during file update processing in the computer system of the first embodiment.
FIG. 5 is a view showing a state in which a large number of pre-update images are accumulated in a log storage area provided in the computer system of the first embodiment.
FIG. 6 is a view showing a state of snapshot creation processing in the computer system of the first embodiment;
FIG. 7 is a flowchart showing a procedure of snapshot creation processing in the computer system of the first embodiment;
FIG. 8 is a view showing the relationship between the pre-update image recording operation and the point in time when a snapshot should be created in the computer system of the first embodiment;
FIG. 9 is a flowchart showing a series of processing procedures executed during file update processing in the computer system of the first embodiment;
FIG. 10 is a diagram showing an example of a tree structure of a file system managed by the computer system of the first embodiment.
11 is a diagram for explaining a recording operation of an image before update when the file system in FIG. 10 is updated. FIG.
FIG. 12 is a view showing a state of snapshot creation processing in the computer system of the first embodiment;
FIG. 13 is a diagram for explaining a snapshot buffer and a snapshot buffer management table used in the computer system according to the second embodiment of the present invention;
FIG. 14 is a view for explaining the principle of snapshot image generation processing in the second embodiment;
FIG. 15 is a view showing a configuration example of a snapshot buffer management table used in the second embodiment;
FIG. 16 is a view showing a buffer area secured on a snapshot buffer used in the second embodiment;
FIG. 17 is a flowchart showing a processing procedure for creating a snapshot buffer management table in the second embodiment;
FIG. 18 is a flowchart showing a procedure of snapshot image generation processing in the second embodiment;
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 11 ... Computer system, 111 ... File management system, 112 ... Secondary storage device, 113 ... Log storage area, 201 ... Pre-update information acquisition unit, 202 ... Snapshot generation unit, 203 ... Inode list, 204 ... Directory information, 301... Snapshot buffer 302. Snapshot buffer management table

Claims (8)

In a computer system having a file system for managing files in a hierarchical structure on a secondary storage device,
Log storage means for accumulating the update history of the file system;
When updating the contents of a block on the secondary storage device used in the file system, the contents before the update of the block are used as an identifier for identifying the file or directory including the block and the block of the block A pre-update image storage means for storing a pre-update image in the log storage means together with a number;
Means for updating the block after storing the pre-update image in the log storage means;
Based on the pre-update image stored in the log storage means and the current image of the file system, the contents before the update of the file or directory including the updated block and the file or directory before the update are obtained. And a snapshot generation means for generating a snapshot showing an image of the file system at a predetermined past time by restoring directory information of the upper directory including ,
The snapshot generation means includes:
Means for newly generating a first alternative block that retains the content before the update of the updated block using an empty block of the secondary storage device;
Based on the content of the management information block on the current image on the file system holding the management information for managing the file or directory containing the updated block and the block number of the first alternative block, The management information is modified so that the management information has link information to the first substitution block instead of the updated block, and the second substitution block holding the revised management information is changed to the second substitution block. Means for newly generating using an empty block of the next storage device;
Based on the contents of the block on the current image on the file system holding the upper directory to which the updated block file or directory belongs and the block number of the second alternative block, the upper directory manages the management The directory information of the upper directory is modified so as to have link information to the second substitute block instead of the information block, and a third substitute block holding the modified directory information is stored in the secondary storage device. And a means for newly generating a free block .   2. The computer system according to claim 1, wherein the log storage means is constituted by a nonvolatile storage device. The pre-update image storage means includes
When updating the contents of a block on the secondary storage device used in the file system, whether or not the update is the first update to the block after a predetermined time point when the snapshot should be generated Means for determining,
Means for executing a process of storing the pre-update image relating to the block in the log storage means only when the update is the first update to the block after a predetermined time point at which the snapshot should be generated. The computer system according to claim 1. A file management method for generating a snapshot at a predetermined past time concerning a file system in a computer system that manages files in a hierarchical structure on a secondary storage device,
When updating the contents of a block on the secondary storage device used in the file system, the contents before the update of the block are used as an identifier for identifying the file or directory including the block and the block of the block A pre-update image storing step for storing in the log storage means for accumulating the update history of the file system as a pre-update image together with a number;
A step of updating the block after storing the pre-update image in the log storage means. And
Based on the pre-update image stored in the log storage means and the current image of the file system, the contents before the update of the file or directory including the updated block and the file or directory before the update are obtained. Including a snapshot generation step of generating a snapshot showing an image of the file system at a predetermined past time by restoring directory information of an upper directory including:
The snapshot generation step includes:
Newly generating a first alternative block that retains the updated contents of the updated block by using an empty block of the secondary storage device;
Based on the content of the management information block on the current image on the file system holding the management information for managing the file or directory containing the updated block and the block number of the first alternative block, The management information is modified so that the management information has link information to the first substitution block instead of the updated block, and the second substitution block holding the revised management information is changed to the second substitution block. Creating a new block using an empty block of the next storage device;
Based on the contents of the block on the current image on the file system holding the upper directory to which the updated block file or directory belongs and the block number of the second alternative block, the upper directory manages the management The directory information of the upper directory is modified so as to have link information to the second substitute block instead of the information block, and a third substitute block holding the modified directory information is stored in the secondary storage device. And a new generation step using an empty block. 5. The file management method according to claim 4, wherein the log storage means is composed of a nonvolatile storage device. The pre-update image storing step includes:
When updating the contents of a block on the secondary storage device used in the file system, whether or not the update is the first update to the block after a predetermined time point when the snapshot should be generated A step of determining;
Only when the update is the first update to the block after a predetermined time point at which the snapshot should be generated, the process of storing the pre-update image for the block in the log storage unit is included. The file management method according to claim 4, wherein: A program for generating a snapshot of a file system in a computer system that manages files including directories in a hierarchical structure at a predetermined past point in time,
When updating the contents of a block on the secondary storage device used in the file system, the contents before the update of the block are used as an identifier for identifying the file or directory including the block and the block of the block A pre-update image storing procedure for storing in the log storage means for accumulating the update history of the file system as a pre-update image together with a number;
A procedure for updating the block after storing the pre-update image in the log storage means;
Based on the pre-update image stored in the log storage means and the current image of the file system, the contents before the update of the file or directory including the updated block and the file or directory before the update are obtained. A snapshot generation procedure for generating a snapshot showing an image of the file system at a predetermined past time by restoring directory information of a higher-level directory including the contents before update of the updated block A procedure for newly generating a first substitute block to be held using an empty block of the secondary storage device, and on the file system holding management information for managing a file or directory including the updated block Current a Based on the contents of the management information block on the image and the block number of the first replacement block, the management information has link information to the first replacement block instead of the updated block. A procedure for correcting the management information and newly generating a second alternative block holding the corrected management information using an empty block of the secondary storage device, and the file or directory of the updated block belongs Based on the content of the block on the current image on the file system holding the upper directory and the block number of the second alternative block, the upper directory replaces the management information block with the second alternative block. Modify the directory information of the upper directory so that it has link information to And causing the computer system to execute a snapshot generation procedure including a procedure for newly generating a third alternative block holding the corrected directory information using a free block of the secondary storage device. program. The pre-update image storage procedure includes:
When updating the contents of a block on the secondary storage device used in the file system, whether or not the update is the first update to the block after a predetermined time when the snapshot should be generated The procedure to determine,
And a procedure for executing a process of storing the pre-update image relating to the block in the log storage means only when the update is the first update to the block after a predetermined time when the snapshot should be generated. The program according to claim 7.

Images