Optimized tape drive unmounting

A computer-implemented method for faster unmount of tape drives includes generating a batch file to be migrated from a primary storage to a tape media acting as a secondary storage. The size of the batch file is determined based on an amount of available storage space on the tape media between a position in a longitudinal direction of storage (LPOS) and longitudinal position three (LP3) on the tape media. The computer-implemented method further includes migrating the batch file from the primary storage to the tape media mounted on a tape drive. Upon completion of migrating the batch file, the LPOS is within a predetermined threshold distance of LP3 on the tape media.

BACKGROUND

The present invention relates generally to the field of hierarchical storage management, and more particularly to migrating data within a hierarchical storage environment.

Hierarchical storage management is a data storage process that moves data within a tiered storage environment. In a tiered storage environment, at least two types of data storage media are delineated by differences in attributes, such as price, performance, capacity, and function. Accordingly, whether data is stored in one tier or another is defined by the requirements of the data to be stored. Typically, data files stored on high-speed storage media are migrated to slower speed storage media if the data files are not used for a period of time.

SUMMARY

According to one embodiment of the present invention, a computer-implemented method for faster unmount of tape drives is disclosed. The computer-implemented method includes generating, by one or more processors, a batch file to be migrated from a primary storage to a tape media acting as a secondary storage, wherein a size of the batch file is determined based on an amount of available storage space on the tape media between a position in a longitudinal direction of storage (LPOS) and longitudinal position three (LP3) on the tape media. The computer-implemented method further includes migrating, by the one or more processors, the batch file from the primary storage to the tape media mounted on a tape drive, wherein upon completion of migrating the batch file, the LPOS is within a predetermined threshold distance of LP3 on the tape media.

According to another embodiment of the present invention, a computer program product for faster unmount of tape drives is disclosed. The computer program product includes one or more computer readable storage media and program instructions stored on the one or more computer readable storage media. The program instructions include instructions to generate a batch file to be migrated from a primary storage to a tape media acting as a secondary storage, wherein a size of the batch file is determined based on an amount of available storage space on the tape media between a position in a longitudinal direction of storage (LPOS) and longitudinal position three (LP3) on the tape media. The program instructions further include instructions to migrate the batch file from the primary storage to the tape media mounted on a tape drive, wherein upon completion of migrating the batch file, the LPOS is within a predetermined threshold distance of LP3 on the tape media.

According to another embodiment of the present invention, a computer system faster unmount of tape drives is disclosed. The computer system includes one or more computer system includes one or more computer processors, one or more computer readable storage media, and program instructions stored on the computer readable storage media for execution by at least one of the one or more processors. The program instructions include instructions to generate a batch file to be migrated from a primary storage to a tape media acting as a secondary storage, wherein a size of the batch file is determined based on an amount of available storage space on a tape media between a position in a longitudinal direction of storage (LPOS) and longitudinal position three (LP3) on the tape media. The program instructions further include instructions to migrate the batch file from the primary storage to the tape media mounted on a tape drive, wherein upon completion of migrating the batch file, the LPOS is within a predetermined threshold distance of LP3 on the tape media.

DETAILED DESCRIPTION

The use of hierarchical storage management allows an enterprise to reduce the cost of data storage, as well as simplify the retrieval of data from slower storage media. Typically, hierarchical storage management is used for deep archival storage of data that is required to be maintained for a prolonged period at low cost. The need for hierarchical storage management stems from the fact that high-speed storage devices (e.g., solid state drive arrays) are more expensive (per byte stored) than slower speed storage devices (e.g., hard disk drives, optical discs, and magnetic tape drives). With hierarchical storage management, infrequently used data files stored on high-speed storage media are migrated to slower speed storage media if the data files are not used (i.e., accessed) for a certain period of time. When access to the data files are required, data is copied or recalled from the secondary storage to the primary storage. In effect, hierarchical storage management turns a fast disk drive into a cache for the slower mass storage devices.

Generally, data in a hierarchical storage environment is migrated between tiered storage. For example, data is migrated between a primary, high-speed storage media (e.g., hard disk drives and/or solid-state disk drives) and a secondary, slower speed storage media (e.g., magnetic tape drives). The primary storage media (typically the faster storage device) is also known as a tape volume cache (TVC). Oftentimes, data is migrated from a primary, high-speed storage media to a secondary, slower speed storage media during off-peak hours or when workload requirements (e.g., read/write operations) of a storage system(s) is low. For example, batch jobs are collected when system workload requirements are high and later executed when system workload requirements are low.

Whereas data migration from primary storage to secondary storage is often a low priority, accessing data from a secondary storage (i.e., recalling data) is typically a high priority. This stems from the fact that data is oftentimes recalled from a secondary storage to a primary storage based on a relative immediate need for access to the data. For example, if a tape media storing the data to be recalled needs to be mounted on a tape drive currently undergoing a data migration, the tape drive finishes writing the migrated files and thereafter, the tape media is unmounted so that the tape media storing the data to be recalled can be mounted. Accordingly, embodiments of the present invention recognize that the amount of time that it takes to mount a new tape media on a tape drive, and thereby recall the data from the new tape media, is directly dependent on the amount of time it takes before the tape media being utilized for an ongoing migration can be unmounted.

Generally, within a hierarchical storage management system, files are not migrated from a primary storage to a secondary storage on an individual basis. Rather, groups or batches of files are created, in which an entire group or batch is migrated as a single entity. For example, a batch of ten (10) files is migrated from a primary storage device (e.g., a disk array) to a secondary storage device (e.g., a tape library), in which multiple batches of files are written (oftentimes simultaneously) to multiple tape media.

FIG. 1is a flow chart diagram depicting operational steps for generating a group or batch of files for migration from a primary storage to a secondary storage in accordance with at least one embodiment of the present invention. More specifically,FIG. 1illustrates a method for creating a group or batch of files for migration from a primary storage to a secondary storage, in which files selected for migration are added in sequential order (e.g., timewise) to a group or batch.FIG. 1provides an illustration of only one implementation 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 by those skilled in the art without departing from the scope of the invention as recited by the claims.

At step S100, the method creates a batch file (i.e., group of files) for migration from a primary storage media to a secondary storage media, such as a tape media. For example, a batch file is created that contains one or more individual data files.

At step S102, the method adds files to the batch file. In some instances, files are added to the batch file in sequential order. For example, files are automatically added to the batch file in sequential order based on length of time since a file was last accessed. In other instances, files are randomly added to the batch file. For example, a predetermined number of files selected by a user or system administrator for migration are randomly added to the batch file.

At decision step S104, the method determines whether a predetermined threshold value for a batch file is reached. In some embodiments, the predetermined threshold value is a number of files included in the batch file. In other embodiments, the predetermined threshold value is a total data size of the files included in the batch file. If the predetermined threshold value for a batch file is reached (decision step S104YES branch), the method proceeds to step S108. If the predetermined threshold value for a batch file is not reached (decision step S104NO branch), the method proceeds to decision step S106.

At decision step S106, the method determines whether another file requires migration from the primary storage media to the secondary storage media. If another file requires migration from the primary storage media to the secondary storage media (decision step S106YES branch), the method returns to step S102. If another file does not require migration from the primary storage media to the secondary storage media (decision step S106NO branch), the method proceeds to step S108. At step S108, the method migrates the batch file from the primary storage media to the secondary media (e.g., tape media) and the process ends.

Typically, if a request to recall data occurs during migration of a batch file, the on-going migration is completed (i.e., any unwritten files contained in the batch file are written to the tape media) prior to unmounting the tape media so that the tape media storing the data to be recalled can be mounted. However, before a tape media being utilized for an ongoing migration can be unmounted from a tape drive, the following operations must be performed after the ongoing migration of a batch is completed: generating an index construct at the end of the data written to the data partition, generating an end of data (EOD) mark that serves as a designation of the end of the data written to the data partition of the tape media after the index construct, moving the tape media to the beginning of the index partition located at longitudinal position 3 (LP3), and overwriting the index located in the index partition with filesystem meta-data for the data newly migrated to the tape media.

Embodiments of the present invention recognize that the process of unmounting a tape media from a tape drive to which data is currently being migrated or written can be time consuming. Typically, upon completion of a data migration on a tape media, the distance between the position of a last write position <endlpos> (i.e., EOD mark) and longitudinal position 3 (LP3) on the tape media is random. Accordingly, on average, the amount of time required to position the tape head from <endlpos> to LP3is around 50 seconds. Furthermore, in a worst case scenario, if <endlpos> of the tape media is at the furthest possible distance from LP3, the amount of time required to move the position the tape head from <endlpos> to LP3can be upwards of 100 seconds (depending on the Wrap length of the tape media). This stems from the fact that in order to return the tape head from a position near longitudinal position 4 (LP4) to LP3, almost the entire length of the tape media must be wound to return the tape head to LP3. Accordingly, with increasing demand for faster, more powerful and more efficient ways to store and retrieve information, optimization of tape storage remains a key challenge in hierarchical storage systems.

Embodiments of the present invention provide one or more of: features, characteristics, operations and/or advantages to recalling data stored on a secondary storage device, such as magnetic tape media, and generally encompass (i) an improvement to at least the field of hierarchical storage management, and (ii) a technical solution to one or more of challenges in the field of hierarchical storage management. Such challenges in the field of hierarchical storage management may include, but are not limited to, one or more of: (i) limitations in the amount of time it takes before a first tape media can be unmounted from a tape drive in order to mount a second, different tape media on the tape drive, (ii) limitations in the amount of time required before a tape media being utilized for an ongoing migration of data can be unmounted from a tape drive, (iii) limitations in the amount of time it takes to recall or otherwise access data stored on a secondary storage media, such as a tape media, and (iv) limitations in the amount of time it takes to recall or otherwise access data stored on a first tape media that requires mounting on a tape drive that is in the process of writing data migrated from a primary storage media to another tape media. Certain embodiments of the present invention both recognize and address other challenges that are not specifically addressed herein, but are readily understood to be encompassed by the technical solutions described herein.

In various embodiments of the present invention, the size of a group or batch of files generated for migration from a primary storage media to a secondary storage media, such as a tape media, is based, at least in part, on an amount of data that can be written from (<endlpos>) to LP3on the tape media. In other words, a group or batch of files is generated based on an amount of available storage space on a tape media between (<endlpos>) and LP3on the tape media. In doing so, the tape head is positioned at or within a predetermined threshold distance of LP3upon completion of writing the batch file to the tape media. Accordingly, embodiments of the present invention reduce the amount of time to recall data (i.e., an amount of time required before a first tape media being utilized for migration of data can be unmounted in order to mount a second tape media containing the data to be recalled. This stems from the fact that when a recall occurs in accordance with embodiments of the invention, the amount of time required to move the tape head to overwrite an index located in the index partition is limited since the tape head will already be at or near the index located at LP3after completion of the migration.

Referring now to various embodiments of the invention in more detail,FIG. 2is a functional block diagram of a network computing environment, generally designated200, suitable for operation of a storage management program201in accordance with at least one embodiment of the present invention.FIG. 2provides an illustration of only one implementation 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 by those skilled in the art without departing from the scope of the invention as recited by the claims.

Network computing environment200includes host device202, tape library204, and client device206interconnected over network208. In embodiments of the present invention, network208can be a telecommunications network, a local area network (LAN), a wide area network (WAN), such as the Internet, or a combination of the three, and can include wired, wireless, or fiber optic connections. In embodiments of the present invention, network208is a storage area network (“SAN”). Network208provides block-level network access to storage, such as tape library204and storage array214. Network208may include one or more wired and/or wireless networks that are capable of receiving and transmitting data, voice, and/or video signals, including multimedia signals that include voice, data, and video information. In general, network208may be any combination of connections and protocols that will support communications between host device202, tape library204, client device206, and other computing devices (not shown) within network computing environment200.

In various embodiments of the present invention, host device202is a computing device that can be a standalone device, a management server, a web server, a mobile device, or any other electronic device or computing system capable of receiving, sending, and processing data. In other embodiments, host device202represents a server computing system utilizing multiple computers as a server system, such as in a cloud computing environment. In an embodiment, host device202represents a computing system utilizing clustered computers and components (e.g. database server computers, application server computers, web server computers, etc.) that act as a single pool of seamless resources when accessed within network computing environment200. In general, host device202represents any programmable electronic device or combination of programmable electronic devices capable of executing machine readable program instructions and communicating with storage management program201, tape library204, client device206, primary storage file system212, storage array214, linear tape file system (LTFS)216, and other computing devices (not shown) within network computing environment200via a network, such as network208.

Host device202includes storage management system210. In various embodiments, storage management system210can migrate and recall data between a primary storage and a secondary storage. For example, storage management system210can be a Linear Tape File System-Enterprise Edition (LTFS-EE). While reference is made to IBM-specific hardware and/or software components, it should be understood that aspects of the present invention may be applied equally to other storage management library technologies. In various embodiments, storage management system210can be a local or cloud storage and backup system (e.g., a special storage device, group of devices, etc.) and software, firmware, etc., that can have hierarchical storage management functionality, whereby data can be migrated between tiered storage.

Storage management system210includes primary storage file system212and storage array214. For example, primary storage file system212can be an IBM General Parallel File System (GBFS) for distributing and managing data across a primary storage, such as storage array214, that can act as a cache for a secondary storage, such as tape media stored in tape library204. While reference is made to IBM-specific hardware and/or software components, it should be understood that aspects of the present invention may be applied equally to other file system technologies.

Storage management system210further includes linear tape file system (LTFS)216. A LTFS is a file system that allows files stored on tape media (e.g., tape cartridges) in a tape library to be accessed in a similar fashion as files stored on a hard disk or flash drive. It requires both a specific format of data on the tape media and software to provide a file system interface to the data. Each LTFS formatted tape media in the tape library appears as a separate folder under the filesystem mount point. One of ordinary skill in the art will appreciate that applying a file system to a tape drive allows users to organize and search the contents of tape media as they would on hard disk, improving access time for data stored on tape media. For example, LTFS216can be an IBM Linear Tape File System-Library Edition (LTFS-LE) that allows LTFS volumes (i.e., tape media) to be used with a tape library, such as tape library204. While reference is made to IBM-specific hardware and/or software components, it should be understood that aspects of the present invention may be applied equally to other linear tape storage technologies.

In various embodiments, storage management system210can convert input/output requests directed to tape library204to storage array214. For example, storage management system210receives a write request for a record initially directed to be stored on a tape media in tape library204. However, rather than directly writing the data to a tape media of tape library206, storage management program210writes (i.e., “saves” or “stores”) the data as a logical volume (i.e., virtual volume) on a disk cache of storage array214.

In various embodiments, storage management system210can migrate and/or recall data between a primary, high-speed storage media, such as a hard disk, and a secondary, slower speed storage media, such as a tape media. Accordingly, data may remain on storage array214until removal of the data is required, at which point, the data can be migrated to a tape media of tape library204. For example, data can be migrated from a disk cache to a tape media based on an amount of free space on the disk cache falling below and/or equaling a predetermined threshold value. In another example, data can be migrated from a disk cache to a tape media based on length of time since a file was last accessed. In yet another example, data can be migrated from a disk cache to a tape media based on a user or system administrator selecting files for migration.

In various embodiments, storage management system210can receive read requests. Upon receiving a read request, storage management system210can determine whether the data is stored in storage array214. If the requested data is stored in storage array214, the data can be read from a disk in storage array214. However, if the requested data is stored on a tape media in tape library204, storage management system210can recall (i.e., load) the data from the tape media (e.g., a magnetic tape) in tape library204to a disk of storage array214, such that the data is read from the disk. In some embodiments, if the requested data is stored on tape media in tape library204, storage management system210does not load data from the tape media to a hard disk. In these embodiments, information can be read from the tape media.

Although various components of storage management system210are depicted inFIG. 2as being integrated with host device202, in alternative embodiments, various components of storage management system210can be remotely located from host device202. For example, one or more of primary storage file system212, storage array214, and LTFS216can be located on one or more additional computing devices that are logically and/or physically distinct from host device202.

Storage management system210further includes storage management program201. Although storage management program201is depicted inFIG. 2as being integrated with storage management program210, in alternative embodiments, storage management program201can be remotely located from storage management system210. In some embodiments, storage management program201can be a component of storage management system210. For example, storage management program201can be a software component or sub-system of storage management210. In other embodiments, storage management program201can be logically distinct from storage management program201. For example, storage management program can be an application running outside of storage management system210.

Tape library204can be an automated tape storage device that includes a plurality of tape drives for writing to and reading from tape media, such as, but not limited to, single-reel or two-reel magnetic tape cartridges. In an embodiment, tape library204can be an IBM TS3400™ Tape Library or an IBM TS3500™ Tape Library. While reference is made to IBM-specific hardware and/or software components, it should be understood that aspects of the present invention may be applied equally to other tape library technologies. In embodiments of the invention, tape library204can include a plurality of tape media stored in banks or groups of storage slots. For example, tape media may include, but is not limited to magnetic tape cartridges, magnetic tape cassettes, and optical tape cartridges. Tape library204can further include a plurality of slots to hold tape media (e.g., tape cartridges), a barcode reader to identify tape media and an automated method (e.g., a robot) for loading tape media.

Client device206can allow a user to access an application running on host device202and/or communicate with storage management program201via a network, such as network208. Client device206may be a laptop computer, a tablet computer, a netbook computer, a personal computer (PC), a desktop computer, a personal digital assistant (PDA), a smart phone, or any programmable electronic device capable of receiving, sending, and processing data. In general, client device206represents any programmable electronic device or combination of programmable electronic devices capable of executing machine readable program instructions and communicating with host device202, tape library204, and other computing devices (not shown) within computing environment200via a network, such as network208.

Client device206can include user interface218. User interface218can provide an interface between client device206, host device202, and tape library204. In some embodiments, user interface218can be a graphical user interface (GUI) or a web user interface (WUI) and can display text, documents, web browser windows, user options, application interfaces, and instructions for operation, and includes the information (e.g., graphic, text, and sound) presented to a user and the control sequences the user employs to control the program. In some embodiments, user interface218can be mobile application software that provides an interface between client device206, host device202, and tape library204.

FIG. 3is a block diagram illustrating a tape system, generally designated300, in accordance with at least one embodiment of the present invention.FIG. 3provides an illustration of only one implementation 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 by those skilled in the art without departing from the scope of the invention as recited by the claims.

Tape system300includes first and second reels310,320. Magnetic recording tape330is spooled on the first and second reels310,320. Magnetic recording tape330is routed over tape head340for reading and writing data on magnetic recording tape330. Reel motors350,360control the positioning of magnetic recording tape330over the tape head340. The reel310,320, which can supply tape at a particular time, can often be referred to as the “outboard” reel and the reel310,320, which can take up the tape at a particular time, can be referred to as the “inboard” reel. Reel motors350,360can be controlled by control system370, which can include one or more motor operation sensors380A,380Band one or more tape radius sensors370A,370Bwhich can sense the radius R of magnetic recording tape330at the reel310,320the motor350,360is driving. Motor operation sensors380A,380Bcan include electromotive force (EMF) sensors, for example.

FIG. 4Ais a block diagram illustrating an example of data stored on a data partition of a tape media, generally designated400, in accordance with at least one embodiment of the invention.FIG. 4Aprovides an illustration of only one implementation 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 by those skilled in the art without departing from the scope of the present invention as recited by the claims.

One of ordinary skill in the art will appreciate that although data stored in a LTFS appears to behave like data stored on a hard disk, the fundamental sequential nature of writing data to tape media remains. Data is sequentially written to zones (i.e., logical blocks) of a predetermined, fixed size and files are always appended to the end of the tape media. Furthermore, a LTFS is a write-once file system. In other words, if a file stored on one or more data blocks is modified, overwritten or removed from a tape image, the associated data blocks are not freed up. Rather, the memory allocated to the associated data blocks becomes invalid (i.e., the associated data blocks are no longer referenced in an index) and newly added data is written as separate, non-contiguous blocks at the end of the tape media.

Furthermore, one of ordinary skill in the art will appreciate that unlike a read/write command for a block device, such as a hard disk, a read/write command issued to a tape drive does not specify a block number. In embodiments of the present invention, the position of data corresponding to a read/write request can be determined based on the current position of the tape media with respect to the tape head. The current position of the tape media can be retrieved by issuing a “Read Position” command. Similarly, the current position of the tape media can be set to any position by issuing a “Locate/Space” command. When a read/write command is successfully executed, the current position of the tape media is updated.

In embodiments of the present invention, data written to tape media stored in tape library206can include the following information: (i) record, (ii) file mark (“FM”), and (iii) end of data (“EOD”) mark. The term “record” as used herein shall refer to a variable length data sequence on a tape media. The term “file mark” as used herein shall refer to a zero-length separator on a tape media that delimits data (i.e., records) of a particular file. The term “end of data mark” as used herein shall refer to a designation of the end of the data written to a tape media.

As depicted byFIG. 4A, data partition400includes Position 0, Position 1, Position 2, Position 3, Position 4, Position 5, and Position 6. Positions 0-6 demarcate physical units of data (i.e., data blocks) of data partition400. In embodiments of the present invention, blocks can include a single record, part of a record, or multiple records. In some embodiments, data blocks can be fixed in size. In some embodiments, data blocks can be variable in size. Data partition400further includes: Rec #0, Rec #1, Rec #2, Rec #3, Rec #4, and Rec #5. Rec #0 and Rec #1 belong to the same file. Recs #2-#5 belong to the same file, and Rec #5 is the end of the data (as indicated by end of data (EOD) mark located at Position 6 written to data partition400. In embodiments of the invention, when a “READ” command is issued, the current position of the tape head is updated. For example, if the current position of a tape head is at Position 1 and a “READ” command is issued for Rec #3, the tape head is moved to Position 3 and Rec #3 is read. Upon completion of reading Rec #3, the current position of the tape head is updated to Position 4.

FIG. 4Bis a block diagram illustrating an example of data stored on a data partition of a tape media, generally designated400, in accordance with at least one embodiment of the present invention.FIG. 4Bprovides an illustration of only one implementation 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 by those skilled in the art without departing from the scope of the invention as recited by the claims.

Data partition400inFIG. 4Billustrates data partition400inFIG. 4Aafter a “WRITE” command is issued. In embodiments of the invention, a “WRITE” command can be issued for one or more of the following: (i) modifying a record, (ii) overwriting a record, and (iii) adding new data. Data partition400includes Position 0, Position 1, Position 2, Position 3, Position 4, Position 5, Position 6, and Position 7. Positions 0-6 on data partition400inFIG. 4Bcorrespond to Positions 0-6 on data partition400inFIG. 4A. Data partition400inFIG. 4Bfurther includes: Rec #0, Rec #1, Rec #2, Rec #3, Rec #4, Rec #5, and Rec #6. Recs #0-#5 on data partition400inFIG. 4Bcorrespond to Recs #0-#5 on data partition400inFIG. 4A. In embodiments of the invention, “WRITE” operations can append data to the end of the tape media. As depicted by data partition400inFIG. 4B, a “WRITE” command has been issued. Accordingly, since Rec #5 was the last record written to data partition400at Position 5 (signified by the EOD mark at Position 6) inFIG. 4A, Rec #6 can be written at Position 6 on data partition400and the EOD mark can be updated to Position 7.

FIG. 5is a block diagram illustrating an example of a complete partition containing data on a tape media, generally designated500, in accordance with at least one embodiment of the present invention.FIG. 5provides an illustration of only one implementation 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 by those skilled in the art without departing from the scope of the invention as recited by the claims.

In various embodiments, a LTFS volume is comprised of a pair of LTFS partitions—a data partition (i.e., an LTFS partition primarily used for storing data files) and an index partition (i.e., an LTFS partition primarily used to store Index Constructs). Each partition in an LTFS volume includes a Label Construct followed by a Content Area. An LTFS construct as used herein shall be comprised of file marks and records (i.e., logical objects). One type of construct is a Label Construct, which contains identifying information for an LTFS volume. A second type of construct is a Data Extent, which contains file data written as sequential logical blocks. A file consists of zero or more data extents plus associated metadata stored in an Index Construct. A third type of construct is an Index Construct, which contains an index, which is an XML data structure which describes the mapping between files and Data Extents. The Index Construct consists of a file mark, followed by an index, followed by a file mark. The Index of an Index Construct consists of a record that follows the same rules as a Data Extent, but it does not contain file data. In other words, the Index of an Index Construct is written as a sequence of one or more logical blocks of size “block size” using the value stored in the LTFS Label. This sequence of blocks records the Index XML data that holds the file metadata and the mapping from files to Data Extents. The Index XML data recorded in an Index Construct is written from the start of each logical block used. Indexes can also include reference to other Indexes in the volume. References (e.g., back pointers and self pointers) to other Indexes can also be used to maintain consistency between partitions in a volume.

FIG. 6is a block diagram illustrating an exemplary linear serpentine recording, generally designated600, in accordance with at least one embodiment of the present invention. More specifically,FIG. 6is representative of a single tape head writing data to a data partition of a tape media.FIG. 6provides an illustration of only one implementation 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 by those skilled in the art without departing from the scope of the invention as recited by the claims.

One of ordinary skill in the art will appreciate that with a linear serpentine recording, a tape drive includes more tracks than tape heads, although each tape head only writes one track at a time. After making a pass over the whole length of the tape media, all heads shift slightly and make another pass in the reverse direction (i.e. Wrap), writing another set of tracks. This procedure is repeated until all tracks have been written.

Referring now toFIG. 6, a data partition610of a tape media can be seen, wherein LP3and LP4are a recording start position and a recording end position of the data storage area (i.e., data partition) in the longitudinal direction of the tape media, respectively. In the first Wrap (W1), data is recorded from LP3to LP4. In the second Wrap (W2), data is reversely recorded from LP4to LP3. In the third Wrap (W3), data is recorded from LP3to LP4. It should be appreciated that data may continue to be recorded in this alternating pattern based on a total Wrap capacity of the tape media. In various embodiments, an index partition including an index is stored at the beginning of the first Wrap.

As further depicted inFIG. 6, File “A” has been recorded from position LS1to position LE1on the tape media. More particularly, File “A” is recorded in Wrap W3from starting position LS1to LP4, in Wrap W4from LP4to LP3, and in Wrap W5from LP3to position LE1. Additionally, File “B” has been recorded from position LS2to position LE2on the tape media. More particularly, File “B” is recorded in Wrap W5from position LS2to position LP4, and in Wrap W6from position LP4to LE2.

One of ordinary skill in the art will appreciate that although data block numbers are sequential on the tape media, data block numbers do not indicate the recording position and/or direction of recording (i.e., LP3to LP4or vice versa) of a record or file on the tape media itself. Rather, the recording position of a record or file on the tape media is indicated by a position in a longitudinal direction of storage on the tape media (hereinafter referred to as “LPOS”) and a position in a lateral direction perpendicular to the longitudinal direction (hereinafter referred to as “Wrap”). However, although a tape drive reads and writes data based on LPOS and Wrap, a tape drive is unaware of which particular Wrap and LPOS of a particular Wrap a record or file is being recorded.

In various embodiments, when a record and/or file is recorded on a secondary storage media, such as a tape media, storage management program201obtains information on the recording position of the record and/or file. In these embodiments, a tape drive writes a record and/or file to a tape media, and storage management program201obtains the actual position of the record and/or file written on the tape media from the tape drive. More particularly, storage management program201identifies the particular Wrap and LPOS at the start of writing and the particular Wrap and LPOS at the end of writing a particular record and/or file from the tape drive. Storage management program201stores the information on the recording position of the record and/or file in an index on a primary storage media, such as hard disk drive in storage array214, and on a secondary storage media, such as a tape media in tape library204, for read access to the record and/or file.

In some embodiments, storage management program201obtains (e.g., via a small computer system interface (SCSI) command) Wrap and LPOS information from sense data or mode page data indicating the operating state of a tape drive. In these embodiments, the sense data and mode page data can include, in addition to information on a record and/or file recording start position and end position, the positional information of the head, from which the Wrap and LPOS of the head can be obtained. In other embodiments, storage management program201obtains Wrap and LPOS information via a command to specify write data and obtain Wrap and LPOS from a tape drive.

Referring back toFIG. 6, after data is recorded on the tape media, storage management program201obtains information on the starting longitudinal position (LS1) and ending longitudinal position (LE1) of File “A” written to data partition610of the tape media. Similarly, storage management program201obtains information on the starting longitudinal position (LS2) and ending longitudinal position (LE2) of File “B” written to data partition610of the tape media. Additionally, storage management program201obtains the starting Wrap (WS1) and the ending Wrap (WE1) of positions LS1and LE1. Similarly, storage management program201obtains the starting Wrap (WS2) and the ending Wrap (WE2) of positions LS2and LE2. Accordingly, an extent for File “A” including LS1at WS1(i.e., Wrap W3) and LE1at WE1(i.e., Wrap W5) is appended to an index. Similarly, an extent for File “B” including LS2at WS2(i.e., Wrap W5) and LE2at WE2(i.e., Wrap W6) is appended to an index. In some embodiments, storage management program201stores the information associated with the recording positions as extents in an index on a primary storage media, such as a hard disk in disk array216(shown inFIG. 2). In other embodiments, storage management program201issues a command to the tape drive to write the information associated with the recording position as extents in an index on the tape media.

FIG. 7is an exemplary index, generally designated700, including Wrap and LPOS information obtained in accordance with at least one embodiment of the present invention. More particularly,FIG. 7illustrates Wrap and LPOS information recorded as an extent in an index located in an index partition of a tape media.FIG. 7provides only an illustration of only one implementation 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 by those skilled in the art without departing from the scope of the invention as recited by the claims.

As depicted inFIG. 7, an extent710created in index700containing Wrap and LPOS information of data written to a tape media can be seen. The boldfaced portion of the index is extent710, of which the bolded, italicized portion of extent710is the information corresponding to the recording position of the record and/or file. In various embodiments, the information written to an extent includes, but is not limited to: (i) the offset of the file (<fileoffset>), (ii) the block number at which recording of the file is started (<startblock>), (iii) the byte count (<bytecount>), (iv) the file-recording start position (<startwrap> and <startlpos>), and (v) the file-recording end position (<endwrap> and (<endlpos>).

FIG. 8is a flow chart diagram depicting operational steps for generating a group of files to be migrated from a primary storage media to a secondary storage media in accordance with at least one embodiment of the present invention. More specifically,FIG. 8illustrates an algorithm for creating a group or batch of files for migration to a tape media, in which the size of a group or batch of files generated is based on an amount of data that can be stored between a LPOS (<endwrap> and <endlpos>) and LP3on the tape media.FIG. 8provides an illustration of only one implementation 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 by those skilled in the art without departing from the scope of the invention as recited by the claims.

At step S800, storage management program201calculates the size (R) of data that can be written to a tape media (T) between LPOS (<endwrap> and <endlpos>) and LP3on the tape media. One of ordinary skill in the art will appreciate that the amount of data (i.e., storage capacity) that can be written in a single Wrap can be determined based on the type (i.e., manufacturer and model) of tape media. For example, if a tape cartridge has a maximum capacity of 300 GB and a total Wrap count of 10, then each Wrap can store 30 GB of data. Thus, the amount of free data space between LPOS (<endwrap> and <endlpos>) and LP3, and therefore, the amount of data that can be written between LPOS and LP3, can be determined.

In those embodiments where storage management program201calculates R(T) for an unmounted tape media stored in tape library204, R(T) is calculated based on the LPOS (i.e., <endwrap> and <endlpos>) and LP3on the tape media. In some embodiments, where storage management program201calculates R(T) for a tape media utilized during an ongoing migration, R(T) is calculated based on the LPOS (<endwrap> and <endlpos>) upon completion of writing a currently migrated record and/or file to the tape media.

At step S802, storage management program201selects a tape media for migration of data from a primary storage media. In various embodiments, storage management program201selects a tape media based on, but not limited to, one or more of the following: tape media having at least a predetermined amount of available storage space, the amount of available storage space on a tape media, an amount of storage space between a LPOS (i.e., <endwrap> and <endlpos>) and LP3on the tape media, whether a tape media is currently mounted on a tape drive or unmounted (e.g., archived in a tape library), and (v) whether a tape drive is currently migrating data to a mounted tape media.

At step S804, storage management program201determines a group or batch file size for migration of data from a primary storage media to the selected tape media. In various embodiments, the size of the group or batch of files is based on an amount of available storage space between the LPOS (i.e., <endwrap> and <endlpos>) and LP3on the tape media. In other words, the size of a group or batch of files is calculated such that a tape head is positioned at or within a predetermined threshold distance of LP3upon completion of writing the group or batch of files to a selected tape media. In some embodiments, the predetermined threshold distance of a tape head position with respect to LP3is on a particular Wrap having a longitudinal recording direction from left to right (i.e., from LP3to LP4). In some embodiments, the predetermined threshold distance of a tape head position with respect to LP3is on a particular Wrap having a longitudinal recording direction from right to left (i.e., from LP4to LP3).

In some embodiments, the size of the batch file is based on an amount of available storage space between the LPOS (i.e., <endwrap> and <endlpos>) and the next successive LP3on the tape media. In other words, the size of a group or batch of files is calculated such that a tape head is positioned at or within a predetermined threshold distance of the next successive LP3upon completion of writing the group or batch of files to a selected tape media.

Referring now toFIG. 9, a block diagram illustrating an exemplary linear serpentine recording, generally designated900, after migrating a group or batch of files from a primary storage to a secondary storage in accordance with at least one embodiment of the process illustrated inFIG. 8can be seen. For example, if <endlpos> is “X” and <endwrap> is Wrap W3, and the next successive LP3 is on Wrap W4, then the amount of available storage space R(T) is the amount of available storage space from position “X” to position LP4on Wrap W3, plus the amount of available storage space from position LP4on Wrap W4to the position LP3on Wrap W4. Accordingly, in this example, storage management program201would generate a batch file (BF) that contains an amount of data such that after writing the batch file to the selected tape media, the <endlpos> is within a threshold distance (TD) of LP3on Wrap W4.

Referring now toFIG. 10, a block diagram illustrating an exemplary linear serpentine recording, generally designated1000, after migrating a group or batch of files from a primary storage media to a secondary storage media in accordance with at least one embodiment of the process illustrated inFIG. 8can be seen. For example, if <endlpos> is “X” and <endwrap> is Wrap W3, and the next successive LP3is on Wrap W4, then the amount of available storage space R(T) is the amount of available storage space from position “X” to position LP4on Wrap W3, plus the amount of available storage space from position LP4on Wrap W4to the position LP3on Wrap W4. Accordingly, in this example, storage management program201would generate a batch file (BF) that contains an amount of data such that after writing the batch file to the selected tape media, the <endlpos> is within a threshold distance (TD) of LP3on Wrap W5.

In some embodiments, the size of the batch file is based on an amount of available storage space between the LPOS (i.e., <endwrap> and <endlpos>) and any subsequent LP3on the tape media. In other words, the size of a group or batch of files is calculated such that a tape head is positioned at or within a predetermined threshold distance of a subsequent LP3upon completion of writing the group or batch of files to a selected tape media. For example, referring back toFIG. 8, if <endlpos> is “X” and <endwrap> is Wrap W3, the next LP3would be at the end of Wrap W4, the next LP3thereafter would be at the beginning of Wrap W5, and the next LP3thereafter would be at the end of Wrap W6. Thus, if storage management program201selects LP3at the end of Wrap W6, then the amount of available storage space R(T) from position “X” and LP3at the end of Wrap W6is the amount of available storage space from position “X” to position LP4on Wrap W3, plus the amount of available storage space from position LP4on Wrap W4to the position LP3on Wrap W4, plus the amount of available storage space from position LP3on Wrap W5to the position LP4on Wrap W5, plus the amount of available storage space from position LP4on Wrap W6to the position LP3on Wrap W6. Accordingly, in this example, storage management program201would generate a batch file that contains an amount of data such that after writing the batch file to the selected tape media, the <endlpos> is within a threshold distance of LP3on Wrap W6or within a threshold distance of LP3on Wrap W7.

In some embodiments, storage management program201performs parallel migration of batch files. In these embodiments, storage management program201selects a number of tape media for migration of data. Thus, the size of each batch file generated for parallel processing is based on an amount of available storage space between the LPOS and a position LP3 of particular tape media selected for data migration.

Returning back toFIG. 8, at step S806, storage management program201adds individual files to the batch file. In various embodiments, storage management program201adds individual files to the batch file based on an amount of available storage space between the LPOS (i.e., <endwrap> and <endlpos>) and LP3on the tape media. In other words, storage management program201adds files to the batch file until the amount of data of the batch file is such that a tape head is positioned at or within a predetermined threshold distance of LP3upon completion of writing the group or batch of files to a selected tape media.

In some embodiments, files are added to the batch file in sequential order. For example, files are automatically added to the batch file in sequential order based on length of time since a file was last accessed. In other embodiments, files are randomly added to the batch file. For example, random files are selected irrespective of the length of time since a file was last accessed. In any of these embodiments, storage management program201adds individual files to the batch file such that the batch file size falls within a predetermined range of an amount of available storage space between a LPOS and a position LP3of a tape media previously selected for migration of data.

At decision step S808, storage management program201determines whether the size of the batch file is such that a tape head will be positioned at or within a predetermined distance of LP3upon completion of writing the group or batch of files to a selected tape media. In some embodiments, files added to the batch file undergo data compression, and as a result, are migrated as compressed files within the batch file. In these embodiments, storage management program201determines a predicted size of the batch file after compression when calculating the total size of the files included in the batch file. For example, storage management program201determines a predicted size based on a predetermined compression rate for a particular file extension corresponding to the batch file. In other embodiments, files added to the batch file do not undergo data compression. In these embodiments, storage management program201determines an actual size of the batch file.

If storage management program201determines that the size of the batch file is such that a tape head will not be positioned at or within a predetermined threshold distance of LP3upon completion of writing the group or batch of files to a selected tape media (decision step S808NO branch), storage management program201returns to step S806. In some embodiments, the size of the batch file is determined to be too small such that a tape head will be positioned greater than a predetermined threshold distance of LP3upon completion of writing the group or batch of files to a selected tape media. In some embodiments, the size of the batch file is determined to be too large such that a tape head will be positioned greater than a predetermined threshold distance of LP3upon completion of writing the group or batch of files to a selected tape media.

If storage management program201determines that the size of the batch file is such that a tape head will be positioned at or within a predetermined threshold distance of LP3upon completion of writing the group or batch of files to a selected tape (decision step S808YES branch), storage management program201stops adding files and migrates the batch file to the preselected tape media at step S810.

FIG. 11is a flow chart diagram depicting operational steps for recalling data stored on an unmounted tape media in accordance with at least one embodiment of the present invention.FIG. 11provides an illustration of only one implementation 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 by those skilled in the art without departing from the scope of the invention as recited by the claims.

At decision step1100, storage management program201determines whether the tape media storing the data to be recalled is mounted on a tape drive. If storage management program201determines that the tape media storing the data to be recalled is not mounted on a tape drive (decision step S1100NO branch), storage management program201proceeds to step S1102. If storage management program201determines that the tape media storing the data to be recalled is mounted on a tape drive (decision step S1100YES branch), storage management program201proceeds to decision step S1200ofFIG. 12.

At decision step S1102, storage management program201determines whether a tape drive is available for mounting the tape media storing the data to be recalled. For example, a tape drive is available for mounting a tape media if another tape media is not currently mounted on the tape drive. If storage management program201determines that a tape drive is currently unavailable to mount the tape media storing the data to be recalled (decision step S1102NO branch), storage management program201proceeds to step S1104. If storage management program201determines that a tape drive is currently available to mount the tape media storing the data to be recalled (decision step S1102YES branch), storage management program201proceeds to step S1106.

At step S1104, storage program201unmounts a tape media from a tape drive. In some instances, a tape drive cannot be unmounted because of an ongoing migration (i.e., the tape drive is currently writing data to a tape media). In an embodiment, storage management program201can unmount a tape media upon completion of the data migration. In an embodiment, storage management program201can unmount a tape media after pausing or otherwise suspending an on-going migration. For example, storage management program201can suspend an on-going migration in response to determining that no tape drives are available for mounting the tape media storing the data to be recalled.

In embodiments of the present invention, prior to unmounting a tape media from a tape drive undergoing a data migration, the following operations, irrespective of whether a migration is completed or suspended, can be performed: generating an index construct at the end of the data written to the data partition, generating an end of data (EOD) mark that serves as a designation of the end of the data written to the data partition of the tape media after the index construct, moving the tape media to the beginning of the index partition located at LP3, and overwriting the index located in the index partition with filesystem meta-data (e.g., filename, date stamps, folder names, and location of the file content) for the data newly migrated to the tape.

Typically, upon completion of a data migration to a tape media, the distance between the <endlpos> of the tape media and LP3is random. Accordingly, on average, the amount of time required to position the tape head from <endlpos> to LP3is around 50 seconds. Furthermore, in a worst case scenario, if <endlpos> is at the furthest possible distance from LP3on the tape media, the amount of time required to position the tape head from <endlpos> to LP3 can be upwards of 100 seconds (depending on the Wrap length of the tape media). This stems from the fact that in order to return the tape head from a position near LP4 to LP3, almost the entire length of the tape media must be wound to return to LP3on the tape media.

However, according to embodiments of the present invention, the amount of time required to unmount a tape media is reduced to several seconds. This stems from the fact that batch files are created such that upon completion of migrating a batch file to a particular tape media, the <endlpos> on the tape media is at or near LP3. Accordingly, the amount of time required to move the position the tape head from <endlpos> to the beginning of the index partition located at LP3 (and thereby unmount a tape media) is substantially reduced.

At step S1106, storage management program201mounts the tape media storing the data to be recalled on an available tape drive. For example, storage management program201issues a mount command to tape library206to retrieve the tape media from tape library206and mount the tape media on a tape drive.

At step S1108, storage management program201recalls the data from the tape media and the process ends. For example, storage management program201issues a read command to the tape drive, thereby updating the current position of the tape head to the beginning of the data to be recalled from the tape media.

FIG. 12is a flow chart diagram depicting operational steps for recalling data stored on a mounted tape media in accordance with at least one embodiment of the present invention.FIG. 12provides an illustration of only one implementation 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 by those skilled in the art without departing from the scope of the invention as recited by the claims.

At decision step S1200, storage program201determines whether the tape media storing the data to be recalled is being utilized for an ongoing migration (i.e., a tape drive is currently writing data to the tape media). If storage management program201determines that the tape media storing the data to be recalled is being utilized for an ongoing migration (decision step S1200YES branch), storage management program201proceeds to step S1202. If storage management program201determines that the tape media storing the data to be recalled is not being utilized for an ongoing migration (decision step S1200NO branch), storage management program201proceeds to step S1204.

At step S1202, storage management program201determines a course of action for the ongoing migration. In some embodiments, storage management program201waits for the ongoing migration of data written to the tape media storing the data to be recalled to be completed. In some embodiments, storage management program201stops the ongoing migration of data written to the tape media storing the data to be recalled when the position of the tape head is within a predetermined threshold distance of LP3, regardless of whether or not the entire batch file has been migrated to the tape media. In some embodiments, storage management program201pauses or otherwise suspends the ongoing migration of data written to the tape media storing the data to be recalled. For example, storage management program201suspends an on-going migration in response to determining that the tape media storing the data to be recalled is being utilized for an ongoing migration.

At step S1204, storage management program201recalls the data from the tape media. For example, storage management program201issues a read command to the tape drive, thereby updating the current position of the tape head to the beginning of the data to be recalled from the tape media. In some embodiments, prior to updating the current position of the tape head to the beginning of the data to be recalled, the following operations can be performed: (i) appending an index construct at the end of the data written to the data partition, (ii) appending an end of data (EOD) mark at the end of the index construct that serves as a designation of the end of the data written to the data partition of the tape media, (iii) moving the tape media to the beginning of the index partition located at LP3, and (iv) overwriting the index located in the index partition with filesystem meta-data (e.g., filename, date stamps, folder names, and location of the file content) for the data newly migrated to the tape media. Accordingly, in these embodiments, information about the data migrated to the tape media can be appended to an index construct and the index located in the index partition is overwritten prior to recalling the data.

In other embodiments, information about the data migrated to the tape media can be appended to an index construct and the index located in the index partition is overwritten after recalling the data. In these embodiments, one or more of the following operations can be performed after recalling the data from the tape media: (i) appending an index construct at the end of the data written to the data partition, (ii) appending an end of data (EOD) mark at the end of the index construct that serves as a designation of the end of the data written to the data partition of the tape media, (iii) moving the tape media to the beginning of the index partition located at LP3, and overwriting the index located in the index partition with filesystem meta-data (e.g., filename, date stamps, folder names, and location of the file content) for the data newly migrated to the tape media. For example, storage management program201obtains and temporarily stores information to be appended in the index on a primary storage media, such as disk cache of storage array116. Upon completion of the data recall, storage management program201transmits the information temporarily stored back to the tape drive to be appended to the index. It should be appreciated that by appending an index construct at the end of the data in the data partition and/or overwriting the index located in the index partition after recalling the data, the data can be recalled faster because the tape head position does not have to be moved to the index partition of the tape media (located at LP3) and then again moved to a position on the tape media corresponding to the beginning of the data to be recalled.

FIG. 13is a block diagram depicting components of a computing device, generally designated1300, suitable for executing storage management program201, host device202, tape library204, client device206, storage management system210, and/or any computing devices generally depicted inFIG. 2in accordance with at least one embodiment of the present invention. Computing device1300includes one or more processor(s)1304(including one or more computer processors), communications fabric1302, memory1306including, RAM1316and cache1318, persistent storage1308, communications unit1312, I/O interface(s)1314, display1322, and external device(s)1320. It should be appreciated thatFIG. 13provides 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, computing device1300operates over communications fabric1302, which provides communications between computer processor(s)1304, memory1306, persistent storage1308, communications unit1312, and input/output (I/O) interface(s)1314. Communications fabric1302can be implemented with any architecture suitable for passing data or control information between processor(s)1304(e.g., microprocessors, communications processors, and network processors), memory1306, external device(s)1320, and any other hardware components within a system. For example, communications fabric1302can be implemented with one or more buses.

Memory1306and persistent storage1308are computer readable storage media. In the depicted embodiment, memory1306includes random-access memory (RAM)1316and cache1318. In general, memory1306can include any suitable volatile or non-volatile one or more computer readable storage media.

Program instructions for storage management program201can be stored in persistent storage1308, or more generally, any computer readable storage media, for execution by one or more of the respective computer processor(s)1304via one or more memories of memory1306. Persistent storage1308can be a magnetic hard disk drive, a solid-state disk drive, a semiconductor storage device, read-only memory (ROM), electronically erasable programmable read-only memory (EEPROM), flash memory, or any other computer readable storage media that is capable of storing program instructions or digital information.

Communications unit1312, in these examples, provides for communications with other data processing systems or devices. In these examples, communications unit1312can include one or more network interface cards. Communications unit1312may provide communications through the use of either or both physical and wireless communications links. In the context of some embodiments of the present invention, the source of the various input data may be physically remote to computing device1300such that the input data may be received, and the output similarly transmitted via communications unit1312.

I/O interface(s)1314allows for input and output of data with other devices that may operate in conjunction with computing device1300. For example, I/O interface(s)1314may provide a connection to external device(s)1320, which may be as a keyboard, keypad, a touch screen, or other suitable input devices. External device(s)1320can also include portable computer readable storage media, 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 may be loaded onto persistent storage1308via I/O interface(s)1314. I/O interface(s)1314also can similarly connect to display1322. Display1322provides a mechanism to display data to a user and may be, for example, a computer monitor.

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows:

FIG. 15is block diagram depicting a set of functional abstraction model layers provided by cloud computing environment50depicted inFIG. 14in accordance with at least one embodiment of the present invention. It should be understood in advance that the components, layers, and functions shown inFIG. 15are intended to be illustrative only and embodiments of the invention are not limited thereto. As depicted, the following layers and corresponding functions are provided: