Method for testing media in a library without inserting media into the library database

[0001] 1. Field of the Invention

[0002] The present invention is related to a mass storage device and more particularly to a mass storage device with removable storage media and methods of testing the removable storage media.

[0003] 2. Background Description

[0004] Data storage systems administering data stored on removable storage media, such as an automated storage media (e.g., tape cartridges) and retrieval library for storing and accessing removable storage media, are well known in the art. Typically, there was no efficient way to test storage media for such storage systems to find out if the media is viable. Testing storage media in a tape library required inserting the media into the library database, performing the test, and ejecting the media. Testing was not possible when the library is full. Normally, hosts systems administered physical volumes in connected data storage subsystems. The hosts loaded volume information into a tape configuration database, a tape management systems database and, perhaps, into a virtual media server database and library manger database in the storage subsystem as well. This time and resource consuming process was necessary to test media for viability. Also, media could not be tested if the library were full.

[0005] Thus, there is a need for a storage media device capable of testing whether storage media is viable and in particular, even when a storage library in the storage media device testing the media is full.

[0006] It is a purpose of the invention to test storage media viability;

[0007] It is another purpose of the invention to test removable storage media viability in a data storage system employing media being tested;

[0008] It is yet another purpose of the invention to test removable storage media viability in a data storage system even when a data library of data volumes stored on removable storage media is full, and so, incapable of inserting additional removable storage media volumes.

[0009] The present invention relates to a storage subsystem, method of testing storage media in the storage subsystem and program product therefor. The storage media, e.g., magnetic tape in a physical volume, is inserted into an input area in the storage subsystem, but not loaded into the subsystem library. The media input area is scanned for physical volumes and a test command is queued for media found. The test storage media is moved to a drive for testing. After testing, the storage media is returned to the input area and the test results may be displayed.

[0014] Turning now to the drawings and, more particularly, FIG. 1 shows an example of a preferred data storage subsystem 100, such as an automated storage media (e.g., tape cartridges) and retrieval library for storing and accessing storage media, wherein physical volumes of storage media are tested for viability independent of and prior to insertion in the library. Although for simplicity of description, application of the present invention is described with reference to a tape cartridge storage subsystem 100, this is for example only. Thus, the present invention has application to any suitable storage subsystem with removable storage media. Further, storage media may be magnetic storage media such as magnetic tape, magnetic disk, optical storage such as compact disk (CD) or digital versatile disk (DVD), or any suitable equivalent non-volatile or volatile storage media.

[0015] In this example the data storage subsystem 100 includes one or more drive units 102 for reading and/or writing data on the physical volumes, e.g., the data storage subsystem 100 may be an IBM 3494 Tape Library Dataserver. Physical volumes or media cartridges 104 may be stored in storage cells in a bulk input or bulk storage rack 106. Typically, a single physical volume 104 can be individually addressed and accessed by a volume serial number (volser). An accessor 108 transports a selected physical volume 104 between a storage cell in bulk input rack 106 and a drive 102. The accessor 108 includes a cartridge gripper 110 for gripping and holding the physical volume 104 during transport. A bar code scanner 112, or similar visual input unit, is mounted on the gripper 110, to “read” labels identifying cartridges with a corresponding volume serial number. An operator console may be included for manual (operator) input, e.g., by an operator interacting with the library or starting media testing. A convenience input/output (I/O) station 116 may also be included for introducing media for testing. As noted hereinabove and depending upon the particular storage media, the drives 102 can be optical disk drives or magnetic disk or tape drives. Correspondingly, the physical volumes 104 can be cartridges or cassettes containing optical or magnetic media (e.g., magnetic tape) or any other suitable removable media and associated drives.

[0016] Thus, according to a preferred embodiment of the present invention, the data storage subsystem 100 tests media viability, e.g., of a tape cartridge 104 newly inserted in a storage cell in bulk storage rack 106 or convenience I/O station 116, without and before inclusion in the local data storage library. So, for example, a customer can insert the untested media in the convenience I/O station 116 or into a storage cell in bulk storage rack 106. The media label is scanned, e.g., by bar code scanner 112, which identifies any cartridges that are present for testing and their volser labels. Then, the media is mounted on the drive 102 and tested for viability using the media input area as storage during the media test. Alternately, the cartridge may be scanned at the drive 102 and the scan results returned to verify which volume was tested.

[0017] FIG. 2 shows an example of block diagram of a preferred data storage system 130 including data storage subsystem 100, such as in the example of FIG. 1 in more detail with like elements labeled identically, connected to host systems 132. The data storage subsystem 100 includes a control unit 120 and library manager (LM) 122. Preferably, the control unit 120 and library manager 122 are in software or firmware, e.g., in microcode stored in read only memory (ROM), running on a typical general purpose processor or processors, microprocessor(s) or embedded processor(s). The control unit 120 controls drive load/unload and related actions of drives 102 and passes host requests to the library manager 122.

[0018] An operator can communicate through operator console 114 with the library manager 122, which controls the accessor 108. A library manager database 124 stores tables and programs for controlling the accessor 108 and includes a table that locates physical volumes 104 in the storage cells. The library manager 122 uses the library manager database 124 for controlling the accessor 108 in retrieving each selected physical volume 104 from its storage cell. Host systems 132 send requests through the control unit 120 to the library manager 122.

[0019] Host systems 132 typically include a data storage system administration program managing a tape configuration database 134 and a tape management systems database 136. Also, typically, the host systems 132 connect over a network 138 to other networked devices (not shown). The data storage system administration program uses the tape configuration database 134 to manage the volumes associated with each data storage subsystem 100 coupled to the particular host 132. The data storage system administration program uses the tape management system database 136 to manage data sets residing on the volumes, including the expiration, owner, access, etc. In addition, the tape configuration database includes a system volume catalog of other data relating to the volumes.

[0020] Previously, the hosts 132 administered every physical volume loaded into the tape configuration database 134, the tape management systems database 136 and, perhaps, the library manger database 124 as well. In addition to consuming both time and resources, though previously unavoidable, entries in these databases 124, 134, 136 are unnecessary just to test media for viability. Advantageously, however, a preferred data storage subsystem 100 avoids this waste of time and resources for media testing by using the media input area, i.e., bulk storage rack 106 and convenience I/O station 116, as temporary storage during the media test. Thus, the host systems 132 are unaware of the presence of test media and test media are tested transparently to the host systems 132.

[0021] FIGS. 3A–C show a flow diagram 140A–C, respectively, providing an example of how storage media is tested without and/or before inclusion in the local data storage library with reference to the subsystem 100 example of FIG. 1 and system example 130 of FIG. 2. First in step 142 the operator selects to the test media. Then, beginning in step 144 the operator selects the input area and test devices, e.g., convenience I/O station 116, or bulk rack 106. In step 146 the input area mode is changed from insert mode to test media mode to prevent the adding the information to the library manager database (124 in FIG. 2) for cartridges that will be inserted for testing. In step 148 the operator is instructed to insert the test media for testing. The operator starts the test in step 150, queuing a Start Test command.

[0022] So, in step 152 the library manger 122 is checked for automatic mode of operation. If the library manger 122 is not in automatic mode, then in step 154 the operator is instructed to place the library manger in auto mode. Once the library manger is in auto mode, whether placed in auto mode in response to step 20 154 or if found in auto mode in step 152, the media test begins in step 156, queuing test media commands into the library command queue, e.g., in library manager database 124, for every cartridge found in the media input area. In step 158, the test media command is fetched from the queue for execution and, the accessor 108 moves the media from the input area 106 or convenience I/O station 116 to one of the selected drives 102. In step 160 the bar code reader 112 scans the feed slot to read the label of the media just inserted and the system is ready to test the media in step 162. When the label is read, the test device is directed to mount the media. When the mount completes, the issuer of the initial command is informed the device is ready and that the label was read. In step 164 the operator is provided with test information indicating success or, failure of the test media command with indications of the type of failure, e.g., a failure message indicating that a volume failed to load into a drive 102. Thus, the operator can easily identify which media is good or bad.

[0023] After the media test completes, the accessor 108 returns the media to its original input area cell, i.e., in bulk storage rack 106 or in convenience I/O station 116, and the operator informed that the test has completed. In step 166 the queue is checked for additional test media commands and, if any remain in the queue, returning to step 158 the next media is fetched for testing. Otherwise, in step 168 the input area is restored for the next media insertion. In step 170, having complete media testing, the system 100 returns to normal operation.

[0024] Advantageously, by avoiding normally storing volumes in storage cells just for testing, a preferred storage subsystem saves time. Furthermore, the media may be tested even if there is no available permanent rack space to hold the media, because the cartridge being tested is moved directly from the media input area to the drive, i.e., bypassing the permanent rack space.

[0025] While the invention has been described in terms of preferred embodiments, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the appended claims.