Tape relocation management for tape data storage drives

Abstract

In the tape relocation management described herein, in response to loading a tape in a tape drive, a Linear Tape File System (LTFS) mount of the tape is initiated, which includes reading an index partition of the tape to extract metadata for mounting the tape LTFS, and the tape is relocated within the data partition to read a virtual high resolution tape directory (vHRTD) recorded in an EOD (end of data) portion of the data partition, e.g., an EOD data set, before accessing the data area of ​​the tape in response to any application access request. The EOD portion is read to read the vHRTD to facilitate application requested access to the tape. In one embodiment, relocating and stopping the tape at the beginning of the data partition after reading the index partition containing metadata is avoided.

Description

[Technical Field]

[0001] The present disclosure relates to computer program products, systems, and methods for managing tape relocation in a tape data storage system. [Background technology]

[0002] Computer systems may include data storage systems for processing and storing data. Historically, data has been stored on local storage devices such as hard disk drives (HDDs), solid-state storage, and removable media such as compact discs (CDs) and digital versatile discs (DVDs). In addition, magnetic tape ("tape") data storage systems are widely used to store digital data. Tape data storage systems offer increased data storage space and lifespan and reduced costs. Modern magnetic tapes are typically packaged in tape cartridges or cassettes. A tape appliance or tape drive is a device that reads or writes digital data from tape.

[0003] Digital data may be written to tapes of different lengths and widths. One standard that defines tape characteristics is the LINEAR TAPE OPEN® (LTO®) standard. (Linear Tape Open and LTO and all LTO-based trademarks and logos are trademarks or registered trademarks of Hewlett-Packard Enterprise, IBM, and Quantum, and / or their affiliates.) The LTO® standard defines raw data capacity, tape partitioning, and read speeds for uncompressed data. For example, LTO-7 can write 6 terabytes of data to a 3150-foot (960-meter) tape at an average speed of 300 MB / sec.

[0004] Tape partitioning involves creating one or more areas (data bands) on a magnetic tape so that the operating system can manage the data in each area separately. One of the partitioning standards adopted by LTO® is the Linear Tape File System (LTFS). The LTFS standard formats the tape in a special way, allowing access to all recorded file metadata at the beginning, thus making it possible to view files and directories on the tape immediately after inserting the tape cartridge. In addition, because the LTFS standard is adopted by many operating systems, the operating system often can view files without any additional software. This allows users to access and use files as if the tape drive were a hard disk drive (HDD) or removable flash drive file system. For example, users are typically allowed to manage and store files in folders (directories), copy, rename, and delete files, and use drag-and-drop and copy-and-paste functions without having to read all the data recorded on the tape.

[0005] The LTFS format defines at least two partitions on a tape that contain data bands. One partition, known as the index partition (IP), is used to store metadata for all files and folders (hereafter referred to as "files" or "files") recorded on the tape. For example, the index partition may contain data identification (i.e., file or folder), file user identifier, file name, data length, attributes, timestamp, partition identification, starting block, byte offset, byte count, file offset, and other metadata. The other partition, the data partition (DP), stores file contents, including the file body and file metadata. In the LTFS standard, file contents are typically appended to the end of the tape (free space) to prevent file deletion from freeing up tape space.

[0006] In one known tape standard, the HRTD (High Resolution Tape Directory) data structure is stored in a data set called a housekeeping data set, which is defined before the first user data area of ​​the tape and is read when the tape is loaded. As used herein, the term "data set" also includes "dataset," which may have specific requirements. In known tape drives, three types of physical objects are recorded on the tape: a normal data set, an end-of-data (EOD) data set, and the aforementioned housekeeping data set. The data sets typically have a fixed length. The normal data set and the EOD data set are written in the user area of ​​the tape, while the housekeeping data set is written outside the user area of ​​the tape.

[0007] In conventional tape drives, two types of logical objects are recorded on the tape. One type is a record, and the other is a file mark (often called a "filemark"). A file mark is a data structure that delimits an area or subarea of ​​a file consisting of any number of records. HRTD divides the tape into many subareas and identifies the records within each subarea to facilitate quick access to a particular file or record specified by an application access request. Both logical objects (file marks and records) are packed into a normal data set.

[0008] Another known tape standard does not allow for the recording of HRTD in a housekeeping data set. However, it is known to record a virtual high-resolution tape directory (vHRTD) in the end-of-data (EOD) data set of the data partition of such a tape. The vHRTD is typically read in conjunction with an application-requested write operation, which appends new data after the EOD data set of the data partition. Like the HRTD, the vHRTD divides the tape into many subareas and identifies records within each subarea to facilitate rapid access to a specific file or record specified by an application access request when the vHRTD becomes available to facilitate the access. The EOD data set is typically written as the last data set in a tape write operation and is therefore located after the last logical object, record, or file mark on the tape. Therefore, on some known drives, the EOD data set indicates that there is no data after the last EOD data set written. Summary of the Invention

[0009] In one embodiment, provided are computer program products, systems, and methods for relocating tapes in a data storage system having a tape drive for use with a tape having a Linear Tape File System (LTFS), an index partition, and a data partition, where the tape drive has memory and resides within an enterprise computer system. In one aspect of tape relocation management according to the present description, in response to loading a tape in the tape drive, a mount of the tape LTFS is initiated, which includes reading the tape's index partition to extract metadata for mounting the tape LTFS, and the tape is relocated within the data partition to read a virtual high-resolution tape directory (vHRTD) recorded in an end-of-data (EOD) portion of the data partition before accessing the data area of ​​the tape in response to any application access requests. The EOD portion is read to read the vHRTD to facilitate application-requested access to the tape. Thus, in one embodiment, after reading the EOD portion to retrieve the vHRTD, the relocation manager waits to receive the first application access request with the vHRTD available to facilitate such application access request.

[0010] In another aspect, relocating the tape within the data partition to read the virtual high-resolution tape directory (vHRTD) recorded in the end-of-data (EOD) portion of the data partition is initiated immediately after reading the tape's index partition to extract metadata for mounting the tape LTFS. In one embodiment, tape relocation management includes extending the vHRTD read from the EOD portion in the system's memory. Thus, in one embodiment, reading the EOD portion to read the vHRTD before processing any application access requests ensures that the vHRTD is available to facilitate application access requests when processed.

[0011] In yet another aspect, tape relocation management in one embodiment includes avoiding relocation and stopping the tape at the beginning of the data partition after reading the index partition containing the meta information to mount the tape LTFS. Instead, relocation proceeds directly to relocate the tape to the data set with the vHRTD after reading the index partition containing the meta information to mount the tape LTFS.

[0012] In one embodiment, the tape conforms to the LTO® (Linear Tape-Open®) standard and does not have a High Resolution Tape Directory (HRTD) recorded in the tape's housekeeping data set.

[0013] In another aspect, tape relocation management includes extracting file system metadata while relocating a tape to a data set having a vHRTD and simultaneously reading an index partition.

[0014] The drawings included in this application are incorporated into and form a part of this specification. The drawings illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the disclosure. The drawings are illustrative of particular embodiments and do not limit the disclosure. [Brief explanation of the drawings]

[0015] [Figure 1A] FIG. 1 illustrates an embodiment of a computing environment that employs aspects of tape relocation management according to the present description. [Figure 1B] FIG. 1 illustrates a high-level block diagram representation of an enterprise computer system including a tape storage drive device that may employ tape relocation management in accordance with the present description. [Figure 2] 1 is an exemplary block diagram illustrating the hardware and software architecture of a data storage system in a computer system that may use tape relocation management according to the present description. [Figure 3] 1 is an exemplary block diagram illustrating a tape storage drive device that may use tape relocation management according to the present description. [Figure 4] FIG. 1 illustrates a known band structure of tape in a tape storage drive system. [Figure 5A] FIG. 1 illustrates a known tape housekeeping data structure in which a High Resolution Tape Directory (HRTD) is recorded. [Figure 5B] FIG. 1 illustrates a known end-of-tape data (EOD) structure in which the virtual high-resolution tape directory (vHRTD) is recorded. [Figure 6] 4 is a diagram showing an example of a tape cartridge that can be used in the tape storage drive device of FIG. 3. [Figure 7A] FIG. 1 shows an example of a tape with a known label and index partition. [Figure 7B] FIG. 1 shows an example of a tape with a known label and index and data partitions. [Figure 8] FIG. 10 illustrates an example of the operation of a computer system employing aspects of relocation management according to the present description. [Figure 9A]FIG. 1 illustrates an example of a tape having a beginning of tape (BOT) at one end of the tape and an end of tape (EOT) at the other end of the tape. [Figure 9B] FIG. 1 illustrates a known example of tape relocation in a tape drive. [Figure 9C] FIG. 1 illustrates a known example of tape relocation in a tape drive. [Figure 9D] FIG. 1 illustrates a known example of tape relocation in a tape drive. [Figure 10A] 1 illustrates an example of tape relocation in a tape drive using tape relocation management according to the present disclosure compared to known examples of tape relocation in a tape drive. [Figure 10B] 1 illustrates an example of tape relocation in a tape drive using tape relocation management according to the present disclosure compared to known examples of tape relocation in a tape drive. [Figure 10C] 1 illustrates an example of tape relocation in a tape drive using tape relocation management according to the present disclosure compared to known examples of tape relocation in a tape drive. [Figure 10D] 1 illustrates an example of tape relocation in a tape drive using tape relocation management according to the present disclosure compared to known examples of tape relocation in a tape drive. [Figure 11] FIG. 1 illustrates another embodiment of a computing environment that employs aspects of tape relocation management according to the present description. [Figure 12] FIG. 1 is a schematic diagram illustrating a cloud computing environment according to some embodiments of the present disclosure. [Figure 13] FIG. 1 is a block diagram illustrating a set of functional abstraction model layers provided by a cloud computing environment according to some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0016] It will be readily understood that the components of the present embodiments, as generally described herein and illustrated in the Figures, could be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the present apparatus, system, method, and computer program product embodiments, as presented in the Figures, is not intended to limit the scope of the claimed embodiments, but is merely representative of selected embodiments.

[0017] The illustrated embodiments will be best understood by referring to the drawings, in which like parts are designated by like numbers throughout. The following descriptions are intended to be merely exemplary and merely illustrate certain selected embodiments of devices, systems, and processes consistent with the embodiments claimed herein.

[0018] The tape relocation management described herein provides a significant improvement to computer technology. For example, in known computer systems, after reading a tape's index partition to extract metadata for mounting a Linear Tape File System (LTFS), the tape is relocated to the beginning of the data partition that follows the index partition that was read to extract the LTFS metadata. Upon reaching the beginning of the data partition, the tape stops and waits for any application access requests. As a result, a virtual high-resolution tape directory (vHRTD) cannot be used to facilitate rapid tape access in response to tape access requests by applications directed to specific records or files on the tape.

[0019] In one aspect of tape relocation management according to the present disclosure, in response to loading a tape in a tape drive, a Linear Tape File System (LTFS) mount of the tape is initiated, which includes reading the tape's index partition to extract metadata for mounting the tape LTFS, and the tape is relocated to the end-of-data (EOD) portion of the data partition with a virtual high-resolution tape directory (vHRTD) recorded in the current end-of-data (EOD) portion of the data partition. The EOD portion is read to read the vHRTD in order to expedite subsequently received application access requests to the tape. Thus, in one embodiment, the vHRTD is read prior to receiving any application access requests, i.e., prior to accessing the data area of ​​the tape in response to any application access requests. In one embodiment, the known process of repositioning and stopping the tape at the beginning of the data partition after reading the index partition containing metadata is avoided. Instead, the tape is repositioned to immediately read the vHRTD prior to application access requests. As a result, the vHRTD tape directory is readily available to facilitate quick tape access to specific files or records specified in application access requests.

[0020] As will be appreciated by those skilled in the art, aspects of tape management according to the present disclosure may be embodied as a system, method, or computer product. Accordingly, aspects of the present disclosure may take the form of an embodiment combining software (including firmware, resident software, microcode, etc.) and hardware aspects, all of which are generally referred to as "modules," "methods," or "systems." Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code / instructions embodied therein, including a controller, microcontroller, or computer processing unit.

[0021] Various aspects of the present disclosure are described below with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products. Turning to FIG. 1A, an example computer system 10 in which aspects of embodiments of the present disclosure may be implemented is shown. Computer system 10 includes a central processing unit (CPU) 12, which is connected to mass storage device(s) 14 and a memory device 16. The mass storage device may include a hard disk drive (HDD) device, which may be configured as a redundant array of independent disks (RAID). In the illustrated embodiment, mass storage device 14 includes a tape data storage system.

[0022] Memory device 16 may include memory such as, for example, random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), or a host of related devices. Memory device 16 and mass storage device 14 are connected to CPU 12 via a signal-bearing medium. Additionally, CPU 12 is connected through communications port 18 to a communications network 20 to which multiple additional computer systems 22 and 24 are attached. Computer system 10 may include one or more processor devices (e.g., CPU 12) and additional memory devices 16 for each individual component of computer system 10.

[0023] FIG. 1B is a high-level block diagram illustrating a representation of an enterprise computer system including a tape data storage system in which aspects of an embodiment of the present disclosure may be implemented. Examples of enterprise-wide applications include, without limitation, payroll, warehousing, transportation, and batch jobs. As shown, the enterprise computer system 100 of FIG. 1B includes several host data processing systems (e.g., server data processing systems 102A, 102B and associated client data processing systems 104A, 104B, . . . 104N) that are communicatively coupled together via a first network interconnect (e.g., a local area network or "LAN" interconnect 106). The server data processing systems 102A, 102B of the illustrated embodiment are further coupled to a storage subsystem 108 that includes several data storage devices and a second network interconnect (e.g., a storage area network or "SAN" interconnect 112). One or more of the server data processing systems 102A, 102B, the client data processing systems 104A, 104B...104N, and the storage system 108 may be configured for relocation management according to the present description.

[0024] 1B, storage system 108 is shown as including a tape data storage system represented by tape data storage system 110. In alternative embodiments, storage system 108 may further include any number and type of data storage devices (e.g., individual disk drives, tape drives, disk arrays, tape arrays, RAID array subsystems, robotic tape libraries, filers, file servers), which may be communicatively coupled together and coupled to server data processing systems 102A, 102B via a storage interconnect (SAN interconnect 112), such as, for example, a Fibre Channel (FC) switch, switch fabric, or arbitrated loop. In the embodiment of FIG. 1, server data processing system 102A includes an application server (e.g., a database server) for providing core operational functionality to one or more of client data processing systems 104A-104N (where "N" is a positive integer), and server data processing system 102B includes another server (e.g., a cluster failover server, a load balancing server, or a backup server).

[0025] The tape data storage system 110 of the illustrated embodiment is coupled to the SAN interconnect 112 via communication links as shown. Each communication link may include any of several communication media (e.g., copper wiring or fiber optic cable, etc.) capable of conveying one or more electrical, optical, or acoustic, or a combination thereof, propagated signals between the SAN interconnect 112 and a communication port of the tape data storage system 110.

[0026] As described further herein, in the illustrated embodiment, one or both of tape data storage system 110 and server data processing system 102A are configured with sufficient functionality to use tape relocation management in accordance with the present description to control and / or manage tape relocation and access provided to data on tape data storage media in tape cartridges coupled to tape data storage device 110. However, it will be recognized that one or more of computer systems 10, 22, 24 (FIG. 1A), server data processing systems 102A, 102B (FIG. 1B), client data processing systems 104a, 104b...104n, and data storage system 108 may be configured to use relocation management in accordance with the present description.

[0027] 1 specifically illustrates a traditional SAN-type interconnect (SAN interconnect 112), other interconnects (e.g., direct connect, local, metropolitan, or wide area network, or a combination thereof) and other protocols (e.g., FICON®, ESCON, or SSA, etc.) may be used. Additionally, while a particular number and arrangement of components is shown for enterprise 100 in FIG. 1B, it should be understood that embodiments of the present disclosure are not limited to enterprises, systems, or data storage devices having any particular number, type, or arrangement of components, and may encompass a variety of system types, architectures, and form factors.

[0028] In an alternative embodiment, FIG. 2 is an exemplary computer system 200 illustrating the hardware and software architecture of a data storage system 204 that may implement aspects of tape relocation management according to the present description. Host computers 210, 220, and 225 are shown, each of which acts as a central processing unit for data processing as part of computer system 200, including data storage system 204. Hosts (physical or virtual devices) 210, 220, and 225 may represent one or more physical or logical devices for purposes of embodiments of the present disclosure. In one embodiment, by way of example only, data storage system 204 may be implemented as an IBM System Storage™ DS8000™ that has been modified to employ tape relocation management according to the present description.

[0029] Network connection 226 may be a Fibre Channel fabric, a Fibre Channel point-to-point link, a Fibre Channel over an Ethernet fabric or point-to-point link, a FICON® or ESCON I / O interface, any other I / O interface type, a wireless network, a wired network, a LAN, a WAN, heterogeneous, homogeneous, public (i.e., Internet), private, or any combination thereof. Hosts 210, 220, and 225 may be local or distributed across one or more locations and may include any type of fabric (or fabric channel) (not shown in FIG. 2) or network adapter to storage controller 228, such as a Fibre Channel, FICON®, ESCON, Ethernet, fiber optic, wireless, or coaxial adapter. Data storage system 204 thus includes a suitable fabric (not shown in FIG. 2) or network for communication. The data storage system 204 shown in FIG. 2 includes a storage controller 228 and storage 230 including a tape data storage drive 231 controlled by the storage controller 228 .

[0030] Storages 230a, 230b...230n of storage 230 may physically include one or more storage devices, such as a storage array. A storage array is a logical grouping of individual storage devices, such as hard disks or tape data storage drives. In certain embodiments, one or more of storages 230a, 230b...230n include a JBOD (Just a Bunch of Disks) array or a RAID (Redundant Array of Independent Disks) array. A collection of physical storage arrays may be further combined to form ranks, which separate physical storage from logical configurations. Storage space within a rank may be allocated to logical volumes, which define storage locations specified in write / read requests. Furthermore, the tape data storage device 110 (see FIG. 1B) described in FIGS. 1B and 3 may be implemented using the architecture described in FIG. 2.

[0031] In one embodiment, by way of example only, the storage system shown in FIG. 2 may include logical volumes, or simply "volumes," and may have different types of allocations. Storage units 230a, 230b, and 230n are depicted as ranks in data storage system 200 and are referred to herein as ranks 230a, 230b, and 230n. Ranks may be local to data storage system 200 or may be physically located at remote locations. In other words, a local storage controller may interface with a remote storage controller to manage storage at a remote location. Rank 230a is shown consisting of two whole volumes 234 and 236 and one partial volume 232a. Rank 230b is shown with another partial volume 232b and a complete volume 237. Volume 232 is thus assigned to ranks 230a and 230b. Rank 230n is shown fully assigned to volume 238. That is, rank 230n represents the entire physical storage for volume 238. From the above example, it will be appreciated that a rank may be configured to include one or more partial volumes, or an entire volume, or both. Volumes and ranks may be further divided into so-called "tracks," which represent fixed blocks of storage. A track may thus be associated with a given volume and given a given rank.

[0032] To facilitate a clearer understanding of aspects of the present disclosure, storage controller 228 is depicted in FIG. 2 as a single processing unit that includes a microprocessor 242 and system memory 243, which may include non-volatile storage ("NVS"), as described in more detail below. Note that in some embodiments, storage controller 228 includes multiple processing units, each with its own processor complex and system memory, interconnected by a dedicated network within data storage system 204. In some embodiments, devices included in storage 230 may be connected in a loop architecture.

[0033] The storage controller 228 manages the storage 230 and facilitates processing of write and read requests intended for the storage 230. The system memory 243 of the storage controller 228 stores program instructions and data that the processor 242 may access to perform the functions and methods of embodiments of the present disclosure for running and managing the storage 230 as described herein. In one embodiment, the system memory 243 includes a tape relocation management 255 associated with or in communication with the operating software 250 for performing the methods and operations using the relocation management described herein. One aspect of the tape relocation management 255 is to control tape relocation logic 257, which controls the position of the tape in the tape data storage drive 231 (FIG. 3). While the tape relocation logic 257 is shown as a component of the tape relocation management 255, it will be appreciated that the tape relocation logic 257 may be located in other components of the system, such as, for example, one or more of the storage controller 228, the hosts 210-225, the network 226, and the tape storage drive 231. Similarly, although the tape management 255 logic is shown as a component of the storage controller 228, it will be appreciated that the tape relocation management 255 may be located in other components of the system, such as, for example, one or more of the tape storage drives 231, the hosts 210-225, and the network 226. Thus, the tape relocation management 255 may be implemented by one or more of hardware, software, and firmware, either alone or in combination.

[0034] 2, system memory 243 may also include or communicate with cache 265, also referred to herein as "cache memory," for storage 230 for buffering "write data" and "read data," which respectively represent write / read requests and their associated data. In one embodiment, cache 265 is allocated on a device external to system memory 243 but is still accessible by microprocessor 242 and may serve to provide additional security against data loss in addition to performing the operations described herein.

[0035] In some embodiments, cache 265 is implemented with volatile and nonvolatile memory and is coupled to microprocessor 242 via a local bus (not shown in FIG. 2 ) to improve performance of data storage system 200. The NVS portion of memory 243 included in the data storage controller is accessible by microprocessor 242 and serves to provide additional support for the operation and execution of embodiments of the present disclosure described in other figures. The NVS is sometimes referred to as a “persistent” cache or “cache memory” and is implemented with nonvolatile memory that may or may not use external power to retain the data stored therein. The NVS may be stored in or with cache 265 for any purpose appropriate to achieve the objectives of embodiments of the present disclosure. In some embodiments, a backup power source (not shown in FIG. 2 ), such as a battery, provides sufficient power to the NVS to retain data stored in the NVS in the event of a power loss to data storage system 200. In certain embodiments, the capacity of the NVS is less than or equal to the total capacity of cache 265.

[0036] Storage controller 228 includes a control switch 266 for controlling a communication protocol, such as a Fibre Channel protocol, to host computers 210, 220, 225. Buffer 267 assists cache 265 in temporarily storing (buffering) read and write data.

[0037] 3 is a block diagram illustrating one embodiment of a tape data storage drive 231 that may employ aspects of tape relocation management according to the present description. The tape data storage drive 231 includes a removable data storage tape cartridge 302 and a communication interface (e.g., host data processing system interface (I / F) 306) for communicatively coupling the tape data storage drive 231 to a storage controller 228 (FIG. 2) or, alternatively, to one or more host data processing systems or associated communication channels (e.g., SAN interconnect 112).

[0038] The communications I / F 306 is configured to receive input / output (I / O) operation requests (e.g., requests for "read" and / or "write") and process such requests in an appropriate manner to control or "manage" access to the tape data storage medium 308 (e.g., magnetic tape) of the removable data storage tape cartridge 302 described herein. In addition to the tape data storage medium 308, the data storage tape cartridge 302 includes a cartridge memory (CM) module 309, which in one embodiment includes a passive, contactless silicon storage device used to store data about the tape cartridge 302 in which it resides. Exemplary data may include, for example, data indicating the volume serial number (VOLSER) of the associated tape cartridge, the "type" of data storage medium within the cartridge, the data format type, and the data stored therein, if any.

[0039] The tape data storage medium 308 of the removable data storage tape cartridge 302 is routed adjacent to a tape access (e.g., read / write) head 310 using media transport reels 312 and 314 and one or more media transport motors 316 as shown. The tape access head 310 is configured to read data from and write data to the tape data storage medium 308, and to temporarily store or "stage" such data in a buffer 318 (e.g., one or more "read-ahead" or staging buffers).

[0040] When writing data to or reading data from tape 308 (FIG. 3), tape 308 is moved relative to read / write head 310 to the location of the data to be written or read. The process of moving to the target data location is typically called a "relocation" process, and it occurs in response to a relocation request issued by the storage controller.

[0041] In example embodiments, the tape cartridge 302 conforms to one or more standard specifications of the Linear Tape Open® (LTO®) generation standard, such as LTO-7. In such an embodiment, the supply reel 312 may be part of an LTO® tape cartridge and is connected to the beginning of the tape 308, and the end of the tape 308 is connected to a leader pin (not shown), which is mechanically grasped by a mechanism (not shown) of the tape data storage drive 231 and attached to the take-up reel 314.

[0042] Control unit 320 contains read and write logic for reading and writing data from and to the tape of the tape storage drive, and thus controls and manages data flow, formatting, and data storage subsystem operation via control signals issued to one or more of communication I / F 306, buffer 318, media transport motor 316, and / or CM I / F 322, which are used to access (read or write) data stored in CM 309.

[0043] In the embodiment shown, some or all of the functionality of the tape relocation logic 257 (FIG. 2) may be located within the control unit 320 of the tape storage drive 231. In another embodiment, such control functionality may be incorporated into one or more of the other components of the tape data storage drive 231. Similarly, while the control unit 320 is shown in FIG. 3 as part of the tape storage drive 231, it will be appreciated that the control unit logic may be located in one or more of the various components of the system, such as, for example, the storage controller 228, the hosts 210-225, and the network 226, and one or more of the tape storage drive 231. Alternatively, some or all of the component functionality may be implemented in hardware devices, such as, for example, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or may be performed by separate dedicated processors.

[0044] The memory 106 may include one or more memory devices, volatile or non-volatile, such as dynamic random access memory (DRAM), phase change memory (PCM), magnetoresistive random access memory (MRAM), spin transfer torque (STT)-MRAM, SRAM storage devices, DRAM, ferroelectric random access memory (FeTRAM), nanowire-based non-volatile memory, and non-volatile direct inline memory modules (DIMMs), NAND storage, e.g., flash memory, solid state drive (SSD) storage, non-volatile RAM, etc.

[0045] Storage 108 may include different types or classes of storage devices in SAN 112, such as magnetic hard disk drives, solid-state storage devices (SSDs) including solid-state electronics, electrically erasable programmable read-only memory (EEPROM), flash memory, flash disks, random access memory (RAM) drives, storage class memory (SCM) such as phase change memory (PCM), resistive random access memory (RRAM), spin transfer torque memory (STT-RAM), conductive bridging RAM (CBRAM), magnetic hard disk drives, optical disks, tapes, etc. Volumes in storage 108 may further consist of arrays of devices, such as a simple bundle of disks (JBODs), direct access storage devices (DASDs), redundant arrays of independent disks (RAID) arrays, virtualization devices, etc. Additionally, storage 108 may include heterogeneous storage devices from different vendors and different types of storage devices, such as a first type of storage device, such as a hard disk drive, that has a slower data transfer rate than a second type of storage device, such as an SSD.

[0046] Storage 108 may include a cloud storage system provided by a cloud storage service provider, such as DropBox®, Google® Drive, Amazon Cloud Drive®, Amazon® S3, and IBM Cloud Object Storage System™ (Dropbox is a registered trademark of Dropbox, Inc., Google is a registered trademark of Google Inc., Amazon and Amazon Cloud Drive are trademarks of Amazon Technologies, Inc., and IBM and Cloud Object Storage System are trademarks of IBM worldwide).

[0047] The network 106 may include, without limitation, a storage area network (SAN), a local area network (LAN), an intranet, the Internet, a wide area network (WAN), a peer-to-peer network, a wireless network, and an arbitrated loop network. Thus, the enterprise computer system 100 includes a storage system 108 coupled to the server 102 through a network 112.

[0048] In the illustrated embodiment, the tape data storage drive 231 is a linear system, in which the width of the tape is conventionally divided into multiple regions (wraps), as shown in FIG. 4. Data is recorded along the length of the tape, represented by the arrows for each wrap, from the beginning of the tape to the end and from the end to the beginning. The width of the region across the tape where valid data for each wrap is written is called the track width (track pitch Wtp). As shown in FIG. 4, recording occurs on tracks moving from the beginning to the end (forward) on even-numbered wraps, and from the end to the beginning (reverse) on odd-numbered wraps. In one known tape standard, the HRTD (High Resolution Tape Directory) data structure 510 (FIG. 5A) is stored on a portion of the tape called the housekeeping data set 514, which is defined before the first user data area of ​​the tape, and is read when the tape is loaded.

[0049] For example, in the LTFS magnetic tape media wrap allocation according to the LTO-7 standard, a magnetic tape may have 112 wraps allocated to four data bands (data band 0 to band 3), where each band has 28 wraps, i.e., data band 0 has 28 wraps, wrap 0 to wrap n-1 Data band 1 has 28 wraps n+0 ~wrap 2n-1 Data band 2 has 28 wraps 2n+0 ~wrap 3n-1 Data band 3 has 28 wraps 3n+0 ~wrap 4n-1Depending on the particular application, all data wraps may be formatted within a single partition, from wrap0 to wrap111, or other formats may be used. For example, one known LTFS standard may divide a tape into two partitions, where the first partition contains wrap0-1, which may be used for metadata, and the second partition contains wrap4-111, which are used to hold data related to the metadata. For example, LTFS typically creates a two-partition tape when formatting a tape. wrap0 and wrap1 are used to provide an index partition. wrap2 and wrap3 are typically used as a guard band. Wrap4 through the last wrap provide a data partition for storing user data, which may be constructed according to the tape drive system's standard records.

[0050] As mentioned above, the LTO-7 standard allows for 6 terabytes of data to be written to a 3150 ft (960 m) length of tape. Physical position in both directions is defined by the length of the tape and is expressed as a longitudinal position counter (LPOS), where LPOS represents the longitudinal position used by the servo motor to locate specific data on the tape. Any new data is typically only appended to the tape, i.e., written to the tape at the LPOS position next to the previously written data.

[0051] The average seek speed to locate specific data on a tape is approximately 32.8 ft / sec (10 m / sec), so it takes approximately 96 seconds for the tape drive head to move from the beginning to the end of the tape. Assuming that a requested file is located in the range from the beginning of the tape to the end of the tape, the average movement time for access is approximately 32 seconds (one-third of 96 seconds). This estimate does not take into account that data is recorded in different directions depending on the wrap, which requires additional time for direction switching and head repositioning. Therefore, it may be advantageous to implement a system that reduces head movement time, particularly in order to locate and read requested data in the shortest time frame. Embodiments of tape relocation management according to the present description provide systems, methods, and program products for facilitating retrieval of files recorded on magnetic tape.

[0052] 6 illustrates an example embodiment of a tape cartridge 302 suitable for use with a tape data storage system, such as the tape data storage drive 231 shown in FIG. 3. According to the example embodiment, the tape cartridge 302 includes a housing 652, a magnetic tape medium 308 ("tape") within the housing 652, and a cartridge memory 309 coupled to the housing 652. In other embodiments, the cartridge memory 309 may be embedded inside the housing 652. In further embodiments, the cartridge memory 309 may be attached to the inside or outside of the housing 652 without modifying the housing 652. The cartridge 302 may also have an identification feature 654 in or on the housing 652.

[0053] According to an example embodiment, controller 320 (FIG. 3) uses cartridge memory 309 via cartridge memory reader or interface 322 as temporary storage for information about data written in both directions of travel on magnetic tape medium 308, such as generated LTFS index values. In a further embodiment, cartridge memory 309 may store information about tape partitioning and other information about the use of magnetic tape medium 308, such as a tape directory (TD).

[0054] In known tape data storage drive systems, a tape repositioning request identifies a target location, which is identified by the record number of the target record or the file mark number of the target file mark. An example of a file mark is represented by file mark 702a in Figure 7A. A file mark is a data structure that delimits an area or subarea of ​​a file consisting of any number of records. However, the exact location of each file mark is typically unavailable to the storage controller or tape data storage drive. The read logic of a tape drive storage system typically does not know exactly where the target record or file mark is written on the tape. Instead, a data structure often called a "tape directory (TD)" is often used to determine which general area of ​​the tape the target record is located in. For example, in an LTO® tape drive, a wrap is divided into two subareas. In such a system, the tape directory identifies which of the two subareas the target record is located in.

[0055] By comparison, in known tape drives, such as the TS1160 sold by IBM, each wrap is divided into 128 smaller sub-areas along the length of the tape. In such systems, in addition to the TD data structure, a high-resolution tape directory (HRTD) data structure 510 (FIG. 5A) identifies, for each record recorded on the tape, the particular sub-area of ​​the 128 sub-areas in which the target record was recorded. As noted above, the HRTD (High-Resolution Tape Directory) data structure 510 (FIG. 5A) is stored in a portion of the tape data called the housekeeping data set 514.

[0056] Thus, in known systems with HRTD-type directories, upon receiving a relocation request to reposition a tape to read a specified target record, the HRTD data structure is consulted to identify which specific subarea of ​​128 possible subareas contains the specified target record number or file mark number. In known tape drive systems, the tape relocation logic knows the physical location of each HRTD subarea on the tape. Therefore, the tape is repositioned by the tape relocation logic to the specific subarea identified by the HRTD data structure. The tape drive system's read logic then searches for the record of the data set located in that area, starting from the beginning of that area and proceeding sequentially.

[0057] The records stored in each area or subarea of ​​a tape are often collectively referred to as a data set. Known tape drive systems use a data set information table (DSIT) that identifies the number of records in a data set that occupy a certain area of ​​a subarea of ​​the tape. The number of file marks in a particular data set is also known as the file mark number of the file mark at the beginning of the data set. Using the target record number of a specified target record in a target data set, the number of records recorded in the target data set indicated in the DSIT, and the first file mark number and number of file marks in the target data set, the read logic of a known tape drive can check whether the target record can be found in the target data set. If the checked data set is found to contain the desired record, the relocation request is terminated. Thus, reading of one or more data sets continues until a data set containing the desired record is found.

[0058] In tape drive systems that use the HRTD data structure in a tape housekeeping data set, it is recognized that a specified record may be located relatively quickly because each tape wrap is further divided into relatively small subareas and the HRTD data structure identifies records in each of these subareas. Thus, a search of a relatively small subarea for a specified record may be completed quickly. On the other hand, LTO® tape drive specifications may be defined by different standards. As a result, data sets such as the HRTD data structure generally cannot be written to the housekeeping data set in known LTO® tape drives. To address this issue, known LTO® tape drives sold by IBM create information that is the same or similar to that found in the HRTD data structure. This HRTD-type information is recorded as a virtual HRTD (vHRTD) in the free space of the data set, typically written at the end of data writes to tape, called the end-of-data (EOD). FIG. 5B shows an example of a known vHRTD 530 recorded in the EOD data set 534 of the data partition described below.

[0059] However, in known tape drive systems, the EOD data set is not read when the tape is loaded and mounted. As a result, the vHRTD is not read in connection with the tape load and mount and is therefore not available to facilitate application-requested read operations after the tape is loaded and mounted. As a result, tape access operations in response to application access requests received after the tape is loaded and mounted do not use the vHRTD directory for time intervals after the tape is loaded and mounted. However, it is recognized that an access request from the host may eventually be received, thereby causing the vHRTD to be read from the EOD. Examples of such subsequent accesses include accessing data added to or near the EOD data set as a result of a host-requested access. Until such an access request is received, the vHRTD remains unread, slowing host-requested accesses during the intervening period. However, once an access that causes the vHRTD to be read is received, subsequent relocations can be performed at high speed using the vHRTD.

[0060] In a typical Linear Tape File System (LTFS), the area of ​​the tape where data is recorded as file system files is often divided into two partitions: a data partition that stores user data, and an index partition that stores file system metadata (e.g., file name, location on the data partition where the file is recorded, size, etc.). Figure 7B shows an example of a user data area "A" of a data partition and an index partition 704b. An example of a known LTFS system is sold by IBM under the brand name Spectrum Archive.

[0061] When writing index information to tape media, a file mark (FM) data structure defined in the LTFS format specification is typically written before and after the index information. In some embodiments, the file mark is written immediately before or after (i.e., adjacent to) the index information. The file mark facilitates locating the index information recorded on the tape media. By recording the most recent index information in index partition 704a, the time required to read the index information when the tape media is inserted into a tape drive is reduced.

[0062] Two additional data structures recorded on an LTFS-formatted tape are often called "labels." One such label is volume label 708a (FIG. 7A), which in this example identifies the tape as volume 1. Another label is LTFS label 712a, which identifies the tape as formatted for the LTFS file system.

[0063] When a request to mount an LTFS tape is received, the tape is loaded into the tape drive and the VOL1 label 708a and LTFS label 712a for the index partition 704a are checked to confirm that the tape is formatted in the LTFS format. Additionally, file system meta information is extracted to provide the file system with file and directory information written to the tape. Therefore, the drive moves (repositions) the tape so that the tape drive read head is positioned at tape position 718a (FIG. 7B) at the beginning of the data partition. As the tape is repositioned to the beginning of the data partition 718a, the metadata is read to check the VOL1 label and the LTFS label. Upon reaching the beginning of the data partition 718a, the tape repositioning in a conventional tape drive simply stops and prepares for the first application-requested access, which is typically a read or write request initiated by a user application running on the host.

[0064] It is recognized herein that ending tape relocation at the beginning of a tape partition upon completion of the tape mount process in known tape drives can significantly slow subsequent application-requested accesses to the tape because the vHRTD data structure has not been read and is therefore unavailable to facilitate rapid access to the desired record. Figure 8 illustrates the operation of a data storage system using tape relocation management according to the present disclosure, in which the vHRTD is read and made available in connection with the initial mounting of a tape file system in response to the insertion of a tape cartridge into a tape drive. As a result, the specified record or file mark for each application-requested access may be quickly located using the vHRTD read in connection with the loading of the tape cartridge and the mounting of the file system.

[0065] In this embodiment, tape relocation manager 255 (FIG. 2), and tape relocation logic 257 and tape cartridge control unit (FIG. 3) controlled by tape relocation manager 255, are configured to perform the operations of FIG. 8, including blocks 804-850 of FIG. 8 and the accompanying description. However, it is recognized that other logic may be configured to perform these operations depending on the particular application.

[0066] In one embodiment, an automated device may load a tape cartridge, such as tape cartridge 302 of Figures 3 and 6, into a tape drive, such as tape drive 231 of Figure 3. In other embodiments, the tape cartridge may be loaded manually by a user and using a suitable user interface of tape relocation management 255, or may be loaded by a combination of automated and manual operations.

[0067] Tape relocation management 255 detects the loading of a tape cartridge into a tape drive system (block 804, FIG. 8) and determines whether the loaded cartridge conforms to a known high-resolution tape directory, such as an HRTD-type tape cartridge (block 808). In one embodiment, the operation of loading a tape may be activated automatically through tape relocation management 255 or a unit controlled by tape relocation management 255. In other embodiments, the operation of loading or mounting a tape may be activated manually through a suitable user interface of tape relocation management 255, or may be activated by a combination of automatic and manual operations.

[0068] Detecting the loading of a tape cartridge into a tape drive system may be performed using a variety of techniques, including, for example, known or hereafter developed detection techniques. Similarly, determining whether a loaded tape cartridge conforms to a High Resolution Tape Directory (HRTD) may be performed using a variety of techniques, including, for example, known or hereafter developed detection techniques.

[0069] For example, the TS11xx line of tape drives, such as the TS1160 sold by IBM for enterprise-level applications, records a high-resolution tape directory, e.g., HRTD 510 (FIG. 5A), in a tape housekeeping data set, e.g., housekeeping data set 514 (FIG. 5A), typically located near the beginning of the tape. Thus, it may be determined that a loaded cartridge has an HRTD recorded in the tape housekeeping data set, e.g., by detecting that the loaded cartridge is a TS11xx type cartridge, or by detecting that tape data storage drive 231 (FIG. 3) controlled by storage controller 228 (FIG. 2) is a TS11xx type tape data storage drive. Other techniques may be used, depending on the particular application.

[0070] For example, tape data storage drive 231 may be detected by storage controller 228 as a TS11xx type tape storage drive when, for example, the tape storage drive is coupled to the storage controller and the storage controller and tape drive exchange suitable signals, including signals that identify the tape storage drive as a TS11xx type tape storage drive. In other embodiments, tape cartridge 302 may have an identification feature 654 (FIG. 6) that may be scanned, for example, electronically or optically, to identify cartridge 302 as a TS11xx type cartridge. For example, as shown in FIG. 6, feature 654 may be in the form of non-volatile memory embedded inside housing 652. In other approaches, non-volatile memory feature 654 may be attached to the inside or outside of housing 652 without modifying housing 652. For example, non-volatile memory may be embedded in a self-adhesive label represented by feature 654. In one approach, the non-volatile memory of feature 654 may be a flash memory device, a read-only memory (ROM) device, or the like, embedded inside or outside of or coupled to the tape cartridge 302. The non-volatile memory is accessible by the tape drive and tape operation software (driver software) or by another device using scanning or wireless technology, such as radio frequency identification (RFID), or other wireless or wired technology, or both. Other techniques may be used to determine the HRTD suitability of a loaded cartridge, depending on the particular application, including the particular type of cartridge and the particular type of tape drive system.

[0071] When it is determined that the loaded cartridge fits into a known high-resolution tape directory (block 808), tape relocation management 255 causes housekeeping data set 514 (FIG. 5A) to be read (block 812, FIG. 8), and the high-resolution tape directory (HRTD) 510 recorded therein is read by tape relocation management 255 (block 816). In one embodiment, the standard housekeeping data set (sHKDS) recorded in the housekeeping data portion of the tape is read using known techniques. Additionally, using known techniques, the read HRTD is expanded and stored in a suitable memory, such as the memory of control unit 320 (FIG. 3) of tape drive 231 or memory 243 (FIG. 2) of storage controller 228. Other techniques developed in the future may be used depending on the particular application.

[0072] Following the reading of the HRTD 510 (FIG. 5A), the index recorded at the end of the index partition 704a (FIGS. 7A and 7B) is read (block 820, FIG. 8), thereby reading the file system metadata described above (block 824, FIG. 8). In this manner, file system meta-information is obtained from the index, which is typically recorded in a read-only XML format.

[0073] Conversely, when it is determined that the loaded cartridge does not fit into a known high-resolution tape directory (block 808), the tape relocation management 255 avoids reading the high-resolution tape directory (HRTD) and instead goes to the index partition 704a (FIGS. 7A, 7B), reads the index recorded therein (block 820, FIG. 8), and reads the file system metadata described above (block 824, FIG. 8). Once the file system metadata is read, mounting of the tape's file system is initiated (block 828, FIG. 8) using known or later-developed file mounting techniques. In one embodiment, the retrieved metadata is sent to the file system, enabling applications running on the host to access files on the tape.

[0074] According to one aspect of tape relocation management according to the present description, before processing any host access request, a determination is made as to whether the loaded and mounted cartridge matches a known virtual high-resolution tape directory, e.g., a vHRTD-type tape cartridge (block 832), and if so, the tape is relocated to an EOD data set of a data partition, e.g., EOD data set 534 (FIG. 5B) (block 834). In the illustrated embodiment, the tape is relocated to an EOD data set of a data partition, e.g., EOD data set 534 (FIG. 5B), in association with the loading and mounting of the tape, not in association with a host access request.

[0075] As described above, in known tape drive systems, after loading a tape cartridge, the system repositions the tape of the just-loaded cartridge, reads the first index partition to mount the tape file system, and then stops the tape at the beginning (first record) of the data partition after the index partition. The tape is stopped at the first record of the data partition and waits for the first access (read or write) requested by the host application. Because the tape is stopped at the beginning of the data partition, vHRTD cannot be used to facilitate quick access to the desired record or file mark number for the application-requested access.

[0076] In comparison, in a tape drive using tape relocation management according to the present disclosure, the tape is not stopped at the beginning of the data partition. Instead, the tape is relocated (block 834) to the data partition's EOD data set, such as EOD data set 534 (FIG. 5B), in conjunction with the initial loading of the tape cartridge and the mounting of the tape's file system. Because the tape is relocated (block 834) to the data partition's EOD data set prior to any application-requested access, the tape is in a position for tape relocation management 255 (FIG. 2) to immediately read the data partition's EOD data set (block 838, FIG. 8) and retrieve the vHRTD recorded therein (block 842, FIG. 8). The retrieved vHRTD information may then be expanded and stored in a suitable memory of the system using known techniques. It will be appreciated that the vHRTD may be stored in various memory locations, such as the memory of the tape drive control unit 320 or the memory 243 of the storage controller 228. When the obtained vHRTD information is stored in memory in a usable format, loading and mounting of a tape according to the present disclosure may be considered complete.

[0077] As a result of obtaining and storing the vHRTD in conjunction with loading the tape and mounting the tape's file system as described herein, upon receiving any application-requested read or write request (block 846, FIG. 8), tape relocation management 255 (FIG. 2) can use the information provided by the vHRTD to quickly relocate the tape to the specified record or file mark number. In this manner, all application-requested read or write accesses may be quickly located even though the tape does not have an HRTD-type directory stored in the housekeeping data set.

[0078] The determination of whether a loaded tape cartridge conforms to a virtual high-resolution tape directory (vHRTD) may be made using known or later-developed detection techniques. For example, tape drives sold by IBM that conform to the LINEAR TAPE OPEN® (LTO®) standard record a virtual high-resolution tape directory (vHRTD) in the EOD data set of the data partition because the LTO® standard does not permit recording of HRTD-type directories in housekeeping data sets. Thus, it may be determined that a loaded cartridge has a vHRTD recorded in the EOD data set of the data partition, for example, by detecting that the loaded cartridge conforms to the LTO® standard, which does not permit HRTDs, or by detecting that the tape data storage drive 231 (FIG. 3) controlled by the storage controller 228 (FIG. 2) is an LTO®-type tape data storage drive that does not permit HRTDs.

[0079] The tape data storage drive 231 may be detected by the storage controller 228 as such an LTO®-type tape storage drive when, for example, the tape storage drive is coupled to the storage controller and the storage controller and the tape drive exchange suitable signals, including signals that identify the tape storage drive as an LTO®-type tape storage drive that does not permit recording of HRTDs in housekeeping data sets. In other embodiments, the tape cartridge 302 may have an identification feature 654 that may be scanned, for example, electronically or optically, to identify the cartridge 302 as such an LTO®-type cartridge in a manner similar to that described above with respect to detecting tape cartridges compatible with HRTDs. Other techniques may be used to determine the vHRTD suitability of a loaded cartridge, depending on the particular application, including the particular type of cartridge and the particular type of tape drive system.

[0080] In one embodiment, the tape may be relocated (block 834) using a "Space EOD" SCSI (Small Computer System Interface) command, which in the illustrated embodiment moves the tape to an EOD position within the data set of the data partition. It will be appreciated that other commands and techniques may be used to relocate the tape to an area where a vHRTD has been recorded. Additionally, it will be appreciated that tape relocation management according to the present description may be used in conjunction with systems that record vHRTD-type directories in other areas of the tape, depending on the particular application.

[0081] Note that as the number of files recorded on tape increases, the time it takes to obtain meta-information (block 824, FIG. 8) to mount the files on the tape (block 828, FIG. 8) may increase. In one embodiment, with the tape relocation management described herein, the tape is relocated to obtain meta-information (block 824) and then relocated to the EOD data set of the data partition (block 834); however, to shorten the overall mount time (block 828), the meta-information may be obtained (block 824) simultaneously with the movement of the tape to the data partition to obtain the vHRTD (block 834), as described herein.

[0082] When it is determined that the loaded cartridge does not fit into a known virtual high-resolution tape directory, such as a vHRTD-type tape cartridge (block 832), relocation of the tape to the EOD data set of the data partition (block 834) is avoided. In this manner, reading the vHRTD-type directory (block 842) is also avoided. Instead, the tape is relocated to the beginning of the data partition (block 850). For example, TS11xx-type tape drives sold by IBM use an HRTD-type directory recorded in a housekeeping data set and therefore do not fit into a known virtual high-resolution tape directory, such as a vHRTD-type tape cartridge. Thus, when the loaded tape cartridge is a TS11xx-type tape cartridge for a TS11xx tape drive, the tape is relocated to the beginning of the first data partition (block 850), and the loading and mounting of such a tape is considered complete.

[0083] In this manner, when a loaded tape cartridge is detected as matching a virtual high-resolution tape directory (vHRTD), the tape is automatically relocated for read and write access to the vHRTD associated with the tape load and file system mount process, instead of being relocated to the start of the data partition. As a result, the tape may be easily and quickly relocated using the obtained vHRTD information to the record number or file mark number specified by a subsequently received tape read or write access initiated by an application running on the host.

[0084] Loading a tape, mounting a tape file system, relocating a tape, and reading a tape directory are generally well-understood computer operating techniques. In one embodiment, these well-known computer operating techniques may be modified as disclosed in the drawings and accompanying description and, after suitable modifications, used for tape relocation management according to the present description.

[0085] 9A illustrates in schematic form an example of a tape with which relocation management according to the present description may be used. In this example, the tape has a beginning-of-tape region BOT at one end and an end-of-tape region EOT at the other end. In this embodiment, the end location of the first index partition 704a (FIG. 7B) and the beginning location 718a of the data partition are both at or near the beginning-of-tape (BOT) end of the tape length L, which may be a variety of lengths, such as 1000 meters.

[0086] As shown in Figure 9B, the average travel distance from the end of the BOT to an arbitrary position ("any position") is L / 2, where L is the length of the tape. In comparison, the average travel distance from one arbitrary position on the tape to another arbitrary position ("any position") is L / 3.

[0087] As previously mentioned, known tape directories (TDs) subdivide a tape wrap into two subareas and identify the records recorded in each subarea. Thus, Figure 9C shows a known example of a tape subdivided into two subareas, with the first subarea beginning with record X and ending with record Y, just before the beginning of the second subarea. In comparison, known vHRTD-type directories subdivide a tape wrap into 64 subareas, a portion of which is shown in Figure 9D. Thus, when a vHRTD is not used, TD-type directories typically identify record numbers as being in one of only two possible subareas: one toward the center of the wrap and one toward the end of the wrap. For example, to move to a target record, such as target record Z, which is midway between records X and Y shown in Figure 9C, a known relocation calculation calculates an approximate initial search position based on the ratio of the beginning and ending record numbers of the TD subarea containing the target record, i.e., target record number Z. In the example of Figure 9C, the initial search position is calculated as follows: L / 2*(ZX) / (YX)-M where M is a margin long enough to fit variable length records, and X, Y, and Z are the record numbers of records X, Y, and Z, respectively. Thus, a jump as represented by the dotted arrow in Figure 9C is made to an initial search position represented by the arrowhead of the dotted arrow, which precedes position L / 2*(ZX) / (YX) by a margin M. The target record is then searched for by reading the data set piece by piece.

[0088] In comparison, when a vHRTD is used, a wrap is divided into 64 subareas, as partially represented by the subareas in Figure 9D, and the record (or range of records) recorded in each subarea is identified in the vHRTD. As a result, the record numbers are continuous, and the specific tape subarea in which the target record was recorded can be easily determined from the record numbers identified at the beginning and end of each subarea. Thus, a rapid move, as represented by the solid arrow in Figure 9D, is made to the beginning of the determined subarea, represented by the arrowhead of the solid arrow in Figure 9D, and from there the data set within the subarea is searched until the target record is found.

[0089]

[0023] Below, an exemplary comparison of relocation movement times between a known tape drive and a tape drive using an embodiment of tape relocation management according to the present disclosure is provided. As previously mentioned, in one known LTO® type tape drive, after reading the index to mount the file system, the tape is relocated to the beginning of the data partition to await the first application request to access the tape. In comparison, in a tape drive using an embodiment of tape relocation management according to the present disclosure, after reading the index to read the vHRTD, the tape is immediately relocated to the EOD data set of the data partition and then awaits the first application request to access the tape.

[0090] In a tape drive that uses an LTFS-type file system, a read command issued by an application running on the host repositions the tape to any position on the tape to read the requested record or file. A write command issued by an application running on the host repositions the tape to the last recorded EOD position to write new data. In this comparison, it is assumed that application commands are not issued immediately after mounting, but rather at a later time when the application requires a read or write.

[0091] In this comparison, it is assumed that the initial tape movement time from when the cartridge is loaded until the index file is read and the file system metadata is read is substantially the same for both known tape drives and those using tape relocation management according to the present disclosure. FIG. 10A shows an index partition including wrap0. In this example, the tape position at which the index file is read is represented as tape position P. However, it is recognized that this initial movement time may vary between known tape drives and tape drives using tape relocation management according to the present disclosure, depending on the particular application. Additionally, FIGS. 10A-10D show a data partition with two wraps in this example; in each of FIGS. 10A-10D, the wraps are in one direction (e.g., wrap4) and in the opposite direction (e.g., wrap5). As previously mentioned, it is recognized that a data partition may have more wraps, depending on the particular application.

[0092] In a first comparative example, an estimate may be made of the average time it takes to move from the last data position in the first index partition (shown as position P in FIG. 10A) to the beginning of the data partition (shown as position Q in FIG. 10A) for a known tape drive in this example. In this example, this tape movement time is represented by the dotted arrow in FIG. 10A. In a known tape drive, this movement time from index position P written at the end of the index partition to position Q of the beginning of the data partition is S N This is often about 10 seconds for a typical travel speed expressed in meters per second. Since the start and end of the travel are adjacent to the BOT end of the tape, no searching is generally required.

[0093] For comparison purposes, an estimate may also be made of the average time it takes to move from the last data location in the first index partition (shown at position P in FIG. 10A ) to the EOD data set where the last vHRTD was recorded in order to read the vHRTD by tape relocation management according to the present disclosure. This tape movement time is represented by the solid arrow in FIG. 10A . In this example, the EOD data set where the last vHRTD was recorded is written to an arbitrary position in wrap5, which represents the last part of the data partition written before the tape was dismounted. Because the vHRTD read by tape relocation management according to the present disclosure is at an arbitrary position, the average time it takes to move from the last data location in the first index partition near the BOT (shown at position P in FIG. 10A ) to the EOD data set where the last vHRTD was recorded is L / (2*S V ) seconds, where S V S represents the average estimated movement speed for a tape drive using tape relocation management according to the present description, V >S Nmeters / second. Because the location of the target EOD data set is typically identified by data stored in memory, searching for the target EOD data set will often not be necessary. The retrieved vHRTD information may be expanded and stored in suitable memory very quickly, so the time for such expansion and storage may be substantially ignored for purposes of this comparison.

[0094] In another comparative example, an estimate may be made of the average time it takes in a known tape drive to move from, in this example, the beginning of the data partition (shown as position Q in FIG. 10B) to any position on the tape to meet an application request for a read at that position. In this example, this tape movement time for a known tape drive is represented by the dotted arrow in FIG. 10B. In such a known tape drive, the beginning of the data partition, position Q, is near the BOT end of the tape, so the average movement time from the beginning of the data partition, position Q, to any position is L / (2*S N ) seconds. Because known tape drives have not yet read the vHRTD information from the EOD data area, and therefore such known tape drives cannot use the vHRTD to facilitate locating the target record or file requested by an application read operation, an extensive search is typically performed to find the target record of the application-requested file.

[0095] For comparison purposes, an estimate may also be made of the average time it takes for tape relocation management according to the present disclosure to move from the EOD data area where the last vHRTD was read to any location on the tape to satisfy an application request for a read at that location. This tape movement time is represented by the solid arrow in FIG. 10B. As noted above, the EOD data area where the last vHRTD was recorded is written to an arbitrary location at the end of the data partition, representing the last data set of the data partition written before the tape was previously dismounted. Similarly, this target record or file may also be at an arbitrary location. The average movement time from one arbitrary location to another is L / (3*S V ) seconds. In a tape drive using tape relocation management according to the present disclosure, the search for the target record or file is relatively quick because the vHRTD information is read and stored in system memory to expedite the search for the target record or file requested by the application request.

[0096] In yet another comparative example, an estimate may be made of the average time it takes in a known tape drive to move from the beginning of the data partition (shown at position Q in FIG. 10C) in this example to any position to meet the application request for writing. In many tape drives, writing new file data typically starts from the EOD data set position of the last write operation, which is an arbitrary position. In this example, this tape movement time for a known tape drive is represented by the dotted arrow in FIG. 10C. In such a known tape drive, the beginning of the data partition, position Q, is near the BOT end of the tape, so the average movement time from the beginning of the data partition, position Q, to the last recorded EOD position, which is an arbitrary position, is L / (2*S N ) seconds.

[0097] For comparison purposes, an estimate may also be made of the average time it takes to move from the EOD position (FIG. 10C) where the vHRTD last recorded by the tape relocation management according to the present disclosure was read to any position on the tape to accommodate an application request for writing at that position. As noted above, the EOD data area where the last vHRTD was recorded is written to the end of the data partition representing the last data set written before the tape was dismounted. Additionally, as noted above, in many tape drives, writing new file data typically begins at the EOD position of the last write operation, which is the current tape position in the example of tape relocation management according to the present disclosure. Therefore, the move time required for a tape drive using tape relocation management according to the present disclosure is zero, because the tape is already positioned at the EOD position to start the new write operation.

[0098] In yet another comparative example, an estimate may be made of the average time it takes in a known tape drive to move from one arbitrary location, such as the site of the last read operation, to another arbitrary location to accommodate another application requirement for a read. In this example, this tape movement time from the site of one read operation to another read operation for a known tape drive is represented by the dotted arrow in FIG. 10D. In a known tape drive, the average movement time from one arbitrary location to another arbitrary location is L / (3*S N) seconds. In known tape drives, vHRTD information may be read from the EOD data area in response to an application write operation to expedite a subsequent read operation requested by the application. Thus, when vHRTD information has been read from the EOD data area in response to a previous application write operation, retrieval of the target record or file in response to a subsequent application access read request may be expedited by the vHRTD in those cases in known tape drives. However, when vHRTD information has not yet been read because a previous write operation has not yet been requested, a broad search is typically performed in known tape drives to find the target record or file for the application read request.

[0099] For comparison purposes, an estimate may be made of the average time it takes for a tape drive using tape relocation management according to the present disclosure to travel from one arbitrary location, such as the site of the last read operation, to another arbitrary location to accommodate another application request for a read. In this example, this tape travel time from the site of one read operation to another read operation for a tape drive using tape relocation management according to the present disclosure is represented by the solid arrow in FIG. 10D. Here, the average travel time from one arbitrary location to another arbitrary location is L / (3*S V ) seconds. In a tape drive using tape relocation management according to one embodiment of the present disclosure, the vHRTD information has already been read from the EOD data area before executing the first application read or write request. Thus, the vHRTD is available to expedite all application read requests by the application.

[0100] It is recognized that in known tape drives, when a read request comes immediately after mounting a cartridge file system, tape relocation according to the present disclosure for that first read request may take longer than tape relocation in known tape drives. For example, the relocation time for a tape drive using tape relocation management according to the present disclosure may be T V and the relocation time for a known tape drive is T N When expressed as T V -T N may be expressed as follows: L / (2*S V )+L / (3*S V )-L / (2*S N )-10 seconds.

[0101] However, a read request usually does not come immediately after the cartridge file system is mounted in a known tape drive. Therefore, if the cartridge file system is mounted in a known tape drive, the read request usually comes at least L / (2*S V )+L / (3*S V )-L / (2*S N If the first read request arrives after 10-10 seconds has elapsed, the relocation time for the first read request for a tape drive using tape relocation management according to the present disclosure will be faster than for a known tape drive. Similarly, for all subsequent read requests, the relocation time for a tape drive using tape relocation management according to the present disclosure and having an available vHRTD tape directory will be faster than for a known tape drive that does not yet have a vHRTD available.

[0102] If a write request comes in immediately after the cartridge file system is mounted, the comparison V -T N may be expressed as follows: L / (3*S V )-L / (2*S N)-10 seconds <L / (6*S)-10<0 This is S V This is satisfied when the vHRTD is approximately equal to 6*S. As noted above, this equation is always negative because L / (6*S) must be negative. Therefore, the relocation time for the first write request for a tape drive using tape relocation management according to the present disclosure is expected to be faster than for known tape drives. It is recognized that in response to the first write request for known tape drives, the vHRTD may be read from the EOD data set, thereby facilitating subsequent application access requests.

[0103] Comparison of the travel time T to respond to a read or write request at another arbitrary position when the tape position is at an arbitrary position and the vHRTD has not yet been read in a known tape drive. V -T N may be expressed as follows: L / (3*S V )-L / (3*S N )<0 This is satisfied. Thus, for these any-location-to-any-location relocations, the relocation time for a tape drive using tape relocation management according to the present disclosure is expected to be faster than for known tape drives. As noted above, it is recognized that in known tape drives, a vHRTD can be read from the EOD data set in response to a subsequent write request, thereby facilitating a subsequent application access request. On the other hand, when a read request continues without a write request obtaining a vHRTD, the relocation time for a tape drive using tape relocation management according to the present disclosure with an available vHRTD tape directory is expected to be faster than for known tape drives where a vHRTD is not yet available.

[0104] Aspects of tape relocation management 255 (FIG. 2) and tape relocation logic 257 may be embodied in a computer system / server at a single location, or, in at least one embodiment, configured in a cloud-based system that shares computing resources. Referring to FIG. 11, a block diagram is provided illustrating an example computer system 1100 including a computer / server 1102, hereafter referred to as host 1102, that communicates with a cloud-based support system to implement the systems, tools, and processes described above with respect to FIGS. 1A-3 and 8. Host 1102 operates in conjunction with numerous other general-purpose or special-purpose computer system environments or configurations. Examples of well-known computer systems, environments, or configurations, or combinations thereof, that may be suitable for use with host 1102 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputer systems, mainframe computer systems, and file systems (e.g., distributed storage environments and distributed cloud computing environments) that include any of the above systems, devices, and their equivalents.

[0105] The computer components of the figures may be implemented in one or more computer systems, such as the computer system or host 1102 shown in FIG. 11. The host 1102 may be described in the general context of computer system-executable instructions, such as program modules, executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, and data structures that perform particular tasks or implement particular abstract data types. The host 1102 may also be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media, including memory storage devices.

[0106] As shown in Figure 11, the host 1102 is shown in the form of a general-purpose computing device. The components of the host 1102 may include, but are not limited to, one or more processors or processing devices or units 1104, such as hardware processors, a system memory 1106, and a bus 1108 that couples various system components, including the system memory 1106, to the processing device 1104. The bus 1108 represents any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus. The host 1102 typically includes a variety of computer system readable media, which may be any available media that can be accessed by the host 1102, including both volatile and nonvolatile media, removable and non-removable media.

[0107] Memory 1106 may include computer system-readable media in the form of volatile memory, such as, for example, random access memory (RAM) 1130 or cache memory 1132, or both. By way of example only, a storage system 1134 may be provided for reading from and writing to a non-removable, non-volatile magnetic medium (not shown, commonly referred to as a "tape drive"). Although not shown, a magnetic disk drive may be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive may be provided for reading from or writing to a removable, non-volatile optical disk, such as, for example, a CD-ROM, DVD-ROM, or other optical medium, each of which may be connected to bus 1108 by one or more data medium interfaces. As further shown and described below, memory 1106 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of embodiments of the present invention.

[0108] Programs / utilities 1140 having a set (at least one) of program modules 1142, as well as an operating system, one or more application programs, other program modules, and program data, may be stored in memory 1106, by way of example and not limitation. Each of the operating system, one or more application programs, other program modules, and program data, or any combination thereof, may comprise an implementation of a networked environment. Program modules 1142 generally perform the functions and / or methods of embodiments to ensure that the vHRTD directory is available for application-requested access. For example, the set of program modules 1142 may include tape relocation management 255, as described in FIG. 2.

[0109] The host 1102 may also communicate with one or more external devices 1114, such as a keyboard, a pointing device, etc.; a display 1124; one or more devices that allow a user to interact with the host 1102; or any device (e.g., a network card, a modem, etc.) that allows the host 1102 to communicate with one or more other computer devices, or a combination thereof. Such communication may occur through input / output (I / O) interface(s) 1122. Additionally, the host 1102 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, via a network adapter 1120. As shown, the network adapter 1120 communicates with other components of the host 1102 via the bus 1108. In at least one embodiment, multiple nodes of a distributed file system (not shown) communicate with the host 1102 via the I / O interface 1122 or the network adapter 1120. Although not shown, it should be understood that other hardware and / or software components may be used with host 1102, including, but not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems.

[0110] In this document, the terms “computer program medium,” “computer usable medium,” and “computer-readable medium” are used to generally refer to media such as main memory 1106, which includes RAM 1130, cache memory 1132, and storage system 1134, such as a removable storage drive and a hard disk installed in a hard disk drive. Computer programs (also called computer control logic) are stored in memory 1106. Additionally, computer programs may be received via a communications interface, such as network adapter 1120. When executed, these computer programs enable the computer system to perform the features of the present embodiments discussed herein. In particular, when executed, the computer programs enable processing device 1104 to perform the features of the computer system. Thus, the computer programs may represent the controller of the computer system. Thus, the functionality for relocation management 255 described in the figures may be embodied as computer program code stored in memory 1106 (in some embodiments as program module 1142), which includes instructions that are executed by processing device 1104 to provide the functionality of relocation management 255 described herein.

[0111] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer diskettes, hard disks, dynamic or static random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), magnetic storage devices, portable compact disk read-only memory (CD-ROM), digital versatile disks (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or raised structures in grooves with recorded instructions, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through fiber optic cable), or electrical signals transmitted through wires.

[0112] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium into each computing / processing device, or may be downloaded to an external computer or external storage device over a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to a computer-readable storage medium within the respective computing / processing device for storage.

[0113] The computer-readable program instructions for carrying out the operations of the present embodiments may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, or C++, and traditional procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server or cluster of servers. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection to the external computer may be made (e.g., over the Internet using an Internet Service Provider). In some embodiments, electronic circuitry, including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by using state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects of the embodiments.

[0114] Thus, the functionality for relocation management described in the figures may be embodied as computer-readable program instructions executed by one or more hardware devices other than, or in addition to, processing device 1104 to provide the functionality of relocation management 255 described herein.

[0115] In at least one embodiment, host 1102 is a node in a cloud computing environment. While this disclosure includes a detailed description of cloud computing, it should be understood that implementation of the teachings described herein is not limited to cloud computing environments. Rather, embodiments of the present disclosure may be implemented in conjunction with any other type of computing environment now known or later developed.

[0116] As known in the art, cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with the service provider. The cloud model may include at least five characteristics, at least three service models, and at least four deployment models. Examples of these characteristics include:

[0117] On-demand self-service: Cloud consumers can unilaterally provision computing capacity, such as server time and network storage, as needed automatically and without human interaction with the provider of the service.

[0118] Broad network access. Functionality is available across the network and accessed through standard mechanisms that facilitate use by a variety of thin and thick client platforms (e.g., cell phones, laptops, and PDAs).

[0119] Resource Pooling. To serve multiple consumers using a multi-tenant model, a provider's computing resources are pooled, with different physical and virtual resources dynamically allocated and reallocated according to demand. Consumers generally have no control or knowledge over the exact location of the resources provided, although there is a sense of location independence in that they may be able to identify a location at a higher abstraction layer (e.g., country, state, or data center).

[0120] Rapid Elasticity. Capabilities can be rapidly and elastically provisioned, sometimes automatically, to quickly scale out, and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear unlimited, and any amount can be purchased at any time.

[0121] Metered services. Cloud systems automatically control and optimize resource usage by utilizing metering capabilities at some abstraction layer appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services used.

[0122] The service model is as follows:

[0123] Software as a Service (SaaS). The functionality offered to the consumer is the use of the provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through thin-client interfaces, such as web browsers (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage, or even individual application functions, with the possible exception of limited user-specific application configuration settings.

[0124] Platform as a Service (PaaS). The functionality offered to the consumer is the deployment onto a cloud infrastructure of applications created or acquired by the consumer, written using programming languages ​​and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the application hosting environment configuration.

[0125] Infrastructure as a Service (IaaS). The functionality provided to the consumer is the provisioning of processing, storage, network, and other basic computing resources onto which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does have control over the operating system, storage, deployed applications, and sometimes limited control over the selection of networking components (e.g., host firewalls).

[0126] The deployment model is as follows:

[0127] Private cloud: This cloud infrastructure is operated solely for one organization. It may be managed by that organization or a third party and may reside on-premises or off-premises.

[0128] Community Cloud: This cloud infrastructure is shared by multiple organizations to support a specific community with common concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by those organizations or a third party and may reside on-premises or off-premises.

[0129] Public cloud: This cloud infrastructure is made available to the general public or large industry groups and is owned by an organization that sells cloud services.

[0130] Hybrid cloud: This cloud infrastructure is a composite of two or more clouds (private, community, or public) that remain their own entities but are bound together by standard or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0131] Cloud computing environments are service-oriented and focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0132] Referring now to FIG. 12 , a schematic diagram illustrating an example cloud computing network 1200 is provided. As shown, cloud computing network 1200 includes a cloud computing environment 1250 having one or more cloud computing nodes 1210, with which local computing devices used by cloud consumers may communicate. Examples of these local computing devices include, but are not limited to, a personal digital assistant (PDA) or mobile phone 1254A, a desktop computer 1254B, a laptop computer 1254C, or an automotive computer system 1254N, or combinations thereof. Individual nodes within node 1210 may also communicate with each other. These nodes may be physically or virtually grouped (not shown) in one or more networks, such as the private, community, public, or hybrid clouds described above, or combinations thereof. This enables cloud computing network 1200 to provide infrastructure, platform, or software, or a combination thereof, as a service for which cloud consumers are not required to maintain resources on their local computing devices. It is understood that the types of computing devices 1254A-N shown in FIG. 8 are intended to be exemplary only, and that the cloud computing environment 1250 can communicate with any type of computing device through any type of network or network-addressable connection (e.g., using a web browser), or both.

[0133] Referring now to Figure 13, there is shown a set of functional abstraction layers 1300 provided by the cloud computing network of Figure 12. It should be understood in advance that the components, layers, and functions shown in Figure 13 are intended to be merely exemplary, and embodiments are not limited thereto. As shown, the following layers and corresponding functions are provided: a hardware and software layer 1310, a virtualization layer 1320, a management layer 1330, and a workload layer 1340.

[0134] The hardware and software layer 1310 includes hardware and software components. Examples of hardware components include mainframes, RISC (reduced instruction set computer) architecture-based servers, servers, blade servers, storage devices, networks, and network forming components. Examples of software components include network application server software and database software.

[0135] The virtualization layer 1320 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers, virtual storage, virtual networks including virtual private networks, virtual applications and operating systems, and virtual clients.

[0136] In one example, the management layer 1330 may provide the following functions: resource provisioning, metering and pricing, user portal, service layer management, and SLA planning and fulfillment. Resource provisioning provides dynamic procurement of computing and other resources used to perform tasks within the cloud computing environment. Metering and pricing provides cost tracking as resources are used within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection of data and other resources. The user portal provides access to the cloud computing environment for consumers and system administrators. Service layer management provides allocation and management of cloud computing resources to meet required service layers. Service layer agreement (SLA) planning and fulfillment provides advance agreement and procurement of cloud computing resources where future demand is predicted by SLAs.

[0137] The workload layer 1340 provides examples of functions for which a cloud computing environment may be used. Examples of workloads and functions that may be provided from this layer include, but are not limited to, mapping and navigation, software development and lifecycle management, virtual classroom instruction delivery, data analytics processing, transaction processing, and application level recovery performed by enterprise level image copies.

[0138] It will be appreciated that systems, methods, apparatus, and computer program products are disclosed herein for evaluating natural language input, detecting questions in the corresponding communication, and resolving the detected questions with answers and / or supporting content.

[0139] While particular embodiments of the present disclosure have been shown and described, it will be apparent to those skilled in the art that, based on the teachings herein, changes and modifications may be made without departing from the embodiments and their broader aspects. Accordingly, the appended claims encompass within their scope all such changes and modifications as falling within the scope of the embodiments. It is further to be understood that the embodiments are defined solely by the appended claims. When a specific number of introduced claim elements is intended, such intention will be explicitly stated in the claims; those skilled in the art will understand that, in the absence of such a statement, no such limitation exists. As a non-limiting example, and to aid in understanding, the appended claims below include the use of the introductory phrases "at least one" and "one or more" to introduce claim elements. However, the use of such phrases should not be interpreted as meaning that introducing a claim element with the indefinite article "a" or "an" means that any particular claim including such introduced claim elements is limited to embodiments including only one such element, even when the same claim also includes the introductory phrases "one or more" or "at least one" and an indefinite article, e.g., "a" or "an." The same applies to the use of definite articles in the claims.

[0140] The present embodiments may be systems, methods, or computer program products, or combinations thereof. In addition, selected aspects of the present embodiments may take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software or hardware aspects or both, all of which may be referred to generally herein as "circuits," "modules," or "systems." Furthermore, aspects of the present embodiments may take the form of a computer program product embodied in a computer-readable storage medium (or media) having computer-readable program instructions for causing a processor to execute aspects of the present embodiments. The disclosed systems, methods, or computer program products, or combinations thereof, so embodied, operate to improve the functionality and operation of a computer-based system or platform.

[0141] Aspects of the present embodiments are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to the embodiments. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0142] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, cause means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored includes instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0143] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operations to create a computer-implemented process, where the instructions executed on the computer, other programmable apparatus, or other device implement the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0144] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions shown in the blocks may occur in a different order than that shown in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. In addition, it will be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations or executes a combination of special-purpose hardware and computer instructions.

[0145] While specific embodiments are described herein for illustrative purposes, it will be recognized that various modifications may be made without departing from the scope of these embodiments. The description of various embodiments of the present disclosure is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will become apparent to those skilled in the art without departing from the scope of the described embodiments. The terms used herein are selected to best explain the principles of the embodiments, practical applications, or technical improvements to technologies found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein. Therefore, the scope of protection of the embodiments is limited only by the following claims and their equivalents.

[0146] The terms "an embodiment," "embodiment," "embodiments," "the embodiment," "the embodiments," "one or more embodiments," "some embodiments," and "one embodiment" mean "one or more (but not all) embodiments of the invention(s)," unless expressly specified otherwise.

[0147] The terms "including," "comprising," and "having" and variations thereof mean "including but not limited to," unless expressly specified otherwise.

[0148] An enumerated list of items does not imply that any or all items are mutually exclusive, unless expressly specified otherwise.

[0149] The terms "a," "an," and "the" mean "one or more," unless expressly specified otherwise.

[0150] Unless expressly specified otherwise, devices that communicate with each other need not be in continuous communication with each other. In addition, devices that communicate with each other may communicate directly or indirectly through one or more intermediaries.

[0151] A description of an embodiment having several components in communication with each other does not imply that all such components are required, to the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the present invention.

[0152] Where a single device or article is described herein, it will be readily apparent that two or more devices / articles (whether or not they cooperate) may be substituted for the single device / article. Similarly, where two or more devices or articles are described herein (whether or not they cooperate), it will be readily apparent that a single device / article may be substituted for the two or more devices or articles, or that a different number of devices / articles may be substituted for the number of devices or articles shown. The functionality and / or features of a device may alternatively be embodied by one or more other devices not expressly described as having such functionality / features. Thus, other embodiments of the present invention need not include the device itself.

[0153] The foregoing description of various embodiments of the invention has been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teachings. It is intended that the scope of the invention be limited not by this detailed description, but rather by the appended claims. The above specification, examples, and data provide a complete description of the manufacture and use of the composition of the invention. Because many embodiments of the invention can be made without departing from the scope of the invention, the invention resides in the claims appended hereto.

Claims

1. 1. A computer program product for a data storage system having a tape drive for use with a tape having a Linear Tape File System (LTFS), an index partition, and a data partition, wherein the tape drive resides in an enterprise computer system having memory, the computer program product including a computer-readable storage medium having program instructions executable by a processor of the enterprise computer system to cause operations to be performed, the operations comprising: Initiating a mount of the tape LTFS in response to loading a tape in the tape drive, the mount including reading an index partition of the tape to extract metadata for mounting the tape LTFS; before accessing a data area of ​​said tape in response to any application access request; relocating the tape within the data partition to read a virtual high resolution tape directory (vHRTD) recorded in an end of data (EOD) portion of the data partition; reading the EOD portion to read the vHRTD; 1. A computer program product comprising:

2. 2. The computer program product of claim 1, wherein the tape conforms to the Linear Tape-Open (LTO) standard and does not have a High Resolution Tape Directory (HRTD) recorded on a housekeeping portion of the tape.

3. 2. The computer program product of claim 1, wherein the operations further comprise waiting to receive a first application access request after reading the EOD portion to read the vHRTD.

4. 2. The computer program product of claim 1, wherein relocating the tape within a data partition having a virtual high-resolution tape directory (vHRTD) recorded in an end-of-data (EOD) portion of the data partition is initiated immediately after reading an index partition of the tape to extract metadata for mounting the tape LTFS.

5. 2. The computer program product of claim 1, wherein the operations further comprise expanding the vHRTD read from the EOD portion in a memory of the enterprise computer system.

6. 2. The computer program product of claim 1, wherein the operations further comprise extracting file system metadata when reading the index partition simultaneously with relocating the tape to the data partition having the vHRTD.

7. 2. The computer program product of claim 1, wherein the operations further include: stopping the tape at the beginning of a data partition, avoiding relocation, after reading the index partition containing meta information for mounting the tape LTFS; and proceeding directly to relocating the tape to a data set having the vHRTD after reading the index partition containing metadata for mounting the tape LTFS.

8. 1. An enterprise computer system comprising: a processor; Memory and a data storage system having a tape drive for use with a tape having a linear tape file system (LTFS), an index partition, and a data partition, the tape drive residing within the enterprise computer system; a computer program product for said enterprise computer system; the computer program product including a computer-readable storage medium having program instructions executable by a processor of the enterprise computer system to cause actions, the actions including: Initiating a mount of the tape LTFS in response to loading a tape in the tape drive, the mount including reading an index partition of the tape to extract metadata for mounting the tape LTFS; before accessing a data area of ​​said tape in response to any application access request; relocating the tape within the data partition to read a vHRTD (virtual high resolution tape directory) recorded in an EOD (end of data) portion of the data partition; reading the EOD portion to read the vHRTD; enterprise computer systems, including

9. 9. The computer system of claim 8, wherein the tape conforms to the Linear Tape-Open (LTO) standard and does not have a High Resolution Tape Directory (HRTD) recorded on a housekeeping portion of the tape.

10. 9. The computer system of claim 8, wherein the operations further comprise waiting to receive a first application access request after reading the EOD portion to read the vHRTD.

11. 9. The computer system of claim 8, wherein relocating the tape within a data partition having a virtual high-resolution tape directory (vHRTD) recorded in an end-of-data (EOD) portion of the data partition is initiated immediately after reading an index partition of the tape to extract metadata for mounting the tape LTFS.

12. 9. The computer system of claim 8, wherein the operations further comprise expanding the vHRTD read from the EOD portion in a memory of the enterprise computer system.

13. 10. The computer system of claim 8, wherein the operations further comprise extracting file system metadata when reading the index partition simultaneously with relocating the tape to the data partition having the vHRTD.

14. 10. The computer system of claim 8, wherein the operations further include: stopping the tape at the beginning of a data partition, avoiding relocation, after reading the index partition containing meta information for mounting the tape LTFS; and proceeding directly to relocating the tape to a data set having the vHRTD after reading the index partition containing metadata for mounting the tape LTFS.

15. loading a tape in a tape drive having a linear tape file system LTFS within the tape drive; Initiating a mount of the tape LTFS, including reading an index partition of the tape to extract metadata for mounting the tape LTFS; relocating the tape within the data partition to read a virtual high-resolution tape directory (vHRTD) recorded in an end-of-data (EOD) portion of the data partition before accessing a data area of ​​the tape in response to any application access request; reading the EOD portion to read the vHRTD; A method comprising:

16. 16. The method of claim 15, wherein the tape conforms to the Linear Tape-Open (LTO) standard and does not have a High Resolution Tape Directory (HRTD) recorded in a housekeeping portion of the tape.

17. 16. The method of claim 15, further comprising waiting to receive a first application access request after reading the EOD portion to read the vHRTD.

18. 16. The method of claim 15, wherein relocating the tape in the data partition having a virtual high resolution tape directory (vHRTD) recorded in an end-of-data (EOD) portion of the data partition includes stopping the tape at the data partition after reading the index partition containing meta information for mounting the tape LTFS, avoiding relocation, so that relocation for the data partition having the vHRTD proceeds immediately after reading the index partition containing meta information for mounting the tape LTFS.

19. 16. The method of claim 15, further comprising expanding the vHRTD read from the EOD portion in a memory of an enterprise computer system that includes the tape drive.

20. 16. The method of claim 15, further comprising extracting file system meta information when reading the index partition simultaneously with relocating the tape to the data partition having the vHRTD.

Images