JPH0675705A - Block assignment control method for auxiliary storage - Google Patents

Abstract

PURPOSE:To quickly update the control information in response to the block assignment and release by providing a normal bit map which is updated into a using state and an unused state when a block is assigned and released respectively and an auxiliary bit map which is copied when a prescribed time passed from the first block assignment processing of the normal bit map. CONSTITUTION:A bit map 1 of the block assignment control information on an auxiliary storage consists of a normal bit map 3 which controls a fact whether the block of the auxiliary storage is presently used or not, an auxiliary bit map 4 which functions to detect an invalid block, and a date 5 when the map 3 is copied onto the map 4. Then the bits of both maps 3 and 4 are compared with each other in a block assignment processing carried out when a prescribed time passed from the first block assignment processing. Then the block corresponding to the working bits of both maps is decided as an invalid block. Thus the using state of the bit is released while the block assignment is carried out.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a block allocation management method when a non-volatile auxiliary storage device of a computer system is used for temporary storage of data, etc. The present invention relates to a block allocation management method for releasing a block.

[0002]

2. Description of the Related Art Generally, a non-volatile auxiliary storage device used in a computer system is configured to transfer data to and from a main storage device by designating an address of a block storing data. ing. Such an auxiliary storage device is called a direct access storage device. Normally, however, one direct access storage device is not used for only one purpose, but a plurality of data sets are stored in one direct access storage device. One direct access storage device is shared for each application.

Since such a direct access storage device can realize input / output to / from the main storage device at a relatively high speed, data processing in which the data contents are updated more frequently than when storing data to be stored for a long time. It is used for temporary storage of data when performing. At the time of this use, a block having a required capacity is secured for each use of data and each user, and data is stored in the secured block.

Therefore, since allocation and deallocation of blocks are frequently performed, management information for managing whether or not a block is in use is required.

The management information includes information for simply managing whether or not the block is in use, and information regarding the purpose of managing what information is stored. As an example of this,
VTOC (Volume Inventory) on Direct Access Storage
There is. In this VTOC (volume list), whether or not each block is in use is managed by the information for managing the free area, and the used block for each purpose is managed by the information for managing the data set.

The allocation and release of blocks on the direct access storage device is realized by updating both the information for managing whether or not this block is in use and the information for managing the block to be used for each purpose.

Therefore, in performing one operation of allocating or releasing a block in this manner, it is necessary to update a plurality of information such as information on whether or not it is in use and information on usage.

However, when updating these pieces of information,
For example, when the system is operating in a multi-program, the processing may be interrupted after updating one information and before updating the other information. Therefore, in preparation for such interruption of processing, it is necessary to detect the occurrence of an inconsistent state with the other information that occurs when only one information is updated, and to recover this inconsistent state.

As a recovery method, prior to updating these management information, an indicator indicating that the management information is updated is set in a certain place, and the indicator is reset after the update of the two management information is completed. In some cases, this indicator is checked prior to updating the management information to detect the occurrence of an inconsistent state and perform necessary recovery processing. The recovery process after detecting the inconsistency state is to simply issue a warning and manage the operation and application programs as well as the blocks used for each application, such as recovery from backup memory and update history. There is a method of manually or automatically recreating the information for managing whether the block is in use from the information to be stored.

The former warning method is described in "VOS3 /
ES1 VSAM Explanation, Hitachi HITAC Manual, 8091-3-039 ”. Also,
For the method of recreating the management information on whether the latter block is in use, refer to "VOS3 / ES1 Data Management Explanation, Hitachi HITAC Manual, 8091-3-042" or "VOS3 / ES1 Data Format, Hitachi HITA.
C Manual, 8090-3-943 ".

However, the former method has a problem that it is very troublesome because the operator of the computer constantly monitors the presence or absence of a warning, and if a warning occurs, special processing must be performed. Also, with the latter method, even when recovery processing is automatically performed, it takes a long time to search all used block management information for each application and recreate the information for managing whether the block is in use. However, there is a problem that the response time required for allocation and release is not constant.

In order to solve such a problem, there is a method of executing recovery processing from an inconsistent state as startup processing of a computer system independently of block allocation and deallocation processing. An example of using this method is spool file allocation management, which is described in "VOS3 / ES1 JSS4 Explanation,
Hitachi HITAC Manual, 8091-3-01
9 ”.

However, a general application program in which the interruption of the process while updating the management information and the startup of the computer system do not correspond to each other cannot accurately grasp the recovery timing. For this reason, not only the indicator that indicates the block allocation and deallocation process is in progress, but also detailed information about what processing is to be performed is stored in a fixed location, the interruption of the process is detected by the indicator, and the detailed information is used. A method of automatically recovering is considered. As another method, prior to updating the used block management information for each application when allocating a block, the management information indicating whether the block is in use or not is updated to “in use state”, thereby displaying the busy state. There is a method of allowing the occurrence of an invalid block that is not actually used but executing an independent recovery process periodically to recreate management information as to whether the block is in use.

[0014]

However, in the above method of storing detailed processing information in a fixed location,
Usage of each block for allocation and deallocation In addition to input / output of updating block management information and management information whether the block is in use or not, input for resetting the detailed information set and relevant information and indicator. Output occurs,
There is a problem that the processing for allocating and releasing blocks cannot be speeded up.

In addition, the method of allowing the generation of invalid blocks requires an independent operation of periodical recovery processing, and thus there is a problem that the operation for that is troublesome.

The present invention has been made to solve such a problem, and an object of the present invention is to assist in updating management information associated with allocation and deallocation of blocks without a quick and troublesome procedure. A block allocation management method for a storage device is provided.

[0017]

In order to achieve the above object, the block allocation management method for an auxiliary storage device of the present invention comprises a plurality of bits indicating whether or not the allocated block is in use, and each bit corresponds to A positive bitmap that is updated to a used state when allocating a block and is updated to an unused state when a block is released, and a sub-bitmap that is copied after a lapse of a predetermined time from the first block allocation process are provided. At the time of block allocation processing after a predetermined time has elapsed from the block allocation processing, each bit of the positive bit map and the sub bit map is compared, and the block corresponding to the bit indicating the usage state is determined to be an invalid block. Enabled to release unused state while executing block allocation process.

[0018]

According to the above means, each bit of the positive bit map and the sub bit map is compared during the block allocation process after a lapse of a predetermined time from the first block allocation process, and both bits correspond to the bit indicating the usage state. Since the block is determined to be an invalid block and is released to the unused state during execution of the block allocation process, there is no input / output other than the used block management information and bitmap record for each purpose when allocating or releasing the block, It is possible to prevent the invalid blocks from increasing and to release the invalid blocks promptly without performing a special operation for the generation of the invalid blocks.

[0019]

Embodiments of the present invention will be described below with reference to FIGS.

FIG. 1 shows the configuration of an embodiment of allocation management information for implementing the block allocation management method for an auxiliary storage device of the present invention. The management information used in the present invention is used by blocks. It is composed of a bitmap 1 which is information for managing whether or not it is inside and a management information group 2 for each purpose.

Of these, the bitmap 1 is a primary bitmap 3 for managing whether or not a block on the auxiliary storage device is in use, a secondary bitmap 4 for detecting an invalid block, and a primary bitmap 3 for the secondary bit. It is composed of the date 5 copied on the map 4.

Primary bitmap 3 and secondary bitmap 4
Correspond to the blocks 6-1 to 6-n on the auxiliary storage device in order from the first bit of the bitmaps 3 and 4, and correspond to when the bit on the bitmaps 3 and 4 is "1". "0" indicates that the block to be used is in use.
The case of indicates that the corresponding block is unused.

The management information group 2 for each purpose is composed of management information 7, 8 for each application such as applications A and B. In the management information 7, 8, ... Of this embodiment, for each of the blocks 6-1 to 6-n on the auxiliary storage device, the block related to the self information is represented by a chain from the head block.

In this case, the management information 7, 8, ...
, The blocks 6-1 to 6- on the auxiliary storage device are shown in FIG.
It may be configured as a bitmap for each application, which indicates that the block having “1” is composed of a plurality of bits corresponding to each of n, and indicates that the block is related to own information. Good.

FIG. 3 is a flow chart showing a process when a block is allocated in the auxiliary storage device.

When allocating the block of the auxiliary storage device, first, the bitmap 1 is read (step 3).
0).

Next, the block allocation processing date is obtained (step 31).

Next, the date 5 in the read bitmap 1 is compared with the allocation execution date to check whether the relationship of date 5 in the bitmap 1 <allocation execution date is satisfied (step 32). That is, it is checked whether or not the elapsed time since the last update of the bitmap 1 is at least one day.

Here, the comparison processing is performed in a magnitude relation not including an equal sign. When a plurality of computers share one auxiliary storage device, a slight time difference between the computers is absorbed. This is because. In addition, it is also possible to judge the elapsed days of the computer, that is, the business days, instead of the actual time of the elapsed days.

As a result, if the elapsed time since the last update of the bitmap 1 is at least one day,
An exclusive OR of the primary bitmap 3 and the secondary bitmap 4 is set in the primary bitmap 3 (step 3).
3). This is because a block that has been used for at least one day since the previous update time and is in use on both the primary and secondary bitmaps is judged to be an invalid block and its management information "Unused"
It means returning to.

Next, the date 5 is set to the current execution date, and the primary bitmap 3 is copied to the secondary bitmap 4.

The processing of steps 33 and 34 is executed only when the first block allocation processing is performed when the relationship of date 5 <allocation execution date in the bitmap 1 is established, and the next block allocation on the same day is performed. It is not executed after the processing.

Therefore, after the first block allocation of the previous day is performed, it is executed only when the first block allocation of the next day is performed.

Next, an unused block is detected by checking the bit which is "0" from the positive bit map 3, and this is allocated as a block for the allocation request and corresponds to this allocated block. The bit of the positive bitmap 3 is updated to "1" (step 3)
5).

Next, a new chain is created by reflecting the used / unused state of each block in the management information 7 for each purpose.

Therefore, in this embodiment, when an invalid block occurs, the invalid block is returned to the unused block two business days after the occurrence.

FIG. 4 is a flowchart showing a processing procedure at the time of releasing a block. First, the information of the block is deleted from the application-specific management information (7 or 8) for managing the designated block (step 40). . Then, the corresponding bits of the primary and secondary bitmaps 3 and 4 of the designated same block are set to "0" (step 41).

That is, the block release procedure is performed in the order of updating the application-specific management information and then updating the bitmap 1.

Therefore, in the procedure of the flow chart of FIG. 4, when the processing is interrupted at the stage where the processing of step 40 is finished, the management information of the purpose is updated to "unused", but whether it is in use or not. That management information still indicates "in use", and an invalid block is generated at this stage.

Also, when the allocation process is interrupted before executing step 36 in FIG. 3, the same invalid block occurs. However, this invalid block is released by the procedure described below.

This will be described with reference to the change of the bit state in the bitmap when the flowchart of FIG. 3 is applied.

When the blocks 6-1 to 6-n are unused, all the bits on the primary bitmap 3 and the secondary bitmap 4 are "0", indicating that they are unused.

Next, the bits on the sub-bitmap 4 do not change and remain "unused" until copying from the positive bitmap 3, and it is not judged as an invalid block.

Next, when the first block allocation process is executed, the bit of the corresponding block of the positive bitmap 3 becomes "1" by the process of step 35. That is, when all the blocks 6-1 to 6-n are unused, for example, when the allocation to the block 6-1 is executed, the first
On the day, the bit of the positive bitmap 3 corresponding to the block 6-1 becomes "1". Then, in the first block allocation process on the second day, since the bit of the sub-bitmap 4 is "0", the exclusive OR with the positive bitmap 3 becomes "1" by the process of step 33, which is It is set to the bit corresponding to block 6-1 of positive bitmap 3. After that, by copying the primary bitmap 3, the corresponding bit on the secondary bitmap 4 also becomes "1".

After this, if the release procedure of the block is completely executed before the date changes, that is, in FIG.
When the procedure of the flowchart in Figure 3 is completely executed, both bits on the positive bitmap 3 and the secondary bitmap 4 are "0".
Is displayed and "unused" is displayed, there is nothing that is judged to be an invalid block.

However, when the process is interrupted at the stage where the process of step 40 is completed in the procedure of the flowchart of FIG. 4, the use management information is updated to "unused",
The management information as to whether or not it is in use still indicates "in use". It should be treated as an invalid block and released immediately.

Therefore, the date is changed and the processing of step 33 is performed in the first block allocation processing on the third day. Then, blocks 6-of the primary and secondary bitmaps 3 and 4
Since the bits corresponding to 1 are both "1", their exclusive OR is "0", which is set to the bit corresponding to the block 6-1 of the positive bitmap 3.
That is, the bit corresponding to the block 6-1 of the positive bitmap 3 is updated to “unused”. After that, by copying this primary bitmap 3, the corresponding bit on the secondary bitmap 4 also becomes "0" and is updated to "unused".

Therefore, according to such a procedure, due to the suspension of the release process or the non-execution of the release process, "1" is set from the first block allocation to the first allocation execution on the third day. The block corresponding to the bit on the sub-bitmap 4 is processed as an invalid block due to suspension of the release process or non-execution of the release process. That is, it is forcibly released during execution of block allocation. As a result, invalid blocks will not exist for more than 2 days at the maximum.

As described above, according to the present invention, when the block is allocated, the management information group 2 for each application is updated after updating the bitmap 1.
By updating the value, it is possible that an invalid block may occur due to the interruption of the allocation process or the deallocation process. However, at the time of block allocation processing after a predetermined time has passed from the first block allocation processing, each bit of the positive bit map and the sub bit map is compared, and it is determined that the block corresponding to the bit indicating the usage state is an invalid block. Since it is released to the unused state during the execution of the block allocation process, there is no input / output other than the used block management information and bitmap for each application when allocating or releasing the block, and it is special for the invalid block occurrence. It is possible to prevent the invalid blocks from increasing and to release them promptly without performing any operation.

The copy date and time need not be time information as long as it can be determined that the usage state of the block that was in use at the time of the previous allocation execution is not continued.

Further, if the bit maps are provided in more stages, it is possible to monitor the stay of invalid blocks for a longer period.

[0052]

As described above, according to the present invention, each bit of the positive bit map and the sub bit map is compared at the time of block allocation processing after a predetermined time has elapsed from the first block allocation processing, and both are used. The block corresponding to the specified bit is judged to be an invalid block and is released to the unused state during the block allocation processing. Therefore, block management information and bitmap record used for each block allocation and release It is possible to prevent the increase of the invalid blocks and quickly release the invalid blocks even if no special operation is performed for the generation of the invalid blocks.

[Brief description of drawings]

FIG. 1 is a configuration diagram showing an embodiment of management information for implementing a block allocation management method for an auxiliary storage device according to the present invention.

FIG. 2 is a diagram showing another configuration example of management information for each application.

FIG. 3 is a flowchart showing a procedure of block allocation processing.

FIG. 4 is a flowchart showing a procedure of block release processing.

[Explanation of symbols]

1 ... bit map, 2 ... use management information group, 3 ... regular bitmap, 4 ... sub bitmap, 5 ... date, 6-1 to 6
-N ... A block of the auxiliary storage device, 7, 8 ... Management information by use.

Claims (2)

[Claims] 1. A management method for allocating a non-volatile auxiliary storage device by dividing it into blocks of a required capacity, comprising a plurality of bits indicating whether or not the allocated block is in use, and each bit corresponds to A positive bitmap that is updated to a used state when allocating a block and is updated to an unused state when a block is released, and a sub-bitmap that is copied after a lapse of a predetermined time from the first block allocation process are provided. At the time of block allocation processing after a predetermined time has elapsed from the block allocation processing, each bit of the positive bit map and the sub bit map is compared, and the block corresponding to the bit indicating the usage state is determined to be an invalid block. A block allocation management method for an auxiliary storage device, which comprises releasing to an unused state during execution of a block allocation process. 2. When releasing the allocated block,
2. The block allocation management method for an auxiliary storage device according to claim 1, wherein the corresponding bits of the primary and secondary bitmaps are set to unused states.