Copying data from a storage system based on a linear tape file system to a random-access nonvolatile memory drive

Abstract

A computer-implemented method includes copying data stored in a Linear Tape File System (LTFS)-based storage system to blocks of a Random Access Nonvolatile Memory (RANVM) drive. The data is copied in units of blocks of the drive. The method further includes constructing file metadata such that the copied data on the drive is accessible as one or more files.

Description

[Technical Field]

[0001] The present invention relates generally to data storage systems, and more particularly to copying data from a Linear Tape File System (LTFS)-based storage system to a Random Access Nonvolatile Memory (RANVM) drive. [Background technology]

[0002] In some data storage settings, data is eventually shifted from an on-premises environment to a cloud-based environment. In some environments, this shift can involve migrating relatively large amounts of data. Some cloud vendors recognize and discuss the importance of efficiently migrating data during such a shift. In particular, while data transfer primarily occurs over a network, it has been discussed that offline data transfer methods via logistics are sometimes introduced when strengthening the network for temporary data movement is impractical. Some cloud vendors provide services through original developments of equipment used exclusively for data transfer. Meanwhile, other cloud vendors offer data transfer services using LTFS. Some approaches also standardize methods for transferring relatively large amounts of data from one system to another using LTFS. Some cloud vendors guarantee online accessibility of data delivered via logistics within 24 hours of receipt. It is important to note that such guarantees are made regardless of the size of the data volume being migrated. Ensuring such guarantees typically involves considering the amount of data received from logistics per unit of time, as well as the amount of data received that can be copied to an online system per unit of time. Consideration of these metrics may be taken into account to build, maintain, and manage a system by preventing the former metric from exceeding the latter metric. For example, operations to use LTFS for data transfer may include ensuring multiple tape drives so that a range of tape cartridges received in a day can be processed within a day. In such an example, a specification that the data be copied within a relatively short period of time may be required in addition to the expected time to perform the data copy. This operation may be particularly useful in environments where such requirements exist.

[0003] While LTFS simplifies tape handling compared to some traditional data storage technologies, some characteristics resulting from the use of tape within storage devices remain the same. When a file is read from a magnetic storage device, such as a hard disk drive (HDD) or magnetic tape, the device (e.g., the device's head) is aligned with the location where the file data is stored to read the data. This process is also known as seeking. A seek operation within an HDD involves only the movement of an arm containing the head over a disk with a diameter of a few centimeters; therefore, the seek may take only a few tens of milliseconds to perform. In contrast, a seek operation on magnetic tape involves reeling the magnetic tape, which may be over 1,000 meters long. Therefore, a seek operation on magnetic tape can take much longer to perform than a seek operation within an HDD. When a relatively large file is copied from an LTFS-based storage system to an HDD, these relatively long seek times can add a significant amount of time to the data copy process. Summary of the Invention

[0004] A computer-implemented method according to one embodiment includes copying data stored in a Linear Tape File System (LTFS)-based storage system to blocks of a Random Access Nonvolatile Memory (RANVM) drive. The data is copied in units of drive blocks. The method further includes constructing file metadata so that the copied data on the drive is accessible as one or more files. The data is efficiently copied from the LTFS-based storage system to the blocks of the RANVM drive based on the data being copied in units of drive files. This is because copying data from an LTFS-based storage system to a drive in units of data files otherwise requires data seek operations that ultimately increase the time required to perform the data copy. These seek operations on magnetic tape involve rewinding the magnetic tape, which may have a length of over 1000 meters. When relatively large files are copied from an LTFS-based storage system to a drive, these relatively long seek times can add a significant amount of time to the data copy process. However, in this technique, while copying data on the magnetic recording tape to blocks in the drive, data seek operations may not be performed on the magnetic recording tape, for example, to determine the start location of an instance of data to be copied, to determine the end location of an instance of data to be copied, to determine the location of split data and / or fragmented data files, etc. Therefore, by avoiding at least some of these seek operations, file data may be copied from the LTFS-based storage system to the drive in significantly less time than the amount of time that would be consumed if copying the file data from the LTFS-based storage system to the drive included performing data seeks. For example, each avoided seek operation may reduce the time of the copy process by up to approximately several tens of seconds.

[0005] During the data copy, a correspondence table may be created that maps data locations within the LTFS to data locations on the drive, and thus may be used to understand which location on the drive to use to copy data located at any location on a block in the LTFS-based storage system.

[0006] According to another aspect, a computer program product includes a computer-readable storage medium having program instructions embodied therein, the program instructions being readable and / or executable by a controller to cause the controller to perform the method described above.

[0007] According to another aspect, a system includes a processor and logic integrated into, executable by, or integrated into and executable by the processor, the logic configured to perform the method described above.

[0008] Any of these techniques may be implemented in a magnetic data storage system, such as a tape drive system, which may include a magnetic head, a drive mechanism for passing a magnetic medium (e.g., recording tape) over the magnetic head, and a controller electrically coupled to the magnetic head.

[0009] Other aspects and techniques of the present invention will become apparent from the following detailed description, which, taken in conjunction with the drawings, illustrate by way of example the principles of the invention. [Brief explanation of the drawings]

[0010] [Figure 1A] 1 is a schematic diagram of a simplified tape drive system according to one approach. [Figure 1B] 1 is a schematic diagram of a tape cartridge according to one approach. [Figure 2A]FIG. 1 shows a side view of one approach to a flat-wrap, bidirectional, two-module magnetic tape head. [Figure 2B] 2B is a view of the tape bearing surface taken from line 2B of FIG. 2A. [Figure 2C] FIG. 2C is a detailed view taken from circle 2C of FIG. 2B. [Figure 2D] FIG. 10 is a detailed view of a partial tape bearing surface of a pair of modules. [Figure 3] FIG. 2 is a partial tape bearing surface view of a magnetic head having a write-read-write configuration. [Figure 4] FIG. 2 is a partial tape bearing surface view of a magnetic head having a read-write-read configuration. [Figure 5] A side view of one approach to a magnetic tape head that includes three modules, all of which typically lie along approximately parallel planes. [Figure 6] FIG. 1 is a side view of a magnetic tape head containing three modules in a tangential (inclined) configuration. [Figure 7] FIG. 1 is a side view of a magnetic tape head containing three modules in an overlapping configuration. [Figure 8A] Schematic diagram showing the principle of tape tenting. [Figure 8B] Schematic diagram showing the principle of tape tenting. [Figure 8C] Schematic diagram showing the principle of tape tenting. [Figure 9] FIG. 1 is a diagram illustrating files and indexes stored on magnetic tape according to one approach. [Figure 10] FIG. 1 is a diagram of a tiered data storage system according to one approach. [Figure 11] 1 is a flowchart of a method, according to one approach. [Figure 12] FIG. 1 is a representation of one approach to copying data from an LTFS-based storage system to blocks on a RANVM drive. [Figure 13A]FIG. 1 illustrates the state of an LTFS-based storage system and correspondence table according to one approach. [Figure 13B] 13B illustrates the copying of data from the LTFS-based storage system of FIG. 13A to a block of a RANVM drive. [Figure 13C] 13A and 13B and a diagram showing the state of the correspondence relationship table in FIG. 13A. [Figure 13D] 13A-13C illustrate copying data from the LTFS-based storage system to blocks of the RANVM drive of FIG. 13B. [Figure 13E] 13A-13D illustrate copying data from the LTFS-based storage system to a destination file system, which is a File Allocation Table (FAT). [Figure 14A] FIG. 1 illustrates the state of an LTFS-based storage system and correspondence table according to one approach. [Figure 14B] 14B is a diagram showing the state of the LTFS-based storage system and the correspondence table of FIG. 14A. [Figure 14C] 14B illustrates the copying of data from the LTFS-based storage system of FIG. 14A to a block of a RANVM drive. [Figure 14D] 14A to 14C and the state of the correspondence relationship table of FIG. 14A to 14B. [Figure 14E] 14A-14D illustrate copying data from the LTFS-based storage system to a block of a RANVM drive. FIG. [Figure 14F] 14A-14D illustrate copying data from the LTFS-based storage system to a destination file system that is FAT. [Figure 15] FIG. 1 is a diagram of a sample pseudocode according to one approach. DETAILED DESCRIPTION OF THE INVENTION

[0011] The following description is made for the purpose of illustrating the general principles of the present invention and is not intended to limit the inventive concepts claimed herein. Moreover, particular features described herein can be used in combination with other described features in each of the various possible combinations and permutations.

[0012] In this specification, unless otherwise specifically defined, all terms are to be given their broadest possible interpretation, including the meaning implied by this specification and the meaning understood by a person skilled in the art and / or defined in dictionaries, treatises, etc.

[0013] It should also be noted that as used in this specification and the appended claims, the singular forms "a," "an," and "the" include plural referents unless specifically stated otherwise.

[0014] The following description discloses several preferred techniques for the data storage system and its operation and / or components.

[0015] In one general approach, a computer-implemented method includes copying data stored in a Linear Tape File System (LTFS)-based storage system to blocks of a Random Access Nonvolatile Memory (RANVM) drive. The data is copied in units of blocks on the drive. The method further includes constructing file metadata such that the copied data on the drive is accessible as one or more files.

[0016] In another general approach, a computer program product includes a computer-readable storage medium having program instructions embodied therein, the program instructions being readable and / or executable by a controller to cause the controller to perform the method described above.

[0017] In another general approach, a system includes a processor and logic integrated with, executable by, or integrated with and executable by the processor, the logic being configured to perform the method described above.

[0018] Figure A1 illustrates a simplified tape drive 100 of a tape-based data storage system that may be employed in connection with the present invention. It should be noted that while one particular implementation of a tape drive is shown in Figure 1A, the techniques described herein may be implemented in connection with any type of tape drive system.

[0019] As shown, a tape supply cartridge 120 and a take-up reel 121 are provided to support a tape 122. One or more of the reels may form part of a removable cartridge and are not necessarily part of the tape drive 100. A tape drive such as that shown in FIG. 1A may further include a drive motor for driving the tape supply cartridge 120 and take-up reel 121 to move the tape 122 over any type of tape head 126. Such a head may include an array of read transducers (also called readers), write transducers (also known in the art as writers), or both.

[0020] Guide 125 guides tape 122 across tape head 126. Such tape head 126 is then coupled to controller 128 via cable 130. Controller 128 may be or include a processor and / or any logic for controlling any subsystem of drive 100. For example, controller 128 typically controls head functions such as servos, data writing, data reading, etc. Controller 128 may include at least one servo channel and at least one data channel, each of which includes data flow processing logic configured to process and / or store information written to and / or read from tape 122. Controller 128 may operate under any logic known in the art and disclosed herein and, therefore, in various ways, may be considered a processor with respect to any of the tape drive descriptions contained herein. Controller 128 may be coupled to any known type of memory 136 capable of storing instructions executable by controller 128. Additionally, controller 128 may be configured and / or programmable to perform or control some or all of the methods presented herein. Thus, controller 128 may be thought of as configured to perform various operations as programmed logic in one or more chips, modules, or blocks, or a combination thereof, software, firmware, or other instructions available to one or more processors, or a combination thereof, and the like.

[0021] Cable 130 may include read / write circuitry for transmitting data to be recorded on tape 122 to tape head 126 and for receiving data read from tape 122 by tape head 126. Actuator 132 controls the position of tape head 126 relative to tape 122.

[0022] An interface 134 may be provided for communication to send and receive data between tape drive 100 and a host (internal or external), as well as for controlling the operation of tape drive 100 and communicating the status of tape drive 100 to the host, all as will be understood by those skilled in the art.

[0023] FIG. 1B illustrates an exemplary tape cartridge 150 according to one approach. Such a tape cartridge 150 may be used with a system such as the system illustrated in FIG. 1A. As shown, the tape cartridge 150 includes a housing 152, a tape 122 within the housing 152, and a non-volatile memory 156 coupled to the housing 152. In some approaches, the non-volatile memory 156 may be incorporated within the housing 152, as shown in FIG. 1B. In other approaches, the non-volatile memory 156 may be attached to the inside or outside of the housing 152 without modifying the housing 152. For example, the non-volatile memory may be incorporated within an adhesive label 154. In one preferred approach, the non-volatile memory 156 may be a flash memory device, a read-only memory (ROM) device, or the like, and may be incorporated within or coupled to the inside or outside of the tape cartridge 150. The non-volatile memory is accessible by the tape drive and tape operating software (driver software), or by another device, or a combination thereof.

[0024] By way of example, FIG. 2A shows a side view of a flat-wrap, bidirectional, two-module magnetic tape head 200 that may be implemented in connection with the present invention. As shown, the head includes a pair of bases 202, each with a module 204, secured at a small angle α relative to one another. The bases may be "U-shaped beams" adhesively bonded together. Each module 204 includes a substrate 204A and a closure 204B, along with a thin-film portion, commonly referred to as a "gap," within which a read transducer and / or write transducer 206 is formed. During use, the tape 208 is moved over the modules 204 along a media (tape) support surface 209 to read and write data on the tape 208 using the read and write transducers in the manner shown. The wrap angle θ at the edge of the tape 208 moving out onto the flat media support surface 209 is typically between about 0.1 degrees and about 3 degrees.

[0025] The substrate 204A is typically constructed of a wear-resistant material such as ceramic, and the closure 204B may be made of the same ceramic as the substrate 204A or a similar ceramic.

[0026] The read and write transducers may be arranged in a piggyback or fused configuration. An exemplary piggyback configuration includes a (magnetically inductive) write transducer above (or below) a (magnetically shielded) read transducer (e.g., a magnetoresistive reader), with the write transducer pole and read transducer shield typically separated. An exemplary fused configuration includes one writer pole and one reader shield in the same physical layer (hence "fused"). The read and write transducers may also be arranged in an interleaved configuration. Alternatively, each array of channels may be only read transducers or only write transducers. Either of these arrays may include one or more servo readers to read servo data on the media.

[0027] Figure 2B shows the tape support surface 209 of one of the modules 204 taken from line 2B of Figure 2A. A representative tape 208 is shown in dashed lines. The module 204 is preferably long enough to support the tape as the head moves between the data bands.

[0028] In this example, the tape 208 includes between 4 and 32 data bands, e.g., 16 data bands and 17 servo tracks 210 on a half-inch (1.27 cm) wide tape 208, as shown in FIG. 2B. The data bands are defined between the servo tracks 210. Each data band may include multiple data tracks (e.g., 1024 data tracks (not shown)). During read / write operations, the read and / or write transducers 206 are positioned at specific track locations within one of the data bands. An outer reader (sometimes referred to as a servo reader) reads the servo tracks 210. Servo signals are then used in a conventional manner to keep the read and / or write transducers 206 aligned to a specific set of tracks during read / write operations.

[0029] FIG. 2C illustrates a plurality of read and / or write transducers 206 formed within a gap 218 on a module 204 within circle 2C in FIG. 2B. As shown in FIG. 2C, the array of read and write transducers 206 includes, for example, 16 write transducers 214, 16 read transducers 216, and two servo readers 212, although the number of these elements may vary. Exemplary approaches include 8, 16, 32, 40, and 64 active read and / or write transducers 206 per array; alternatively, interleaved designs include an odd number of read or write transducers, such as 17, 25, or 33. Exemplary approaches include 32 read transducers per array or 32 write transducers per array, although the actual number of transducer elements may be greater (e.g., 33, 34, etc.). Multiple simultaneously operated transducers allow the tape to move at a moderate speed while maintaining a high data transfer rate. A lower speed is desirable to reduce the mechanical difficulty of tracking caused by speed.

[0030] As shown in Figure 2C, the read transducers and write transducers may be arranged in a piggyback configuration, although the read transducers 216 and write transducers 214 may be arranged in an interleaved configuration. Alternatively, each array of read and / or write transducers 206 may be only read transducers or only write transducers, and each array may include one or more servo readers 212. As shown by considering Figures 2A and 2B-2C together, each module 204 may include complementary sets of read and / or write transducers 206 for bidirectional reading and writing, play-while-recording capabilities, backward compatibility, etc.

[0031] FIG. 2D shows a partial tape-bearing surface view of complementary modules of magnetic tape head 200 according to one approach. In this approach, each module includes multiple read / write (R / W) pairs and optional electrically insulating layer 236 formed on a common substrate 204A in a piggyback configuration. Write transducer 214 and read transducer 216 are aligned parallel to the intended direction of tape media movement therethrough, forming R / W pairs exemplified by R / W pair 222. Note that the intended direction of tape movement is sometimes referred to herein as the tape movement direction, and these terms may be used interchangeably. Such tape movement direction may be inferred from the system design, for example, by examining guides, observing the actual tape movement direction relative to a reference point, etc. Furthermore, in a system operable for bidirectional reading and / or writing, the tape movement directions in both directions are typically parallel, and therefore may be considered equivalent to each other.

[0032] There may be a plurality of R / W pairs 222, such as 8, 16, 32, etc. The R / W pairs 222 are shown aligned linearly, generally perpendicular to the direction of tape movement across them. However, the pairs may also be aligned diagonally, etc. Servo readers 212 are located outside the array of R / W pairs, and their function is well known.

[0033] Typically, the magnetic tape medium moves in either a forward or reverse direction, as indicated by arrow 220. The magnetic tape medium and head assembly 200 operate in a transducing relationship in a manner well known in the art. Head assembly 200 includes two thin-film modules 224 and 226 of generally identical construction.

[0034] Modules 224 and 226, coupled together with the space existing between their closures 204B (partially shown), form a single physical unit and provide play-while-record functionality by activating the write transducer of the preceding module and the read transducer of the succeeding module aligned with the write transducer of the preceding module parallel to the direction of tape movement relative thereto. When modules 224, 226 of magnetic tape head 200 are constructed, layers are formed within gap 218 on a conductive substrate 204A (partially shown), such as AlTiC. The layers for R / W pair 222 generally include an insulating layer 236, a first shield 232, typically an iron alloy such as NiFe (e.g., approximately 80 / 20 at% NiFe, also known as Permalloy), cobalt zirconium tantalum (CZT) or Al-Fe-Si (Sendust), a sensor 234 for sensing data tracks on the magnetic media, a second shield 238, typically an iron-nickel alloy (e.g., Permalloy), first and second writer poles 228, 230, and a coil (not shown). The sensors may be of any known type, including sensors based on magnetoresistive (MR), GMR, AMR, tunneling magnetoresistance (TMR), and the like.

[0035] The first and second writer poles 228, 230 may be fabricated from a high magnetic moment material such as CoFe. Note that these materials are provided merely as examples, and other materials may be used. Additional layers may be present, such as insulation between the shield and / or pole tips and an insulating layer surrounding the sensor. Exemplary materials for insulation include alumina oxide and other oxides, insulating polymers, etc.

[0036] One approach to tape head 126 configuration includes multiple modules, preferably three or more. In a write-read-write (WRW) head, an outer module for writing flanks one or more inner modules for reading. Referring to FIG. 3, which illustrates a WRW configuration, outer modules 252, 256 each include one or more arrays 260 of write transducers. Inner module 254 of FIG. 3 includes one or more arrays 258 of read transducers in a similar configuration. Variations of multi-module heads include RWR heads (FIG. 4), RRW heads, WWR heads, etc. In yet other variations, one or more of the modules may include read / write pairs of transducers. Furthermore, there may be four or more modules. In yet other approaches, two outer modules may flank two or more inner modules, e.g., in a WRRW, RWWR, etc. arrangement. For simplicity, a WRW head will be primarily used herein to illustrate the approach of the present invention. Those skilled in the art, informed by the teachings herein, will understand how the permutations of the present invention apply to configurations other than the WRW configuration.

[0037] FIG. 5 illustrates a magnetic head 126 according to one approach of the present invention, including first, second, and third modules 302, 304, and 306, respectively, each including a tape-bearing surface 308, 310, and 312, respectively, which may be flat, contoured, or the like. While the term "tape-bearing surface" may appear to imply that the surface facing the tape 315 is in physical contact with the tape-bearing surface, this is not necessarily the case. Rather, only a portion of the tape may be in constant or intermittent contact with the tape-bearing surface, while another portion of the tape may rest (or "float") above the tape-bearing surface on a layer of air (sometimes referred to as air bearing). The first module 302 is referred to as the "leading" module because it is the first module encountered by the tape in a three-module design with the tape moving in the direction shown. The third module 306 is referred to as the "trailing" module. The trailing module is the last module encountered by the tape in a three-module design, following the middle module. The leading module 302 and the trailing module 306 are collectively referred to as the outer modules. Note also that the outer modules 302, 306 alternate as the leading module depending on the direction of tape 315 movement.

[0038] In one approach, the tape bearing surfaces 308, 310, 312 of the first, second, and third modules 302, 304, 306 lie on substantially parallel planes (which is intended to include parallel planes and near-parallel planes (e.g., planes between parallel and tangent, as in FIG. 6 )), with the tape bearing surface 310 of the second module 304 above the tape bearing surfaces 308, 312 of the first and third modules 302, 306. As explained below, doing so has the effect of creating a desired wrap angle α2 of the tape relative to the tape bearing surface 310 of the second module 304.

[0039] If the tape bearing surfaces 308, 310, and 312 were parallel or nearly parallel but along offset planes, intuitively, the tape would peel from the tape bearing surface 308 of the leading module 302. However, experimentation has shown that the vacuum created by the peeling edge 318 of the leading module 302 is sufficient to keep the tape adhered to the tape bearing surface 308 of the leading module 302. The trailing edge 320 of the leading module 302 (the end where the tape leaves the leading module 302) serves as an approximate reference point for defining the wrap angle α2 on the tape bearing surface 310 of the second module 304. The tape remains in close proximity to the tape bearing surface until it approaches the trailing edge 320 of the leading module 302. Therefore, the transducers 322 may be located near the trailing edges of the outer modules 302 and 306. These approaches are particularly suitable for write-read-write applications.

[0040] A benefit of this and other approaches described herein is that because the outer modules 302, 306 are fixed in a determined offset position relative to the second module 304, the inner wrap angle α2 is fixed when the modules 302, 304, 306 are bonded together or otherwise secured to the head. The inner wrap angle α2 is approximately tan -1 (δ / W), where δ is the height difference between the planes of the tape bearing surfaces 308, 310, and W is the width between the opposing ends of the tape bearing surfaces 308, 310. Exemplary inner wrap angles α2 are in the range of about 0.3° to about 1.1°, but can be any angle required by the design.

[0041] The inside wrap angle α2 on the side (leading edge) of the module 304 that receives the tape is advantageously larger than the inside wrap angle α3 on the trailing edge as the tape 315 rides onto the trailing module 306. This difference is beneficial because a smaller α3 typically tends to counter the steeper the resulting effective wrap angle has traditionally been.

[0042] Note that the tape bearing surfaces 308, 312 of the outer modules 302, 306 are positioned to achieve a negative wrap angle at the trailing edge 320 of the leading module 302. This is beneficial in that it helps reduce friction resulting from contact with the trailing edge 320, provided that the location of the crowbar region in the tape, which typically occurs at the head-off location, is properly considered. This negative wrap angle also reduces flutter and scraping against elements on the leading module 302. Furthermore, because the tape 315 floats above the tape bearing surface 312 in the trailing module 306, there is virtually no wear against elements as the tape moves in this direction. In particular, the tape 315 does not significantly ride on the tape bearing surface 312 of the third module 306 (though some contact may occur) due to air drag. This is acceptable because the leading module 302 is writing while the trailing module 306 is idle.

[0043] Write and read functions are performed by different modules at any one time. In one approach, the second module 304 includes multiple data readers and an optional servo reader 331, but does not include a write transducer. The first and third modules 302, 306 include multiple write transducers 322 and do not include a data read transducer, except that the outer modules 302, 306 may include optional servo readers. The servo readers may be used to position the head during read and / or write operations. The servo readers on each module are typically located toward the ends of the array of read or write transducers.

[0044] By having only the read transducer or side-by-side write transducer and servo reader in the gap between the substrate and the closure, the gap length can be significantly reduced. A typical head includes piggybacked read and write transducers, with a write transducer formed above each read transducer. A typical gap is 20-35 microns. However, irregularities on the tape can tend to droop into the gap and cause gap erosion. Therefore, the smaller the gap, the better. The smaller the gap enabled herein, the less likely it is to exhibit wear-related problems.

[0045] In some approaches, the second module 304 includes a closure, while the first and third modules 302, 306 do not. If no closures are present, a hard coating is preferably added to the modules. One preferred coating is diamond-like carbon (DLC).

[0046] In the approach shown in FIG. 5 , the first, second, and third modules 302, 304, and 306 each include a closure 332, 334, and 336, respectively, which extend the tape-bearing surface of the associated module, thereby effectively positioning the read / write elements away from the edge of the tape-bearing surface. The closure 332 on the second module 304 can be a ceramic closure of the type typically found on tape heads. However, the closures 334 and 336 on the first and third modules 302 and 306 can be shorter than the closure 332 on the second module 304 when measured parallel to the direction of tape travel on each module. This allows the modules to be positioned closer together. One way to fabricate the shorter closures 334 and 336 is to overlap the standard ceramic closure of the second module 304 by an additional amount. Another method is to plate or deposit the thin-film closure on top of the elements during thin-film processing. For example, a thin film closure of a hard material such as sendust or an iron-nickel based alloy (eg, 45 / 55) can be formed over the module.

[0047] By using reduced thickness ceramic or thin film closures 334, 336 on the outer modules 302, 306, or no closures at all, the gap spacing between the writer and reader can be reduced to less than about 1 mm (e.g., about 0.75 mm), or 50% less than the spacing of commonly used linear tape open (LTO) tape heads. The spacing between the modules 302, 304, 306 can still be set to about 0.5 to 0.6 mm, which in some approaches is optimal for stabilizing tape movement above the second module 304.

[0048] Depending on the tape tension and stiffness, it may be desirable to tilt the tape-bearing surface of the outer module relative to the tape-bearing surface of the second module. Figure 6 illustrates an approach in which the modules 302, 304, and 306 are in a tangential or near-tangential (inclined) configuration. In particular, the tape-bearing surfaces of the outer modules 302 and 306 are approximately parallel to the tape at the desired wrap angle α2 of the second module 304. In other words, the planes of the tape-bearing surfaces 308 and 312 of the outer modules 302 and 306 are oriented approximately at the desired wrap angle α2 of the tape 315 relative to the second module 304. This approach also causes the tape to lift off the subsequent module 306, thereby reducing wear on the elements of the subsequent module 306. These approaches are particularly useful for write-read-write applications. Additional aspects of these approaches are similar to those previously described.

[0049] Typically, the wrap angle of the tape may be set approximately halfway between the approaches shown in FIGS.

[0050] FIG. 7 illustrates an approach in which modules 302, 304, and 306 are in an overlapping configuration. In particular, the tape support surfaces 308, 312 of the outer modules 302, 306 are slightly tilted relative to the tape 315 when set at the desired wrap angle α2 relative to the second module 304. In this approach, the tape does not lift off the subsequent modules, allowing the subsequent modules to be used for writing or reading. Thus, the leading module and the middle module can both perform read and / or write functions, while the subsequent module can read any previously written data. Therefore, these approaches are preferred for write-read-write, read-write-read, and write-write-read applications. In the latter approach, the closure should be wider than the tape canopy to ensure read functionality. A wider closure may require a wider gap separation. Therefore, a preferred approach has a write-read-write configuration, which allows for the use of a shortened closure and therefore a narrower gap separation.

[0051] Additional aspects of the approach shown in Figures 6 and 7 are similar to those previously described.

[0052] A 32-channel version of the multi-module head 126 may use a cable 350 with leads on the same or similar pitch as the current 16-channel piggyback LTO modules, or alternatively, the connections on the modules may be organ-keyboarded to reduce cable length by 50%. Unshielded cables for the upper and lower write pairs may be used for write transducers, which may have integrated servo readers.

[0053] The outer wrap angle α1 may be set in the drive by any type of guide known in the art, such as adjustable rollers, slides, or alternatively by outriggers integrated into the head. For example, a roller including an offset shaft may be used to set the wrap angle. The offset shaft creates an orbital arc of rotation, allowing for precise alignment of the wrap angle α1.

[0054] Conventional U-shaped spar assemblies may be used to assemble any of the aforementioned approaches. Thus, the mass of the resulting head may be maintained or reduced compared to previous generation heads. Alternatively, the module may be constructed as a single unit. Those skilled in the art with knowledge of this specification will understand that other known methods of manufacturing such heads may be suitable for use in constructing such heads. Furthermore, unless otherwise specified, processes and materials of the type known in the prior art may be suitable for use in the various approaches, consistent with the contents of this specification, as will be apparent to those skilled in the art upon reading this disclosure.

[0055] As the tape travels over the module, it is preferable for the tape to pass close enough to the magnetic transducers on the module so that reading and / or writing can be performed efficiently, e.g., with a low error rate. According to some approaches, tape tenting may be used to ensure that the tape passes close enough to the portion of the module that contains the magnetic transducer. To better understand this process, FIGS. 8A-8C illustrate the principle of tape tenting. FIG. 8A shows a module 800 including an upper tape support surface 802 that extends between opposing edges 804, 806. A stationary tape 808 is shown wrapped around the edges 804, 806. As shown in the figure, the bending stiffness of the tape 808 lifts the tape from the tape support surface 802. As shown in FIG. 8A, tension in the tape tends to flatten the tape's shape. When tape tension is minimal, the tape's curvature is greater than the parabolic curve shown in the figure.

[0056] FIG. 8B shows tape 808 in motion. The leading edge (i.e., the first edge the tape encounters as it moves) can act to strip air from the tape, thereby creating a subambient air pressure between tape 808 and tape support surface 802. In FIG. 8B, if the tape is moving from left to right, the leading edge is the left edge and the right edge is the trailing edge. As a result, atmospheric pressure above the tape forces the tape toward tape support surface 802, thereby creating tape tenting near each of the edges. The bending stiffness of the tape resists the effects of atmospheric pressure, thereby causing tape tenting near both the leading and trailing edges. Modeling predicts that the shapes of the two tents are very similar.

[0057] FIG. 8C shows how air pressure below ambient pressure forces tape 808 toward tape bearing surface 802 even when a subsequent guide 810 is positioned above the plane of the tape bearing surface.

[0058] Thus, tape tenting may be used to direct the path of the tape as it passes over the modules, preferably to ensure that the tape passes close enough to the portions of the modules containing the magnetic transducers so that reading and / or writing can be performed efficiently, e.g., with a low error rate.

[0059] Magnetic tapes may be stored in tape cartridges, which are then stored in storage slots or the like within a data storage library. Tape cartridges may be stored in the library so that they are physically accessible for retrieval. In addition to magnetic tapes and tape cartridges, data storage libraries may include data storage drives that store data on magnetic tapes, retrieve data from magnetic tapes, or both. Additionally, data libraries and their contained components may implement file systems that provide access to tapes and data stored on tapes.

[0060] A file system may be used to control how data is stored in and retrieved from memory. Thus, a file system may include the processes and data structures (e.g., how files are structured in memory) that an operating system uses to track files in memory. The Linear Tape File System (LTFS) is an exemplary form of file system that may be implemented in certain libraries to enable access to compatible tapes. It should be understood that the various techniques herein may be implemented using a wide range of file system formats, including, for example, IBM® Spectrum® Archive Library Edition (LTFS LE). (IBM and IBM-based trademarks and logos are trademarks or registered trademarks of International Business Machines Corporation and / or its affiliates.) However, to provide background and simply to assist the reader, some of the techniques below may be described with reference to LTFS, a type of file system format. This reference is made merely as an example and should not be considered a limitation on the invention defined in the claims.

[0061] A tape cartridge may be "loaded" by inserting the cartridge into a tape drive, and a tape cartridge may be "removed" by removing the tape cartridge from the tape drive. After being loaded into a tape drive, the tape in the cartridge may be "threaded" into the drive by physically pulling the tape (magnetic recording portion) from the tape cartridge and threading it over the magnetic head of the tape drive. Additionally, the tape may be attached to a take-up reel (e.g., see 121 in Figure 1A above) to move the tape over the magnetic head.

[0062] After a tape in a cartridge is threaded through a tape drive, it may be "mounted" by reading the metadata on the tape and placing the tape in a state where LTFS can use it as part of its file system. Furthermore, to "unmount" a tape, metadata is preferably first written to the tape (e.g., as an index), and then the tape may be removed from a state where LTFS can use it as part of its file system. Finally, to "unmount" a tape, the tape is removed from the take-up reel and physically placed back inside the tape cartridge. The cartridge may remain installed in the tape drive even after the tape is unloaded, for example, while awaiting another read or write request, or both. However, in other instances, the tape cartridge may be removed from the tape drive, for example, when the tape is unloaded as described above.

[0063] Magnetic tape is a sequential-access medium. Therefore, new data is written to the tape by appending it to the end of previously written data. Therefore, when data is recorded to a tape containing only one partition, metadata (e.g., allocation information) is sequentially appended to the end of the previously written data as the data is frequently updated and rewritten to the tape accordingly. As a result, when a tape is first mounted, the information at the end is read to access the most recent copy of the metadata corresponding to this tape. However, this read introduces a significant amount of delay into the process of mounting a particular tape.

[0064] To overcome this delay caused by single-partition tape media, the LTFS format includes a tape divided into two partitions: an index partition and a data partition. The index partition may be configured to store metadata, such as file allocation information (index), while the data partition may be configured to store the data itself.

[0065] 9, one approach illustrates a magnetic tape 900 including an index partition 902 and a data partition 904. As shown, data files and indexes are stored on the tape. As will be understood by those skilled in the art upon reading this description, the LTFS format allows index information to be recorded in the index partition 902 at the beginning of the tape 906.

[0066] When index information is updated, it is preferable to overwrite the previous version of the index information, thereby allowing the currently updated index information to be accessed in the index partition at the beginning of the tape. According to the specific example shown in FIG. 9, the latest version of the metadata, Index 3, is recorded in Index partition 902 at the beginning of the tape 906. Conversely, all three versions of the metadata, Index 1, Index 2, and Index 3, and the data, File A, File B, File C, and File D, are recorded in Data partition 904 of the tape. Although Index 1 and Index 2 are old (e.g., not updated) indexes, as previously described, because information is written to tape by appending information to the end of previously written data, these old indexes, Index 1 and Index 2, remain stored in Data partition 904 on the tape 906 without being overwritten.

[0067] The metadata contained in the index partition 902 and / or the data partition 904 may be updated in the same or different ways, depending on the desired approach. According to some approaches, for example, the metadata in the index partition and / or the data partition 902, 904 may be updated in response to a tape being unmounted so that the index can be quickly read from the index partition when the tape is remounted. Metadata is preferably also written to the data partition 904, so that a tape may be mounted with the metadata recorded in the data partition 904, for example, as a backup option.

[0068] According to one example, which is in no way intended to limit the invention, LTFS LE may be used to provide the ability to write an index to a data partition when explicitly instructed by the user to the system or at a time specified by a predefined period that may be set by the user, so as to mitigate data loss in the event of, for example, a sudden power outage.

[0069] Referring now to FIG. 10 , one approach to storage system 1000 is illustrated. Note that, according to various approaches, some of the elements illustrated in FIG. 10 may be implemented as hardware and / or software. Storage system 1000 may include a storage system manager 1012 for communicating with multiple media and / or drives on at least one upper storage tier 1002 and at least one lower storage tier 1006. Upper storage tier 1002 may preferably include one or more random-access and / or direct-access media 1004, such as hard disks in a hard disk drive (HDD), nonvolatile memory (NVM), semiconductor memory in a solid-state drive (SSD), flash memory, SSD arrays, flash memory arrays, or the like, or other media described herein or known in the art, or combinations thereof. The lower storage tier 1006 may preferably include one or more lower performance storage media 1008, including sequential access media such as magnetic tape and / or optical media in a tape drive, slow access HDDs, slow access SSDs, etc., or other sequential access media described herein or known in the art, or combinations thereof. The one or more additional storage tiers 1016 may include any combination of storage memory media according to the requirements of the designer of the system 1000. Also, either the upper storage tier 1002 and / or the lower storage tier 1006 may include any combination of storage devices and / or storage media.

[0070] The storage system manager 1012 may communicate with the drives and / or storage media 1004, 1008 on the upper storage tier 1002 and the lower storage tier 1006 via a network 1010, such as the storage area network (SAN) shown in FIG. 10 or other suitable network type. The storage system manager 1012 may communicate with one or more host systems (not shown) via a host interface 1014, which may or may not be part of the storage system manager 1012. The storage system manager 1012 and / or any other components of the storage system 1000 may be implemented in hardware and / or software and may utilize a processor (not shown), such as a central processing unit (CPU), field programmable gate array (FPGA), application specific integrated circuit (ASIC), or the like, to execute commands of a type known in the art. Of course, any arrangement of storage systems may be used, as would be apparent to one of ordinary skill in the art upon reading this description.

[0071] In other approaches, storage system 1000 may include any number of data storage tiers, each containing the same or different storage media. For example, each data storage tier may contain the same type of storage media, such as HDDs, SSDs, sequential access media (such as tapes in tape drives or optical disks in optical disk drives), direct access media (such as CD-ROMs or DVD-ROMs), or any combination of storage types. In one such configuration, upper storage tier 1002 may contain a majority of SSD storage media for storing data in a higher performance storage environment, while the remaining storage tiers, including lower storage tier 1006 and additional storage tier 1016, may contain any combination of SSDs, HDDs, tape drives, etc. for storing data in a lower performance storage environment. In this manner, more frequently accessed data, data with a higher priority, data that needs to be accessed more quickly, etc. may be stored in the upper storage tier 1002, while data that does not have one of these attributes may be stored in additional storage tiers 1016, including the lower storage tier 1006. Of course, those skilled in the art, upon reading this description, may devise many other combinations of storage media types to implement different storage schemes in accordance with the techniques presented herein.

[0072] According to some approaches, a storage system (e.g., 1000) may include logic configured to receive a request to open a data set, logic configured to determine whether the requested data set is stored in multiple related portions in a lower storage tier 1006 of the tiered data storage system 1000, logic configured to move each related portion of the requested data set to an upper storage tier 1002 of the tiered data storage system 1000, and logic configured to assemble the requested data set on the upper storage tier 1002 of the tiered data storage system 1000 from the related portions.

[0073] Of course, this logic may be implemented in a variety of ways, as a method on any device and / or system, or as a computer program product.

[0074] As mentioned above, in some data storage settings, data eventually shifts from an on-premises environment to a cloud-based environment. In some environments, this shift can involve migrating relatively large amounts of data. Some cloud vendors recognize and discuss the importance of efficiently migrating data during such a shift. In particular, while data transfer primarily occurs over a network, it has been argued that strengthening the network for temporary data movement can be impractical, leading to the introduction of offline data transfer methods via logistics. Some cloud vendors offer services through original developments of equipment used exclusively for data transfer. Meanwhile, other cloud vendors offer data transfer services using LTFS. Some approaches also standardize methods for transferring relatively large amounts of data from one system to another using LTFS. Some cloud vendors guarantee online accessibility of data delivered via logistics within 24 hours of receipt. It is important to note that such guarantees are made regardless of the size of the data volume being migrated. Ensuring such guarantees typically involves considering the amount of data received from logistics per unit of time, as well as the amount of data received that can be copied to an online system per unit of time. Consideration of these metrics may be taken into account to build, maintain, and manage a system by preventing the former metric from exceeding the latter metric. For example, actions to use LTFS for data transfer may include ensuring multiple tape drives so that a range of tape cartridges received in a day can be processed within a day. In such an example, a specification that the data will be copied within a relatively short period of time may be required in addition to the expected time to perform the data copy. This action may be particularly useful in environments where such requirements exist.

[0075] While LTFS simplifies tape handling compared to some traditional data storage technologies, some characteristics resulting from the use of tape within storage devices remain the same. When a file is read from a magnetic storage device, such as a hard disk drive (HDD) or magnetic tape, the device (e.g., the device's head) is aligned with the location where the file data is stored to read the data. This process is also known as seeking. A seek operation within an HDD involves only the movement of an arm containing the head over a disk with a diameter of a few centimeters; therefore, the seek may take only a few tens of milliseconds to perform. In contrast, a seek operation on magnetic tape involves reeling the magnetic tape, which may be over 1,000 meters long. Therefore, a seek operation on magnetic tape can take much longer to perform than a seek operation within an HDD. When a relatively large file is copied from an LTFS-based storage system to an HDD, these relatively long seek times can add a significant amount of time to the data copy process.

[0076] One conventional technique used to reduce data migration time involves reducing redundant seeks by rearranging the order of files to be copied prior to performing the migration. In particular, this rearrangement may be performed according to the location of the file data stored on tape. However, this conventional technique has a disadvantage because seeks cannot be avoided when files are fragmented. Furthermore, this conventional technique increases the time required for the migration process as a result of the rearrangement performed, and further requires relatively more CPU resources as the number of target files increases. Due to the difficulty of predicting volume seeks in advance, it is also difficult to predict the time required to copy data.

[0077] The various techniques described herein eliminate redundant seeks during the copying of data from an LTFS-based storage system to a RANVM drive because the data is copied block by block to the drive. By eliminating these redundant seeks, the time to perform the copy is reduced.

[0078] Referring now to Figure 11, there is shown, in one approach, a flowchart of a method 1100. Method 1100 may be performed in accordance with the present invention in a variety of ways, particularly in any of the environments shown in Figures 1-10 and 12-15. Of course, as one skilled in the art will understand upon reading this description, method 1100 may include more or fewer operations than those specifically illustrated in Figure 11.

[0079] Each of the steps of method 1100 may be performed by any suitable component of an operating environment. For example, in various approaches, method 1100 may be performed, in part or in whole, by a controller or other device including one or more processors. A processor (e.g., a processing circuit, chip, or module, or a combination thereof) implemented in hardware and / or software and preferably including at least one hardware component may be utilized within any device to perform one or more steps of method 1100. Exemplary processors include, but are not limited to, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or the like, combinations thereof, or any other suitable computing device known in the art.

[0080] It may be prefaced that method 1100 may be utilized to reduce the time required to migrate data from an LTFS-based storage system to a RANVM drive at the drive block level. Accordingly, as described below, method 1100 may include operations for both preparing and executing the data migration. Note that in a preferred approach, copying data from an LTFS-based storage system to a drive is not performed at the file level. This is because additional migration time would otherwise be incurred in the seek operations required to copy data at the file level. Accordingly, utilization of the various approaches described herein results in reduced data migration time.

[0081] As previously mentioned, LTFS is an exemplary format of a file system that may be implemented within a particular tape drive library to provide access to compatible tapes. By way of background, the LTFS-based storage systems of various approaches herein may be magnetic tape-based storage systems of known types, but may be modified in accordance with the teachings herein. In one preferred approach, the LTFS-based storage system includes a magnetic tape drive, possibly including multiple tape drives within a tape library. The system may include one or more magnetic recording tapes. Additionally, the RANVM drives may be storage drives of known types (e.g., HDDs, SSDs, etc.).

[0082] Method 1100 may initially include writing data in an LTFS file system to an LTFS-based storage system. For example, operation 1102 of method 1100 includes writing data to a block in the LTFS file system. In some approaches, writing data to an LTFS-based storage system may occur without receiving any request and / or instruction to copy the data from the LTFS-based storage system to a RANVM drive. In contrast, in some other approaches, data may be written to an LTFS-based storage system even though there are plans to migrate the data written to the LTFS-based storage system to a RANVM drive at some point.

[0083] In some approaches, data may be written to the LTFS as a file, and therefore, one or more write operations performed in method 1100 may include writing file data to blocks within the LTFS. It can be expected that data in the LTFS will eventually be copied to blocks of the RANVM drive on a block-by-block basis. Therefore, when file data is written to an LTFS-based storage system, the location of the file data in blocks within the LTFS may be managed by the LTFS-based storage system according to block numbers in the same manner as file data is managed by a RANVM drive. Note that writing file data to blocks within the LTFS on an LTFS-based storage system occurs before the data is copied to blocks on the drive. For example, a write operation to an LTFS-based storage system may include an initial write of data to the LTFS before a request to copy / migrate the data to a RANVM drive ever exists. In some approaches, file data written to blocks on an LTFS-based storage system may include file data for multiple files. In some other approaches, file data written to a block on an LTFS-based storage system may contain file data for a single file.

[0084] In some techniques, the location of a data file, e.g., on a magnetic recording tape in an LTFS-based storage system, is known based on metadata containing location information about the file data indexed on the LTFS-based storage system, even though the location of the file data is managed according to block numbers in the same way that file data is managed by the drive while writing data to blocks on the LTFS-based storage system. In other words, writing data files to blocks on an LTFS-based storage system according to block numbers in the same way that file data is managed by the drive preferably does not impair the performance of the LTFS-based storage system. As described in more detail below, managing the write location where file data is written to blocks on an LTFS-based storage system in such a manner allows all of the file data to be copied from the LTFS-based storage system to a RANVM drive without having to perform seeks on the magnetic recording tape in the LTFS-based storage system (except perhaps an initial seek to find the start of the data within a particular data band on the magnetic recording tape) or otherwise formatting writes on the drive to conform to the drive's blocks. As a result, file data may be copied from an LTFS-based storage system to a drive in significantly less time than would be consumed if copying the file data from the LTFS-based storage system to the drive included performing data seeks. For example, each avoided seek operation may reduce the duration of the copy process by up to about several tens of seconds.

[0085] In some approaches, while writing file data to blocks on an LTFS-based storage system, file data boundaries may be aligned to the size of the blocks on the drive (e.g., the scheduled size of the blocks on the drive). Note that this alignment may be ensured based on the management of where data is written to blocks on an LTFS-based storage system, as described immediately above. Depending on the approach, file data boundaries may be defined by one or more positions and / or characteristics of the file data. For example, in one preferred approach, file data boundaries include the beginning of at least a portion of the file data. In another approach, file data boundaries may include the end of at least a portion of the file data.

[0086] By way of background, the size of a block on a drive may depend on the approach. As previously mentioned, this size may preferably be incorporated into the management of where data is written to blocks on an LTFS-based storage system. In some preferred approaches, the size of a block on a drive may be related to the size of a block on an LTFS-based storage system. For example, during writing of data to an LTFS-based storage system, the size of each of the blocks on the LTFS-based storage system may be an integer multiple of the size of one of the blocks on the drive in some preferred approaches. The integer multiple may be set, for example, by an administrator of the LTFS-based storage system, an administrator of the drive, a manufacturer of one or more components of the LTFS-based storage system, a manufacturer of one or more components of the drive, a table, or a combination thereof. In other words, the size of one of the blocks on the LTFS-based storage system and the size of one of the blocks on the drive may establish a block size ratio. For example, in one approach, the block size ratio may be the quotient of the size of one of the blocks on the LTFS-based storage system and the size of one of the blocks on the drive. One preferred block size ratio may be 4, i.e., one block in an LTFS-based storage system corresponds to four blocks on the drive. Note that the block size ratio and integer multiple may be interchangeable. For example, in the example above, the integer multiple and block size ratio are both 4. In some other approaches, the integer value may be a different value, such as 1, 10, 100, a fraction, the nearest integer multiple if the block size ratio is not an integer, etc.

[0087] In some approaches, managing the location where file data is written to blocks on an LTFS-based storage system may additionally and / or alternatively include adjusting the block offset (e.g., byte offset) of the file data on the LTFS-based storage system. For example, in some approaches, the block offset of the file data on the LTFS-based storage system may be adjusted so that the remainder of the quotient of the block offset and the size of one of the drive's blocks is equal to the remainder of the quotient of the offset (e.g., file offset) of the file data on the LTFS-based storage system and the size of one of the drive's blocks. This adjustment of the block offset may be applied to address issues that would otherwise be presented in copying data from an LTFS-based storage system when the data is stored in at least one shared block (e.g., when a block on the LTFS-based storage system contains data of a first data file and data of a second data file). In particular, this adjustment may align data boundaries with the block size of the file system on the drive when file data is written to the LTFS-based storage system.

[0088] Operation 1104 of method 1100 includes copying data stored in the LTFS-based storage system to blocks of the RANVM drive. Preferably, the data may be copied in units of drive blocks. More specifically, data may not be copied in units of data files from the LTFS-based storage system to the drive because doing so may increase the total time required to copy the data. This is because copying data in units of data files from the LTFS-based storage system to the drive involves data seek operations that ultimately increase the time required to perform the data copy. In some approaches, the magnetic recording tape of the LTFS-based storage system is not mounted (e.g., unavailable to applications) during the copy. While the file system on the RANVM drive may be mounted (e.g., available to applications) during the copy, it is preferable that a sufficient amount of free space exists on the drive to copy all of the data recorded on the LTFS-based storage system. Therefore, in one optional approach, method 1100 may include determining the size of the file to be copied before performing the copy. Such a determination may, in some approaches, be made based on, for example, the length of a magnetic recording tape in an LTFS-based storage system, where the entire length of the tape may be assumed to contain data based on the length of the portion of the tape to which the data is being copied, where the entire length of that portion of the tape may be assumed to contain data based on the size of the LTFS-based storage system's tape index, known techniques, etc. The determined size of the file to be copied may be compared to the determined size of free space on the drive. In response to a determination that the determined size of the file to be copied is greater than the determined size of free space on the drive, copying the data from the LTFS-based storage system to the drive may be delayed, performed in parts, performed on two or more media in two or more RANVM drives, etc.By ensuring that the size of the file being copied is less than or equal to a determined amount of free space on the drive, known types of errors associated with running beyond the available free space on the drive are avoided.

[0089] In some approaches, the data copied to the drive's blocks may include all of the data on the LTFS-based storage system. For example, in some approaches, the data copied to the drive's blocks may include all of the data stored between a first end of the magnetic recording tape on the LTFS-based storage system and a second end of the magnetic recording tape on the LTFS-based storage system. In other approaches, the data copied to the drive's blocks may include only a portion of the data on the LTFS-based storage system. For example, in some approaches, the data copied to the drive's blocks may include, for example, data stored in multiple predetermined portions of the LTFS-based storage system located between the first end of the magnetic recording tape and the second end of the magnetic recording tape, data on predetermined blocks of the magnetic recording tape, data stored in one or more data tracks of a predetermined data band of the magnetic recording tape, a predetermined subportion of the magnetic recording tape used to perform a known type of rollback to a previous state of the magnetic recording tape, etc.

[0090] While various techniques herein describe copying data from an LTFS-based storage system to blocks on a RANVM drive, whether "data" includes valid data, invalid data, or both may depend on the technique. LTFS is a write-once file system in which, when overwriting a file, recorded blocks on the magnetic recording tape of an LTFS-based storage system are not rewritten, but the overwritten data is appended to the file. Therefore, in LTFS, invalid areas may be created in blocks on an LTFS-based storage system, and block data may be split at arbitrary boundaries (e.g., arbitrary offsets) due to file overwrites. Meanwhile, typical file systems on RANVM drives, such as typical file systems on HDDs, may not include a mechanism for handling copied blocks marked as invalid. Therefore, the RANVM drive may not be able to properly process data containing such blocks as a file. However, various techniques described herein are configured to address the issue of handling overwritten files. This is because various techniques described herein involve performing boundary adjustment during writing of a data file to a block on an LTFS-based storage system, e.g., during writing of file data to a block on an LTFS-based storage system, one boundary of the file data may be aligned to the size of a block on the drive, during writing of file data to a block on an LTFS-based storage system, multiple boundaries of the file data may be aligned to the size of a block on the drive, etc. Accordingly, in some techniques, the LTFS-based storage system may include at least some invalid data, and therefore, data copied from the LTFS-based storage system to a block on a RANVM drive may include at least some invalidated data (e.g., invalid data resulting from an overwrite operation performed on the LTFS-based storage system).However, in some other approaches, the data copy operation may include copying only valid data from the LTFS-based storage system to blocks of the RANVM drive based on the invalid data being located in portions of the magnetic recording tape not addressed by the data copy operation. For example, in an approach where only data stored in at least one data track of a given data band of the magnetic recording tape is copied from the LTFS-based storage system to blocks of the RANVM drive, and the given data track does not contain any invalid data, no invalid data is copied during the data copy operation. In some further approaches, the LTFS-based storage system may contain only valid data, e.g., data that has not been deleted or overwritten, and therefore the data copy operation may include copying only valid data from the LTFS-based storage system to blocks of the RANVM drive.

[0091] As briefly mentioned above, some techniques do not perform data seek operations on an LTFS-based storage system while copying data to blocks on a drive. More specifically, some techniques do not require seek operations to be performed during copying, for example, to determine the start location of an instance of data to be copied on the tape of an LTFS-based storage system, to determine the end location of an instance of data to be copied, or to determine the location of divided data and / or fragmented data files. By not performing these seek operations, which would otherwise be performed when data on an LTFS-based storage system's tape is copied to a RANVM drive in units of data files, the time required for the process of copying data from an LTFS-based storage system to blocks on a RANVM drive is reduced. It should be noted that copying data from an LTFS-based storage system to blocks on a RANVM drive in units of drive blocks rather than units of data files has not been considered in conventional data migration techniques. As mentioned above, recall that such conventional migration techniques utilize rearranging the order of files to be copied prior to data migration in an attempt to reduce seek time during data migration. However, this process cannot avoid seeks if the files are fragmented, increases migration time as a result of the reordering that is performed, and further consumes relatively greater amounts of CPU resources as the number of target files increases. In sharp contrast, various techniques herein that anticipate such migration from an LTFS-based storage system to blocks on a RANVM drive allow data to be written to blocks on an LTFS-based storage system in a manner that alleviates at least some of the seek operations that would otherwise be performed in conventional migration techniques.Thus, the inventive findings disclosed herein regarding copying data from an LTFS-based storage system to a RANVM drive block by block, rather than by file, of data, go against conventional wisdom.

[0092] Operation 1106 of method 1100 includes creating a correspondence table during the copying of data from the LTFS-based storage system to blocks on the RANVM drive. The correspondence table preferably maps data locations within the LTFS-based storage system to data locations on the drive and may be shared with the LTFS-based storage system and / or the drive, e.g., shared with a controller of the LTFS-based storage system, shared with a controller of the drive, shared with a processor of the LTFS-based storage system, shared with a processor of the drive, etc. In some approaches, creating the correspondence table may include collecting information related to managing where file data is written to blocks on the LTFS-based storage system. For example, this information may include, e.g., block offset information, block offset adjustment information, file data, file data boundary information, block size information, data validity information, LTFS formatting information, etc., which may be added to the correspondence table. In some approaches, this information may additionally and / or alternatively include one or more known types of data location information.

[0093] At some point after copying data on the LTFS-based storage system to blocks on the RANVM drive, invalid data may be removed from the blocks on the drive, e.g., overwritten, erased, marked as reclaimable storage write locations, etc. In some approaches, data correspondence information may be used to schedule and / or perform deletions on the storage media of the LTFS-based storage system and / or the drive's storage media. Removal of invalid data from the blocks on the drive increases the drive's available storage space.

[0094] At operation 1108 of method 1100, file metadata (e.g., file block allocation) is constructed on the drive so that the copied data on the drive is accessible as one or more files (e.g., so that the copied data on the drive is accessible as one or more files on the drive). In some approaches, the file metadata may be a directory entry that points to one or more starting blocks in the FAT (e.g., see FIG. 13E for an example of constructing metadata). Metadata other than the block allocation (e.g., file name) may be copied from the LTFS index in one approach. In another approach, the block allocation may be constructed from a correspondence table that includes data locations on the blocks of the LTFS-based storage system and on the drive (e.g., see correspondence table 1230 in FIG. 12). It should be noted that in conventional approaches, data copied from an LTFS-based storage system to a drive cannot be accessed as one or more files on the drive without performing various seek operations while copying the data. This is because conventional approaches do not consider copying data from an LTFS-based storage system to a RANVM drive at the granularity of the drive's blocks. In sharp contrast, conventional techniques initiate timely seek operations to copy data from an LTFS-based storage system to a drive on a file-by-file basis. Therefore, as a result of the various techniques described herein that avoid seek operations while copying data from an LTFS-based storage system to a RANVM drive on a drive block-by-block basis, the time to copy data from an LTFS-based storage system to a RANVM drive is relatively more efficient than conventional data copy techniques.

[0095] Figures 12-14F illustrate data being copied from an LTFS-based storage system to a RANVM drive in units of drive blocks rather than files, for example, without using a file system application programming interface (API). Furthermore, file metadata (e.g., file block allocation) may be constructed on the drive so that the copied blocks can be treated as files on the drive. In some approaches, data is copied block by block, from end of tape to end, thereby eliminating the need for seeks during data copying. LTFS also manages the location of file data recording according to block numbers, in the same manner as a typical file system on the drive. This copying of data is possible based on mapping block numbers on the LTFS-based storage system to block numbers in the file system on the destination drive. In some approaches, data is copied from an LTFS-based storage system to a RANVM drive while a correspondence table is created to map data locations within the LTFS to data locations on the drive. Furthermore, this copying of data may be made possible by aligning data boundaries to the file system block size on the drive when writing file data to blocks within the LTFS of an LTFS-based storage system.

[0096] As a prerequisite for the various techniques described herein, the block size of each block in the LTFS (hereinafter referred to as "LBS" (LTFS Block Size)) may be an integer multiple of the block size of the file system on the destination drive (hereinafter referred to as TBS (Target Block Size)). In some techniques, an integer multiple of the block size of the file system on the destination drive, which may be a value obtained by dividing LBS by TBS, may be hereinafter referred to as "BSR" (Block Size Ratio). It should be noted that in some preferred techniques, the source LTFS is not mounted (e.g., unavailable to applications) during the copy. The file system on the destination drive may be mounted (e.g., available to applications) during the copy, but preferably has enough free space to copy all of the data recorded on the source tape.

[0097] 12 illustrates states 1200 for copying data from an LTFS-based storage system to blocks on a RANVM drive according to one approach. Optionally, states 1200 may be implemented with features from any other approach shown herein, such as features described with reference to other figures. However, it should be understood that such states 1200 and other states presented herein may be used in various applications and / or permutations that may or may not be specifically described in the exemplary approach shown herein. Furthermore, states 1200 presented herein may be used in any desired environment.

[0098] 12 includes a representation of multiple blocks on the LTFS-based storage system (e.g., see LTFS block numbers 10 through 15) and a representation of multiple target blocks on the RANVM drive (e.g., see target block numbers 1200 through 1207, target block numbers 1212 through 1220, and target block numbers 1222 through 1228). A correspondence table 1230 is also included in FIG. 12 for contextual reference, further illustrating the copying of data from the LTFS-based storage system to the RANVM drive.

[0099] Data on an LTFS-based storage system is copied to a RANVM drive in units of drive blocks (e.g., target blocks) rather than in units of files. In some approaches, data on an LTFS-based storage system is read into memory in units of multiples of LBS. Furthermore, data read into memory may be written to free blocks on the drive in units of multiples of TBS.

[0100] Note that free blocks on the drive that will be utilized during the copy may be made unavailable to applications, for example, by using one or more known techniques to create a special file that is inaccessible to applications and allocate the needed free blocks to this special file before copying the data. However, in some approaches, these blocks may be realized by the application despite the application being prevented from using them.

[0101] Continuing with reference to FIG. 12, it may be assumed that the BSR is 4, and therefore, data from one block on an LTFS-based storage system can be copied to four free blocks on a drive. According to a more specific example, two LTFS blocks, 10 and 11, on an LTFS-based storage system are shown being copied block by block on a drive based on a BSR of 4. For example, copy operation 1 includes copying data from LTFS blocks 10 through 11 to eight blocks 1200 through 1207 on a drive. According to another example, copy operation 2 includes copying data from LTFS blocks 12 through 13 and a portion of data from LTFS block 14 to nine blocks (e.g., blocks 1212 through 1220) on a drive. According to yet another example, copy operation 3 includes copying a portion of data from LTFS block 14 and data from LTFS block 15 to seven blocks (e.g., blocks 1222 through 1228) on a drive.

[0102] In some approaches, the data locations on the blocks of an LTFS-based storage system and the data locations on the drives are recorded in a correspondence table 1230. The correspondence table 1230 may be used to understand which location on the drives should be used to copy data located at any location on the blocks of an LTFS-based storage system.

[0103] To implement this correspondence table 1230, there may be issues with shared blocks, an inherent characteristic of LTFS. LTFS uses larger block sizes than typical file systems to efficiently read data from and / or write data to tape. For example, while the recommended LBS value is 512 kilobytes (KB) in one approach, for various approaches described herein, the LBS may be assumed to be 256 KB for clarity in the examples shown in the various figures. However, depending on the approach, the LBS may be configured to any value (e.g., 128 KB, 64 KB, 1024 KB, etc.). Due to the relatively efficient use of tape capacity at larger block sizes, storage systems based on LTFS may store data from multiple files in a single block, in contrast to typical file systems on the drive. This practice is sometimes referred to as shared blocks. Techniques for copying data stored on an LTFS-based storage system to a RANVM drive in units of blocks of the drive, where at least a portion of the data on the LTFS-based storage system is stored in shared blocks, are further described elsewhere herein (e.g., see Figures 13A-13B).

[0104] Figures 13A-13B illustrate states 1300, 1330 that involve a shared LTFS block problem during copying data stored in an LTFS-based storage system to blocks on a RANVM drive, according to one approach. Figures 13C-13E illustrate states 1340, 1350, and 1360 that mitigate the problem of Figures 13A-13B during copying data stored in an LTFS-based storage system to blocks on a RANVM drive, according to one approach. Optionally, states 1300, 1330, 1340, 1350, and 1360 may be implemented with features from any other approach shown herein, such as features described with reference to other figures. However, it should be understood that such states 1300, 1330, 1340, 1350, and 1360, as well as other states presented herein, may be used in various applications and / or permutations that may or may not be specifically described in the exemplary approach shown herein. Furthermore, the states 1300, 1330, 1340, 1350, 1360 presented herein may be used in any desired environment.

[0105] Referring first to Figure 13A, state 1300 includes a representation of multiple blocks on an LTFS-based storage system (e.g., see LTFS block numbers 10 through 11). State 1330 in Figure 13B shows data being transferred from a block on the LTFS-based storage system to multiple target blocks on a RANVM drive, in units of target blocks on the drive (e.g., see target block numbers 1300 through 1307).

[0106] Referring again to FIG. 13A, state 1330 illustrates an example of a shared LTFS block on an LTFS-based storage system. For example, note that LTFS block number 11 contains two portions of a first file (e.g., file 1) and the entire second file (e.g., file 2). In LTFS, file data locations are managed as a list of ranges. Note that the LTFS block in state 1300 is reconstructed in state 1330. In some approaches, the list of ranges may be stored in a correspondence table (e.g., correspondence table 1320). A range may represent a single piece of contiguous data. In some approaches, a range may include a starting block number (e.g., see starting block), a block starting offset (e.g., see byte offset), a length of the contiguous data (e.g., see number of bytes), and the location of the range in the file (e.g., see file offset).

[0107] As described above, in Figures 13A and 13B, LTFS block number 11 is shared by file 1 and file 2. In this technique, the stored data of file 1 includes 36 KB from the beginning of LTFS block number 11 and 26 KB from offset (36 + 106) KB of LTFS block number 11. Furthermore, the stored data of file 2 includes 106 KB from offset 36 KB of LTFS block number 11. Therefore, a shared block may store data of multiple files along any boundary, for example, using any offset and any length. On the other hand, a typical file system on a RANVM drive containing a target block does not include a mechanism for handling shared blocks. Therefore, in a technique in which one block is shared by multiple files, or in a technique in which file data is stored from the center of the block forward, or both, it is not feasible for a drive based on a RANVM drive that does not include a mechanism for handling shared blocks to properly handle files. This problem is illustrated in Figure 13B, where data from shared LTFS block 11 on an LTFS-based storage system is being copied to target blocks 1304 through 1306 on a RANVM drive. Specifically, the data for file 1 and file 2 stored in LTFS block 11, which is being copied to target blocks 1304 through 1306 on the RANVM drive in drive block units, does not incorporate boundary alignment, so target blocks such as 1304 and 1306 contain data that cannot be handled by the drive's file system. Note that in state 1330, the BSR is 4 and the TBS is 64KB.

[0108] To mitigate the problem of copying data in shared blocks, such as those shown in Figures 13A-13B, and referring now to Figures 13C-13D, during writing of file data on an LTFS-based storage system, data boundaries may be aligned to the block size of the file system on the RANVM drive. More specifically, the block offset (e.g., byte offset) may be adjusted so that the remainder obtained by dividing the block offset (e.g., byte offset) by the TBS is equal to the remainder obtained by dividing the file offset (e.g., file offset) by the TBS. An equation that may be used for this adjustment is shown below: (byte offset)%TBS=(file offset)%TBS Equation (1) Here, "%" represents the modulus operator.

[0109] As a result of this adjustment applied to the example shown in Figure 13A, a boundary may be established within the shared block, as shown in Figure 13C, and data from the shared block may be copied to a target block on the RANVM drive, as shown in Figure 13D, where data is stored starting at the center of target block number 1307 and copied to target block number 1304 so that the data can be handled by the file system on the RANVM drive.

[0110] This adjustment may be incomplete because it creates redundant areas on the magnetic tape of an LTFS-based storage system where no file data is recorded, thereby reducing the data capacity of the LTFS-based storage system. In the example of Figure 13C, the areas shown in the empty portions of LTFS block number 11 from offset 36K to offset 64K and from offset (64+106)K to offset (64*3+36)K are redundant areas. However, these redundant areas also exist in the file system on the RANVM drive and do not pose any significant problems in the use of LTFS, assuming that data is copied to the RANVM drive. As a result of filling all redundant areas on the magnetic tape with zeros, the compression function of the drive of the LTFS-based storage system can function effectively, thereby minimizing the reduction in data capacity on the LTFS-based storage system.

[0111] In some approaches, each block stored in the LTFS-based storage system may be copied to a RANVM drive, and then the data locations of all files on the LTFS-based storage system may be mapped to data locations on the drive according to a correspondence table to build file metadata on the drive, thereby completing the copying of all files on the LTFS-based storage system to the drive.

[0112] Referring now to FIG. 13E, state 1360 illustrates an approach in which the destination file system (e.g., the destination file system for data being copied from an LTFS-based storage system to a drive in units of blocks on the drive) is FAT.

[0113] 14A-14F illustrate states 1400, 1410, 1420, 1430, 1440, and 1450 for copying data stored in an LTFS-based storage system to blocks of a RANVM drive in accordance with one approach. Optionally, states 1400, 1410, 1420, 1430, 1440, and 1450 may be implemented with features from any other approach shown herein, such as features described with reference to other figures. However, it should be understood that such states 1400, 1410, 1420, 1430, 1440, and 1450, as well as other states presented herein, may be used in various applications and / or permutations that may or may not be specifically described in the exemplary approach shown herein. Furthermore, the states 1400, 1410, 1420, 1430, 1440, 1450 presented herein may be used in any desired environment.

[0114] In a manner similar to the way shared blocks are processed during drive-by-drive copying from an LTFS-based storage system to a RANVM drive (see, for example, Figures 13A-13E), one or more specific measures may be implemented during the process of copying data from an LTFS-based storage system to a RANVM drive if the data contains an overwritten file. LTFS is a write-once file system in which, when overwriting a file, recorded blocks on magnetic tape are not rewritten, but the overwritten data is appended to the file. Figures 14A-14B illustrate states 1400 and 1410 in which a file is overwritten on an LTFS-based storage system. In particular, Figure 14A illustrates the state 1400 of a file on an LTFS-based storage system before the file is overwritten. Furthermore, Figure 14B illustrates the state 1410 of a file on an LTFS-based storage system after the file is overwritten. For example, if 106 KB is overwritten after 36 KB in a file recorded within the range shown in FIG. 14A, the range is split as shown in FIG. 14B, leaving the source data in LTFS block number 10, and new data is added. Note that this range progression can also be shown in the correspondence table (see, for example, correspondence tables 1402 and 1412). Therefore, in an LTFS-based storage system, file overwrites can split block data at arbitrary boundaries (e.g., arbitrary offsets) and create invalid areas within blocks (see, for example, the invalid area in state 1410). On the other hand, a typical file system on a RANVM drive may not have the technology to handle invalid areas within blocks, and therefore the drive may not be able to properly process the data containing such blocks as a file. FIG. 14C shows an example of copying overwritten file blocks to a drive without boundary alignment.For example, as shown in Figure 14C, after the blocks containing such invalid regions are copied to the drive, blocks on the drive, such as target block number 1400 and target block number 1402, may contain data that may be created on the drive that cannot be handled by the file system. Note that in Figure 14C, the BSR is 4 and the TBS is 64 KB.

[0115] In some approaches, to address the issue of handling overwritten files, boundary alignment may be additionally and / or alternatively performed, e.g., to allow the drive to handle any areas within a block that are invalid. For example, if boundary alignment adjustment is applied to the example shown in FIG. 14B, the data boundaries within the shared block would be as shown in FIG. 14D, and the shared block would be copied to the drive as shown in FIG. 14E. FIG. 14D includes boundary alignment of data overwriting a file. FIG. 14E illustrates an example of copying an overwritten file block to the drive, e.g., with boundary alignment. Note that the boundaries in FIG. 14D may be represented in a correspondence table (e.g., see correspondence table 1432). In FIG. 14E, invalid areas exist at target block numbers 1400 and 1402 on the drive, but valid data is copied from number 1404 to number 1400 and from number 1402 to number 1406 into the invalid areas, allowing the data to be handled within the file system.

[0116] Figure 14F shows an example where the destination file system is a FAT. Specifically, state 1450 shows the FAT as the destination for data at target block numbers 1400 to 1407 on the drive.

[0117] FIG. 15 illustrates a pseudocode sample 1500 for structuring file block allocations on a destination file system according to one approach. Optionally, this pseudocode sample 1500 may be implemented with features from any other approach described herein, such as features described with reference to other figures. However, it should be understood that such pseudocode sample 1500 and other samples presented herein may be used in various applications and / or permutations that may or may not be specifically described in the exemplary approach described herein. Furthermore, the pseudocode sample 1500 presented herein may be used in any desired environment.

[0118] In one approach, pseudocode sample 1500 is an algorithm for copying data on an LTFS-based storage system to a destination RANVM drive in drive block units and then building file metadata (e.g., file block allocation) on the destination file system. In particular, LB_TO_TB may function as a function that returns the block number on the destination drive that corresponds to a specified block number and its location from the beginning of the block on the LTFS-based storage system. TB_COPY may function as a function for copying a specified region of a specified block to specify another block on the destination drive. TB_ALLOC may function as a function for allocating a specified list of blocks to a specified file in the destination file system.

[0119] Although the LTFS standard may allow any file region to be written according to any size (e.g., in FIG. 14B, the bytes in range 2 are rewritten to 106 ±α and the file offset in range 3 is rewritten to 36 + 106 ±α), the various techniques described herein do not handle such overwrites. More specifically, FIG. 14B shows 106K of old data at a file offset of 36K being overwritten by 106K of new data. The Portable Operating System Interface (POSIX) allows 106K of old data to be overwritten only by 106K of new data. However, the LTFS standard allows 106K of old data to be overwritten by new data of any size. For example, 106K of old data could be overwritten by 110K of new data. Note that in this example, α = +4K. Even though the LTFS standard allows overwrites, common file system APIs, such as the Portable Operating System Interface (POSIX), may not allow overwrites. Therefore, some techniques described herein may function without dealing with such overwrites.

[0120] A tape containing data written by applying techniques described elsewhere herein may not deviate from the LTFS standard, and thus data within this tape may be read and written by an LTFS to which various techniques described herein may not be applied. However, a tape containing data written by an LTFS to which such techniques are not applied may not have data boundary alignment, and therefore, it may not be possible to copy the data to a drive according to some of the techniques described herein. Therefore, a technique may be required to easily distinguish whether data within a tape was written exclusively by LTFS. The technique utilized to achieve such a distinction may vary depending on the techniques described herein, but may be achieved, for example, by updating the extended attribute value of a particular hidden file with an LTFS index generation number. When data is written on an LTFS-based storage system, the LTFS index may be updated. In some techniques, the index generation number included in the index may be updated. When an LTFS-based storage system to which various techniques described are applied writes an index to a tape, the extended attribute value of a particular hidden file may be updated with the index generation number. However, if, when the index is read from the tape, it is determined that the extended attribute value of a particular hidden file differs from the index generation number, then subsequent extended attribute values ​​of the particular hidden file may not be changed. This technique may be used to determine whether various techniques described herein are applicable for copying data from the tape to a drive where the data is copied in units of blocks of the drive. In response to determining that such techniques are applicable, a copy may be made using various techniques described herein.However, in some other approaches, in response to determining that such techniques are not applicable, copies may be made using other known techniques, but using those known techniques incurs seek time.

[0121] The present invention may be a system, a method, or a computer program product, or a combination thereof, at any possible level of technical detail of integration. The computer program product may include a computer-readable storage medium containing computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0122] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device, such as, 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 thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes portable floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves on which instructions are recorded, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as being ephemeral 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 over wires.

[0123] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device over a network (e.g., the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof) that 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 for storage on a computer-readable storage medium within each computing / processing device.

[0124] Computer-readable program instructions for carrying out the operations of the present invention may be source or object code written in any combination of one or more programming languages, including assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk®, C++, and 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 on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, to carry out aspects of the present invention, electronic circuitry including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions to customize the electronic circuitry by utilizing state information of the computer-readable program instructions.

[0125] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. 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.

[0126] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus to create a machine, where the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may be stored on a computer-readable storage medium and capable of directing 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 comprises an article of manufacture containing instructions for performing aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0127] Computer-readable program instructions may be loaded into a computer, other programmable data processing apparatus, or other device such that the instructions, which execute on the computer, other programmable apparatus, or other device, perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams, thereby causing a series of operable steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process.

[0128] 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 invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, comprising one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may actually be executed concurrently as a single step, or may be executed substantially concurrently in a partially or fully overlapping manner in time, or may even be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart diagrams, and combinations of blocks included in the block diagrams and / or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs the specified function or operation or executes a combination of special-purpose hardware and computer instructions.

[0129] Furthermore, systems according to various embodiments may include a processor and logic integrated into and / or executable by the processor, the logic configured to perform one or more of the processing steps enumerated herein. The processor may be any configuration as described herein, such as a discrete processor or processing circuit, including many components, such as processing hardware, memory, and I / O interfaces. By integrated, we mean that the logic is embedded in the processor as hardware logic, such as an application-specific integrated circuit (ASIC), FPGA, etc. By executable by the processor, we mean that the logic is hardware logic accessible by the processor, software logic (such as firmware, part of an operating system, part of an application program, etc.), or some combination of hardware and software logic, configured to cause the processor to perform some function when executed by the processor. The software logic may be stored in any memory type known in the art, local and / or remote memory. Any processor known in the art may be used, such as a software processor module or a hardware processor, or both, such as an ASIC, an FPGA, a central processing unit (CPU), an integrated circuit (IC), a graphics processing unit (GPU), etc.

[0130] It will be apparent from the description provided above that multiple combinations may be made and the various features of the systems and / or methods described above may be combined in any manner.

[0131] It will further be appreciated that embodiments of the present invention may be provided in the form of a service that is deployed for customers to provide the service on demand.

[0132] The description of various embodiments of the present invention is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many changes and modifications will be 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, practical applications, or technical improvements of the embodiments beyond those found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. copying data stored in a storage system based on a Linear Tape File System (LTFS) to blocks of a Random Access Non-Volatile Memory (RANVM) drive, wherein the data is copied in units of the blocks of the drive; constructing file metadata so that the copied data on the drive is accessible as one or more files; 11. A computer-implemented method comprising:

2. 2. The computer-implemented method of claim 1, wherein the data is stored in blocks on the storage system based on the LTFS, and the size of each of the blocks in the LTFS is an integer multiple of the size of one of the blocks on the drive.

3. 3. The computer-implemented method of claim 1, wherein the data copied to the block of the drive includes all data stored between a first end of a magnetic recording tape and a second end of the magnetic recording tape of the LTFS-based storage system, and wherein no data seek operations are performed on the magnetic recording tape during the copying of the data on the magnetic recording tape to the block of the drive.

4. 4. The computer-implemented method of claim 1, further comprising creating a correspondence table during the copying of the data, the correspondence table mapping data locations within LTFS to data locations on the drive.

5. 2. The computer-implemented method of claim 1, wherein the data comprises file data, and the method further comprises writing the file data to blocks on the LTFS-based storage system before copying the data to the blocks on the drive, and wherein the locations at which the file data is written to the blocks on the LTFS-based storage system are managed by the LTFS-based storage system according to block numbers in the same manner as file data is managed by the drive.

6. 6. The computer-implemented method of claim 5, wherein during the writing of the file data to blocks in an LTFS, boundaries of the file data are aligned to the size of the blocks on the drive.

7. 7. The computer-implemented method of claim 6, wherein a block offset of the file data on the LTFS-based storage system is adjusted so that a remainder of a quotient of the block offset and the size of one of the blocks on the drive is equal to a remainder of a quotient of the offset of the file data on the LTFS-based storage system and the size of one of the blocks on the drive.

8. 2. The computer-implemented method of claim 1, wherein the data includes file data for multiple files, and the method includes writing the file data to blocks on the LTFS-based storage system before copying the data to the blocks on the drive, and wherein during the writing of the file data to blocks on the LTFS-based storage system, boundaries of the file data are aligned to the size of the blocks on the drive.

9. 2. The computer-implemented method of claim 1, wherein the data includes at least some invalidated data resulting from an overwrite operation performed on the LTFS-based storage system.

10. A computer-readable storage medium having program instructions embodied thereon, the program instructions being readable and / or executable by a controller, the controller comprising: copying, by the controller, data stored in a storage system based on a Linear Tape File System (LTFS) to blocks of a Random Access Non-Volatile Memory (RANVM) drive, wherein the data is copied in units of the blocks of the drive; constructing file metadata so that the copied data on the drive is accessible by the controller as one or more files; A computer-readable storage medium that causes the computer to execute the method.

11. 11. The computer-readable storage medium of claim 10, wherein the data is stored in blocks on the storage system based on the LTFS, and the size of each of the blocks in the LTFS is an integer multiple of the size of one of the blocks on the drive.

12. 12. The computer-readable storage medium of claim 10, wherein the data copied to the block of the drive includes all data stored between a first end of a magnetic recording tape and a second end of the magnetic recording tape of the LTFS-based storage system, and wherein no data seek operations are performed on the magnetic recording tape during the copying of the data on the magnetic recording tape to the block of the drive.

13. 13. The computer-readable storage medium of claim 10, wherein the program instructions are readable and / or executable by the controller and cause the controller to create a correspondence table during the copying of the data by the controller, the correspondence table mapping data locations within a LTFS to data locations on the drive.

14. 11. The computer-readable storage medium of claim 10, wherein the data includes file data, the program instructions are readable and / or executable by the controller and cause the controller to write the file data to blocks on the LTFS-based storage system before copying the data to the blocks on the drive, and the locations where the file data is written to the blocks on the LTFS-based storage system are managed by the LTFS-based storage system according to block numbers in the same manner as file data is managed by the drive.

15. 15. The computer-readable storage medium of claim 14, wherein during the writing of the file data to blocks in an LTFS, boundaries of the file data are aligned to the size of the blocks on the drive.

16. 16. The computer-readable storage medium of claim 15, wherein a block offset of the file data on the LTFS-based storage system is adjusted so that a remainder of a quotient of the block offset and the size of one of the blocks on the drive is equal to a remainder of a quotient of the offset of the file data on the LTFS-based storage system and the size of one of the blocks on the drive.

17. 11. The computer-readable storage medium of claim 10, wherein the data includes file data for a plurality of files, the program instructions being readable and / or executable by the controller and causing the controller to write the file data to blocks on the LTFS-based storage system before copying the data to the blocks on the drive, and wherein during the writing of the file data to blocks on the LTFS-based storage system, boundaries of the file data are aligned to the size of the blocks on the drive.

18. 11. The computer-readable storage medium of claim 10, wherein the data includes at least some invalidated data resulting from an overwrite operation performed on the LTFS-based storage system.

19. a processor; logic integrated with, executable by, or integrated with and executable by said processor; and wherein the logic comprises: copying data stored in a storage system based on a Linear Tape File System (LTFS) to blocks of a Random Access Non-Volatile Memory (RANVM) drive, wherein the data is copied in units of the blocks of the drive; constructing file metadata so that the copied data on the drive is accessible as one or more files; A system configured to run

20. 20. The system of claim 19, wherein the data is stored in blocks on the storage system based on the LTFS, and the size of each of the blocks in the LTFS is an integer multiple of the size of one of the blocks on the drive.

21. 21. The system of claim 19 or 20, wherein the data copied to the block of the drive includes all data stored between a first end of a magnetic recording tape and a second end of the magnetic recording tape of the LTFS-based storage system, and no data seek operations are performed on the magnetic recording tape during the copying of the data on the magnetic recording tape to the block of the drive.

22. 22. The system of claim 19, wherein the logic is configured to create a correspondence table during the copying of the data, the correspondence table mapping data locations within a LTFS to data locations on the drive.

23. 20. The system of claim 19, wherein the data includes file data, the logic is configured to write the file data to blocks on the LTFS-based storage system before copying the data to the blocks on the drive, and the location where the file data is written to the blocks on the LTFS-based storage system is managed by the LTFS-based storage system according to block number in the same way as file data is managed by the drive.

24. 24. The system of claim 23, wherein during the writing of the file data to blocks in an LTFS, boundaries of the file data are aligned to the size of the blocks on the drive.

25. 25. The system of claim 24, wherein a block offset of the file data on the LTFS-based storage system is adjusted so that a remainder of a quotient of the block offset and the size of one of the blocks on the drive is equal to a remainder of a quotient of the offset of the file data on the LTFS-based storage system and the size of one of the blocks on the drive.

Images