This application claims priority from Japanese Patent Application No. JP2004-167457, filed Jun. 4, 2004, the entire disclosure of which is incorporated herein by reference.
The present invention relates to a disk drive, a method for controlling the disk drive and a falsification detection method. More particularly, the present invention relates to a method for controlling a disk drive having a flag area that can be only referred to by a host but not written thereby and relates to a falsification detection method for detecting a falsification of data, which has been recorded by the disk drive on the storage medium employed in the disk drive, by making a 2-stage analysis, i.e., an analysis of a time transient of meta data and an analysis of a time transient of contents.
With popularization of various kinds of application software, there is also progress in efforts to convert documents prepared by the user into electronic data. Unlike a document written on a piece of paper, electronic data can be changed with ease. Thus, by carrying forward the efforts to convert documents into electronic data, improvement of the work efficiency can be expected. In order to use electronic data as evidence in typically a judicial trial, however, it is required that the time to make the electronic data and the contents of the electronic data are not falsified. For this reason, the faultlessness of the electronic data must be verified or, if the electronic data has been falsified, the falsification must be detected.
The conventional detection of electronic data recorded by a disk drive on a storage medium mounted thereon can be divided into two large categories as follows:
As the first method, ‘a file system and a program storage medium’ have been proposed and disclosed in Japanese Patent Laid-open No. 10-283262 and as the second method, ‘a system and method for preventing falsification of electronic texts’ have been proposed and disclosed in Japanese Patent Laid-open No. 11-261550.
Japanese Patent Laid-open No. 10-283262 Zhas proposed a new file system capable of determining whether or not a file has been falsified. When a new file is generated, an authentication file is also created. The authentication file includes a checksum of the new file, its creation date and information on the creator thereof. By using this new file system, every time a file recorded on a storage medium in a disk drive is updated through an operation carried out by a host to write data onto the storage medium, a post-updating checksum and an updating date are added to the authentication file. Thus, it is possible to determine whether or not the file has been falsified.
In Japanese Patent Laid-open No. 11-261550, a method has been proposed as a falsification detection method allowing an outside authenticator to create authentication data of an electronic text. In accordance with this method, first of all, a central player extracts characteristic data representing characteristics of an electronic text and encrypts the characteristic data by using a first encryption key. Then, the outside authenticator adds external authentication data including at least a date to the encrypted characteristic data and further encrypts the characteristic data by using a second encryption key to produce authentication data of the electronic text. The central player is not capable of creating the authentication data. Thus, by comparing the electronic text with the authentication data, it is possible to determine whether or not the electronic text has been falsified.
A falsification detection method using a checksum and extracting characteristics on the basis of this file system has the following problems.
First of all, the method disclosed in Japanese Patent Laid-open No. 10-283262 has the following problems:
On the other hand, the method disclosed in Japanese Patent Laid-open No. 11-261550 has the following problems:
It is thus a feature of the present invention to provide a method for controlling a disk drive by creating a flag area that can be only referred to by a host but not updated thereby for every smallest write unit of a recording medium in the disk drive.
It is another feature of the present invention to provide a falsification detection method for detecting a falsification of data recorded on a storage medium in a disk drive for recording new data into a free area on the storage medium so as to prevent existing data from being overwritten by the new data by making an analysis of a time transient of meta information and an analysis of a time transient of contents specified by the meta information at every stage of the time transient of the meta information.
It is another feature of the present invention to provide a falsification detection method capable of referring to a result of falsification detection in both the forward and opposite directions of the time axis.
It is another feature of the present invention to provide a falsification detection method capable of suspending and resuming a process to detect a falsification.
It is another feature of the present invention to provide a falsification detection method capable of writing an identifier of contents into a flag area of a storage medium for recording the contents.
It is another feature of the present invention to provide a falsification detection method capable of recording a check point into a flag area for an address on a storage medium for recording meta information and contents with consistency.
It is another feature of the present invention to provide a falsification detection method capable of determining whether or not contents identified by a specified identifier has been falsified.
It is another feature of the present invention to provide a falsification detection method capable of outputting a difference between contents after being falsified and the contents before being falsified.
It is another feature of the present invention to provide a falsification detection method capable of invalidating falsified data.
It is another feature of the present invention to provide a falsification detection method capable of checking information in a flag area included into the storage medium mounted in a disk drive as an area that can be only referred to by a host but not updated thereby and capable of checking consistency between a time transient of meta information and a time transient of contents.
In specific embodiments of the present invention, the disk drive, the disk-drive control method and the falsification detection method include the components or aspects as below.
A control unit executes the steps of: providing a flag area for each unit of writing data into the storage medium employed in the disk drive as an area, which a host is capable of only referring to but only the control unit is capable of writing information into; generating information based on internal information of the disk drive; and writing the generated information into the flag area.
The control unit further executes the steps of: receiving a write command from the host; generating information based on internal information; and generating information, which changes to accompany execution of the write command.
The control unit further executes the steps of: receiving a read command from the host; generating information based on internal information; and generating information, which changes to accompany execution of the read command.
The information, which changes to accompany execution of the write command, is a total operating time of the disk drive, the total number of write commands issued to the disk drive or a write-command count computed for every unit of writing data onto the storage medium.
The control unit employed in the disk drive, a first host writing data onto a storage medium employed in the disk drive, a second host writing no data onto the storage medium employed in the disk drive or a management console of the disk drive executes the steps of: setting a logical structure of data recorded onto the storage medium employed in the disk drive; identifying a record of meta information used as information of the set logical structure of the data among pieces of data recorded on the storage medium employed in the disk drive on the basis of the logical structure; analyzing a time transient of the identified meta information from an initial state of the meta information to a most recent state of the meta information; and analyzing a time transient of contents of data specified by the meta information as a time transient from an initial state of the contents to a most recent state of the contents at every stage in the analyzed time transient of the meta information.
From the result of analyzing the time transient of the meta information, the control unit further executes the step of generating a time transient of the meta information in the opposite direction from the most recent state to the initial state and, from the result of analyzing the time transient of the contents, the control unit further executes the step of generating a time transient of the contents in the opposite direction from the most recent state to the initial state.
The control unit further executes the steps of:
allocating an area for saving an analysis result;
saving the present state of an analysis process in the allocated area;
checking the allocated area for data saved therein at the start of a falsification detection process and reading out the state of an analysis process in a case where the state has been saved in the area; and
starting an analysis process as a continuation of an immediately preceding analysis process from the last state of the preceding analysis process in a case where the last state of the preceding analysis process has been read out from the area or starting an analysis process all over from the beginning if no state of the analysis process has been read out from the area.
The control unit further executes the step of recording an identifier of contents into a flag area, which is provided on the storage medium for every smallest management unit, for a recording area included in the storage medium as an area in which contents of data specified by meta information are recorded by the disk drive.
The control unit further executes the steps of: identifying an address on the storage medium employed in the disk drive as an address, at which meta information and contents have been recorded by maintaining consistency between the meta information and the contents, from a result of analyzing a time transient of the meta information and a result of analyzing a time transient of the contents; and recording a check point, which shows that the meta information and the contents have been recorded by maintaining consistency, in the flag area corresponding to the specified address on the storage medium.
The control unit further executes the steps of:
receiving an identifier entered by the user via a console as the identifier of contents;
searching a result of analyzing a time transient of meta information for the identifier and determining whether or not the contents have been replaced;
outputting information indicating the event of content replacement on the console in a case where the contents have been replaced;
searching a result of analyzing a time transient of the contents for the identifier and determining whether or not the contents have been renewed; and
outputting information indicating the event of content renewal on the console in a case where the contents have been renewed.
The control unit further executes the steps of: receiving two arbitrary events entered to the console as events selected among pieces of information each output to the console to indicate the event of content replacement or pieces of information each output to the console to indicate the event of content renewal; computing a difference between meta information requested by one of the received events and meta information requested by the other received event and outputting the difference to the console; and computing a difference between contents requested by one of the received events and contents requested by the other received event and outputting the difference to the console.
The control unit further executes the steps of: receiving an arbitrary event entered to the console as an event selected among pieces of information each output to the console to indicate the event of content replacement or pieces of information each output to the console to indicate the event of content replacement; and invalidating contents requested by the received event.
The control unit further executes the step of invalidating meta information and contents, which have the same identifier as a content identifier requested by a received event and have been recorded on the storage medium employed in the disk drive at and after a point of time the received event was generated.
The control unit further executes the step of invalidating all pieces of meta information and all contents, which have been recorded on the storage medium employed in the disk drive at and after a point of time the received event was generated.
The control unit further executes the steps of: checking consistency between a result of analyzing a time transient of meta information and information stored in the flag area; and checking consistency between a result of analyzing a time transient of contents and information stored in the flag area.
The control unit further executes the step of periodically scanning the storage medium and uses information read out at the scanning step as information based on internal information of the disk drive.
A disk drive including a storage medium and a control unit for exchanging a command and data with a host and executing control of operations to write data onto the storage medium in accordance with the command received from the host as well as control of operations to read out data from the storage medium in accordance with the command received from the host comprises: a flag-area generation module for providing a flag area, which the host is capable of only referring to but only the disk drive is capable of writing information into, for every unit of an operation to write data into the storage medium; an internal-state information generation module for generating internal-state information based on an internal state of the disk drive; and an internal-state information write module for writing internal-state information generated by the internal-state information generation module into the flag area provided by the flag-area generation module.
The internal-state information generation module uses a state, which changes to accompany execution of a write command, and a state, which changes to accompany execution of a read command, as the internal state. The state, which changes to accompany execution of a write command, includes the total operating time of the disk drive, the number of write commands issued to the disk drive or a write-command count computed for every unit of the operation to write data into the storage medium.
The disk drive further includes a scan mechanism for periodically scanning the storage medium and the internal-state information generation module uses a state changed by the scan mechanism as the internal state.
The present invention exhibits the following effects. Since an external recognition mechanism is not required, the present invention has the effect of an ability to detect a falsification even in a standalone environment.
Since a falsification can be detected by merely reading out data of a management information portion from the storage medium employed in the disk drive, the present invention has the effect of an ability to shorten the time it takes to detect a falsification by a quantity proportional to a decrease in amount of data to be read out.
Since a function to suspend and resume a process to detect a falsification makes it unnecessary to repeat the falsification detection process for an area, in which a falsification has been detected, the present invention has the effect of an ability to increase the speed of the process.
In the case of a file that has been falsified, the present invention has the effect of an ability to confirm the existence of the falsification through examination of a falsification point by tracing back from the most recent state to a preceding state.
Data may have been written into a file in the storage medium employed in the disk drive by issuing a command for a block device directly from the host without going through a file system. By tracing a history of operations to write data into blocks for recording the contents of the file, nevertheless, the present invention has the effect of an ability to detect a falsification of the file even if data has been written into the file by issuing a direct command in such a way.
The present invention also has the effect of an ability to apply the detection of a falsification to any applications other than the file system as long as the applications each write data onto a storage medium employed in the disk drive as data having a logical structure.
By referring to operations recorded in a history of directory operations before referring to a history of file operations, the present invention can exhibit an ability to trace updated contents of a file even if the file has been replaced.
The present invention also has the effect of an ability to restore the pre-falsification state of the disk drive and sustain consistency of the file system through invalidation of data of a minimum possible amount by identification of a condition in which consistency of the file system is established in a pre-falsification state of the disk drive.
FIG. 1 is a PAD diagram referred to in explaining a method of tracing a history of write operations carried out in accordance with a first embodiment of the present invention.
FIG. 2 is a PAD diagram referred to in explaining a subroutine 130 according to the first embodiment of the present invention.
FIG. 3 is a PAD diagram referred to in explaining a subroutine 140 according to the first embodiment of the present invention.
FIG. 4 is a PAD diagram referred to in explaining a subroutine 150 according to the first embodiment of the present invention.
FIG. 5 is a PAD diagram referred to in explaining a method according to the first embodiment of the present invention as a method of detecting a falsification of a file.
FIG. 6 is a diagram showing a screen appearing on a display unit of a console as a screen according to the first embodiment of the present invention.
FIG. 7 is a block diagram showing hardware according to the first embodiment of the present invention.
FIG. 8 is a diagram showing recording formats of a storage medium in a disk drive according to the first embodiment of the present invention.
FIG. 9 is a diagram showing the data structure of a flag area according to the first embodiment of the present invention.
FIG. 10 is a diagram showing a directory state transition repository according to the first embodiment of the present invention.
FIG. 11 is a PAD diagram referred to in explaining a method of tracing a history of write operations in accordance with a second embodiment of the present invention.
FIG. 12 is a PAD diagram referred to in explaining a subroutine 1130 according to the second embodiment of the present invention.
FIG. 13 is a PAD diagram referred to in explaining a subroutine 1140 according to the second embodiment of the present invention.
FIG. 14 is a PAD diagram referred to in explaining a subroutine 1150 according to the second embodiment of the present invention.
FIG. 15 is a PAD diagram referred to in explaining a method according to the second embodiment of the present invention as a method of detecting a falsification of a file.
FIG. 16 is a diagram showing a screen appearing on a display unit of a console as a screen according to the second embodiment of the present invention.
FIG. 17 is a diagram showing the configuration of a system according to the second embodiment of the present invention.
FIG. 18 is a diagram showing the data structure of a block for recording meta information of a directory in accordance with the first embodiment of the present invention.
FIG. 19 is a diagram showing data structures of meta information of a file as data structures according to the first embodiment of the present invention.
FIG. 20 is a diagram showing the data structure of a directory state transition repository according to the first embodiment of the present invention.
FIG. 21 is a diagram showing the data structure of a file state transition repository according to the first embodiment of the present invention.
FIG. 22 is a diagram showing the data structure of an LBA state transition repository provided for blocks specified in the file transition entries of a file state transition repository as an LBA state transition repository according to the first embodiment of the present invention;
FIG. 23 is a diagram showing a typical screen appearing on the display unit of a console as a screen according to the first embodiment of the present invention.
FIG. 24 is a diagram showing the data structure of an LBA state transition repository provided for blocks specified in the file transition entries of a file state transition repository as an LBA state transition repository according to the second embodiment of the present invention.
FIG. 25 is a diagram showing a typical screen appearing on the display unit of a console as a screen according to the second embodiment of the present invention.
Embodiments of the present invention will be described with reference to the drawings below. It is to be noted that the same configuration elements are denoted by the same reference numeral through out the description.
FIG. 1 is a PAD diagram referred to in explaining a method of tracing a history of write operations carried out in accordance with a first embodiment of the present invention. In FIG. 1, reference numeral 100 denotes the PAD diagram referred to in explaining the method of tracing a history of write operations carried out by the first embodiment implementing a falsification detection method provided by the present invention. Reference numeral 110 denotes the step of checking whether or not there is a result of an analysis made previously. Reference numeral 111 denotes the step of fetching the result of an analysis made previously. Reference numeral 112 denotes the step of fetching analysis resumption information required for starting an analysis as a continuation of the immediately preceding analysis. Reference numeral 113 denotes the step of fetching the logical structure of data recorded on the storage medium employed in the disk drive. Reference numeral 114 denotes the step of setting an analysis program for tracing a history of write operations. Reference numeral 115 denotes the step of seeking the storage medium employed in the disk drive for the beginning of the storage medium. Reference numeral 116 denotes the step of allocating a location for storing a result of an analysis. Reference numeral 117 denotes the step of writing a result of an analysis. Reference numeral 118 denotes the step of writing analysis resumption information required for starting a present analysis as a continuation of the immediately preceding analysis. Reference numeral 119 denotes the step of recording an error. Reference numeral 120 denotes the step of executing a loop in a range of PBAs (Physical Block Addresses) of an analysis-object block already completing a write operation in the storage medium employed in the disk drive. Reference numeral 121 denotes the step of determining whether or not a write operation carried out on a block serving as the object of the analysis is a directory operation. Reference numeral 122 denotes the step of determining whether or not a write operation carried out on a block serving as the object of the analysis is a file operation. Reference numeral 123 denotes the step of determining whether or not a write operation carried out on a block serving as the object of the analysis is a block operation. Reference numeral 130 denotes a subroutine for a case where a write operation carried out on a block serving as the object of the analysis is a directory operation. Reference numeral 140 denotes a subroutine for a case where a write operation carried out on a block serving as the object of the analysis is a file operation. Reference numeral 150 denotes a subroutine for a case where a write operation carried out on a block serving as the object of the analysis is a block operation.
FIG. 2 is a PAD diagram referred to in explaining the subroutine 130 provided by the first embodiment of the present invention. In FIG. 2, reference numeral 200 denotes the PAD diagram referred to in explaining the subroutine 130 provided by the first embodiment implementing a falsification detection method provided by the present invention. Reference numeral 201 denotes the step of comparing a state existing before updating of meta information recorded in a block serving as the object of the analysis as meta information of a directory with a state existing after the updating of the meta information. Reference numeral 202 denotes the step of seeking for the next block. Reference numeral 210 denotes the step of determining whether or not the write operation is a file creation. Reference numeral 211 denotes the step of searching for the same file name existing in the past as the name of a file serving as the object of the analysis. Reference numeral 212 denotes the step of determining whether or not the same file name exists on the basis of a result of the search. Reference numeral 213 denotes the step of adding an item to existing file transition entries of the directory state transition repository as a file transition entry item for saving a result of an analysis. Reference numeral 214 denotes the step of adding a reference remark indicating an opposite direction to a file transition entry. Reference numeral 215 denotes the step of creating a new file transition entry in the directory state transition repository. Reference numeral 220 denotes the step of determining whether or not the write operation is a file deletion. Reference numeral 221 denotes the step of adding a file transition entry of a file deletion to the directory state transition repository. Reference numeral 230 denotes the step of determining whether or not the write operation is an operation to change the name of a file. Reference numeral 231 denotes the step of adding a file transition entry of a file-name modification to the directory state transition repository.
FIG. 3 is a PAD diagram referred to in explaining the subroutine 140 provided by the first embodiment of the present invention. In FIG. 3, reference numeral 300 denotes the PAD diagram referred to in explaining the subroutine 140 provided by the first embodiment implementing a falsification detection method provided by the present invention. Reference numeral 301 denotes the step of comparing a state existing before updating of meta information recorded in a block serving as the object of the analysis as meta information of a file with a state existing after the updating of the meta information. Reference numeral 310 denotes the step of checking whether or not meta information of a file has been updated. Reference numeral 311 denotes the step of adding an operation to update meta information as a file transition entry to the directory state transition repository. Reference numeral 312 denotes the step of searching an LBA (Logical Block Address) state transition repository for managing only LBAs of blocks each used for recording contents of an unidentifiable file for an LBA in meta information. Reference numeral 313 denotes the step of determining whether or not an LBA in meta information has already been cataloged in the LBA state transition repository for managing only LBAs of blocks each used for recording contents of an unidentifiable file. Reference numeral 314 denotes the step of moving an LBA block entry from the LBA state transition repository for managing only LBAs of blocks each used for recording contents of an unidentifiable file to an LBA state transition repository provided for blocks specified in the file transition entries of a file state transition repository. Reference numeral 315 denotes the step of searching an LBA block entry moved from an LBA state transition repository for managing only LBAs of blocks each used for recording contents of an unidentifiable file to an LBA state transition repository provided for blocks specified in the file transition entries of a file state transition repository for the LBA of a block for storing the tail of a file. Reference numeral 316 denotes the step of determining whether or not the LBA of a block for storing the tail of a file is included in an LBA block entry moved from an LBA state transition repository for managing only LBAs of blocks each used for recording contents of an unidentifiable file to an LBA state transition repository provided for blocks specified in the file transition entries of a file state transition repository. Reference numeral 317 denotes the step of adding a consistency flag to a management area of a rearmost block of a file. Reference numeral 318 denotes the step of checking consistency between meta information and information recorded in a flag area.
FIG. 4 is a PAD diagram referred to in explaining the subroutine 150 provided by the first embodiment of the present invention. In FIG. 4, reference numeral 400 denotes the PAD diagram referred to in explaining the subroutine 150 provided by the first embodiment implementing a falsification detection method provided by the present invention. Reference numeral 401 denotes the step of searching an LBA state transition repository of blocks specified in the file transition entries of a file state transition repository for the LBA of a block serving as the object of the analysis. Reference numeral 410 denotes the step of determining whether or not the LBA of a block serving as the object of the analysis has been cataloged in an LBA state transition repository provided for blocks specified in the file transition entries of a file state transition repository. Reference numeral 411 denotes the step of adding information associated with a block serving as the object of the analysis to an LBA state transition repository provided for blocks specified in the file transition entries of a file state transition repository. Reference numeral 412 denotes the step of checking consistency between meta information and information recorded in a flag area. Reference numeral 413 denotes the step of adding a reference remark indicating an opposite direction to an LBA state transition repository provided for blocks specified in the file transition entries of a file state transition repository. Reference numeral 414 denotes the step of determining whether or not a block serving as the object of the analysis is the last block for recording the end of the contents of a file. Reference numeral 415 denotes the step of adding a consistency flag to a management area of the last block of a file. Reference numeral 416 denotes the step of adding a new entry to an LBA state transition repository for managing only LBAs of blocks each used for storing contents of an unidentifiable file.
FIG. 5 is a PAD diagram referred to in explaining a method provided by the first embodiment of the present invention as a method of detecting a falsification of a file. In FIG. 5, reference numeral 500 denotes the PAD diagram referred to in explaining the method of detecting a falsification of a file in accordance with the first embodiment implementing a disk-drive control method and a file-falsification detection method, which are provided by the present invention. Reference numeral 501 denotes the step of specifying a path name. Reference numeral 510 denotes the step of looping a history of operations to update meta information of a directory state transition repository in a reversed order. Reference numeral 511 denotes the step of determining whether or not a path name is the specified path name. Reference numeral 512 denotes the step of reading out the substance of an operation from the history of operations to update meta information. Reference numeral 513 denotes the step of outputting the fetched substance of the operation to a console. Reference numeral 520 denotes the step of executing a loop as long as a fetched substance of the operation exists. Reference numeral 527 denotes the step of extracting a difference at a file level between replaced and replacing files. Reference numeral 528 denotes the step of outputting the file difference to the console. Reference numeral 531 denotes the step of reading out consistency of a history of operations to update meta information. Reference numeral 532 denotes the step of outputting the consistency of the history of operations to update meta information to the console. Reference numeral 533 denotes the step of reading out consistency of file updating. Reference numeral 534 denotes the step of outputting the consistency of file updating to the console.
FIG. 6 is a diagram showing a screen appearing on a display unit of a console as a screen provided by the first embodiment of the present invention. In FIG. 6, reference numeral 600 denotes the display screen of the console as a screen provided by the first embodiment implementing a disk-drive control method and a falsification detection method, which are provided by the present invention. Reference numeral 601 denotes an input portion for inputting a path name and reference numeral 602 denotes a command button for making a request for a display of an analysis result corresponding to the path name. Reference numeral 603 denotes a display area for displaying a meta-information difference and reference numeral 604 denotes a display area for displaying a file difference. Reference numeral 605 denotes a command button for making a request for invalidation of data and reference numeral 610 denotes a directory-operation display area. Reference numeral 611 denotes a display column for displaying the substance of each directory operation and reference numeral 612 denotes a display column for displaying the consistency of each directory operation. Reference numeral 613 denotes a row of a selected directory operation and reference numeral 620 denotes a display area for displaying blocks each used for recording the contents of a file. Reference numeral 621 denotes a display column for displaying the LBA of each block for recording the contents of a file. Reference numeral 622 denotes a display column for displaying the consistency of each block for recording the contents of a file.
FIG. 7 is a block diagram showing hardware according to the first embodiment of the present invention. In FIG. 7, reference numeral 700 denotes a block diagram showing a host and reference numeral 701 denotes a main storage unit. Reference numerals 702 and 703 denote a WORM (Write Once Read Many) control program and a falsification detection program respectively. Reference numerals 704 and 705 denote a processor and a disk interface respectively. Reference numeral 710 denotes a block diagram showing a disk drive and reference numeral 711 denotes a flash ROM. Reference numerals 712 and 713 denote a main memory and a cache memory respectively. Reference numeral 714 denotes a microprocessor (MPU). Reference numeral 715 denotes a hard disk controller (HDC) and an SCSI protocol controller (SPC). Reference numerals 716 and 717 denote a servo controller and a read/write channel.
FIG. 8 is a diagram showing a recording format of a block into the storage medium employed in a disk drive provided by the first embodiment of the present invention. In FIG. 8, reference numeral 800 denotes a block recording-format according to the conventional technology as a reference format. Reference numerals 801 and 802 denote user data and an error correction code respectively. Reference numeral 810 denotes a block recording-format according to the present embodiment and reference numeral 811 denotes a flag area.
FIG. 9 is a diagram showing the data structure of the flag area 811 according to the first embodiment of the present invention. Reference numeral 901 denotes a total operating time of the disk drive 710 and reference numeral 902 denotes the total number of write commands issued to the disk drive 710 . Reference numeral 903 denotes the number of write commands issued to an object sector. Reference numeral 910 denotes the data structure of the flag area 811 as a data structure including only the total operating time 901 . Reference numeral 920 denotes the data structure of the flag area 811 as a data structure including only the total write-command count 902 . Reference numeral 930 denotes the data structure of the flag area 811 as a data structure including the total operating time 901 and the total number write-command count 902 . Reference numeral 940 denotes the data structure of the flag area 811 as a data structure including the total operating time 901 , the total write-command count 902 and the write-command count 903 of the object sector.
FIG. 10 is a diagram showing a directory state transition repository according to the first embodiment of the present invention. FIG. 18 is a diagram showing the data structure of a block for recording meta information of a directory in accordance with the first embodiment of the present invention. In FIG. 18, reference numeral 1801 denotes a column showing file names or directory names and reference numeral 1802 denotes a column showing the inode number of each file or each directory. Reference numeral 1800 denotes a state indicating that there is only one file. Reference numeral 1810 denotes a state indicating that the file name has been changed. Reference numeral 1820 denotes a state indicating that a file has been added. Reference numeral 1830 denotes a state indicating that a file has been deleted.
FIG. 19 is a diagram showing data structures of meta information of a file and showing blocks of a storage medium, in accordance with the first embodiment of the present invention. In FIG. 19, reference numeral 1900 denotes an initial state and reference numeral 1901 denotes information on a file type and information on an access mode. Reference numeral 1902 denotes information on the owner of the file and reference numeral 1903 denotes a timestamp of the file. Reference numeral 1904 denotes the size of the file and reference numeral 1905 denotes the index numbers of each block for recording contents of the file. Reference numeral 1906 denotes the total number of blocks used for recording the contents of the file and reference numeral 1907 denotes the data structure of the inode. Reference numeral 1911 denotes a block for recording the inode of the file and reference numeral 1912 denotes blocks each used for recording contents of the file. Reference numeral 1913 denotes a block containing updated contents of the file and reference numeral 1910 denotes a state obtained after a block has been changed.
FIG. 20 is a diagram showing the data structure of a directory state transition repository according to the first embodiment of the present invention. In FIG. 20, reference numeral 2000 denotes the directory state transition repository and reference numeral 2001 denotes a column showing the value recorded in a flag area of a block for storing meta data of each file serving as the object of the analysis or each directory serving as the object of the analysis. Reference numeral 2002 denotes a column showing the name of a directory to which each file serving as the object of the analysis or each directory serving as the object of the analysis pertains. Reference numeral 2003 denotes a column showing the name of each file serving as the object of the analysis or each directory serving as the object of the analysis. Reference numeral 2004 denotes a column showing the file type of each object of the analysis and reference numeral 2005 denotes a column showing the type of an operation carried out on each file serving as the object of the analysis or each directory serving as the object of the analysis. Reference numeral 2006 denotes a column showing the inode number of each file serving as the object of the analysis or each directory serving as the object of the analysis and reference numeral 2007 denotes a column showing a remark on each file serving as the object of the analysis or each directory serving as the object of the analysis.
Reference numeral 2011 denotes an entry of a file newly added to the directory. Reference numeral 2012 denotes an entry of a file with the name thereof changed. Reference numeral 2013 denotes an entry of a new file added to the directory as a file having a file name identical with the name of a file existing in the past. Reference numeral 2014 denotes an entry of a directory newly added to the directory. Reference numeral 2015 denotes an entry of a file deleted from the directory. Reference numeral 2016 denotes an entry of a directory deleted from the directory. Reference numeral 2017 denotes an entry of a new file added to the directory as a file having a file name identical with the name of a file existing in the past.
FIG. 21 is a diagram showing the data structure of a file state transition repository according to the first embodiment of the present invention. In FIG. 21, reference numeral 2100 denotes the file state transition repository for a specific file and reference numeral 2101 denotes a column showing the value recorded in a flag area of each block for storing meta information of the file. Reference numeral 2102 denotes a column showing the type of each operation carried out on the file. Reference numeral 2103 denotes a column showing the timestamp of each operation carried out on the file and reference numeral 2104 denotes a column showing the index number of blocks each involved in each operation carried out on the file as blocks for recording contents of the file. Reference numeral 2105 denotes a column showing a remark on each operation carried out on the file.
Reference numeral 2111 denotes an entry of a file newly added to the directory. Reference numeral 2112 denotes an entry of a file with the name thereof changed. Reference numeral 2113 denotes an entry of a created file having the same name as a file existing in the past. Reference numeral 2114 denotes an entry of a block added to the file as a block for recording contents of the file. Reference numeral 2115 denotes an entry of a changed attribute of the file. Reference numeral 2116 denotes an entry of blocks each added to the file as a block for recording contents of the file. Reference numeral 2117 denotes an entry of a deleted file. Reference numeral 2118 denotes an entry of the file name of another file as a file name changed to the file name of a file existing in the past. Reference numeral 2119 denotes an entry of changed blocks each used for recording contents of the file.
FIG. 22 is a diagram showing the data structure of an LBA state transition repository provided for blocks specified in the file transition entries of a file state transition repository according to the first embodiment of the present invention. In FIG. 22, reference numeral 2200 denotes the LBA state transition repository and reference numeral 2201 denotes a column showing the index number of each block for recording the contents of the file. Reference numeral 2202 denotes a column showing the LBA of each sector corresponding to the index number of every block.
Reference numeral 2203 denotes an entry including the LBA of every sector for recording the contents of a block indicated by a block number of 204 . In the same way, reference numeral 2204 denotes an entry including the LBA of every sector for recording the contents of a block indicated by a block number of 251 . Likewise, reference numeral 2205 denotes an entry including the LBA of every sector for recording the contents of a block indicated by a block number of 516 . Similarly, reference numeral 2206 denotes an entry including the LBA of every sector for recording the contents of a block indicated by a block number of 538 . By the same token, reference numeral 2207 denotes an entry including the LBA of every sector for recording the contents of a block indicated by a block number of 621 . In the same way, reference numeral 2208 denotes an entry including the LBA of every sector for recording the contents of a block indicated by a block number of 622 . Likewise, reference numeral 2209 denotes an entry including the LBA of every sector for recording the contents of a block indicated by a block number of 623 . Similarly, reference numeral 2210 denotes an entry including the LBA of every sector for recording the contents of a block indicated by a block number of 624 . By the same token, reference numeral 2211 denotes an entry including the LBA of every sector for recording the contents of a block indicated by a block number of 625 . In the same way, reference numeral 2212 denotes an entry including the LBA of every sector for recording the contents of a block indicated by a block number of 961 .
FIG. 23 is a diagram showing a typical screen appearing on the display unit of a console as a screen according to the first embodiment of the present invention. In FIG. 23, reference numeral 2300 denotes a typical display of the console and reference numeral 2301 denotes a row including a problem of consistency. Reference numeral 2302 denotes a row including selected meta information and reference numeral 2303 denotes a row including an LBA having a problem of consistency.
This embodiment is characterized in that a falsification of data stored into the storage medium employed in the disk drive system is detected by analyzing the data by adoption of a method for analyzing the following two types of information:
An outline of the first embodiment of the present invention is explained with reference to FIG. 7.
A host 700 comprises a processor 704 , a main storage unit 701 and a disk interface 705 . The processor 704 executes a WORM control program 702 stored in the main storage unit 701 , issuing a write command to a disk drive 710 by way of the disk interface 705 in order to write received data as data to be stored into a storage medium employed in the disk drive 710 as requested by the user in such a way that the received data is not written over data already existing in the storage medium. The processor 704 executes a falsification detection program 703 to determine whether or not data written into the storage medium of drive 710 in this way has been falsified. The falsification detection program 703 analyzes a time transient of the data in accordance with an algorithm explained by referring to FIGS. 1 to 5 and shows a result of the falsification detection to the user on a screen appearing on the display unit of the console as shown in FIG. 6.
A control program of the disk drive 710 is stored in a flash ROM 711 . When the power supply of an MPU 714 is turned on, the MPU 714 loads the control program from the flash ROM 711 into a main memory 712 . The control program also generates data to be written into a flag area shown in FIG. 8.
An HDC/SPC 715 receives a command from the host 700 and transmits a response to the host 700 . The SPC transmits and receives a command and data in accordance with an SCSI protocol. After a process carried out by the SPC is ended, processing control is transferred to the MPU 714 .
The MPU 714 executes the control program loaded in the main memory 712 to carry out necessary processing to make an access to the storage medium of the HDD (the disk drive 710 ). Write data received from the host 700 and read data read out from the storage medium of the HDD are stored in a cache memory 713 . The main memory 712 is also used for storing variables necessary for generating data to be written into the flag area shown in FIG. 8.
After the MPU 714 completes the processing carried out thereby, the processing control is transferred to the HDC. The HDC issues an instruction specifying a physical block address to a read/write channel 717 . The physical block address has been obtained as a result of an address conversion process carried out by the MPU 714 . Receiving the instruction, the read/write channel 717 carries out a write operation to write data at the physical block address in the storage medium, or a read operation to read out data stored at the address from the storage medium. In the case of a write operation, the read/write channel 717 transfers write data stored in the cache memory 713 to the physical block address along with data generated on the basis of the variables stored in the main memory 712 to the flag area in the storage medium.
In order to make the disk drive 710 capable of writing information based on an internal state of the disk drive 710 into the flag area instead of writing information into the flag area in accordance with a command received from the host 700 , the disk drive 710 is provided internally with:
If the flag area is provided after user data in the data format as shown in FIG. 8, it is necessary to change the recording format in the storage medium. Since the HDC is the component for controlling the recording format, the flag-area generation module is a portion of the HDC employed in the HDC/SPC 715 .
In order to generate the information based on the internal state of the disk drive 710 , the MPU 714 must function as a processor capable of collecting the information and, if necessary, processing the collected information. In addition, in order to reference the information based on the internal state at a later time, it is necessary to preserve the information in a memory. Thus, the internal-state information generation module is implemented by the MPU 714 and the main memory 712 .
In order to write the information based on the internal state into the storage medium employed in the disk drive 710 , it is necessary to carry out a process of transferring the information from a data buffer to the storage medium by controlling a write head. The MPU 714 is the component for writing the information based on the internal state into the cache memory 713 serving as the data buffer. A servo controller 716 is the component for controlling the write head and the read/write channel 717 is the component for carrying out an operation of transferring the information based on the internal state from the cache memory 713 to the storage medium. Thus, the internal-state information write module is implemented by the MPU 714 , the cache memory 713 , the servo controller 716 and the read/write channel 717 .
In the case of a disk drive for carrying out write and read operations by using a block interface, the only apparatus knowing the structure of data written into the storage medium employed in the disk drive is a host that has written the data into the storage medium. Thus, in order to detect the existence of a falsification of the data written into the storage medium employed in the disk drive, it is necessary to execute a falsification detection analysis program understanding the structure of the data written by the host after keeping a history of all write operations in the disk drive.
In order to preserve the history of all write operations in the disk drive, it is necessary to write data into the storage medium employed in the disk drive by execution of WORM control for recording new data into a free area on the storage medium so as to prevent existing data from being overwritten. The WORM control can be executed in two ways, i.e., execution in the disk drive and execution in the host.
The execution of the WORM control in the disk drive offers a merit in which the history of write operations can be kept in the disk drive with a high degree of reliability even if the host issues a write command to the disk drive to write new data over data already existing in the storage medium employed in the disk drive. However, the execution of the WORM control in the disk drive has a demerit in which, if the host writes data into a storage medium employed in the disk drive without being aware of a WORM condition, an access performance will deteriorate due to processing such as an address conversion process carried out in the disk drive.
The execution of the WORM control in the host offers a merit of no access-performance deterioration. However, the execution of the WORM control in the host has a demerit in which data can be falsified with ease due to the fact that new data can be written over data already existing into the storage medium employed in the disk drive.
In this embodiment of the present invention, the host executes the WORM control in an operation to write data into the storage medium employed in the disk drive. Since the disk drive is capable of detecting an operation to write data over data already existing in the storage medium, however, the embodiment has the effect of an ability to detect a falsification without relaying on an outside authenticator as is the case with the method disclosed in Japanese Patent Laid-open No. 11-261550. In addition, since the format of data to be written into the storage medium employed in the disk drive is not limited to the format compatible with the file system, unlike the method disclosed in Japanese Patent Laid-open No. 10-283262, the embodiment has the effect of an ability to detect a falsification even for an arbitrary application other than the file system. On the top of that, the method provided by the present embodiment can be applied with ease to not only a case in which the host executes the WORM control in an operation to write data into the storage medium employed in the disk drive, but also to a case in which the disk drive executes the WORM control in an operation to write data in the storage medium employed in the disk drive.
Furthermore, even though a method to detect a falsification in a file system in accordance with this embodiment is explained, the method to detect a falsification can also be applied to any arbitrary data other than the file system as long as the data is data recorded in a logical structure. An example of such data is a database.
With reference to FIGS. 1 to 4 , the following description explains a method of tracing a write history required for falsification detection based on a file system. In an operation to trace a write history of data, which was written on a storage medium in a disk drive, in an order the data was written thereon, and an operation to detect a falsification of the data, the value of each LBA (Logical Block Address) completing an analysis and a result of the analysis are stored. Thus, another analysis can be started as a continuation of the analysis, which is an analysis immediately preceding the other analysis. By suspending and resuming an analysis in this way, it is necessary to merely analyze only the contents of a file newly stored in the storage medium employed in the disk drive. Thus, there is demonstrated the effect of an ability to shorten the analysis time.
Since an analysis is suspended and resumed as described above, at the step 110 described before, a work area allocated in the storage medium employed in the disk drive 710 as an area used specially for detecting a falsification is examined to determine whether or not a result of an analysis made previously has been saved in the area. If a result of an analysis made previously has been saved in the work area, the PAD flow goes on to the step 111 . If no result of an analysis made previously has been saved in the work area, on the other hand, the PAD flow goes on to the step 113 . At the step 111 , the result of an analysis made previously is fetched. Then, at the next step 112 , analysis resumption information required for resuming the analysis is fetched and a seek operation is carried out to position the head at the LBA of a continuation of the immediately preceding analysis. The analysis resumption information includes at least the value of an LBA for which the setting of an analysis program and an analysis by using the program have been completed.
If no result of a previous analysis has been saved in the work area, the analysis program can be assumed to be in a state of being never executed even once. In this case, steps 113 , 114 and 115 are executed to set the analysis program. An analysis program is required for every data format, that is, for every file system kept in the disk drive 710 . A process of providing an analysis program for every file system stored in the disk drive 710 takes a very large number of man-hours. In order to solve this problem, the analysis program is divided into two portions, i.e., (1) a definition portion for defining the data structure of a file system and (2) a search portion based on the definition of every defined data structure. In this way, a definition portion is prepared for every file system but only one search portion common to all file systems is required. At the step 113 , the data structure of a file system is loaded from a volume included in the disk drive 710 as a volume serving as the object of the analysis into a parameter area allocated in the main storage unit 701 as an area for the falsification detection program 703 . Then, at the next step 114 , the falsification detection program 703 inputs the data structure loaded at the step 113 . Finally, at the next step 115 , a seek operation is carried out to position the head at the beginning of the volume serving as the object of the analysis.
At the step 120 , a loop is executed in an LBA (Logical Block Address) range of a block already completing a write operation in the storage medium employed in the disk drive. The loop is executed to make an analysis in dependence on whether the write operation carried out on the block is a directory operation, a file operation or a block operation. This is because write operations carried out on a block through a file system can be classified into the following three categories:
One of the three categories can be uniquely determined by a data structure loaded at the step 113 as a category to which a write operation carried out on a block pertains. At the step 121 , the write operation carried out on the block is examined to determine whether or not the write operation is a directory operation. If the write operation carried out on the block is a directory operation, the PAD flows go on to the subroutine 130 . At the step 122 , the write operation carried out on the block is examined to determine whether or not the write operation is a file operation. If the write operation carried out on the block is a file operation, the PAD flows go on to the subroutine 140 . At the step 123 , the write operation carried out on the block is examined to determine whether or not the write operation is a block operation. If the write operation carried out on the block is a block operation, the PAD flows go on to the subroutine 150 . Finally, if the write operation carried out on the block is not a directory operation, a file operation and a block operation, the write operation can be interpreted as a generated error. In this case, the PAD flow goes on to the step 119 at which the error is recorded. After the analysis in the loop executed at the step 120 is ended for all LBAs each completing a write operation, the PAD flow goes on to the step 116 at which a location for saving a result of the analysis is allocated. Then, the PAD flow goes on to the step 117 at which the result of the analysis is saved. Eventually, the PAD flow goes on to the step 118 at which information necessary for resuming the analysis is saved.
To put it in detail, at the step 116 , a location for saving the result of the analysis is allocated in the work area allocated in the storage medium employed in the disk drive 710 as an area specially used for detecting a falsification of data. Then, the PAD flow goes on to the step 117 . At the step 117 , the analysis result for the volume analyzed in the loop executed at the step 120 is stored at the location allocated at the step 116 in the work area. Then, the PAD flow goes on to the step 118 . At the step 118 , information necessary for resumption of the analysis from an LBA, for which the present analysis has been completed, is saved at the location allocated at the step 116 in the work area in order to allow the next analysis to be made. The information saved as information necessary for resumption of the analysis includes at least the data set in the analysis program at the step 114 and the value of an LBA completing the analysis made in the loop executed at the step 120 .
The subroutine executed at the step 130 searches the directory structure for a change in directory structure as a change made through the file system. Such a change in directory structure is made as a result of creation of a file or a directory, deletion of a file or a directory or modification of the name of a file or a directory. In order to recognize a generated change in directory structure, it is necessary to check into an updating command issued by the host for a block for recording meta information as information for managing directory entries. Since all updating substances are recorded in the disk drive serving as the target of a write operation carried out by execution of the WORM control, it is possible to determine what operation has been carried out by comparison of data before the modification with data after the modification. If a change in directory structure is recognized, the substance of the change is recorded in a directory state transition repository for managing such changes.
At the steps 140 and 150 , changes in file contents are checked. A time transient of a block for recording the changed contents is recorded in a file state transition repository.
Development of a program for manipulating a file by using a text editor and an RCS (Revision Control System) is used as an example in explanation of the directory state transition repository. FIG. 10 is a diagram showing the progression of a directory state transition repository along the time axis. In this figure, time lapses in the downward direction. Every solid-line arrow represents the event of a directory operation that can be detected from a falsification detection algorithm. On the other hand, every dashed-line arrow represents the event of a directory operation that can be determined from an application in use.
At a stage of saving a file named for the first time by using a text editor, a CREATE event is cataloged in a foo.c entry. Then, when a file named foo.c is updated and saved by using a text editor such as Emacs, the name of the pre-updating file is changed to foo.c˜˜and the file named foo.c˜is also saved. Thus, a new foo.c˜entry is created and a CREATE event is cataloged in the foo.c˜entry as an event of renaming the file from foo.c to foo.c˜. Then, when the file named foo.c is again updated, the file named foo.c˜is deleted once, the name of the already existing pre-updating file is changed to foo.c˜and the file named foo.c is saved. Thus, in the foo.c˜entry of the directory state transition repository, a REMOVE event is cataloged as an event of deleting the file named foo.c˜, and a CREATE event is also cataloged as an event of renaming the file named foo.c to foo.c˜.
In development of a program, the RCS manages versions of the file for storing the program. In the RCS, a check-in operation caused the item of an original file to be deleted from an RCS file for storing a history of the file. Subsequently, when the file is edited, a check-out operation fetches the file from the RCS file. A check-in operation catalogs a CREATE event in an foo.c,v entry of the directory state transition repository and a REMOVE event in the foo.c entry of the directory. In a check-out operation, the name of the user fetching the file and information on the fetching time and others are cataloged in the RCS file. In order to prevent an original file from being lost due to an accident in the course of an operation to write data into the file, the original file is saved as a file having a different name. Then, after the data has been written into the file normally and the normal write operation has been verified, the saved original file is discarded. Thus, a CREATE event is cataloged in a foo.c,v˜entry of the directory state transition repository as an event of renaming the original file to the other name. Then, after a CREATE event is cataloged in the foo.c,v entry of the history, a REMOVE event is cataloged in a foo.c,v˜entry of the history.
With reference to FIGS. 18 and 19, the following description explains the format of data stored into the storage medium employed in the disk drive as a format conforming to the file system. FIG. 18 is a diagram showing the data format of a block included into the storage medium employed in the disk drive as a block for storing meta information of a directory. The data format is a structure comprising entries each consisting of a pair of the name 1801 of a file in the directory or the name of the directory and an inode number 1802 of an inode for keeping the meta information for the file or the directory.
Reference numeral 1800 denotes the data format of an initial state indicating that only one file named foo.c exists in the directory. Reference numeral 1810 denotes the data format of a state after the name of the file has been changed from foo.c to foo.c˜. Since the contents of the file do not change even after the file is renamed, the inode number serving as an index to an inode for recording the meta information for the file also remains the same as well. Reference numeral 1820 denotes the data format of a state after a file named foo.c is added to the directory. Even though the name of the added file is the same as the file name in the data format 1800 , a new inode number assigned to the added file is different from the inode number of the file named foo.c in the data format 1800 . This is because the contents of the added file are different from those of the file named foo.c in the data format 1800 . Reference numeral 1830 denotes the data format of a state after the file named foo.c˜is deleted from the directory.
FIG. 19 is a diagram showing data structures of meta information of a file and showing blocks of a storage medium. Reference numeral 1911 denotes a block for recording the inode of the file. User data 801 of the block 1911 includes the inode stored therein. Reference numeral 1907 denotes the data structure of the inode. Reference numeral 1900 denotes a pre-updating state of the contents of the file and reference numeral 1910 denotes a post-updating state of the contents of the same file. A flag area 811 is attached to each of blocks 1911 to 1913 .
Reference numeral 1901 denotes information on an access mode determining a file type and a permission type. The file type includes a directory, a file or a symbolic link. On the other hand, the permission type can be read permission, write permission or execute permission. Reference numeral 1902 denotes information on the owner of the file and reference numeral 1903 denotes timestamps of the file. The recorded timestamps of the file include three kinds of time, i.e., a most recent time to read out the contents of the file, a most recent time to write data into the file and a most recent time to update the inode of the file. Reference numeral 1904 denotes the size of the file and reference numeral 1905 denotes the index number of each block for recording contents of the file. The index numbers 1905 can each be used for identifying one of blocks 1912 for recording the contents of the file. Reference numeral 1906 denotes the total number of blocks used for recording the contents of the file.
In order to update the contents of the file, it is necessary to update a block for recording contents like a block 1913 . When the index number 1905 of a block is changed or a block for recording contents of the file is added, the index number 1905 of the block needs to be updated. In this case, the file-updating time included in the timestamps 1903 to update the file is also changed. In addition, the inode-updating time is changed as well.
It is to be noted that the structure of the file system determines which block is used as a block for storing information corresponding to the inode number. By the same token, the structure of the file system also determines which sector in the HDD is used as a sector for storing the index number of a block.
FIG. 20 is a diagram showing the data structure of a directory state transition repository. In FIG. 20, reference numeral 2001 denotes a column showing a result of sorting the values stored in flag areas. From an analysis of blocks each having a data structure shown in FIG. 18 and meta information stored in the blocks as shown in FIG. 19, data is organized to form entries (or rows) in the directory state transition repository. Every entry includes data as below. Reference numeral 2002 denotes the name of a directory to which a file (or a directory) serving as the object of the analysis pertains. Reference numeral 2003 denotes the name of the file or the directory. Reference numeral 2004 denotes a file type, which can be a file or a directory. Reference numeral 2005 denotes the type of an operation carried out on the file or the directory. Reference numeral 2006 denotes the inode number of the file or the directory. Reference numeral 2007 denotes what is known at an analysis time as a remark on the file or the directory. The file or the directory is associated with the value 2001 recorded in a flag area 811 of a block for storing the meta information (the inode) of the file or the directory. A directory name 2002 and a name 2003 in the same entry as the directory name 2002 can be used for identifying a file or a directory in the file system.
For example, an entry 2011 includes data for a new file, which did not exist in the directory state transition repository so far. In the case of this entry, the operation type 2005 is CREATE and the remark 2007 states “new file.” By the same token, an entry 2014 includes data for a new directory. In the case of this entry, the operation type 2005 is CREATE and the remark 2007 states “new dir.” An entry 2012 includes data representing a change of a file name. Even if a file name is changed, the inode number remains the same. Thus, it is possible to identify a file (or a directory), the name of which has been changed from a file name to another. In the case of the entry 2012 , the file name has been changed from foo.c to foo.c˜newly set as the file name 2003 with “SRC foo.c” described in the remark 2007 to indicate that the original file name is foo.c. For indicating this change of the file name, RENAME is set as the operation type 2005 . An entry 2015 includes data representing deletion of a file. In this case, REMOVE is set as the operation type 2005 .
FIG. 21 is a diagram showing the data structure of a file state transition repository. In particular, this figure shows the file state transition repository for the /src/foo.c file represented by data in an entry of the directory state transition repository shown in FIG. 20. An entry 2111 corresponds to the entry 2011 . The entry 2111 includes data representing creation of a new file named /src/foo.c. A flag 2101 is the value recorded in a flag area 811 of a block for recording meta information (or the inode) of the file. Reference numeral 2103 denotes the value of a timestamp 1903 included in the meta information of the file. FIG. 21 shows timestamps each including only an updating time of the file due to a limited space. In actuality, the timestamp 1903 includes all the aforementioned pieces of timestamp information. Reference numeral 2104 denotes the value of an index number 1905 pointing to a block for recording contents of the file. A remark 2105 states “new file” indicating creation of a new file.
By the same token, an entry 2112 corresponds to the entry 2012 . The entry 2112 includes data representing a state indicating that the file name /src/foo.c has been changed to /src/foo.c˜. An operation type 2102 of this entry 2112 is thus RENAME. The remark 2105 states “DST foo.c˜” indicating that the post-change file name is foo.c˜. In the same way, an entry 2113 corresponds to the entry 2013 . The entry 2113 includes data representing a state indicating that a new file with a file name of /src/foo.c has been created. An entry 2114 includes data representing a state indicating that blocks for recording contents of a file have been added. In this entry, the operation type 2102 , the time stamp 2103 and the block index number 2104 are respectively UPDATE, a file-updating time and the index numbers of the added blocks. The remark 2105 states ADD BLK indicating that blocks have been added. An entry 2115 includes data representing a state indicating that an attribute of the file has been changed. An example of the attribute is an access mode. In this entry, the operation type 2102 is UPDATE and the remark 2105 states MOD ATTR. Since the timestamp 2103 in the entry 2115 also shows only the attribute-updating time, the shown attribute-updating time is the same as that of the entry 2114 . However, the timestamp 2103 in the entry 2114 shows an inode-updating time. An entry 2117 includes data representing a state indicating that the file has been deleted. The operation type 2102 in this entry states REMOVE. An entry 2118 includes data representing a state indicating that a file name of /src/baz.c has been changed to the file name of /src/foo.c. In this entry, the operation type 2102 is RENAME and the remark 2105 states SRC baz.c. An entry 2119 includes data representing a state indicating that blocks for recording contents of the file have been replaced. In this entry, the operation type 2102 is UPDATE and the remark 2105 states MOD BLK. After the blocks have been replaced, the index numbers 2104 of the replaced blocks are recorded in the entry.
In a state transition from the entry 2117 to the entry 2118 , the file has been replaced with the timestamp 2103 of the entry 2118 remaining unchanged from that of the entry 2117 . The same timestamps indicate that it is quite within the bounds of possibility that the file has been falsified by file replacement. By the same token, the fact the timestamp of the entry 2119 remains the same as that of the entry 2118 suggests that it is quite within the bounds of possibility that the file has been falsified by block replacement.
FIG. 22 is a diagram showing the data structure of an LBA state transition repository provided for blocks inside a file state transition repository. To be more specific, the LBA state transition repository shown in FIG. 22 is a history provided for blocks inside the file state transition repository shown in FIG. 21. Reference numeral 2201 denotes a column showing the index number of each block. Associated with the index number 2201 , reference numeral 2202 denotes a column showing the LBA of each sector in a hard disk employed in the HDD. A block corresponds to 4 sectors. In addition to the LBAs, the column 2202 also shows the values stored in flag areas 811 each associated with one of the LBAs.
Data included in the file state transition repository shown in FIG. 21 is obtained as a result of an analysis made at a meta-information level of the file, while data included in the LBA state transition repository shown in FIG. 22 is obtained as a result of an analysis made at an LBA level of the hard disk mounted on the HDD. Thus, even if data stored in a sector of a hard disk employed in the HDD is changed without going through the file system, the falsification can be detected. For example, look at an entry 2212 . In this entry, the value recorded in a flag area 811 for an LBA of 3078 assigned to one of the four sectors composing a block does not exhibit continuity with respect to the values for the remaining sectors. This discontinuity obviously indicates that it is quite within the bounds of possibility that a falsification has been made with regard to the LBA of 3078 .
FIG. 22 shows only a post-falsification state of the entry 2212 for a block of 961 . By carrying out the process to detect a falsification periodically and saving the directory state transition repository shown in FIG. 20, the file state transition repository shown in FIG. 21 as well as the LBA state transition repository shown in FIG. 22, however, both states before and after a falsification at an LBA can be recorded in the LBA state transition repository.
At the step 201 of the subroutine executed at the step 130 in FIGS. 1 and 2, a pre-change state of meta information is compared with a post-change state thereof. Meta information of a directory can be identified by using an identifier of the directory. Thus, pieces of meta information recorded previously are searched for a piece having the same identifier as the object of the analysis, and the meta information found in the search is compared with that of the object of the analysis. This comparison can be carried out due to the fact that data has been written on the storage medium employed in the disk drive by execution of the WORM control. After a point of change is detected in the comparison, the PAD flow goes on to the step 210 . At the step 210 , a result obtained at the step 201 is examined to determine whether or not a file has been newly created. If a file has been newly created, the PAD flow goes on to the step 211 . After the processing of the step 210 is ended, the PAD flow goes on to the step 220 .
As described above, if data is saved in an existing file by an application, the contents of the existing file are left in a file serving as a backup with a file name different from the old name of the existing file so that the existing file becomes a file for recording new contents by retaining the old name in some cases. Thus, in order to detect a falsification of a file having an old name, it is necessary to trace operations to update the file. At the step 211 , in order to implement this method of tracing operations to update a file, the file transition entries of the directory state transition repository are searched for the same file name existing in the past. After the search is completed, the PAD flow goes on to the step 212 . At the step 212 , the search result obtained at the step 211 is examined to determine whether or not the same file name existed in the past. If the same file name existed in the past, the PAD flow goes on to the step 213 . If the same file name did not exist in the past, on the other hand, the PAD flow goes on to the step 215 . For example, assume that data is written into an existing file named A, and the previous contents of the file named A are retained in a new file named A.BACKUP. In this case, at the step 213 , a state indicating that a new file named A has been created is added to existing file transition entries included in the directory state transition repository as a new entry for the existing file named A. In addition, an entry indicating that the name of the existing file has been changed from A to A.BACKUP is added to the directory state transition repository.
If an analysis of blocks is made in an order the blocks were written into the storage medium employed in the disk drive, file transition entries of the directory state transition repository can be traced only in the order the files were updated. If it is desired to determine whether or not a specific file has been falsified, however, tracing the file from the most recent state to previous states is convenient. Thus, at the next step 214 , a reference remark is added to the file transition entry added at the step 213 as a remark indicating an opposite direction of the file tracing from the state indicated by the file transition entry added at the step 213 to the preceding state. At the next step 215 , a new file transition entry for the new file is created in the directory state transition repository to indicate that the new file has been created.
At the step 220 , a comparison result obtained at the step 201 is examined to determine whether or not a file has been deleted. If a file has been deleted, the PAD flow goes on to the step 221 . After the step 220 is ended, the PAD flow goes on to the step 230 . At the step 221 , a state indicating that a file has been deleted is added as a file transition entry to the directory state transition repository. Then, the PAD flow goes on to the step 214 . At the next step 214 , a reference remark is added to the file transition entry as a remark indicating an opposite direction of the file tracing from the state of a deleted file to the preceding state.
At the step 230 , a comparison result obtained at the step 201 is examined to determine whether or not the name of a file has been changed. If the name of a file has been changed, the PAD flow goes on to the step 211 . At the step 211 , the file transition entries of the directory state transition repository are searched for the same file name existing in the past. After the search is completed, the PAD flow goes on to the step 212 . At the step 212 , a search result obtained at the step 211 is examined to determine whether or not the same file name existed in the past. If the same file name existed in the past, the PAD flow goes on to the step 231 . If the same file name did not exist in the past, on the other hand, the PAD flow goes on to the step 215 . At the step 231 , a state indicating that a file name has been changed from one to another is added as a file transition entry to the directory state transition repository. At the next step 214 , a reference remark is added to the file transition entry added at the step 231 as a remark indicating an opposite direction of the file tracing from the state indicated by the file transition entry added at the step 231 to the preceding state. Then, at the next step 215 , a new file transition entry for the new file is created in the directory state transition repository to indicate that the name of a file has been changed from one to another. After the step 230 is ended, the PAD flow goes on to the step 202 . At the step 202 , a seek operation to find the next block is carried out.
In the subroutine executed at the step 140 of FIG. 1, meta information used as management information of the file is checked for a change. The management information of a file includes a correction time of the file and the value of the LBA of each block for storing contents of the file. Much like the subroutine executed at the step 130 , the pre-updating contents of a block for storing meta information are compared with the post-updating contents of the block to determine what kind of updating has been carried out. At the step 301 of the subroutine executed at the step 140 of FIGS. 1 and 3, a state existing before updating of meta information of the file is compared with a state existing after the updating of the meta information. The meta information of a file can be identified by using the identifier of the file. Thus, pieces of meta information recorded previously are searched for a piece having the same identifier as the object of the analysis, and the meta information found in the search is compared with that of the object of the analysis. This comparison can be carried out due to the fact that data has been written on the storage medium employed in the disk drive by execution of the WORM control. After the step 301 is ended, the PAD flow goes on to the step 310 . At the step 310 , a change point recognized at the step 301 is examined to determine whether or not the meta information of the file has been updated. If the meta information of the file has been updated, the PAD flow goes on to the step 311 . At the step 311 , a state indicating the change point of the meta information used as the management information is added as a new file transition entry to the directory state transition repository. As described above, examples of the management information include a correction time of the file and the value of the LBA of each block for storing contents of the file.
The meta information of a file is information, which is updated every time an access is made to the file. Thus, in order to enhance the performance of the file system, the meta information is normally stored in a cache memory of the host. In consequence, it is quite within the bounds of possibility that, at a stage of saving contents of a file in a block, the meta information stored in the cache memory is not reflected in the block. Thus, if an analysis of the contents of a block is made by execution of the WORM control in an order the contents were written into the storage medium employed in the disk drive, in some cases, it is impossible to determine which file includes contents stored in the block. In order to solve this problem, this embodiment is provided with two different types of repository for managing an LBA in dependence on whether or not it is possible to identify which file includes contents stored at the LBA from the meta information.
If it is possible to identify which file includes contents stored at an LBA from the meta information, the LBA is managed by using an LBA state transition repository provided for blocks specified in the file state transition repository. The LBA state transition repository provided for blocks specified in the file state transition repository is used for cataloging changes with regard to such LBAs every time the contents of the file are updated. If it is impossible to identify which file includes contents stored in a block at an LBA from the meta information, on the other hand, the LBA is cataloged in an LBA state transition repository for managing only such LBAs. Then, as will be described later, at a certain stage, it becomes possible to identify which file includes contents stored at such an LBA. At this stage, the entry for such an LBA is moved from the LBA state transition repository for managing only such LBAs to the LBA state transition repository provided for blocks specified in the file state transition repository.
After the step 311 is ended, the PAD flow goes on to the step 312 at which the LBA state transition repository for managing only LBAs of blocks each used for storing contents of an unidentifiable file is searched for an LBA block entry including an LBA in meta information. After the step 312 is ended, the PAD flow goes on to the step 313 to determine whether or not the LBA in meta information has been found in the search. If the LBA in meta information has been found in the search, the PAD flow goes on to the step 314 . At the step 314 , the entry of the LBA found in the search is moved from the LBA state transition repository for managing only LBAs of blocks each used for storing contents of an unidentifiable file to the LBA state transition repository provide