Patent Application
20070073964
1. Technical Field
The present invention relates to tape storage systems in general. More particularly, the present invention relates to tape storage systems having multi-volume datasets. Still more particularly, the present invention relates to a method and apparatus for handling multi-volume datasets in a tape storage system.
2. Description of Related Art
Virtual tape servers (VTSs) are one of the tape dataset stacking products specifically designed to cater customers demand for an efficient way to manage information stored on magnetic tapes. A VTS system typically includes a host interface, a VTS cache, and an automated library having multiple tape devices.
A VTS system is usually attached to a host computer such as a mainframe computer. When the host computer writes a dataset to the VTS system, the dataset is written to a virtual volume on the VTS system. If a dataset being written to a virtual volume exceeds the capacity of a single virtual volume, the dataset can be written by the host computer to a series of virtual volumes commonly referred to as a multi-volume dataset.
When the host computer reads a virtual volume of a multi-volume dataset from the VTS system, the virtual volume can be retrieved from a VTS cache if the virtual volume is currently resided on the VTS cache. If the virtual volume is not resided on the VTS cache, a storage manager determines which of the magnetic tapes contains the virtual volume. The corresponding magnetic tape is subsequently mounted on one of the tape devices, and the virtual volume is sent from the magnetic tape to the VTS cache and to the host computer. Since tape mounting can be very time-consuming, it is always favorable to have the frequently accessed virtual volumes retained in the VTS cache.
Often, when one virtual volume in a multi-volume dataset is accessed, the other virtual volumes within the same multi-volume dataset will typically be accessed as well. If an application within the host computer is going to access all the virtual volumes in the multi-volume dataset, it would be very advantageous to prestage all the virtual volumes into the VTS cache before they were accessed by the application within the host computer. However, the VTS system generally does not have the knowledge of which virtual volumes belong to a multi-volume dataset; thus, it would be desirable to provide such knowledge to the VTS system.
In accordance with a preferred embodiment of the present invention, in response to a write request for a multi-volume dataset, the information of the multi-volume dataset are captured by intercepting and deciphering a set of volume mount commands. Otherwise, the information of the multi-volume dataset are captured by snooping header information from a previous volume listed in a header of the multi-volume dataset. A chain of logical volume names that belongs to the multi-volume dataset is then built. Finally, the chain of logical volume names is then stored in a chain database.
All features and advantages of the present invention will become apparent in the following detailed written description.
The invention itself, as well as a preferred mode of use, further objects, and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
Referring now to the drawings, and specifically to
Host computer 110 can write a dataset into a virtual volume within VTS system 100. Sometimes, a dataset can be very large and the dataset has to be written in several virtual volumes known as a multi-volume dataset. Virtual volumes that are frequently accessed by host computer 110 can be stored in DASD cache 116, and virtual volumes that are less frequently accessed by host computer 110 can be stored in tapes 144 accessible by tape drives 118.
Distributed storage manager client 112 sends the frequently accessed virtual volumes to DASD cache 116, and distributed storage manager server 114 moves data between DASD cache 116 and tape drives 118. Library manager 122 controls an accessor 142 that accesses tapes 144 via commands from distributed storage manager server 114.
Quite often, when one virtual volume in a multi-volume dataset is accessed by an application within host computer 110, other virtual volumes of the same multi-volume dataset will also be accessed by the same application within host computer 110. But if some or all of the virtual volumes of the multi-volume dataset are not already in DASD cache 116, they will have to be recalled from one or more of tapes 144. Because the process of mounting tapes 144 is relatively time-consuming, it would be very advantageous to prestage (or preload) all the virtual volumes of the multi-volume dataset into DASD cache 116 before they are accessed by the application within host computer 110, especially when the application is actually going to access all the virtual volumes in the multi-volume dataset.
However, VTS system 100 does not have the knowledge of the relationship between virtual volumes and multi-volume datasets. Thus, VTS system 100 does not know which virtual volume corresponds to what multi-volume dataset until each virtual volume is being accessed by the application within host computer 110. As such, VTS system 100 cannot prestage any of the virtual volumes of a multi-volume dataset into DASD cache 116. Furthermore, even after VTS system 100 has acquired such knowledge and performs prestaging by diligently recalling all the associated virtual volumes of a multi-volume dataset into DASD cache 116 each time a virtual volume is requested, VTS system 100 would have wasted a lot of resources if only a few of the virtual volumes of the multi-volume dataset are actually going to be accessed by the application within host computer 110.
In order for VTS system 100 to be able to intelligently handle multi-volume dataset, the first step is for VTS system 100 to identify each multi-volume dataset by automatically capturing certain information on every multi-volume dataset. VTS system 100 can automatically capture information on multi-volume datasets via one of the following two methods. If a multi-volume dataset is generated by an application within host computer 110 having an Advanced Policy Management enabled, the Library Universal Mount (LUM) for each subsequent mount will contain the name of the first (or previous) virtual volume in the multi-volume dataset as the “clone” source virtual volume. Thus, the first method is to intercept those clone LUM commands, deciphers the clone LUM commands, and then builds a chain of logical volume names that belongs to a multi-volume dataset. The chain of logical volume names should include the previous virtual volume in the chain of logical volume names, and the position of the current virtual volume in the chain of logical volume names. One chain of logical volume names is associated with one multi-volume dataset.
The second method is to “snoop” all headers-build chain list from the previous logical volume listed in the multi-volume dataset header, preferably by using VTS microcode. The headers-build chain list would allow VTS system 100 to build a chain of logical volume names that belong to a multi-volume dataset. Again, the chain of logical volume names should include the previous virtual volume in the chain of logical volume names, and the position of the current virtual volume in the chain of logical volume names.
Chains of logical volume names formed by one of the above-mentioned two method are preferably stored in a chain database 127 within automatic storage manager administrator 126. With reference now to
After VTS system 100 has identified every multi-volume dataset, VTS system 100 is ready to perform prestaging in response to an access request to any of the multi-volume datasets stored within VTS system 100. Referring now to
However, if virtual volume N belongs to a multi-volume dataset, a determination is made as to the percentage of time all virtual volumes in the multi-volume dataset were accessed when virtual volume N was requested previously. If the percentage of time is higher than a first high threshold (such as 90%), then all virtual volumes in the multi-volume dataset are recalled from the tapes and sent to DASD cache 116 (from
Otherwise if the percentage of time is not higher than the first high threshold, then a determination is made as to the percentage of time virtual volumes within the multi-volume dataset were accessed randomly or sequentially when virtual volume N was requested previously. If the percentage of time is higher than a second high threshold (such as 80%), then all virtual volumes in the multi-volume dataset are recalled from the tapes and sent to DASD cache 116 if they are not already in DASD cache 116, as shown in block 304.
Otherwise if the percentage of time is not higher than the second high threshold, then a determination is made as to the percentage of time virtual volumes within the multi-volume dataset were accessed sequentially when virtual volume N was requested previously. If the percentage of time is higher than a first moderate threshold (such as 70%), then all virtual volumes subsequently to virtual volume N in the multi-volume dataset are recalled from the tapes and sent to DASD cache 116 if they are not already in DASD cache 116, as depicted in block 305.
Otherwise if the percentage of time is not higher than the first moderate threshold, then a determination is made as to the percentage of time virtual volume N−M−1 within the multi-volume dataset was accessed when virtual volume N was requested previously. If the percentage of time is higher than a second moderate threshold (such as 60%), then virtual volumes N+1 through 2N−M in the multi-volume dataset are recalled from the tapes and sent to DASD cache 116 if they are not already in DASD cache 116, as shown in block 306.
Otherwise if the percentage of time is not higher than the second moderate threshold, then a determination is made as to the percentage of time virtual volume N+1 within the multi-volume dataset was accessed when virtual volume N was requested previously. If the percentage of time is higher than a first low threshold (such as 50%), then virtual volume N+1 in the multi-volume dataset is recalled from the tapes and sent to DASD cache 116 if it is not already in DASD cache 116, as depicted in block 307.
Otherwise if the percentage of time is not higher than the first low threshold, then a determination is made as to the percentage of time virtual volume N−1 within the multi-volume dataset was accessed when virtual volume N was requested previously after virtual volume N−1 had been mounted. If the percentage of time is higher than a second low threshold (such as 50%), then virtual volume N+1 in the multi-volume dataset is recalled from the tapes and sent to DASD cache 116 if it is not already in DASD cache 116, as depicted in block 308. If the percentage of time is not higher than the second low threshold, then no prestaging is performed, as depicted in block 309.
As has been described, the present invention provides a method and apparatus for handling multi-volume datasets within a tape storage system.
It is also important to note that although the present invention has been described in the context of hardware, those skilled in the art will appreciate that the mechanisms of the present invention are capable of being distributed as a program product in a variety of forms, and that the present invention applies equally regardless of the particular type of signal bearing media utilized to actually carry out the distribution. Examples of signal bearing media include, without limitation, recordable type media such as floppy disks or compact discs and transmission type media such as analog or digital communications links.
While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.
