JP2003296047A - Raid file system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a RAID file system for maintaining the parity consistency even when the write is stopped at any point during the write. <P>SOLUTION: In updating a logical block 5 in stripes constituted by logical blocks 4-6 stored in a distributed manner in physical disks vol. 1, 3 and 6 so as to realize RAID, storage areas for an updated logical block 5new and a parity block 4new newly calculated for the updating are ensured in non-used areas of a disk so as to realize RAID to/from the logical area 6, write is performed therein, and meta data is updated thereafter. <P>COPYRIGHT: (C)2004,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a RAID file system having a function of maintaining parity consistency.

[0002]

2. Description of the Related Art RAI for redundantly storing data in a plurality of disk devices in order to improve the reliability of data written in the disk and the access speed of the disk.
The D file system is well known.

Japanese Unexamined Patent Publication No. 2000-99282 discloses a RAID file system capable of arbitrarily setting the stripe width for each file independently of the configuration of the actual disk array. The metadata that describes each file includes the stripe width and an address conversion table that converts the number of the logical block in the logical stripe configuration determined by the stripe width into the block number in the physical disk. Each block in the stripe configuration can be dynamically and efficiently mapped to the block in the real disk while satisfying the condition for realizing RAID.

The reliability of the RAID file system is provided by the presence of information called parity blocks in addition to the data blocks in each stripe as a component of the file. This is to restore a certain block by using the parity block (and the data block group that configures the stripe to which the block belongs) when the block becomes unreadable or otherwise loses reliability. Yes, of course, the parity block needs to be updated as the data block is updated.

The problem here arises when the node performing the writing process goes down between the time when the data writing is started and the time when the parity writing is completed. This state may be either old or new and data and parity may be consistent, new data may be overwriting (parity remains old), parity block (data is new) May be overwritten.

If this state is discarded, and a certain block (here, in particular, a block other than the block that is about to be written down) becomes unreadable, the restoration processing of this block is performed by the above-mentioned reliability. Since it will be based on the parity block and the data block, which have no effect, the state that the reliability cannot be guaranteed will propagate to the block that has nothing to do with the abnormal processing (down in the process of writing). .

In order to avoid this, in a file system that allows a RAID file, it is necessary to provide a data and parity consistency guarantee means.

[0008]

SUMMARY OF THE INVENTION It is, therefore, an object of the present invention to provide a RAID file system in which the consistency of parity is assured even when writing is stopped at any point during writing.

[0009]

According to the present invention, there is provided a RAID file system in which each stripe has a parity block in addition to a data block, the data block being updated and the data block being updated in association with the update of the data block. Means for writing the updated parity block to an unused area of the external storage device different from and different from the external storage device storing the other data blocks in the stripe to which the data block belongs, and the updated data. After the writing of the block and the updated parity block is completed, the metadata is updated so that the file is configured to include the area in which the updated data block and the updated parity block are written. A RAID file system is provided.

This system has means for determining whether or not to update the data block by the unused area writing means and the metadata updating means, based on the attribute set in the file to which the data block to be updated belongs. Further, it is preferable to further comprise.

According to the present invention, each stripe has a parity block in addition to a data block and is writable by a plurality of nodes. The RAID file system stores information for specifying an update location. A means for later overwriting the updated data and the updated parity on the unupdated data block and the updated parity block, respectively, and invalidating the updated location specifying information only when the write authority is returned from the node. RA and means for checking the parity of the corresponding stripe when there is unrevoked updated location specifying information when the system is restarted.
An ID file system is also provided.

In accordance with the invention, each stripe has a parity block in addition to a data block, and write conflicts from multiple nodes are token controlled.
RA which is an AID file system and comprises means for identifying all tokens issued to a down node and means for restoring parity consistency for all blocks updatable by the identified tokens.
An ID file system is also provided.

According to the present invention, there is also provided a program for causing a computer to implement the above-mentioned RAID file system.

[0014]

1 shows a file system according to an embodiment of the present invention. In this system, one or more virtual (logical) disks are realized by one or more physical disks. In the example shown in the figure, four physical disks vol
1 to 4 are recognized as one logical disk 10. File metadata 1 stored in the logical disk 10
2 is stored in a physical disk different from the data storage disks vol1 to vol4.

This file system supports a RAID file, and for the RAID file, a file name 16 and a file size 18 as well as a RAID stripe width 20 are set in one file information 14 in its metadata 12. . This RAID stripe width can be set regardless of the number of physical disks. Also,
Files with different stripe widths can be mixed. To realize RAID, each physical disk vol
It is not required that the storage capacities of 1 to 4 are uniform.

At the bottom right of FIG. 1, a logical stripe configuration 24 for a file having a stripe width of 3 is shown. When the stripe width is 3, the first stripe is composed of logical blocks 1 to 3, the second stripe is composed of 4 to 6, the third stripe is composed of logical blocks 7 ... Each stripe contains one parity block. In the example shown in the figure, as an example, the logical block numbers 1, 2, 3, ...
4, 7 ... Are used as parity blocks.

The RAID information 22 in (or pointed to by) one file information 14 stores information in the order according to this logical stripe configuration. In order to realize RAID, a plurality of logical blocks forming each stripe are mapped on a real disk so that the contents are stored in different physical disks. In the example shown in the figure, the logical block 4 forming the second stripe is vol
In some block in 1, logical block 5 is vol 3
The logical block 5 is mapped to the block in vol 4 and the logical block 5 is mapped to the block in vol 4. Further, the logical blocks 1 to 3 forming the first stripe are vol 1,
It is mapped to blocks within 2 and 4. These pieces of information are stored in the 1-stripe information 26 in (or pointed to by) the RAID information 22.

An updating method according to an embodiment of the present invention will be described below.

I) The physical block (group) in which the update target data d-old is stored is b-old.

Ii) On the other hand, the updated data is d-ne
Let w.

Iii) When the file attribute of the file to be updated is RAID and has parity, data is arranged so that RAID can be realized based on the position of another physical block belonging to the stripe to which the block to be updated belongs. The storage locations of blocks and parity blocks are secured from unused areas.

Here, d-new is a physical block (group)
It is assumed that a block (group) for parity, which needs to be changed by this update, can be secured in p-new in b-new.

Iv) d-new is a physical block b-new
Write in.

V) Read data from another block belonging to the same stripe, calculate a new parity together with d-new, and write this into p-new.

At this point, in the metadata (file attribute information), blocks constituting the file are b-old and p-
I recognize that it is old. When the data block 5 is updated in the example of FIG. 1, as shown in FIG. 2, the updated data block 5new and the parity block 4new are written in any one of vol 3 and vol 2, respectively. The data still points to blocks 5 and 4 before the update.

Vi) Rewrite the metadata to the updated status.

At this point, the corresponding file is b-ne
It is possible to recognize w and p-new as constituent blocks.
In the example shown in FIGS. 1 and 2, one stripe information 26 in the metadata 12 is stored in the block 4ne as shown in FIG.
The update is completed by rewriting so as to point to w and 5new.

It is assumed here that the metadata file is updated every time data and parity are prepared in the new area. Other than this, it is possible to collectively reflect all the block groups and parity groups at the time of file closing, to process a plurality of files collectively, and the like.

Even if the writing process is down at any of the above timings, the configuration of the relevant part of the file does not take any form other than the combination of old data and old parity and the combination of new data and new parity.
The parity consistency on the file will be maintained.
Therefore, the recovery process for maintaining the parity consistency is unnecessary. It should be noted that although no mention is made of the case where the metadata is down during the writing of the metadata, the maintenance of the validity of the metadata can be dealt with by a conventional technique such as logging the writing content prior to the writing.

According to this update processing, the updated portion is stored at a position apart from the unupdated portion within one file, so-called fragmentation of the file occurs, and the access performance deteriorates. On the other hand, if the frequency of reading the updated file is higher than a certain level (or if the frequency itself is low but high-speed reading is required when necessary), then a process other than the user-specified process (for example, back-up process) is performed. Defragmentation and reconfiguration of the file configuration block group in the disk (position change pursuing optimization) may be performed.

In addition, since it is necessary to access the updated part and the unupdated part apart from it in the updating process, there is a problem that the processing time becomes longer than that in the case of simply overwriting the data block. .

Therefore, it is conceivable to selectively use the simple overwrite process and the update process of the present invention by using various file attributes in the metadata file as a criterion.

The discrimination method is as follows.

I) A storage / calculation mechanism for the operation, which inputs the file attribute (group) and outputs the write processing type, is prepared.

Ii) It is indispensable to refer to the file attribute before the writing process.

Iii) A file attribute is given to the above arithmetic mechanism,
The write processing type is determined.

Iv) The write (update) process for each file is selected after referring to this type.

The simplest example above would be to have a "write type" as a file attribute and refer to it directly. However, in this case, the setting by the user or the upper application also needs to be performed in file units. Such complication can be avoided if the "writing type" is determined by calculation from one or more of the file attributes that are normally set.

As an option other than the above when executing the write (update) processing according to the "write type", for example, a method of logging the parity position affected by the write prior to the write can be considered. Then, at the time of restoration, the parity of the logged parity position is calculated from the existing data and rewritten to maintain the parity consistency. This method only recovers the parity consistency at the time of down, but it is not guaranteed whether the data itself is old or new, but the additional load at the time of writing logs sufficient information to identify the parity block (block number etc.) It is only that. Therefore, it has the opposite characteristic to the above-mentioned method of replacing the old and new blocks after writing to the new area.

This “method of logging the parity position”
First, if only the parity consistency is guaranteed (the data itself is not guaranteed), the simplest process is the entire file system (data held by the file system) when the parity consistency cannot be guaranteed. It is to repeat the parity calculation. However, this would take a long time, and short-term recovery and system restart cannot be expected. Therefore, some means is provided to limit the recalculation range. In the above-mentioned “method of logging the parity position”, this is realized by logging the information that specifies the parity block affected by the actual writing.

This "information for specifying the parity position" is invalidated after the writing is completed. Then, when the system is restarted, if the parity position specifying information that has not been invalidated remains, the parity is recalculated for the corresponding stripe to restore the parity consistency.

By the way, in a file system in which writing is performed from a plurality of nodes, for example, one token is prepared for each block, and only the node having the token is allowed to actually write to the disk, so that a plurality of nodes can be written. Controls write conflicts from. Therefore, the invalidation of the logging information, that is, the writing of the invalidation information to the log is not performed each time writing of each block is completed, but is performed when the token is returned, thereby reducing the load required for writing the invalidation information.

When this method is adopted, there is only one piece of invalidation information for at least one write process executed within one token acquisition period in the same node, but at least the invalidation information exists. If the invalidation information does not exist, it can be seen that the last update data for the corresponding block existing in the log is valid when the invalidation information does not exist. Alternatively, even if the last update data is not extracted, it is also possible to actually write all the valid data so that the state of the last update data is actually obtained.

As a similar means, it is conceivable to write the invalidation information at the time of releasing the lock in the disk write control by the lock method.

This method is effective when the load of logging processing is reasonably high and the range of file update in a certain process is narrow (for example, deviated to a specific file).

The fact that the disk access is token-controlled means that a certain node always holds the token of the corresponding portion while updating a certain portion of the file. Therefore, if a certain node goes down, performing a parity check on all the places that can be updated with the token held by the corresponding node is a process that satisfies the sufficient condition for recovery of the parity consistency.

However, this processing causes the recovery range to be wider than in the case of logging the parity position (which is exactly the same in the worst case), that is, the recovery time is increased.

Therefore, it is desirable to limit the conditions for using this function only when the logged information on the parity position loses reliability. This situation can occur if all the nodes that have access to the logs go down.

In the above-mentioned method of replacing the old and new blocks after writing to the new area, the restoration process is not necessary. In the method of logging the parity position, by referring to the log file, it is possible to identify stripes that may not be consistent because writing was in progress at the time of down. Parity recalculation is performed for this. When the parity values are different before and after the calculation, the stripe information is presented in some form (to the user or the administrator) and the writing of this new parity value is executed. This guarantees the integrity of the stripes, and the user is presented with the possibility that the data part that was being written when the stripe was down had an unintended value. I can give instructions. It should be noted that the corresponding data block (which may not contain a valid value) is in this state (invalid information lacking validity as data) is recorded on the metadata disk and carelessly recorded. Do not use the corresponding data. Further, the parity recalculation is based on the premise that all the blocks forming the corresponding stripe can be normally accessed. If this condition is not satisfied, recording of the corresponding data block (and inaccessible block) in the metadata (not valid) is unconditionally instructed.

When the log cannot be accessed, the parity check of all stripes that can be updated by the token held by the node that has gone down makes it impossible to limit which stripe was actually updated at the time of down, and the update is not possible. It only shows the range that could have been done. Even in this case, the parity recalculation and the parity write are performed for the stripes belonging to the relevant range as described above. However, this time, when a parity block having a different value is generated before and after the calculation, it is necessary to present the corresponding stripe information (as a range in which an unintended value may be included).

If even token information cannot be obtained, the entire disk (storage area) is set as the parity recalculation range.
In this case, the non-guaranteed range is the entire stripe in which the parity cannot be calculated, and the entire data block group (stripe) related to the parity block whose value is different before and after the calculation.

(Supplementary Note 1) A method of updating a data block in a RAID file system, wherein each stripe has a parity block in addition to the data block,
(A) The data block after the update and the parity block after the update with the update of the data block are different from the external storage device in which other data blocks in the stripe to which the data block belongs are stored and Write to unused areas of different external storage devices,
(B) After the writing of the updated data block and the updated parity block is completed, the metadata is set so that the file is configured to include the area in which the updated data block and the updated parity block are written. A method comprising the step of updating.

(Supplementary Note 2) (c) Based on the attribute set in the file to which the data block to be updated belongs, a step of determining whether or not to update the data block in steps (a) and (b) The method according to Note 1 further comprising.

(Supplementary Note 3) (d) When it is determined in step (c) that the update in steps (a) and (b) is not to be performed, the data and the updated data are stored after storing the information for specifying the update location. The subsequent parity is overwritten on the data block before update and the parity block before update, respectively, and (e) the update location specifying information is invalidated after the end of step (d), and (f) it is not invalidated when the system is restarted. 3. The method according to appendix 2, further comprising the step of recalculating the parity for the corresponding stripe when the updated location specifying information is present.

(Supplementary Note 4) A method of updating a data block in a RAID file system in which each stripe has a parity block in addition to a data block and is writable from a plurality of nodes. Only after the data block after update and the parity block after update are overwritten on the data block before update and the parity block before update, respectively, after storing the information for identifying (b) the write authority is returned from the node. A method comprising the step of invalidating the updated location specifying information, and (c) performing a parity check on the corresponding stripe when the updated location specifying information that has not been invalidated exists when the system is restarted.

(Supplementary Note 5) RAID in which each stripe has a parity block in addition to a data block, and write competition from a plurality of nodes is controlled by a token
A method for recovering parity consistency in a file system, comprising the steps of identifying all tokens issued to a down node and recovering parity integrity for all blocks that can be updated by the identified tokens. how to.

(Supplementary Note 6) In a RAID file system in which each stripe has a parity block in addition to a data block, the updated data block and the parity block after the update with the update of the data block are A means for writing to an unused area of an external storage device that is different from and different from the external storage device that stores other data blocks in the stripe to which the data block belongs, and a means for writing the updated data block and the updated parity block. A RAID file system, comprising means for updating metadata so that a file is configured to include an area in which an updated data block and an updated parity block are written after writing is completed. (1) (Supplementary Note 7) A means for deciding whether or not to update the data block by the unused area writing means and the metadata updating means based on the attribute set in the file to which the data block to be updated belongs. Additional Note 6
The described RAID file system. (2) (Supplementary note 8) When the determining unit determines not to perform the update by the unused area writing unit and the metadata updating unit, the data after the update and the parity after the update are stored after storing the information specifying the update point. Means for overwriting the data block before update and the parity block before update, means for invalidating the update location specifying information after the overwriting is finished, and update location specifying information that is not invalidated when the system is restarted. The RAID file system according to appendix 7, further comprising means for recalculating parity for the corresponding stripe.

(Supplementary Note 9) A RAID file system in which each stripe has a parity block in addition to a data block and is writable from a plurality of nodes, and is updated after storing information specifying an update location. A means for overwriting the data block after update and the parity block after update over the data block before update and the parity block before update, respectively, and invalidating the update location specifying information only when the write authority is returned from the node. A RAID file system comprising means and means for checking the parity of the corresponding stripe when there is update location identification information that has not been invalidated when the system is restarted. (3) (Supplementary note 10) A RAID file system in which each stripe has a parity block in addition to a data block, and write competition from a plurality of nodes is controlled by a token, and is issued to a down node. A RAID file system comprising means for identifying all the tokens, and means for restoring parity consistency for all the blocks that can be updated by the identified tokens. (4) (Supplementary Note 11) The RAI according to any one of Supplementary Notes 6 to 10.
A program that causes a computer to realize the D file system. (5)

[0059]

As described above, the following effects can be expected in the present invention.

(1) Even if a node goes down in the middle of writing, the actuality of data (limited to either the old or new state and not halfway) and parity consistency are ensured.

(2) There is an alternative means in a state where it cannot be used unless the above processing is prepared for a certain load, and the parity consistency can be guaranteed at least after the occurrence of the down.

(3) The time required to restore the above consistency can be minimized.

[Brief description of drawings]

FIG. 1 is a block diagram of a file system according to an embodiment of the present invention.

FIG. 2 is a block diagram showing a state in which a data block and a parity block are being updated.

FIG. 3 is a block diagram showing a state after updating of a data block and a parity block is completed.

   ─────────────────────────────────────────────────── ─── Continued front page    F term (reference) 5B065 BA01 CA30 EA03 EA12 EA31                 5B082 CA01

Claims (5)

[Claims] 1. A RAID file system, in which each stripe has a parity block in addition to a data block, wherein the updated data block and the parity block updated in association with the update of the data block are the data blocks. Means for writing to the unused areas of the external storage device that are different from and different from the external storage device that stores the other data blocks in the stripe to which the A RAID file system comprising: after completion, updating the metadata so that the file is configured to include an area in which the updated data block and the updated parity block are written. 2. A means for determining whether or not to update the data block by the unused area writing means and the metadata updating means based on the attribute set in the file to which the data block to be updated belongs. The RAID file system according to claim 1. 3. A RAID file system in which each stripe has a parity block in addition to a data block and is writable from a plurality of nodes, and after updating after storing information specifying an update location, A means for overwriting the data block and the updated parity on the data block before the update and the parity block before the update, respectively, a means for invalidating the update location specifying information only when the write authority is returned from the node, and a system At the time of resumption, when there is update location identification information that has not been invalidated, a RAID for checking the parity of the corresponding stripe is provided.
File system. 4. A RAID file system in which each stripe has a parity block in addition to a data block and write contention from multiple nodes is controlled by a token, all issued to a down node. R token, and means for restoring parity consistency for all blocks updatable by the identified token.
AID file system. 5. RA according to any one of claims 1 to 4.
A program that causes a computer to realize an ID file system.