JP2009140142A - Journal file system and its repair method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To repair a file wherever possible within a time permitted for file repair, or within the limit of it. <P>SOLUTION: The journal file system and its repair method are achieved by a storage device in which a file and meta data ranked according to significance and journal as update content in the middle of the update of a file are stored and a computer which successively repairs the meta data of the file by using the journal successively from the file ranked in a high order within the limit of a prescribed time in response to restart accompanied by stop in the middle of file update. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a journal file system and a repair method thereof, and more particularly, to a journal file system and a repair method thereof for repairing a predetermined time.

  A general file system has metadata which is file management information. When updating a file, it is necessary to update not only the user data that is the contents of the file but also the metadata related to the file. The journal file system records the updated contents of the metadata in the journal when the file is updated. Journal file when the system is stopped due to a failure, etc. during file update, and the file and metadata in the (cache) memory of the computer are lost or corrupted, making the file and metadata inconsistent. Based on the journal, the system reconfirms the file and metadata, and repairs the file.

  In order to repair the file in this way, the update content is recorded in a journal secured in a non-volatile storage device such as a magnetic disk device before responding to the file update request. There are two problems in the journal file system. One is that the update contents of the file are not reflected in the file and metadata entities on the magnetic disk device, etc., so the repair target will be longer if there are many such repair targets. It is a problem that affects the operation of the system. The other is to record the update contents in a journal on a magnetic disk device, etc., and then reduce the effect of speeding up the performance using the (cache) memory of the computer to respond to the file update request. The problem is that the performance of the file system depends on the input / output performance of a magnetic disk device for recording in a journal.

  In response to the above-mentioned one problem, Patent Document 1 describes the update contents of a file in a journal by the control device of a storage system such as a magnetic disk device that stores the substance and journal of the file and metadata. The technology to be reflected in the entity is disclosed.

  In response to the other problem, Patent Document 2 selects an object that can be repaired within a time allowed for repair, and logs the selected object as a target, thereby reducing a decrease in execution performance. Is disclosed.

US Patent Publication USP 7,047,355 JP-A-6-175900

  The technology disclosed in Japanese Patent Laid-Open No. 2004-228561 uses a control device when a RAID (Redundant Array of Inexpensive Disks) system having a control device that realizes various functions with high performance is used as a device for storing journal and file entities. It is feasible in general and is difficult to accept for general offices and individuals.

  The technique disclosed in Patent Document 2 gives priority to restoration time and execution performance, and generates a new problem that a file that does not take a log is not likely to be restored.

  Therefore, it is necessary to repair the file as much as possible within the time allowed for the file repair or as a target.

  The journal file system and the repair method thereof according to the present invention accompany a storage device that stores files and metadata that are rated according to importance and a journal that is an update content during file update, and a stop during file update. In response to the restart, this is realized by the configuration of the computer and the operation of the computer that repair the file using the journal sequentially from the higher-ranked file with a predetermined time as a target.

  According to the present invention, a file can be repaired as much as possible within the time allowed for file repair or as a target.

  The best mode for carrying out the present invention will be described below in detail with reference to the drawings.

  First, journal recording and restoration of a file system using a recorded journal in a journal file system which is a premise for carrying out the present invention will be described.

  FIG. 1 is a diagram for explaining recording in a journal log (hereinafter simply referred to as a journal), which is the main point of the journal file system. A file metadata management area 20, an area 30a, and a journal area 40 are provided in the storage device 10 for storing files.

  A case where the file A is created in the area 30a will be described as an example. First, “Journal 30a is in use for file A” is recorded in the journal area 40. The state of the recorded journal area 40 is shown in 40a. In the metadata management area 20, metadata “area 30 a is used for file A” is stored. When file data is written as file A, the file data is written into area 30a.

  Here, the journal file system generally behaves as if writing metadata into the metadata area 20 on the non-volatile storage device 10 such as a disk device and writing file data into the area 30a. The metadata area 20 on the storage device 10 is simply written to the (cache) memory of the computer (not shown) on which the journal file system operates, and is later read from the (cache) memory by the OS (operating system) of the computer. And written in the area 30a. A journal for repairing the file is stored in the storage device 10, and the journal file system responds to the file update request after confirming the storage of the journal.

  If the data is written in the metadata area 20 and the area 30a on the storage device 10 by the OS, even if the computer is stopped, the data is retained, so that there is no need for restoration. If this situation occurs, the journal replay start position (pointer) in the journal area is shifted (40b), and those data are excluded from the restoration target.

  The problem here is that if the data is stored in the memory of the computer and not written in the storage device 10 and the computer is stopped due to a power failure or the like, the data in the memory is lost.

  A file system repair, which is a response to this problem, will be described with reference to FIG. Following the situation of FIG. 1, assume that file B is created in area 30b of FIG.

  In the journal area 40, “area 30b is in use for file B” is recorded. The state of the recorded journal area 40 is shown in 40c. In the metadata area 20, metadata “area 30 b is used for file B” is stored. When file data is written as file B, the file data is written into area 30b.

  As described above, it is assumed that at least one of the metadata and the file data of the file B is in the memory and is not written in the storage device 10, and it is assumed that the computer is stopped due to power interruption or the like in this state. At least one of the metadata of file B and the file data in memory is lost.

  When the computer is restarted, it becomes clear from the state 40c of the journal area 40 that the area 30b has been allocated to the file B. Depending on the journal file system, the journal data may be data corresponding to metadata, or data corresponding to both metadata and file data.

  In the former case, the metadata of the file B is restored using the journal, but the file data corresponding to the restored metadata is not restored. That is, the metadata and the file data are not matched. However, the file data is not restored, but since the metadata is restored, the area 30b allocated to the file B can be accessed from the journal file system. In the latter case, the metadata and the file data are restored in a consistent state.

  Embodiments will be described below with reference to the drawings. FIG. 3 shows the configuration of a system having a journal file system.

  When a user program being executed by the processor 113 accesses a file or directory on the disk device 115, the request is transferred to the disk device 115 via the disk interface 114.

  In this embodiment, the system is a system in which one server and one disk device are connected, but a system in which a plurality of servers and a plurality of disk devices are connected may be used. The processor 113 of the server 101 includes a file access process 104, a file creation process 105, a file deletion process 106, an upgrade determination process 107, a rating setting process 108, a file system restoration process 109, a file restoration, which are programs 103 stored in the memory 102. The predicted time calculation process 110, the upgrade process 111, the downgrade process 112, and the user notification process 121 are executed. These processes are the main processes of this embodiment, and there are a plurality of processes below these processes. On the disk device 115, a file information table 116, a repair file list 117, a definition list 118, a file repair prediction time management table 119, and a notification information management table 120 are stored.

  Note that the metadata area, the file storage area, and the journal area provided on the disk device 115 described in FIGS. 1 and 2 are not shown.

  FIG. 4 is a file information table 116 that holds information on files to be repaired. The file information table 116 is stored in the disk device 115. The file information table 116 holds a file path name 201, an access count 202, an access user 203, and a rating 204 which is a file importance attribute. The file path name 201 is position information of files and directories. . The access count 202 is the total number of times that the user program has created, updated, and changed attributes of files and directories. The access user 203 is the name of the user who accessed the file. The rating 204 is a file importance attribute (A, B, or C).

FIG. 5 shows a repair file list 117 that stores file path names to be repaired when the file system is repaired. When the user program starts processing for creating, updating, or changing attributes of a file or directory, the file path name 210 of the file to be processed is stored in the repair file list 117. When these processes are completed, the file path name 210 of the file to be processed is deleted from the repair file list 117. The rating 211 is a rating corresponding to the file path name of the file to be processed, and the rating 204 stored in the file information table 116 is stored. FIG. 6 is predefined by the system administrator (Administrator or root) A definition list 118 having definition items 220 and definition contents 221. Based on this definition, the rating is determined as the importance attribute of the file or directory. Files and directories whose cumulative access count exceeds the defined access count, and files and directories that exceed the defined access user count are targets for upgrading the importance attribute of the file. The specified repair time is a target value for the file system repair time.

  FIG. 7 shows a file repair prediction time management table 119, which stores the number of repair files 231 and the file repair prediction time 232 in the previous and current file system repairs as the repair sequence 230. The predicted file repair time 232 is a predicted repair time per file.

  FIG. 8 is a notification management information table 120 that stores information for notifying the owner of a repaired or deleted file. The notification management information table 120 includes a file path name 240 of a file that has been repaired or deleted, an owner 241 of the file, a flag 242 that indicates whether the file has been repaired or deleted, and that registered in the notification management information table. A generation number 243 indicating whether the current operation or the previous operation is held.

  The generation number 243 is 0 for the current operation and 1 for the previous operation. If the generation number is 1 or more, the file has been repaired. When a file is repaired, the file path name, file owner, repair flag, and generation number to be repaired are stored in the notification information management table 120. At this time, 0 is stored in the generation number 243.

  When deleting a file, the file path name, file owner, deletion flag, and generation number to be deleted are stored in the notification information management table 120. Generation number 243 stores 0.

  FIG. 9 shows journal file system activation processing after computer system activation (not shown in FIG. 1). The journal file system may be automatically activated with the activation of the computer system, or may be activated by a command or the like.

  It is determined whether the file system needs to be repaired (step (hereinafter, S) 600). If an inconsistency between a file in the journal file system and metadata is detected due to an event such as an emergency system stop, it is determined that the file system needs to be repaired. In general, as described with reference to FIG. 2, whether or not the file system needs to be repaired is determined based on the presence or absence of journal data whose metadata or file data is not reflected in the respective entities in the storage device 115 at this time. If unnecessary, the journal file system activation process is terminated.

  If the file system needs to be repaired, a file system repair process (described later) is executed (S605). 1 is added to the generation number 243 of the notification information management table 120 (S610). If a plurality of rows are stored in the notification information management table 120, 1 is added to the generation number 243 of each row. When a file is repaired or deleted by executing file system repair processing, the file path name of the notification information management table 120 is changed according to whether the flag 242 of the notification information management table 120 is repaired or deleted. Get file name from 240 and output to log. In addition, a notification 606 is sent to the file owner 241 of the notification information management table 120 by e-mail (S615). The notified generation number 243 of 1 or more is deleted from the notification information management table 120 (S620).

  FIG. 10 shows the file creation process 104. Based on a file or directory creation request by a user program or command, execution of file creation processing is started. Registration processing (described later) in the repair file list 117 is executed (S700), and a file information table 116 is assigned (S705). One line is prepared in the file information table 116 shown in FIG. 4 for each file or directory. An update history of metadata updated as the file is created is recorded in the journal (S710).

  In the present embodiment, the journal recording is described in a journal file system in which the metadata update history is recorded in the journal and the file data update history is not recorded in the journal. As described with reference to FIG. 1, the file data is described as a journal file system that is stored in the (cache) memory and stored in the storage device 115 at the same time when the file creation is completed.

  The file path name 201, the access count 202, and the access user 203 in the file information table 116 are recorded in the file and directory positions to be created (S715). When a rating setting process (described later) is executed (S720), the rating 204 of the file information table 116 is recorded.

  A file and a directory are created (S725). As described with reference to FIGS. 1 and 2, when the creation or update of the file and directory is completed, the file data and metadata in the memory are reflected in the storage device 115 (file data and metadata in the storage device 115). The file data and metadata created or updated on the memory are written into the data real area (not shown in this step).

  Even if the computer stops for some reason at this stage, the created files and metadata are no longer lost, so the process of deleting the contents of the repair file list registered in step 700 (described later) is executed (S730). The metadata update history recorded in the journal is deleted from the journal. Deletion of the update history of the metadata recorded in the journal from the journal is realized by shifting the pointer as described with reference to FIG.

  FIG. 11 shows the file access process 104. A file access process 801 is a process of writing or reading a file, or changing a file attribute. Based on the file access request by the user program or command, the execution of the file access process is started.

  A process of registering in the repair file list (described later) is executed (S800), and an update history of metadata that needs to be updated as the file is accessed is recorded in the journal (S805).

  The access count and access user of the element matching the file path name of the file and directory to be accessed and the file path name of the file information table 116 are updated (S810). Upgrade determination processing (described later) is executed (S815). File access is executed (S820), and deletion processing (described later) from the repair file list is executed (S825).

  Note that the reflection to the storage device 115 and the deletion of the journal related to S820 and S825 are the same as S725 and S730 in FIG.

  FIG. 12 shows the file deletion process 106. Execution of file deletion processing is started based on a request for a file or directory by a user program or command. Processing for registering in the repair file list (described later) is executed (S900), and the file path name element (row) that matches the file path name to be deleted from the file information table is deleted from the file information table 116 (S905). An update history of metadata that needs to be updated or deleted with the deletion of the file is recorded in the journal (S910), and the file, directory, and its metadata are deleted (S915). After the processing result of 915 is reflected in the storage device 115, deletion processing (described later) from the repair file list is executed (S920).

  FIG. 13 shows the registration process to the repair file list. This process is called when executing a process in which the state of a file or directory changes, such as when a file or directory is created (S700), when a file is accessed (S800), or when a file is deleted (S900). In this process, the file path name is recorded 1002 in the last element (row) of the repair file list 117 (S1000). As described with reference to FIG. 5, the elements (each line) stored in the repair file list 117 are files to be repaired.

  FIG. 14 shows a deletion process from the repair file list. This process is executed when a file or directory is changed (S730), when a file is accessed (S825), when a file is deleted (S920), or when a file is restored (described later). It is called with. As described above, this is called when the reflection of the metadata related to the file in the storage device 115 is completed.

  The element (line) whose target file path name matches the file path name is deleted from the repair file list 117 (S1100), and the deleted element (line) is filled with free space (S1105).

  FIG. 15 shows a rating setting process 108 for setting an initial value of the rating of the file in the file creation process 105. If the owner attribute of the file is the system administrator (root, administrator) (S1200), A is set as the rating of the file in the file information table 116 (S1205), and if the owner attribute is other than the system administrator, the file The file rating of the information table 116 is set to C (S1210).

  FIG. 16 shows the upgrade determination process 107 for upgrading the rating of the file stored in the file information table 116 in accordance with the access to the file (S815 of the file access process 104). The file access count of the file information table 116 is n times or more (n = 10 in the definition list 118 in FIG. 6) (S1300), or the access user is m or more (m = 3 in the definition list 118 in FIG. 6) (S1310). )), The file rating of the file information table 116 is updated to B (S1305, S1315). However, if the file rating before update is higher than the rating after update, the above update is not performed.

  FIG. 17 shows a file system repair process (S605 in FIG. 9) in the file system activation process.

  The rating corresponding to the file path name in the repair file list 117 is copied from the file information table 116 to the repair file list 117 (S1400). The head (line) of the repair file list 117 is pointed (S1405), and the measurement of the repair time is started (S1410). If there is no file in the line of the repair file list 117 pointed to (S1415), the repair time measurement is terminated (S1420), and the file system repair process is terminated.

  If the file rating of the repair file list 117 being pointed to is A (S1425), a file repair process (described later) is executed (S1430), and the process proceeds to step 1460. If the rating is A, the file repair process must be executed, and the system administrator's file will be repaired by the file owner with high importance regardless of the repair specified time (even if the repair specified time is exceeded). become. If step 1425 is executed after step 1435, the repair designation time will be taken into consideration for the repair of the file with the rating A, but if this is done, a new file will be restored without repairing the high-importance file. Operation such as file creation will be started, and there is a possibility that a new system stop factor is included.

  If the rating is not A (S1425), the remaining file system repair time is re-estimated by the repair time re-estimation process (described later) (S1435), and the difference between the predicted repair time of the file system and the remaining repair time is repaired. If it falls within 10% of the specified time (the repair specified time defined in the definition list 118, which is 10 seconds in FIG. 6) (S1440), the process proceeds to step 1460.

  Note that “within 10% of the repair designation time” means that the control is performed with the repair designation time as a target, and the value indicating the allowable range may be another value. Further, depending on the situation, there may be a control that allows −10% from the designated repair time and does not allow the repair designated time to be exceeded.

  The difference between the estimated file system repair time and the rest of the repair specified time (a new repair specified time described later with reference to FIG. 18) is within 10% of the repair specified time (the repair specified time initially set in the definition list 118). If the predicted file system repair time is shorter than the remaining repair specified time (S1440), upgrade processing (described later) is executed (S1450). If the predicted file system repair time is longer than the remaining repair specified time, Then, a downgrade process (described later) is executed (S1455).

  A rating-specific process corresponding to the rating as a result of the upgrade process or the downgrade process is executed (S1460), the next file in the repair file list 117 is pointed (S1465), and the process returns to step 1415.

  FIG. 18 shows a file repair process for reconciling the metadata and the file related to one file specified by the file system repair process (FIG. 17) or the repair process classified by rating described later. The file repair time measurement is started (S1500).

  The contents recorded in the journal are re-executed, and journal replay is performed to restore the consistency between the metadata and the file (S1505). The journal replay is as described with reference to FIG. 2. Here, the journal data of the specified file is sequentially searched from the journal replay start pointer, and the searched journal data is stored in the storage device 115. Will be reflected in the metadata. As described above, this is a case where metadata is taken as journal data. However, when file data is also taken as journal data, the file itself can be repaired.

  The file repair time measurement is terminated (S1510). The time from step 1500 to step 1510 is set as the measured file repair time for the repaired file (S1515). The measured file repair time is subtracted from the repair specified time, and this is used as a new repair specified time (S1520). You can rewrite the repair specification time in the definition list 118, but the administrator sets the contents of the definition list every time the file system is started. Therefore, a new repair specification time is added to the work area when the first file is repaired. It is desirable to store and process using this. Further, based on the measured file repair time, a file repair predicted time calculation process (described later) is executed (S1525). The details of the file repair prediction time calculation process will be described later, but a file repair prediction time that is a repair prediction time per file is calculated.

  The file path name and file owner of the repaired file are stored in the notification information management table 120. Further, the repair flag is stored in the notification information management table 120 as “repair” and the generation number is “0” (S1530). Deletion processing (FIG. 14) from the repair file list for deleting the repaired file from the repair file list 117 is executed (S1535).

  FIG. 19 shows the restoration time re-estimation process of the file system restoration process (S1435 in FIG. 17). The number of files with the repair file list rating B, B-, and C + is obtained as the number of remaining repair files (S1600), and the number of remaining repair files obtained and the number of repairs in the file repair prediction time management table 119 are as follows. A value obtained by multiplying the predicted file repair time stored in the line is returned to the file system repair process as the predicted file system repair time (S1605).

  FIG. 20 shows a file repair prediction time calculation process 110 for predicting the time required to repair one file. During the file repair process (FIG. 18), the time required to repair the file is measured (measured file repair time).

  In the current file system repair, if the first file is repaired (S1700), the average value of the previous file repair predicted time stored in the file repair predicted time management table 119 and the measured file repair time is calculated as the current file system repair. The file repair prediction time is recorded in the file repair prediction time management table 119 (S1705), and the number of repair files is updated (+1) (S1715).

  If the second and subsequent files are restored in the current file system restoration (S1700), the average value of the current file restoration estimated time and the measured file restoration time in the file restoration estimated time management table 119 is determined as the current file. The file repair prediction time management table 119 is overwritten as the repair prediction time (S1710), and the number of repair files in the file repair prediction time table 119 is updated (+1) (S1715).

  FIG. 21 shows a rating-specific repair process for repairing a file based on the rating of the file. In the repair processing classified by rating, when the rating of the file to be repaired is C or B- (S1800), the file and metadata related to the file are deleted (S1805). Further, the file path name of the deleted file, the file owner, and the “delete” flag indicating that the file has been deleted are stored in the notification information management table 120 (S1810). If the file rating is A, B, or C + (S1800), file repair is executed (S1815). When deleting a file, it is controlled so that the rating C is deleted first by the upgrade process.

  FIG. 22 shows an upgrade process 111 for upgrading the file rating of the repair file list 117. The remaining time limit (new repair designation time updated in the file repair process (FIG. 18)) is divided by the current file repair predicted time in the file repair predicted time management table 119, and the rating of the file that has not been repaired from the quotient Substitute the value obtained by subtracting the number of files B and C + into n (n is a temporary variable value) (S1900).

  If a file of rating B- remains in the repair file list 117 (S1905), upgrade processing from B- to B is executed (S1910). In the upgrade process from B- to B, which will be described later, if the B- file remains (S1915), the process ends.

  If there is no rating B- file remaining in the repair file list 117 (S1915) and a rating C file remains in the repair file list 117 (S1920), the upgrade process from C to C + is executed (S1925). .

  FIG. 23 shows an upgrade process for upgrading a file from B- to B. The upgrade process from B- to B is called from the upgrade process 111. Rating n B files from the top of the repair file list 117 are upgraded to rating B. Here, n indicates the variable value n calculated in the upgrade process (FIG. 22). The upgrade from B- to B + is executed preferentially from the head file in the repair file list 117 (S2000).

  If n is greater than 0 (S2005) and the rating of the repaired file list 117 currently pointed to is B- (S2010), the rating B- of this file is upgraded to B, and the rating of the repaired file list 117 is Is updated to B (S2015). 1 is subtracted from the value of n (S2020). It points to the next line (file) in the repair file list 117 (S2025) and returns to step 2005. If n is 0 or less or there is no file in the repaired file list 117 pointed to (S2005), the process is terminated.

  FIG. 24 shows an upgrade process for upgrading the file rating from C to C +. The upgrade process from C to C + is called from the upgrade process 111. From the last file stored in the repair file list 117, n files of rating C are upgraded to rating C +. Here, n indicates n calculated by the upgrade process (FIG. 22) and updated by the upgrade process from B- to B (FIG. 23). The upgrade from C to C + is executed preferentially from the last file in the repair file list 117 (S2100).

  If n is greater than 0 (S2105) and the rating of the repair file list 117 currently pointed to is C (S2110), the rating C of this file is upgraded to C +, and the rating of the repair file list 117 is C +. (S2115). 1 is subtracted from the value of n (S2120), the previous file in the repair file list 117 is pointed (S2125), and the process returns to step 2105. If n is 0 or less or there is no file in the repair file list 117 pointed to (if it points before the head of the repair file list 117) (S2105), the process ends.

  FIG. 25 shows a downgrade process 112 for downgrading the file rating of the repair file list 117. The remaining time limit (new repair designation time updated in the file repair process (FIG. 18)) is divided by the current file repair predicted time in the file repair predicted time management table 119, and the file of the file that has not been repaired from its quotient A value obtained by adding 1 to the value obtained by subtracting the number of files with ratings of B and C + is substituted for n (n is a temporary variable value) (S2200).

  If a file of rating C + remains in the repair file list 117 (S2205), a downgrade process from C + to C is executed (S2210). In the downgrade process from C + to C, which will be described later, if a C + file remains (S2215), the process ends.

  If no rating C + file remains in the repair file list 117 (S2215) and a rating B file remains in the repair file list 117 (S2220), a downgrade process from B to B- is executed (S2225). ).

  FIG. 26 shows a downgrade process for downgrading the file rating from C + to C. The downgrade process from C + to C is called from the downgrade process 112. Rating C + files from the top of the repair file list 117 are downgraded to rating C. Here, n indicates the variable value n calculated in the downgrade process (FIG. 25). The downgrade from C + to C is executed preferentially from the first file in the repair file list 117 (S2300).

  If n is greater than 0 (S2305) and the rating of the currently repaired file list 117 is C + (S2310), the rating C + of this file is downgraded to C, and the rating of the repaired file list 117 is C. (S2315). 1 is subtracted from the value of n (S2320). It points to the next line (file) in the repair file list 117 (S2325) and returns to step 2305. If n is 0 or there is no file in the repair file list 117 pointed to (S2305), the process is terminated.

  FIG. 27 shows a downgrade process for downgrading the file rating from B to B-. The downgrade process from B to B- is called from the downgrade process 112. The n files of rating B from the last file stored in the repair file list 117 are downgraded to the rating B-. Here, n indicates n calculated by the downgrade process (FIG. 25) and updated by the downgrade process from C + to C (FIG. 26). Downgrading from B to B- is executed preferentially from the last file in the repair file list 117 (S2400).

  If n is greater than 0 (S2405), and the rating of the repaired file list 117 currently pointed to is B (S2410), the rating B of this file is downgraded to B-, and the rating of the repaired file list 117 is Update to B- (S2415). 1 is subtracted from the value of n (S2420). It points to the previous file in the repair file list 117 (S2425) and returns to step 2405. If n is 0 or less, or there is no file in the repaired file list 117 pointed to (if it points before the beginning of the file list 117) (S2405), the process ends.

  FIG. 28 shows a log screen (a) 2501 that outputs the file path name that has been repaired or deleted by the file system repair processing 109, and a mail screen (b) 2502 that notifies the file owner that the file has been repaired. A mail screen (c) 2503 for notifying the owner of the file that the file has been deleted.

  The log screen 2501 that outputs the file path name that has been repaired or deleted starts the start of the file system, detects that the root file system needs to be repaired, starts the file system repair, and the notification information management table It indicates that / etc / hosts has been repaired from the flag 120 and that / etc / hosts has been repaired. Further, it is detected that a different file system needs to be repaired, the file system repair is started, /home/root/var.txt is repaired from the flag of the notification information management table 120, and / home / foo / This indicates that var.txt has been deleted, /home/root/var.txt has been repaired, and /home/foo/var.txt has been deleted. Also, file system repair of a different file system is started, and it is detected from the flag of the notification information management table 120 that the / tmp file has been deleted, indicating that the / tmp file has been deleted.

  A mail screen 2502 for notifying root, which is a file owner, that a file has been repaired is a mail screen for notifying root, which is a file owner, that a root file output to the log in 2501 has been repaired.

  A mail screen 2503 for notifying the file owner foo that the file has been deleted is a mail screen for notifying the file owner foo that the file foo output to the log in 2501 has been deleted.

  According to the present embodiment, when the system is restarted after the system is stopped due to a system failure or the like, it is possible to improve the operability by shortening the startup time of the file system and notify the user of a damaged file.

It is a figure explaining a journal file system. It is a figure explaining restoration of a journal file system. The system configuration | structure of an Example is shown. A file information table is shown. Show repair file list. The definition list defined in advance by the system administrator is shown. A file repair prediction time management table is shown. A notification information management table is shown. It is a flowchart of a journal file system starting process. It is a flowchart of a file creation process. It is a flowchart of a file access process. It is a flowchart of a file deletion process. It is a flowchart of the registration process to a repair file list. It is a flowchart of the deletion process from a repair file list. It is a flowchart of a rating setting process. It is a flowchart of an upgrade determination process. It is a flowchart of a file system repair process. It is a flowchart of a file repair process. It is a flowchart of a repair time re-estimation process. It is a flowchart of file restoration prediction time calculation processing. It is a flowchart of the repair process classified by rating. It is a flowchart of an upgrade process. It is a flowchart of the upgrade process from B- to B. It is a flowchart of the upgrade process from C to C +. It is a flowchart of a downgrade process. It is a flowchart of the downgrade process from C + to C. It is a flowchart of the downgrade process from B to B-. This is a screen for notifying a repaired or deleted file by log or email.

Explanation of symbols

  101: Computer (server), 102: Memory, 103: Program, 104: File access processing, 105: File creation processing, 106: File deletion processing, 107: Rating determination processing, 108: Rating setting processing, 109: File system repair Processing: 110: File repair prediction time calculation processing, 111: Upgrade processing, 112: Downgrade processing, 113: Processor, 114: Disk interface, 115: Storage device, 116: File information table, 117: Repair file list, 118: Definition List: 119: File repair prediction time management table, 120: Notification information management table, 121: User notification processing.

Claims (8)

  A file that is rated according to importance, a storage device that stores the metadata of the file and the update contents during the update of the file as a journal, and a restart that is connected to the storage device and that is stopped during the update of the file In response to the above, a journal file system comprising: a computer for repairing the file using the journal in order from the file with the highest ranking in a predetermined time.   The rating of the file is one of a top level to be repaired, a top level to be repaired if it can be repaired within the predetermined time, and a low level to be deleted. When the predetermined time is shorter than a predicted repair time of a rating file, the upper rating file is downgraded to the lower rating, and the downgraded file and metadata of the file are deleted. The journal file system as claimed in claim 1.   When the predetermined time is longer than the estimated repair time of the higher-ranked file, the lower-ranked file is upgraded to the higher-ranked file, and the upgraded file and the metadata of the file are subject to the repair. The journal file system according to claim 2, wherein:   4. The journal file system according to claim 3, wherein information specifying the repaired file and the deleted file is output as a notification.   The update contents during the update of the file are stored in a storage device as a journal, and in response to a restart associated with the stop during the file update, the upper rank of the rating assigned according to the importance is set for a predetermined time. A method for repairing a journal file system, comprising repairing metadata of the file sequentially from a file using a journal stored in the storage device.   The rating of the file is one of a top level to be repaired, a top level to be repaired if it can be repaired within the predetermined time, and a low level to be deleted. When the predetermined time is shorter than a predicted repair time of a rating file, the upper rating file is downgraded to the lower rating, and the downgraded file and metadata of the file are deleted. The journal file system repairing method according to claim 5.   When the predetermined time is longer than the estimated repair time of the higher-ranked file, the lower-ranked file is upgraded to the higher-ranked file, and the upgraded file and the metadata of the file are subject to the repair. The journal file system repair method according to claim 6, wherein:   8. The journal file system repair method according to claim 7, wherein information specifying the repaired file and the deleted file is output as a notification.

Images