Multivolume group management

A multivolume management method, executed by a computer, includes storing a dataset over a plurality of media storage devices, wherein the plurality of media storage devices has a corresponding plurality of physical identifiers, generating a conversion table that assigns the plurality of physical identifiers to a corresponding plurality of sequentially ordered virtual identifiers, wherein each physical identifier is uniquely assigned to one virtual identifier, receiving a request for the dataset, wherein the request references the plurality of sequentially ordered virtual identifiers, in response to receiving the request, generating a response comprising an ordered list of physical identifiers using the conversion table, and responding to the request with the response. A computer system and computer program product corresponding to the above method are also disclosed herein.

BACKGROUND OF THE INVENTION

The present invention relates generally to storage systems, and more specifically, to the management of datasets that span multiple storage volumes.

In the field of storage systems, a dataset that is too large to fit on any one single storage volume may be stored over multiple volumes. When a dataset spans multiple volumes, it is important to manage all of the volumes as a group. One problem with multivolume group management is keeping the volumes in a coherent order, especially when individual volumes become corrupt and require replacement volumes.

SUMMARY

As disclosed herein, a multivolume management method, executed by a computer, includes storing a dataset over a plurality of media storage devices, wherein the plurality of media storage devices has a corresponding plurality of physical identifiers, generating a conversion table that assigns the plurality of physical identifiers to a corresponding plurality of sequentially ordered virtual identifiers, wherein each physical identifier is uniquely assigned to one virtual identifier, receiving a request for the dataset, wherein the request references the plurality of sequentially ordered virtual identifiers, in response to receiving the request, generating a response comprising an ordered list of physical identifiers using the conversion table, and responding to the request with the response. A computer system and computer program product corresponding to the above method are also disclosed herein.

DETAILED DESCRIPTION

Embodiments of the present invention relate generally to storage systems, and more specifically, to the management of datasets that span multiple storage volumes. Datasets that are too large for any one storage medium, or volume, must be stored across several volumes. In order to access such a dataset in its entirety, all of its volumes must be available. An important aspect of multivolume dataset management is maintaining an accurate accounting of all of the volumes. To ensure the proper sequence and contiguity of the dataset, it is important to keep the volumes in the correct order as well. One approach is to physically label each volume. However, when a volume becomes corrupt or is otherwise replaced, the replacement volume's label may not conform to the labelling system. Thus, it is necessary to manage multivolume groups using labels that correspond to each volume's identifier.

It should be noted that references throughout this specification to features, advantages, or similar language herein do not imply that all of the features and advantages that may be realized with the embodiments disclosed herein should be, or are in, any single embodiment of the invention. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, discussion of the features, advantages, and similar language, throughout this specification may, but do not necessarily, refer to the same embodiment.

These features and advantages will become more fully apparent from the following drawings, description and appended claims, or may be learned by the practice of the invention as set forth hereinafter. The present invention will now be described in detail with reference to the figures.

FIG. 1is a block diagram depicting an example of a multivolume management system100in accordance with embodiments of the present invention. As depicted, multivolume management system100includes tape library110, drives120A-120C, tape cartridges130A-130E, enclosure140, robot150, labeler160, slot170, and server180. Tape library110may enable server180to access data on tape cartridges loaded into tape library110. Tape library110may also label tape cartridges in order to organize or otherwise manage multivolume datasets.

Tape library may include multiple drives120A-120C, tape cartridges130A-130E in enclosure140, robot150, labeler160, and import/export slot170. Drives120A-120C may include any data storage device that is capable of receiving tape cartridges in order to read and write data to/from the cartridge. Tape cartridges130A-130E may include any sort of magnetic tape storage device that is compatible with one or more of the drives120A-120C. Tapes that are not currently inserted into a drive may be stored in enclosure140. In some embodiments, there are more or fewer drives in tape library110, and/or enclosure140may hold more or fewer tape cartridges.

Robot150may include any automated means of loading and unloading tapes from enclosure140into a drive. In some embodiments, robot150identifies particular tape cartridges by scanning an identifying barcode associated with each tape cartridge. To eliminate redundant scanning, robot150may keep track of the location of previously-identified tape cartridges within enclosure140. In one embodiment, robot150receives instructions from server180to select a tape cartridge from enclosure140and insert the tape cartridge in an available drive. For example, robot150may select and remove tape cartridge130C from enclosure140and insert tape cartridge130C in drive120B. Tape library may monitor the availability of drives (e.g. whether or not a drive currently has a tape loaded into it), or may be instructed as to the availability of drives by tape library110, server180, or the like.

Labeler160may label tape cartridges according to an organizational system. In some embodiments, labeler160receives instructions from server180to label or relabel a tape cartridge. As depicted inFIG. 1, tape cartridge130A is positioned such that it is available for labeling by labeler160. Thus, server180may provide instructions to labeler160to label or relabel tape cartridge130A. Labeler160may print an adhesive barcode label and adhere the label to a tape cartridge. If relabeling, labeler160may remove a previous label, or apply an adhesive label over a label being replaced. In some embodiments, labeler160labels a tape cartridge with by writing to a memory storage device associated with the tape cartridge, such as an RFID tag, which may be rewriteable. In response to instructions from server180, robot150may remove tape cartridges from enclosure140and place in a location accessible to labeler160for labeling.

Slot170may provide access to tape library110so that tape cartridges can be imported and exported from enclosure140. Slot170may provide manual access to cartridge storage areas in enclosure140. In some embodiments, robot150transfers tape cartridges to and from slot170for import and export. For example, in response to a request from server180, robot150may transfer a cartridge from slot170into enclosure140, or remove a cartridge from enclosure140and export the cartridge via slot170.

Sever180may include any computer capable of interfacing with tape library110in order to read and/or write datasets to/from tape cartridges. In some embodiments, server180manages multivolume datasets by tracking the location of tape cartridges in enclosure140and/or drives120A-120C, as well as how datasets are defined (e.g. as ranges of physical IDs or virtual IDs). Server180may instruct labeler160to label tape cartridges with physical labels. In some embodiments, server180stores, generates, and updates conversion tables, such as conversion table300inFIGS. 3A and 3B.

FIG. 2is a block diagram depicting an example of a cartridge labeling system200in accordance with embodiments of the present invention. As depicted, cartridge labeling system200includes tape cartridge130with physical label210, labeler160, and server180. Server180may instruct labeler160to provide physical label210to tape cartridge130.

Tape cartridge130may have a physical label210. Physical label210may be an original or replacement label for tape cartridge130. Physical label210may be a barcode label and may be optically scannable by a barcode reader that may be associated with robot150, slot170, and/or labeler160. In some embodiments, physical label210is an RFID tag containing portions of memory to which labeler160may write or rewrite data. In other embodiments, the media storage volume is not a tape cartridge such as cartridge130, but a hard drive, flash drive, floppy drive, optical disc, or the like.

Labeler160may apply physical label210onto tape cartridge130. In some embodiments, physical label210is an adhesive barcode label that labeler160prints and applies onto tape cartridge130. Physical label210may be an optically-scannable label, such as a QR code, UPC-style linear barcode, or the like. Labeler130may replace labels by applying a newly-printed label over the replaced label. Labeler160may receive instructions to label tape cartridge130from server180. In some embodiments, labeler160prints labels using an inkjet or laser-jet printer, and stores sheets containing blank labels in a storage tray or reel.

FIGS. 3A and 3Bare tables depicting examples of a conversion table300in accordance with embodiments of the present invention. As depicted,FIGS. 3A and 3Beach have a physical ID column and virtual ID column. Conversion table300enables a group volume request for virtual IDs to be translated into physical IDs. Each physical ID may be represented on a cartridge with a physical label such as physical label210on tape cartridge130.

FIG. 3Adepicts a conversion table that may be initially generated from a group of tape cartridges whose physical IDs are sequential (e.g., PHY001-PHY005). When storing a multivolume dataset for the first time, it is easy to manage the multiple volumes because a user may select volumes that already have sequential physical IDs. Server180may then assign sequential virtual IDs (e.g., V5001-V5005) to match the physical IDs.

FIG. 3Bdepicts a conversion table that has been updated after one of the volumes of a multivolume group has been replaced. Storage volumes such as tape cartridge130may encounter read/write errors that necessitate replacement of the entire cartridge with a new cartridge. InFIG. 3B, the cartridge having a physical ID of PHY003 encountered such an error, so the data stored on it may be transferred to a new cartridge, which has a physical ID of PHY006. Now the dataset can no longer be described as a simple sequential range (e.g. PHY001-PHY005 described the dataset inFIG. 3A) but must be described as PHY001-PHY002, PHY004-006. Conversion table300may be updated so that the virtual ID V5003 now refers to PHY006 instead of PHY003. Thus, the dataset may still be described as a simple sequential range via the use of virtual IDs (in this case, V5001-V5005 still describe the dataset both before and after the replacement of cartridge PHY003 with PHY006).

FIG. 4is a flow chart depicting an example of a multivolume management method400in accordance with embodiments of the present invention. As depicted, multivolume management method400includes storing (410) dataset, labeling (420) storage devices, generating (430) conversion table, receiving (440) request for dataset, generating (450) response to request, and responding (460) to the request. Multivolume management method400facilitates the management of datasets that span multiple volumes by ensuring that all of the volumes which make up the dataset can be kept in sequential order.

Storing (410) a dataset on storage devices may include writing a dataset to multiple storage devices such as tape cartridges. Datasets that are too large to fit on any one storage device may span across several. For example, with reference toFIG. 1, if each tape cartridge is capable of storing one gigabyte, and a dataset is 4.5 gigabytes in size, then the dataset may span tape cartridges130A-130E, with one gigabyte being stored on cartridge130A, one gigabyte on cartridge130B, one gigabyte on cartridge130C, one gigabyte on cartridge130D, and the remaining 0.5-gigabyte portion of the dataset on cartridge130E. Thus, in order to describe the dataset, tape cartridges130A-130E would all need to be available, and in the proper sequence. In some embodiments, sever180writes the dataset to the group of tape cartridges130A-130E and server180is responsible for determining how the dataset spans the multivolume group.

Labeling (420) storage devices may include applying an identifying label to each volume of the multivolume group. In some embodiments, labeler160labels each tape cartridge130A-130E with a unique label. While the volumes of a dataset may originally be labeled with a sequential range of physical IDs, changes to volumes may introduce an out-of-sequence physical ID. In such a case, all volumes may be relabeled with a new label corresponding to the updated virtual IDs in order to maintain the multivolume group's sequential range of IDs Server180may track the pairing of virtual IDs to physical IDs for each cartridge130.

Labeling (420) storage devices with replacement labels may enable a multivolume dataset to be described using a range of sequential IDs in the event that the individual tape cartridges do not have sequential physical labels. For example, referring toFIGS. 3A and 3B, regardless of how many individual cartridges in a multivolume group have been swapped out, by relabeling each volume with a label corresponding to the virtual ID, the possibility of sequentially describing multivolume groups is maintained. The labeling operation420may occur whenever tape library110receives instructions to eject a multivolume group; thus, each volume of the group will be labeled with the most up-to-date virtual ID according to conversion table300, which will ensure that the multivolume group is labeled with a sequential range of label IDs.

Generating (430) a conversion table may include creating a database that links each virtual ID to physical ID. The conversion table may be created by server180or labeler160and stored with server180and/or tape library110. Each time a volume is swapped out and with a replacement volume, the conversion table may be updated so that the replaced volume's virtual ID points to the physical ID of the replacement volume. In some embodiments, conversion tables may be stored as conversion table300inFIGS. 3A and 3B, with an ordered pairing of physical IDs and virtual IDs. Each time labeler160reuses a virtual ID by assigning it to a new physical ID of a replacement cartridge, the conversion table is updated to reflect the new pairing of physical ID and virtual ID. When a label corresponding to a virtual ID replaces a label corresponding to a physical ID, the virtual ID may itself be considered a physical ID from the perspective of a future execution of multivolume management method400.

Receiving (440) a request for a dataset may include receiving a request in the form of a range of virtual IDs. For example, when a user requests a dataset, the request may be in the form of a range of virtual IDs such as “V5001 to V5005” as depicted inFIGS. 3A and 3B. In some embodiments, a user may request a dataset by inputting its range of virtual IDs, or the name of the dataset, which server180may translate into the virtual ID range. Generating (450) a response to request may include translating the virtual ID range request into a response of physical IDs corresponding to those virtual IDs. For example, if a request is for V5001 to V5005, then using conversion table300inFIG. 3A, the response generated would be PHY001, PHY002, PHY003, PHY004, and PHY005, in that order (and not represented as a range). If a request is for V5001-V5005 using conversion table300inFIG. 3B, then the response may be PHY001, PHY002, PHY006, PHY004, and PHY005. This means that the dataset may be reconstructed in a contiguous and proper order by reading from the beginning of PHY001 to PHY002, to PHY006, to PHY004, and finally to the end of the dataset on PHY005.

Responding (460) to the request may include responding with the generated listing of physical IDs in the correct order. In some embodiments, the tape cartridges corresponding to the physical IDs may be loaded into drives120A-120C by robot150and read sequentially in order to provide the dataset to server180. If some or all of the tape cartridges whose physical labels correspond to the request physical IDs are not present in enclosure140and drives120A-120C, then the user may be prompted to insert the missing volumes into tape library110via slot170.

FIG. 5is a flow chart depicting an example of a volume replacement method500in accordance with embodiments of the present invention. As depicted, volume replacement method500includes checking (510) for errors, determining (520) whether errors exist, replacing (530) storage devices, and updating (540) conversion table. Volume replacement method500enables a dataset to remain definable by a virtual ID range even when individual physical volumes are replaced (which also changes the physical IDs of the volumes).

Checking (510) for media storage errors may include checking the integrity of storage volumes for read/write errors. Errors may include any sort of defect in a media storage device that impacts its ability to store information. Upon determining (520) that there is an error, then volume replacement method500may proceed to media replacement operation530; otherwise, volume replacement method500may terminate.

Replacing (530) storage devices may include a removing defective tape cartridge, providing a replacement tape cartridge, and writing to the replacement tape cartridge the portion of the dataset stored previously on the defective tape cartridge. The replacement tape cartridge may have a physical ID that is different from the physical ID associated with the defective tape cartridge.

Updating (540) the conversion table may include updating the physical ID field to reflect that the replacement tape cartridge's physical ID has been assigned to the virtual ID. Following the example of conversion table300inFIGS. 3A and 3B, the conversion table of3B has been updated such that V5003 now corresponds to PHY006. Thus, a request for a dataset in terms of virtual IDs V5001-V5005 will return PHY001, PHY002, PHY006, PHY004, and PHY005 in the appropriate order, since PHY006 replaced defective volume PHY003, which was removed. In some embodiments, the conversion table is updated on-the-fly while volumes are swapped out of a multivolume group that is loaded into tape library110, and when the group is ejected, all of the volumes receive new physical labels corresponding to their virtual ID.

Thus, volume replacement method500detects errors in one or more volumes that make up a multivolume group for a dataset and replace the volumes with new physical media storage. When replacing a volume, the range of physical IDs may be interrupted, so volume replacement method500reassigns the virtual ID of the replaced volume to the replacement volume, thereby enabling a dataset to be defined as an uninterrupted, sequential range of virtual IDs.

FIG. 6is a block diagram depicting components of a computer600suitable for executing the methods disclosed herein. It should be appreciated thatFIG. 6provides only an illustration of one embodiment and does not imply any limitations with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made.

As depicted, the computer600includes communications fabric602, which provides communications between computer processor(s)604, memory606, persistent storage608, communications unit612, and input/output (I/O) interface(s)614. Communications fabric602can be implemented with any architecture designed for passing data and/or control information between processors (such as microprocessors, communications and network processors, etc.), system memory, peripheral devices, and any other hardware components within a system. For example, communications fabric602can be implemented with one or more buses.

Memory606and persistent storage608are computer readable storage media. In the depicted embodiment, memory606includes random access memory (RAM)616and cache memory618. In general, memory606can include any suitable volatile or non-volatile computer readable storage media.

One or more programs may be stored in persistent storage608for execution by one or more of the respective computer processors604via one or more memories of memory606. The persistent storage608may be a magnetic hard disk drive, a solid state hard drive, a semiconductor storage device, read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, or any other computer readable storage media that is capable of storing program instructions or digital information.

Communications unit612, in these examples, provides for communications with other data processing systems or devices. In these examples, communications unit612includes one or more network interface cards. Communications unit612may provide communications through the use of either or both physical and wireless communications links.

I/O interface(s)614allows for input and output of data with other devices that may be connected to computer600. For example, I/O interface614may provide a connection to external devices620such as a keyboard, keypad, a touch screen, and/or some other suitable input device. External devices620can also include portable computer readable storage media such as, for example, thumb drives, portable optical or magnetic disks, and memory cards.

Software and data used to practice embodiments of the present invention can be stored on such portable computer readable storage media and can be loaded onto persistent storage608via I/O interface(s)614. I/O interface(s)614may also connect to a display622. Display622provides a mechanism to display data to a user and may be, for example, a computer monitor.