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

Abstract

A computer-implemented method includes copying data stored on a linear tape file system (LTFS)-based storage system to blocks of a random access non-volatile memory (RANVM) drive. The data is copied in units of blocks of the drive. The method also includes constructing file metadata such that the copied data on the drive is accessible as one or more files.

Description

Technical Field

[0001] This invention relates generally to data storage systems, and more specifically to copying data from a storage system based on a linear tape file system “LTFS” to a random access nonvolatile memory “RANVM” drive. Background Technology

[0002] In some data storage setups, data is ultimately transferred from an on-premises environment to a cloud-based environment. In some environments, this transfer may involve migrating relatively large amounts of data. Some cloud providers recognize and discuss the importance of efficiently migrating data during such transfers. Specifically, it has been discussed that line reinforcement for temporary data movements may be impractical, despite data transmission inherently occurring over a network, and offline data transmission measures via logistics have been introduced. Some cloud providers offer this service through the original development of appliances specifically designed for data transmission. Other cloud providers, on the other hand, use LTFS to provide data transmission services. Methods for transferring relatively large amounts of data from one system to another using LTFS have also been standardized in some schemes. Some cloud providers guarantee the online accessibility of data delivered by logistics within 24 hours of receipt. It is important to note that such guarantees are made regardless of the size of the data to be migrated. Protecting this guarantee typically involves considering the amount of data received from logistics per unit time and the amount of received data that can be replicated to the online system per unit time. These metrics can be considered in order to build, maintain, and manage systems by preventing the former from exceeding the latter. For example, operations used for data transfer using LTFS may include securing multiple tape drives so that a range of tape cartridges received in a day can be processed within that day. In such an example, it may be necessary to predict the timing of data replication and specify the replication schedule for relatively short time intervals. This operation can be particularly useful in environments where such requirements exist.

[0003] Compared to some conventional data storage technologies, LTFS simplifies tape handling; however, some characteristics attributable to the use of magnetic tape in storage devices remain the same. When reading a file from a magnetic storage device such as an HDD or magnetic tape, the device (e.g., the device head) is aligned to read the data at the location where the file data is stored. This process is also known as seek. Seek operations in an HDD involve only the movement of an arm with a head across a disk a few centimeters in diameter, and therefore seek operations may take at most only tens of milliseconds to execute. In contrast, seek operations on magnetic tape involve the winding of the tape, which can be over 1000 meters long. Consequently, seek operations on magnetic tape can take a relatively longer time than seek operations in HDDs. When copying relatively large files from an LTFS-based storage system to an HDD, these relatively long seek times can add a considerable amount of time to the data copying process. Summary of the Invention

[0004] One computer-implemented method, according to one aspect, involves copying data stored on a Linear Tape File System (LTFS)-based storage system to blocks of a Random Access Non-Volatile Memory (RANVM) drive. Data is copied in blocks on the drive. The method also includes constructing file metadata such that the copied data on the drive is accessible as one or more files. Copying data from the LTFS-based storage system to blocks of the RANVM drive is efficient because copying data from the LTFS-based storage system to the drive, which would otherwise be done file-by-file, would utilize ongoing data seek operations, ultimately increasing the time required to perform the data copy. These seek operations on the tape include tape winding, which can be over 1000 meters long. When copying relatively large files from the LTFS-based storage system to the drive, these relatively long seek times can add a considerable amount of time to the data copying process. However, in the current approach, during the copying of data from the magnetic recording tape to blocks on the drive, data seek operations on the magnetic recording tape can be avoided. These operations include determining the start position of instances of copied data, determining the end position of instances of copied data, determining the location of split and / or segmented data files on the tape of the LTFS-based storage system, etc. Therefore, by avoiding at least some of these seek operations, the file data can be copied from the LTFS-based storage system to the drive in significantly less time than if data seek operations were included. For example, each avoided seek operation can reduce the copying process time by up to approximately tens of seconds.

[0005] A mapping table can be created during data replication. This mapping table maps data locations in LTFS to data locations on the drive. Therefore, the mapping table can be used to understand which location on the drive is used to replicate data from any location on a block in an 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 can be read and / or executed by a controller to cause the controller to perform the methods described above.

[0007] According to another approach, a system includes a processor and logic integrated with the processor and executable by the processor, or logic integrated with and executable by the processor. This logic is configured to perform the methods described above.

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

[0009] Other aspects and solutions of the invention will become clear from the following detailed description, which, when taken in conjunction with the accompanying drawings, illustrates the principles of the invention by way of example. Attached Figure Description

[0010] Figure 1A This is a schematic diagram of a simplified magnetic tape drive system based on a scheme.

[0011] Figure 1B This is a schematic diagram of a tape cassette based on a design scheme.

[0012] Figure 2A A side view of a bidirectional dual-module tape head with a flat-lapped configuration according to one scheme is shown.

[0013] Figure 2B From Figure 2A Line 2B is a view of the surface of the magnetic tape carrier.

[0014] Figure 2C From Figure 2B A detailed view captured by circle 2C.

[0015] Figure 2D It is a detailed view of part of the tape-carrying surface of a pair of modules.

[0016] Figure 3 This is a partial magnetic tape carrier surface view with a write-read-write configuration for the magnetic head.

[0017] Figure 4This is a partial magnetic tape carrier surface view with a read-write-read configuration head.

[0018] Figure 5 It is a side view of a tape head with three modules according to a scheme, wherein the modules are typically placed along a roughly parallel plane.

[0019] Figure 6 It is a side view of a tape head with three modules in a tangential (angled) configuration.

[0020] Figure 7 This is a side view of a tape head with three modules in the outer packaging configuration.

[0021] Figures 8A-8C This is a schematic diagram illustrating the principle of tape tenting.

[0022] Figure 9 It is a representation of files and indexes stored on magnetic tape according to a scheme.

[0023] Figure 10 This is a diagram of a hierarchical data storage system based on a scheme.

[0024] Figure 11 It is a flowchart of a method based on a scheme.

[0025] Figure 12 It is a representation of the state of data being copied from an LTFS-based storage system to a RANVM drive according to a scheme.

[0026] Figure 13A Describe the state and mapping table of an LTFS-based storage system according to a given scheme.

[0027] Figure 13B Depicting data from Figure 13A The state of blocks copied from the LTFS-based storage system to the RANVM drive.

[0028] Figure 13C Depicting Figures 13A-13B The status of LTFS-based storage systems and Figure 13A The corresponding table.

[0029] Figure 13D Depicting data from Figures 13A-13C Replication of LTFS-based storage systems Figure 13B The state of the RANVM driver block.

[0030] Figure 13E Depicting data from Figures 13A-13DThe LTFS-based storage system is copied to the destination file system, which is the File Allocation Table (FAT).

[0031] Figure 14A Describe the state and mapping table of an LTFS-based storage system according to a given scheme.

[0032] Figure 14B Depicting Figure 14A The status and mapping table of the LTFS-based storage system.

[0033] Figure 14C Depicting data from Figure 14A The state of blocks copied from the LTFS-based storage system to the RANVM drive.

[0034] Figure 14D Depicting Figures 14A-14C The status of LTFS-based storage systems and Figures 14A-14B The corresponding table.

[0035] Figure 14E Describes the process of transferring data from Figures 14A-14D The state of blocks copied from the LTFS-based storage system to the RANVM drive.

[0036] Figure 14F Depicting data from Figures 14A-14D The LTFS-based storage system is copied to the destination file system, which is FAT.

[0037] Figure 15 It is a sample of pseudocode based on a scheme. Detailed Implementation

[0038] The following description is for illustrative purposes only and is not intended to limit the inventive concept claimed herein. Furthermore, the specific features described herein can be used in combination with other described features in each of a variety of possible combinations and substitutions.

[0039] Unless otherwise specified herein, all terms will be given their broadest possible interpretation, including the meaning implied from the specification and the meaning understood by those skilled in the art and / or the meaning defined as in dictionaries, papers, etc.

[0040] It should also be noted that, as used in the specification and appended claims, the singular forms “a,” “an,” and “the” include plural indicators, unless otherwise stated.

[0041] The following description discloses several preferred embodiments of a data storage system and its operation and / or components.

[0042] In a general approach, a computer-implemented method includes copying data stored on a linear tape file system (LTFS) based storage system to blocks of a random access non-volatile memory (RANVM) drive. Data is copied in blocks on the drive. The method also includes constructing file metadata such that the copied data on the drive is accessible as one or more files.

[0043] In another general embodiment, a computer program product includes a computer-readable storage medium having program instructions embodied therein. The program instructions can be read and / or executed by a controller to cause the controller to perform the methods described above.

[0044] In another general embodiment, a system includes a processor and logic integrated with the processor and executable by the processor, or integrated with and executable by the processor. This logic is configured to perform the methods described above.

[0045] Figure 1A A simplified tape drive 100 for a tape-based data storage system that can be used in the context of this invention is shown. Although in Figure 1A The document illustrates a particular implementation of a tape drive; however, it should be noted that the method described herein can be implemented in the context of any type of tape drive system.

[0046] As shown, a tape supply cassette 120 and a take-up reel 121 are provided to support the tape 122. One or more of the reels may form part of the removable cassette and are not necessarily part of the tape drive 100. A tape drive, such as... Figure 1A The tape drive shown may also include a drive motor to drive the tape supply cassette 120 and the take-up reel 121, thereby moving the tape 122 on any type of tape head 126. Such a head may include an array of read transducers (also referred to as readers), write transducers (also referred to as writers in the art), or both.

[0047] Guide 125 guides tape 122 through tape head 126. This 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 servo tracking, data writing, data reading, etc. Controller 128 may include at least one servo channel and at least one data channel, each channel including data stream processing logic configured to process and / or store information to be written to and / or read from tape 122. Controller 128 may operate under logic known in the art and any logic disclosed herein, and therefore may be considered, in various schemes, as a processor for any description of the tape drive included herein. Controller 128 may be coupled to memory 136 of any known type, which may store instructions executable by controller 128. Furthermore, controller 128 may be configured and / or programmable to perform or control some or all of the methods presented herein. Therefore, controller 128 can be viewed as being configured to perform various operations by logic programmed into one or more chips, modules and / or blocks; software, firmware and / or other instructions available to one or more processors; and so on, as well as combinations thereof.

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

[0049] Interface 134 may also be provided for communication between tape drive 100 and host (internal or external) to send and receive data, and for controlling the operation of tape drive 100 and transmitting the status of tape drive 100 to host, as will be understood by those skilled in the art.

[0050] Figure 1B An exemplary tape cassette 150 according to one scheme is shown. This tape cassette 150 can be used with, for example... Figure 1A The system shown is used together. As shown, the tape cartridge 150 includes a housing 152, a magnetic tape 122 within the housing 152, and a non-volatile memory 156 coupled to the housing 152. In some embodiments, the non-volatile memory 156 may be embedded within the housing 152, such as... Figure 1BAs shown. In many embodiments, the non-volatile memory 156 can be attached to the interior or exterior of the housing 152 without modifying the housing 152. For example, the non-volatile memory can be embedded in a self-adhesive tag 154. In a preferred embodiment, the non-volatile memory 156 can be a flash memory device, a read-only memory (ROM) device, etc., embedded or coupled to the interior or exterior of the tape cartridge 150. The non-volatile memory can be accessed by a tape drive and tape operation software (drive software) and / or another device.

[0051] By way of examples Figure 2A A side view of a flat-overlap bidirectional dual-module magnetic tape head 200, which can be implemented in the context of this invention, is shown. As shown, the head includes a pair of bases 202, each equipped with a module 204, and fixed relative to each other at a small angle α. The bases may be “U-beams” adhesively coupled together. Each module 204 includes a substrate 204A and a closure 204B having a thin-film portion (generally referred to as a “gap”), in which a read transducer and / or a write transducer 206 is formed. In use, a magnetic tape 208 moves along a media (magnetic tape) support surface 209 on the module 204 in the manner shown to read and write data on the magnetic tape 208 using the read and write transducers. The wrap angle θ of the magnetic tape 208 at the edges reaching and leaving the flat media support surface 209 is typically between about 0.1 degrees and about 3 degrees.

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

[0053] Read and write transducers can be arranged in a backpack or combined configuration. An illustrative backpack configuration includes a (magnetically inductive) write transducer on top of (or below) a (magnetically shielded) read transducer (e.g., a magnetoresistive reader, etc.), where the poles of the write transducer and the shield of the read transducer are typically separate. An illustrative combined configuration includes a reader shield in the same physical layer as the writer poles (hence the "combined"). Read and write transducers can also be arranged in an interleaved configuration. Alternatively, each channel array can be either a read or write transducer. Either of these arrays may contain one or more servo readers for reading servo data on the medium.

[0054] Figure 2B It shows from Figure 2A Line 2B cuts through the magnetic tape carrying surface 209 of one of the modules 204. A representative magnetic tape 208 is shown in dashed lines. Module 204 is preferably long enough to support the magnetic tape as the head steps between data tapes.

[0055] In this example, tape 208 includes 4 to 32 data tapes, for example, such as Figure 2B As shown, there are 16 data strips and 17 servo tracks 210 on a half-inch wide magnetic tape 208. The data strips are defined between the servo tracks 210. Each data strip may include multiple data tracks, such as 1024 data tracks (not shown). During a read / write operation, the read transducer and / or write transducer 206 is positioned at a specific track location within one of the data strips. An external reader (sometimes referred to as a servo reader) reads the servo track 210. Servo signals are then used in a conventional manner to keep the read transducer and / or write transducer 206 aligned with the specific track group during read / write operations.

[0056] Figure 2C Describing the formation in Figure 2B Multiple read transducers and / or write transducers 206 in gap 218 on module 204 in circle 2C. (e.g.) Figure 2C As shown, the array of read and write transducers 206 includes, for example, 16 write transducers 214, 16 read transducers 216, and two servo readers 212, but the number of elements can vary. Illustrative schemes include 8, 16, 32, 40, and 64 active read and / or write transducers 206 per array, and alternatively, interleaved designs with odd numbers (such as 17, 25, 33, etc.) of read or write transducers. Illustrative schemes include 32 read transducers and / or 32 write transducers per array, where the actual number of transducer elements can be larger, for example, 33, 34, etc. Multiple simultaneously operating transducers allow the tape to travel at a moderate speed while maintaining a high data transfer rate. Lower speeds are desirable for reducing mechanical difficulties arising from speed-induced tracking.

[0057] Although read transducers and write transducers can be like Figure 2C The backpack configuration shown is used, but the read transducers 216 and write transducers 214 can also be arranged in an interleaved configuration. Alternatively, each array of read and / or write transducers 206 can be only a read or write transducer, and the array can contain one or more servo readers 212. (As considered together) Figure 2A and Figures 2B to 2C As indicated, each module 204 may include a set of complementary read transducers and / or write transducers 206 for things such as bidirectional read and write, read-while-write capability, backward compatibility, etc.

[0058] Figure 2DA partial tape-bearing surface view of a complementary module of a tape head 200 according to one scheme is shown. In this scheme, each module has multiple read / write (R / W) pairs in a back-to-back configuration formed on a common substrate 204A and an optional electrically insulating layer 236. Write transducers 214 and read transducers 216 are aligned parallel to the intended direction of the tape medium's travel to form R / W pairs, exemplified by R / W pair 222. Note that the intended direction of tape travel is sometimes referred to herein as the direction of tape travel, and such terms are used interchangeably. Such a direction of tape travel can be inferred from the system design, for example, by examining the guide; observing the actual direction of tape travel relative to a reference point; and so on. Furthermore, in systems operable for bidirectional reading and / or writing, the directions of tape travel in both directions are generally parallel, and therefore the two directions can be considered equivalent to each other.

[0059] There may be several R / W pairs 222, such as 8, 16, 32 pairs, etc. The R / W pairs 222 shown are linearly aligned in a direction generally perpendicular to the direction in which the magnetic tape travels. However, these pairs can also be aligned diagonally, and so on. A servo reader 212 is located outside the array of R / W pairs, and its function is well-known.

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

[0061] Modules 224 and 226 are joined together, with space (partially shown) between their closures 204B to form a single physical unit, thereby providing read-write capability by activating the write transducer of the lead module and the read transducer of the trailing module aligned with the write transducer of the lead module in the direction of tape travel relative to the write transducer of the lead module. When constructing modules 224, 226 of the tape head 200, layers are formed in gaps 218 created above the conductive substrate 204A (partially shown), such as AlTiC, typically in the following order according to R / W pair 222: insulating layer 236; first shield 232, typically made of an iron alloy such as NiFe (e.g., about 80 / 20% NiFe, also known as permalloy); cobalt-zirconium-tantalum (CZT) or Al-Fe-Si (Sendust); sensor 234 for sensing data tracks on the magnetic medium; second shield 238, typically made of a nickel-iron alloy (e.g., permalloy); first writer pole 228 and second writer pole 230; and coil (not shown). The sensor can be of any known type, including those based on magnetoresistive (MR), gravitational magnetoresistive (GMR), amorphous magnetoresistive (AMR), tunneling magnetoresistive (TMR), etc.

[0062] The first writer electrode 228 and the second writer electrode 230 may be made of a high magnetic moment material such as CoFe. Note that these materials are provided by way of example only, and other materials may be used. Additional layers may be present, such as a shield and / or an insulating layer between the electrodes, and an insulating layer surrounding the sensor. Illustrative materials for insulation include alumina and other oxides, insulating polymers, etc.

[0063] According to one configuration, the tape head 126 includes multiple modules, preferably three or more. In a write-read-write (WRW) head, the external module for writing is located to the side of one or more internal modules for reading. (See reference) Figure 3 The WRW configuration is described, with external modules 252 and 256 each including one or more arrays of write transducers 260. Figure 3 The internal module 254 includes one or more arrays of readout transducers 258 in a similar configuration. Variations of the multi-module head include RWR heads ( Figure 4 ), RRW header, WWR header, etc. In other variations, one or more of the modules may have read / write transducer pairs. Furthermore, more than three modules may exist. In other embodiments, two external modules may be located on the sides of two or more internal modules, for example, arranged in WRRW, RWWR, etc. For simplicity, the WRW header is primarily used herein to illustrate the embodiments of the invention. Those skilled in the art, upon learning from the teachings herein, will appreciate how the substitutions of the invention will be applied to configurations other than the WRW configuration.

[0064] Figure 5A tape head 126 according to one embodiment of the present invention is shown, comprising a first module 302, a second module 304, and a third module 306, each module having tape-carrying surfaces 308, 310, and 312, which may be flat, wavy, etc. Note that although the term "tape-carrying surface" may seem to imply that the surface facing the tape 315 is in physical contact with the tape-carrying surface, this is not necessarily the case. Rather, only a portion of the tape may be in continuous or intermittent contact with the tape-carrying surface, while other portions of the tape ride (or "fly") above the tape-carrying surface on an air layer (sometimes referred to as "air-carrying"). The first module 302 will be referred to as the "leading" module because it is the first module encountered by the tape in a three-module design for the tape to move in the indicated direction. The third module 306 will be referred to as the "tailing" module. The tailing module follows the intermediate modules and is the last module seen by the tape in a three-module design. The leading module 302 and the tailing module 306 are collectively referred to as the outer modules. It should also be noted that external modules 302 and 306 will alternate as the leading module, depending on the direction of travel of the tape 315.

[0065] In one embodiment, the magnetic tape carrying surfaces 308, 310, and 312 of the first module 302, the second module 304, and the third module 306 are located on generally parallel planes (this is intended to include parallel and nearly parallel planes, e.g., ...). Figure 6 (between parallel and tangential), and the magnetic tape carrying surface 310 of the second module 304 is above the magnetic tape carrying surfaces 308, 312 of the first module 302 and the third module 306. As described below, this has the effect of producing the desired wrap angle α2 of the magnetic tape relative to the magnetic tape carrying surface 310 of the second module 304.

[0066] With the tape-carrying surfaces 308, 310, and 312 positioned along parallel or nearly parallel but offset planes, intuitively, the tape should peel off from the tape-carrying surface 308 of the lead module 302. However, experiments have shown that the vacuum generated by the scraping edge 318 of the lead module 302 is sufficient to keep the tape adhered to the tape-carrying surface 308 of the lead module 302. The trailing edge 320 of the lead module 302 (the end where the tape leaves the lead module 302) is an approximate reference point that defines the wrap angle α2 on the tape-carrying surface 310 of the second module 304. The tape remains close to the tape-carrying surface until it approaches the trailing edge 320 of the lead module 302. Therefore, the transducer 322 can be located near the trailing edge of the outer modules 302 and 306. These schemes are particularly suitable for write-read-write applications.

[0067] The advantage of this and other schemes described herein is that, because these external modules 302, 306 are fixed at a defined offset from the second module 304, the inner containment angle α2 is fixed when these modules 302, 304, 306 are coupled together or otherwise fixed to the head. The inner containment angle α2 is approximately tan α2. -1 (δ / W), where δ is the height difference between the planes of the tape-carrying surfaces 308 and 310, and W is the width between the opposite ends of the tape-carrying surfaces 308 and 310. The illustrative inner wrap angle α2 is in the range of approximately 0.3° to approximately 1.1°, but can be any angle required by the design.

[0068] Advantageously, the inner wrap angle α2 on one side (leading edge) of the module 304 that houses the magnetic tape will be larger than the inner wrap angle α3 on the trailing edge, since the magnetic tape 315 rides on top of the trailing module 306. This difference is generally beneficial because the smaller α3 tends to be the opposite of the steeper effective wrap angle so far.

[0069] Note that the tape-carrying surfaces 308 and 312 of the outer modules 302 and 306 are positioned to achieve a negative wrap angle at the trailing edge 320 of the lead module 302. This is generally beneficial in helping to reduce friction caused by contact with the trailing edge 320, provided that the location of the crowbar area formed in the tape, where the tape is peeled off from the beginning, is properly taken into account. This negative wrap angle also reduces jitter and scrubbing damage to the components on the lead module 302. Furthermore, at the trailing module 306, the tape 315 flies over the tape-carrying surface 312, so there is virtually no component wear as the tape moves in this direction. Specifically, the tape 315 entrains air and therefore does not significantly ride on the tape-carrying surface 312 of the third module 306 (some contact may occur). This is permissible because the lead module 302 is being written to while the trailing module 306 is idle.

[0070] Write and read functions are performed by different modules at any given time. In one embodiment, the second module 304 includes multiple data and optional servo readers 331 and no write transducers. The first module 302 and the third module 306 include multiple write transducers 322 and no data read transducers, except that external modules 302, 306 may include optional servo readers. The servo readers can be used to position the head during read and / or write operations. The servo readers on each module are typically positioned toward the end of the array of read or write transducers.

[0071] The gap length can be substantially reduced by placing only the read transducer or arranging the write transducer and servo read transducer side-by-side in the gap between the substrate and the enclosure. A typical head has a back-mounted read and write transducer configuration, with the write transducer formed above each read transducer. Typical gaps are 20–35 micrometers. However, irregularities on the magnetic tape can tend to sag into the gap and cause gap erosion. Therefore, a smaller gap is preferable. The smaller gap achieved in this paper exhibits fewer wear-related problems.

[0072] In some designs, the second module 304 has a closure, while the first module 302 and the third module 306 do not. When a closure is not present, a hard coating is preferably added to the module. A preferred coating is diamond-like carbon (DLC).

[0073] exist Figure 5 In the illustrated configuration, the first module 302, the second module 304, and the third module 306 each have closures 332, 334, and 336 that extend over the magnetic tape carrying surface of the associated module, thereby effectively positioning the read / write element away from the edge of the magnetic tape carrying surface. The closure 332 on the second module 304 can be a ceramic closure typically found on magnetic tape heads. However, the closures 334 and 336 of the first module 302 and the third module 306 can be shorter than the closure 332 of the second module 304, as measured parallel to the direction of magnetic tape travel over the respective module. This allows the modules to be positioned closer together. One way to produce shorter closures 334 and 336 is to overlap the standard ceramic closure of the second module 304 by an additional amount. Another way is to plate or deposit thin-film closures over the element during thin-film processing. For example, thin-film closures of a hard material (e.g., Sendust or a nickel-iron alloy (e.g., 45 / 55)) can be formed on the module.

[0074] In the absence of closures on the ceramic or thin-film closures 334, 336 with reduced thickness, or on the external modules 302, 306, the write-to-read gap can be reduced to less than about 1 mm, for example, about 0.75 mm, or 50% smaller than the commonly used linear open-to-top (LTO) tape head pitch. The open space between modules 302, 304, 306 can still be set to about 0.5 to 0.6 mm, which is ideal in some schemes for stabilizing tape movement on the second module 304.

[0075] Depending on the tape tension and stiffness, it may be desirable to make the tape-carrying surface of the outer module at an angle relative to the tape-carrying surface of the second module. Figure 6A configuration in which modules 302, 304, and 306 are in a tangential or near-tangential (angular) arrangement is shown. Specifically, the tape-carrying surfaces of these external modules 302 and 306 are approximately parallel to the tape at a desired wrap angle α2 relative to the second module 304. In other words, the planes of the tape-carrying surfaces 308 and 312 of these external modules 302 and 306 are oriented at a desired wrap angle α2 relative to the second module 304 at approximately the tape 315. In this configuration, the tape will also eject from the trailing module 306, thereby reducing wear on the components in the trailing module 306. These configurations are particularly useful for write-read-write applications. Other aspects of these configurations are similar to those given above.

[0076] Typically, the tape wrap angle can be set at... Figure 5 and Figure 6 Approximately midway between the schemes shown.

[0077] Figure 7 A configuration in which modules 302, 304, and 306 are in an outer packaging configuration is shown. Specifically, when set at the desired wrap angle α2 relative to the second module 304, the tape-carrying surfaces 308 and 312 of these outer modules 302 and 306 are at a slightly larger angle than the tape 315. In this configuration, the tape is not ejected from the trailing module, allowing it to be used for writing or reading. Therefore, both the leading and intermediate modules can perform read and / or write functions, while the trailing module can read any data that has just been written. Thus, these configurations are preferred for write-read-write, read-write-read, and write-write-read applications. In the latter configurations, the closure should be wider than the tape cover to ensure readability. A wider closure may require a wider gap-to-gap spacing. Therefore, a preferred configuration has a write-read-write configuration that uses a shortened closure, allowing for closer gap-to-gap spacing.

[0078] Figure 6 and Figure 7 Other aspects of the schemes shown are similar to those given above.

[0079] The 32-channel version of the multi-module tape head 126 can use a cable 350 with leads having the same or smaller pitch as the current 16-channel backpack LTO module, or alternatively, the connections on the module can be accordion-style to reduce cable span by 50%. Over-under, write-pair unshielded cables can be used for the write transducer, which may have an integrated servo reader.

[0080] The wrap angle α1 can be set in the drive, for example by any type of guide known in the art, such as an adjustable roller, a slider, etc., or alternatively by an extension bracket integrated with the head. For example, a roller with an offset axis can be used to set the wrap angle. This offset axis produces a rotating track arc, thereby allowing for precise alignment of the wrap angle α1.

[0081] To assemble any of the above embodiments, conventional U-beam assemblies can be used. Therefore, the mass of the resulting head can be maintained or even reduced compared to the previous generation. In other embodiments, the modules can be constructed as a single unit. Those skilled in the art will understand from the teachings of this invention that other known methods of manufacturing such a head are applicable to its construction. Furthermore, as will become apparent to those skilled in the art upon reading this disclosure, unless otherwise indicated, processes and materials of the types known in the art can be applied to various embodiments consistent with the teachings herein.

[0082] When the magnetic tape is running on the module, preferably, the tape passes sufficiently close to the magnetic transducer on the module to perform reads and / or writes efficiently (e.g., with a low error rate). According to some schemes, tape bulges can be used to ensure that the tape passes sufficiently close to the portion of the module containing the magnetic transducer. To better understand this process, Figures 8A to 8C The principle behind the magnetic tape bulge is illustrated. Figure 8A A module 800 is shown having an upper magnetic tape carrying surface 802 extending between opposing edges 804, 806. A fixed magnetic tape 808 is shown wound around the edges 804, 806. As shown, the bending stiffness of the magnetic tape 808 lifts the tape away from the magnetic tape carrying surface 802. Tape tension tends to flatten the tape profile, as... Figure 8A As shown. Under the condition of minimum magnetic tape tension, the curvature of the magnetic tape is more parabolic than shown.

[0083] Figure 8B A magnetic tape 808 in motion is depicted. The leading edge (i.e., the first edge encountered by the tape during movement) can be used to scrape air from the tape, thereby creating an air pressure below ambient pressure between the tape 808 and the tape-bearing surface 802. Figure 8B In the diagram, as the magnetic tape moves from left to right, the leading edge is the left edge and the right edge is the trailing edge. Therefore, the atmospheric pressure above the tape forces it towards the tape-bearing surface 802, creating tape bulges near each edge. The tape's bending stiffness resists the effects of atmospheric pressure, resulting in tape bulges protruding close to both the leading and trailing edges. Modeling predicts that the two bulges will be very similar in shape.

[0084] Figure 8CIt depicts how sub-ambient pressure causes the magnetic tape 808 to move toward the magnetic tape carrying surface 802, even when the trailing guide 810 is positioned above the plane of the magnetic tape carrying surface.

[0085] Therefore, as the magnetic tape passes through the module, the tape bulge can be used to guide the tape's path. As previously mentioned, the tape bulge can be used to ensure that the tape passes sufficiently close to the portion of the module containing the magnetic transducer, preferably enabling reading and / or writing to be performed efficiently, for example, with a low error rate.

[0086] Tape can be stored in tape cartridges, which are then stored in storage slots or other locations within a data repository. Tape cartridges can be stored within the repository, making them physically accessible. In addition to tape and tape cartridges, the data repository may also include data storage drives that store data to and / or retrieve data from tape. Furthermore, the tape library and its included components can implement a file system that enables access to the tape and the data stored on it.

[0087] A file system can be used to control how data is stored in and retrieved from memory. Therefore, a file system can include the processes and data structures used by the operating system to track files in memory, such as how files are organized in memory. The Linear Tape File System (LTFS) is an exemplary format that can be implemented in a given library to enable access to tape-compatible file systems. It should be understood that the different schemes described herein can be implemented using a wide range of file system formats, including, for example... Archive Library Edition (LTFSLE) (IBM and all IBM-based trademarks and logos are trademarks or registered trademarks of International Business Machines Corporation and / or its subsidiaries). However, for the purpose of providing context and individually assisting the reader, reference may be made to LTFS (which is a type of file system format) to describe some of the following schemes. This is done by way of example only and should not be considered as a limitation of the invention as defined in the claims.

[0088] A tape cassette can be "loaded" by inserting it into a tape drive, and "unloaded" by removing it from the drive. Once loaded, the tape in the cassette is "threaded" through the drive by physically pulling the tape (the magnetic recording section) from the cassette and passing it over the drive's head. Additionally, the tape can be attached to a take-up reel (see above, for example). Figure 1A (121) to move the magnetic tape on the magnetic head.

[0089] Once inserted into the tape drive, the tape in the cassette can be "mounted" by reading the metadata on the tape and bringing the tape into a state where LTFS can use the tape as a component of the file system. Furthermore, to "unthread" the tape, metadata (e.g., as an index) is preferably written onto the tape first, after which the tape can be removed from the state allowing LTFS to use the tape as a component of the file system. Finally, to "unthread" the tape, the tape is removed from the reel and physically placed back into the tape cassette. Even after the tape has been unthreaded, for example while awaiting another read and / or write request, the tape cassette can remain loaded in the tape drive. However, in other cases, the tape cassette can be unthreaded from the tape drive when the tape is unthreaded, as described above.

[0090] Magnetic tape is a sequential access medium. Therefore, data is written to the tape by appending new data to the end of previously written data. Thus, when data is recorded on a tape with only one partition, metadata (e.g., allocation information) is continuously appended to the end of previously written data and overwritten onto the tape as it is frequently updated. As a result, when the tape is first installed to access the latest copy of the metadata corresponding to the tape, the last piece of information is read. However, this introduces a considerable amount of latency during the installation of a given tape.

[0091] To overcome this latency caused by single-partition tape media, the LTFS format includes tape divided into two partitions: an index partition and a data partition. The index partition can be configured to record metadata (meta-information), such as file allocation information (index), while the data partition can be configured to record the body of the data, such as the data itself.

[0092] See Figure 9 A magnetic tape 900 with an index partition 902 and a data partition 904 is illustrated according to one scheme. As shown, data files and indexes are stored on the magnetic tape. As those skilled in the art will appreciate upon reading this specification, the LTFS format allows index information to be recorded in the index partition 902 at the beginning of the magnetic tape 906.

[0093] When the index information is updated, it preferably overwrites the previous version of the index information, thereby allowing the currently updated index information to be accessed at the beginning of the tape in the index partition. According to Figure 9In the specific example shown, the latest version of metadata index 3 is recorded at the beginning of tape 906 in index partition 902. Conversely, all three versions of metadata indexes 1, 2, and 3, as well as data files A, B, C, and D, are recorded in data partition 904 of the tape. Although indexes 1 and 2 are old (e.g., obsolete) indexes, they remain on tape 900 stored in data partition 904 without being overwritten because information is written to tape by appending it to the end of previously written data, as described above.

[0094] The metadata in index partition 902 and / or data partition 904 can be updated in the same or different ways depending on the desired scheme. According to some schemes, the metadata in index partition 902 and / or data partition 904 can be updated in response to the tape not being installed, for example, so that the index can be quickly read from the index partition when the tape is reinstalled. The metadata is preferably also written to data partition 904 so that the tape can be installed using the metadata recorded in data partition 904, for example, as a backup option.

[0095] According to one example, which is by no means intended to limit the invention, LTFSLE can be used to provide the functionality of writing an index into a data partition when the user explicitly instructs the system to write an index into a data partition or at a time specified by a predetermined period that can be set by the user (e.g., to mitigate data loss in the event of a sudden power outage).

[0096] Now for reference Figure 10 The diagram illustrates a storage system 1000 according to one scheme. It should be noted that, depending on the various schemes, in... Figure 10Some of the components shown 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 higher storage layer 1002 and at least one lower storage layer 1006. Higher storage layer 1002 may preferably include one or more random access and / or direct access media 1004, such as hard disks in hard disk drives (HDDs), non-volatile memory (NVM), solid-state drives (SSDs), flash memory, SSD arrays, flash memory arrays, etc., and / or others pointed out herein or known in the art. Lower storage layer 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 tape drives), slower access HDDs, slower access SSDs, etc., and / or others pointed out herein or known in the art. One or more additional storage layers 1016 may include any combination of storage media desired by the designer of system 1000. Furthermore, either the higher storage layer 1002 and / or the lower storage layer 1006 may include a combination of storage devices and / or storage media.

[0097] Storage system manager 1012 can be connected to network 1010, such as Figure 10 The storage area network (SAN) or some other suitable network type shown communicates with drives and / or storage media 1004, 1008 on the higher storage tier 1002 and lower storage tier 1006. The storage system manager 1012 may also 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 component of the storage system 1000 may be implemented in hardware and / or software and may utilize processors (not shown) for executing commands of types known in the art, such as central processing units (CPUs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc. Of course, any arrangement of the storage system may be used, as will be apparent to those skilled in the art upon reading this specification.

[0098] In many other embodiments, storage system 1000 may include any number of data storage layers, and each storage layer may include the same or different storage media. For example, each data storage layer may include the same type of storage media, such as HDD, SSD, sequential access media (tape in a tape drive, optical disc in an optical disc drive, etc.), direct access media (CD-ROM, DVD-ROM, etc.), or any combination of media storage types. In one such configuration, higher storage layer 1002 may include most of the SSD storage media for storing data in a higher-performance storage environment, and the remaining storage layers including lower storage layer 1006 and additional storage layer 1016 may include any combination of SSDs, HDDs, tape drives, etc., for storing data in a lower-performance storage environment. In this way, more frequently accessed data, data with higher priority, data requiring faster access, etc., can be stored in higher storage layer 1002, while data that does not have any of these attributes can be stored in additional storage layer 1016 (including lower storage layer 1006). Of course, those skilled in the art, after reading this description, can design many other combinations of storage media types to implement different storage schemes based on the schemes presented herein.

[0099] According to some schemes, a storage system (e.g., 1000) may include logic configured to receive a request to open a dataset, logic configured to determine whether the requested dataset is stored in multiple associated portions in a lower storage layer 1006 of the hierarchical data storage system 1000, logic configured to move each associated portion of the requested dataset to a higher storage layer 1002 of the hierarchical data storage system 1000, and logic configured to assemble the requested dataset from the associated portions on the higher storage layer 1002 of the hierarchical data storage system 1000.

[0100] Of course, depending on the approach, this logic can be implemented as a method or computer program product on any device and / or system.

[0101] As mentioned elsewhere above, in some data storage setups, data is ultimately transferred from an on-premises environment to a cloud-based environment. In some environments, this transfer may include migrating relatively large amounts of data. Some cloud providers recognize and discuss the importance of efficiently migrating data during such transfers. Specifically, it has been discussed that line reinforcement for temporary data movements may be impractical, despite data transmission inherently occurring over a network, and offline data transmission measures via logistics have been introduced. Some cloud providers offer this service through the original development of appliances specifically designed for data transmission. Other cloud providers, on the other hand, use LTFS to provide data transmission services. Methods for transferring relatively large amounts of data from one system to another using LTFS have also been standardized in some schemes. Some cloud providers guarantee the online accessibility of data delivered by logistics within 24 hours of receipt. It is important to note that such guarantees are made regardless of the size of the data to be migrated. Protecting this guarantee typically involves considering the amount of data received from logistics per unit time and the amount of received data that can be replicated to the online system per unit time. These metrics can be considered in order to build, maintain, and manage systems by preventing the former from exceeding the latter. For example, operations used for data transfer using LTFS may include securing multiple tape drives so that a range of tape cartridges received in a day can be processed within that day. In such an example, it may be necessary to predict the timing of data replication and specify the replication schedule for relatively short time intervals. This operation can be particularly useful in environments where such requirements exist.

[0102] Compared to some conventional data storage technologies, LTFS simplifies tape handling; however, some characteristics attributable to the use of magnetic tape in storage devices remain the same. When reading a file from a magnetic storage device such as an HDD or magnetic tape, the device (e.g., the device head) is aligned to read the data at the location where the file data is stored. This process is also known as seek. Seek operations in an HDD involve only the movement of an arm with a head across a disk a few centimeters in diameter, and therefore seek operations may take at most only tens of milliseconds to execute. In contrast, seek operations on magnetic tape involve the winding of the tape, which can be over 1000 meters long. Consequently, seek operations on magnetic tape can take a relatively longer time than seek operations in HDDs. When copying relatively large files from an LTFS-based storage system to an HDD, these relatively long seek times can add a considerable amount of time to the data copying process.

[0103] A common technique used in attempts to reduce data migration time involves reducing redundant seeks by sorting the files to be copied in order before performing the migration. Specifically, this sorting can be based on the location of the file data stored on tape. However, this common technique has drawbacks because seeks cannot be avoided when files are segmented. Furthermore, as a result of performing the sorting, this technique increases the migration process time and, with an increasing number of target files, additionally demands increasingly more CPU resources. The time required to copy data is also difficult to predict due to the difficulty in anticipating the amount of data seeking.

[0104] Since data is copied in blocks to drives, the different schemes described in this paper eliminate redundant seeks during the replication of data from an LTFS-based storage system to a RANVM drive. By eliminating these redundant seeks, the time spent performing the replication is reduced.

[0105] Now for reference Figure 11 A flowchart of method 1100 according to one scheme is shown. According to the present invention, method 1100 can be implemented as shown in Figure 1- Figure 10 and Figures 12-15 It can be executed in various ways in any environment depicted herein. Of course, as those skilled in the art will understand upon reading this specification, method 1100 may include... Figure 11 The specific operations described in the text may include more or fewer operations.

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

[0107] It can be illustrated that method 1100 can be used to reduce the time required to migrate data from an LTFS-based storage system to a RANVM drive on a block-by-drive basis. Therefore, as will be described elsewhere below, method 1100 may include operations for both preparing for and performing the data migration. It should be noted that, in a preferred embodiment, data copying for migrating data from the LTFS-based storage system to the drive is not performed on a file-by-file basis, as this would incur additional migration time in the seek operations performed to copy data on a file-by-file basis. Thus, the use of the different approaches described herein results in reduced data migration time.

[0108] As stated above, LTFS is an exemplary format for a file system that can be implemented in a given tape drive library to enable access to compliant tapes. For the context, the LTFS-based storage systems described in the different embodiments herein can be known types of tape-based storage systems, but modified in accordance with the teachings herein. In a preferred embodiment, the LTFS-based storage system includes tape drives, and may include multiple tape drives in the tape library. The system may also include one or more magnetic recording tapes. Furthermore, the RANVM drive can be a known type of storage drive, such as an HDD, SSD, etc.

[0109] Method 1100 may include initially writing data from the LTFS to an LTFS-based storage system. For example, operation 1102 of method 1100 includes writing data to blocks in the LTFS. In some scenarios, writing data to an LTFS-based storage system can be performed without receiving any request and / or instruction to copy data from the LTFS-based storage system to the RANVM drive. In contrast, in some other scenarios, data may be written to the LTFS-based storage system even though there is a plan to migrate the data written on the LTFS-based storage system to the RANVM drive at some point.

[0110] In some schemes, data can be written as files to LTFS, and therefore one or more write operations performed in method 1100 may include writing file data to blocks in LTFS. It is anticipated that the data in LTFS may eventually be copied to blocks on the RANVM drive, in units of blocks. Thus, when file data is written to an LTFS-based storage system, the location of the blocks in LTFS written to the file data can be managed by the LTFS-based storage system according to block numbers in the same way that file data is managed by the RANVM drive. It should be noted that writing file data to blocks in LTFS on an LTFS-based storage system is performed before copying the data to blocks on the drive; for example, a write operation to an LTFS-based storage system may include initially writing data to LTFS before a request to copy / migrate data to the RANVM drive. In some schemes, the file data written to blocks on an LTFS-based storage system may include file data from multiple files. In some other schemes, the file data written to blocks on an LTFS-based storage system may include file data from a single file.

[0111] In some schemes, the location of the data file is known (e.g., on magnetic recording tape, such as on an LTFS-based storage system) based on metadata including location information about the file data indexed on the LTFS-based storage system, although the location of the file data is managed according to block number in the same way as file data managed by the drive during the writing of data to blocks on the LTFS-based storage system. In other words, writing the data file to blocks on the LTFS-based storage system according to block number in the same way as file data managed by the drive preferably does not impair the performance of the LTFS-based storage system. As will be described in more detail elsewhere below, managing the write location of file data to blocks on the LTFS-based storage system in this way makes it possible to copy all file data from the LTFS-based storage system to the RANVM drive without performing seeks on the magnetic recording tape in the LTFS-based storage system (except for possible initial seeks to find the start of data in a given data band on the magnetic recording tape), and without having to additionally format the writes on the drive to conform to the drive's blocks. Therefore, copying file data from an LTFS-based storage system to a drive can be done in significantly less time compared to the time required to perform data seeks. For example, each avoided seek operation can reduce the copying process time by up to approximately tens of seconds.

[0112] In some schemes, during the writing of file data to blocks on an LTFS-based storage system, the boundaries of the file data can be aligned with the size of the blocks on the drive (e.g., the scheduling size of the blocks on the drive). It should be noted that this alignment can be ensured based on the management of the location where data is written to blocks on the LTFS-based storage system, as directly described above. Depending on the scheme, the boundaries of the file data can be defined by one or more locations and / or characteristics of the file data. For example, in a preferred scheme, the boundaries of the file data include the beginning of at least a portion of the file data. In another scheme, the boundaries of the file data may include the end of at least a portion of the file data.

[0113] For the given context, the block size on the drive can be scheme-dependent. As previously mentioned, this size is preferably incorporated into the management of where data is written to blocks on the LTFS-based storage system. In some preferred embodiments, the block size on the drive can be related to the block size on the LTFS-based storage system. For example, during data writing to the LTFS-based storage system, in some preferred embodiments, the size of each block in the LTFS-based storage system can be an integer multiple of the size of one of the blocks on the drive. This integer multiple can be set by, for example, the administrator of the LTFS-based storage system, the administrator of the drive, the manufacturer of one or more components of the LTFS-based storage system and / or the manufacturer of one or more components of the drive, a table, etc. In other words, a block size ratio can be established between the size of one of the blocks on the LTFS-based storage system and the size of one of the blocks on the drive. For example, in one embodiment, the block size ratio can 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. A preferred block size ratio can be four, meaning that one block in the LTFS-based storage system corresponds to four blocks on the drive. Note that block size ratios and integer multiples can be interchangeable; for example, in the previous example, both the integer multiple and the block size ratio are four. In some other schemes, the integer value can be a different value, such as one, ten, one hundred, a fraction, the nearest integer multiple when the block size ratio is not an integer, and so on.

[0114] In some schemes, the management of 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 schemes, the block offset of the file data on the LTFS-based storage system may be adjusted such that the remainder of the quotient of the block offset and the size of one of the blocks on the drive becomes 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 blocks on the drive. This adjustment of the block offset may be applied to address problems that would otherwise arise when copying data from an LTFS-based storage system, where the data is stored in at least one shared block, for example, where the block on the LTFS-based storage system includes data from a first data file and data from a second data file. Specifically, when file data is written to the LTFS-based storage system, this adjustment may align the data boundaries with the block size of the file system on the drive.

[0115] Operation 1104 of method 1100 includes copying data stored on an LTFS-based storage system to blocks on a RANVM drive. Data can preferably be copied in blocks on the drive. More specifically, data may not be copied from the LTFS-based storage system to the drive in files, as doing so would increase the total time required to copy the data. This is because copying data from the LTFS-based storage system to the drive in files would otherwise utilize ongoing data seek operations, which would ultimately increase the time required to perform the data copy. In some embodiments, the magnetic recording tape of the LTFS-based storage system is not mounted during copying, for example, it is not available from the application. Although a file system on the RANVM drive (e.g., available from the application) may be mounted during copying, it is preferable to have sufficient free space on the drive to copy all the data recorded on the LTFS-based storage system. Therefore, in an alternative embodiment, method 1100 may include determining the size of the files to be copied before performing the copy. In some schemes, this determination can be made, for example, based on the length of the magnetic recording tape of the LTFS-based storage system (where the entire length of the tape can be assumed to include data), the length of a portion of the tape from which data is being copied (where the entire length of that portion of the tape can be assumed to include data), the size of the index of the tape in the LTFS-based storage system, or based on known techniques. The determined size of the file to be copied can be compared with the determined size of the free space on the drive. In response to determining that the determined size of the file to be copied is greater than the determined size of the free space on the drive, the copying of data from the LTFS-based storage system to the drive can be performed (for example) delayed, partially, or on more than one medium on more than one RANVM drive. By ensuring that the size of the file to be copied is equal to or less than the determined size of the free space on the drive, known types of errors associated with exhausting the available free space on the drive are avoided.

[0116] In some implementations, the data copied to the drive may include all data on the LTFS-based storage system. For example, in some implementations, the data copied to the drive includes all data stored between the first end and the second end of the magnetic recording tape of the LTFS-based storage system. In other implementations, the data copied to the drive may include only some data from the LTFS-based storage system. For example, in some implementations, the data copied to the drive may include: data stored on multiple predetermined portions of, for example, the LTFS-based storage system located between the first and second ends of the magnetic recording tape; data on predetermined blocks on the magnetic recording tape; data stored on one or more data tracks of a predetermined data tape of the magnetic recording tape; predetermined sub-sections of the magnetic recording tape for performing a known type of rollback to a previous state of the magnetic recording tape; and so on.

[0117] While the different schemes described in this document represent data being copied from an LTFS-based storage system to blocks on a RANVM drive, whether "data" includes valid and / or invalid data may vary depending on the scheme. LTFS is a write-once file system where the recording blocks on the magnetic recording tape of an LTFS-based storage system are not overwritten when a file is overwritten, and the data to be overwritten is added to that file. Thus, in LTFS, due to file overwriting, block data can be partitioned at any boundary (e.g., any offset) because invalid regions can be created on blocks on an LTFS-based storage system. Meanwhile, a generic file system on a RANVM drive (e.g., a generic file system on an HDD) may not include mechanisms for handling copied blocks marked as invalid and those within copied blocks marked as invalid; therefore, the RANVM drive may not correctly treat data containing such blocks as a file. However, the various schemes described herein are configured to address the problem of handling overwritten files. This is because the various schemes described herein include performing boundary adjustments during the writing of data files to blocks on an LTFS-based storage system. For example, the boundaries of the file data may be aligned with the block size on the drive during the writing of file data to blocks on an LTFS-based storage system, and so on. Therefore, in some schemes, the LTFS-based storage system may include at least some invalid data, and thus the data copied from the LTFS-based storage system to blocks on the RANVM drive may include at least some invalid data, such as invalid data resulting from an overwrite operation performed on the LTFS-based storage system. However, in some other schemes, based on invalid data located on portions of the magnetic recording tape not addressed by the data copy operation, the data copy operation may include copying only valid data from the LTFS-based storage system to blocks on the RANVM drive. For example, in a scheme where only data on at least one data track of a predetermined data tape stored on the magnetic recording tape is copied from the LTFS-based storage system to blocks on the RANVM drive, and the predetermined data track does not include any invalid data, invalid data is not copied during the data copy operation. In some further embodiments, the LTFS-based storage system may include only valid data (e.g., data that has not yet been deleted or overwritten), and therefore, the data copying operation may include copying only valid data from the LTFS-based storage system to blocks of the RANVM drive.

[0118] As briefly mentioned elsewhere above, in some schemes, no data seek operations are performed on the LTFS-based storage system during the copying of data to blocks on the drive. More specifically, in some schemes, seek operations, such as determining the start position of instances of copied data, determining the end position of instances of copied data, and determining the position of split and / or segmented data files on tape in the LTFS-based storage system, may be omitted during copying. Excluding these seek operations (which would be performed if data were copied from tape in the LTFS-based storage system to the RANVM drive on a file-by-file basis) reduces the time spent copying data from the LTFS-based storage system to blocks on the RANVM drive. It should be noted that this block-by-drive copying of data from the LTFS-based storage system to the RANVM drive, rather than file-by-file, is not considered in conventional data migration techniques. Recall that, as described elsewhere above, such conventional migration techniques have attempted to reduce seek time during data migration by sorting the files to be copied in order before the data migration. However, this process cannot avoid seek operations when files are segmented, increasing migration time due to the sorting performed, and further consuming relatively large amounts of CPU resources as the number of target files increases. In contrast, the various schemes for such migrations from LTFS-based storage systems to RANVM drives, as envisioned in this paper, can mitigate at least some of the seek operations otherwise performed in conventional migration techniques by writing data to blocks on LTFS-based storage systems. Thus, the inventive discovery disclosed herein regarding the copying of data from LTFS-based storage systems to RANVM drives on a block-by-drive basis, rather than on a file-by-file basis, is contrary to conventional practice.

[0119] Method 1100's operation 1106 includes creating a mapping table during the copying of data from an LTFS-based storage system to blocks on a RANVM drive. The mapping table preferably maps data locations in the LTFS to data locations on the drive and may be shared with the LTFS-based storage system and / or the drive, for example, with the controller of the LTFS-based storage system, with the controller of the drive, with the processor of the LTFS-based storage system, with the processor of the drive, etc. In some embodiments, creating the mapping table may include collecting information associated with the management of the location where file data is written to blocks on the LTFS-based storage system. For example, the information may include information that can be added to the mapping table, such as block offset information, block offset adjustment information, file data, file data boundary information, block size information, data validity information, LTFS formatting information, etc. In some embodiments, this information may additionally and / or alternatively include one or more known types of data location information.

[0120] After data is copied from an LTFS-based storage system to blocks on a RANVM drive, invalid data can be deleted from the drive blocks at some point, such as through overwriting, erasing, or marking as reclaimable storage write locations. In some schemes, data mapping information can be used to schedule and / or perform deletions on the recording media of the LTFS-based storage system and / or the recording media of the drive. Deleting invalid data from the drive blocks increases the available storage space of the drive.

[0121] In operation 1108 of method 1100, file metadata (e.g., file block allocation) is constructed on the drive such that the copied data on the drive is accessible as one or more files, for example, as one or more files on the drive. In some schemes, the file metadata may be directory entries pointing to one or more start blocks in the FAT, for example, see [link to relevant documentation]. Figure 13E This illustrates an example of constructing metadata. In one scenario, metadata other than block allocations (e.g., filenames) can be copied from an LTFS index. In another scenario, block allocations can be constructed from a mapping table that includes the data locations on blocks and drives on an LTFS-based storage system, for example, see [link to example]. Figure 12The corresponding table is 1230. It should be noted that in conventional schemes, 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 during data replication. This is because conventional schemes do not consider copying data from an LTFS-based storage system to a RANVM drive on a block-by-drive basis. In contrast, conventional schemes perform seek operations in a timely manner to copy data from an LTFS-based storage system to a drive on a file-by-file basis. Therefore, due to the techniques described herein for various schemes that avoid seek operations during data copying from an LTFS-based storage system to a RANVM drive on a block-by-drive basis, the time required to copy data from an LTFS-based storage system to a RANVM drive is relatively more efficient than conventional data replication techniques.

[0122] Figures 12 to 14F This describes the state of data copied from an LTFS-based storage system to a RANVM drive not in units of files but in units of drive blocks (e.g., without using the file system's application programming interface (API)). Furthermore, file metadata (e.g., file block allocation) can be built on the drive so that the copied blocks can be treated as files on the drive. In some schemes, data is copied from one end of tape to the other in blocks, thus eliminating the need for seek operations during data copying. LTFS also manages the location of file data recorded therein based on block numbers, in the same way as a general file system on the drive. This data copying is possible based on the ability to map block numbers on the LTFS-based storage system to block numbers in the file system on the destination drive. In some schemes, data is copied from the LTFS-based storage system to the RANVM drive while a mapping table is created, for example, mapping data locations in LTFS to data locations on the drive. Furthermore, when writing file data to blocks in the LTFS of the LTFS-based storage system, this data copying can be achieved by aligning the data boundaries with the block size of the file system on the drive.

[0123] As a prerequisite for the various schemes described herein, the block size of each block in the LTFS (hereinafter referred to as "LBS," which stands for LTFS block size) can be an integer multiple of the block size of the file system on the destination drive (hereinafter referred to as "TBS," the target block size). In some embodiments, an integer multiple of the block size of the file system on the destination drive (which can be a value obtained by dividing the LBS by the TBS) can be referred to hereinafter as "BSR," which stands for block size ratio. It should be noted that in some preferred schemes, the source LTFS is not mounted during copying, for example, it is not available from the application. Although the file system on the destination drive can be mounted, for example, it can be available from the application, and preferably there is a sufficient amount of free space to copy all the data recorded on the source tape.

[0124] Figure 12 State 1200 is depicted for copying data from an LTFS-based storage system to a RANVM drive according to a scheme. Alternatively, state 1200 can be implemented by combining features from any other schemes listed herein, such as those described with reference to other accompanying figures. However, such state 1200 and other states presented herein can, of course, be used in various applications and / or in substitutions that may or may not be specifically described in the illustrative schemes listed herein. Furthermore, state 1200 presented herein can be used in any desired environment.

[0125] Figure 12 State 1200 includes representations of multiple blocks on an LTFS-based storage system (e.g., see LTFS blocks #10-#15) and representations of multiple target blocks on a RANVM driver (e.g., see target blocks #1200-#1207, target blocks #1212-#1220, and target blocks #1222-#1228). Corresponding table 1230 is also included. Figure 12 The context reference details the data replication from LTFS-based storage systems to RANVM drives.

[0126] Instead of copying data from LTFS-based storage systems to RANVM drives, data is copied in blocks (e.g., target blocks) of the drive. In some schemes, data on LTFS-based storage systems is read into memory in multiples of LBS. Furthermore, data read into memory can be written to free blocks on the drive in multiples of TBS.

[0127] Note that before copying data, free blocks on the drive that will be utilized during the copying process can be set to be inaccessible from the application, for example, using one or more known techniques for creating special files that are inaccessible from the application and allocating the required free blocks to the special files. However, in some scenarios, these blocks can be implemented by the application, even though the application is prevented from using these blocks.

[0128] Continue to refer to Figure 12 Assuming a BSR of 4, data from one block on an LTFS-based storage system can be copied to four free blocks on the drive. According to a more specific example, with a BSR of 4, the illustration shows the copying of two LTFS blocks #10 and #11 on an LTFS-based storage system, block by block on the drive. For example, copy operation 1 involves copying data from LTFS blocks #10-#11 to eight blocks #1200-#1207 on the drive. According to another example, copy operation 2 involves copying data from LTFS blocks #12-#13 and a portion of data from LTFS block #14 to nine blocks on the drive, such as blocks #1212-#1220. According to yet another example, copy operation 3 involves copying a portion of data from LTFS block #14 and data from LTFS block #15 to seven blocks on the drive, such as blocks #1222-#1228.

[0129] In some schemes, the data locations on blocks and drives in the LTFS-based storage system are recorded in a corresponding table 1230. The corresponding table 1230 can be used to understand which location on the drive is used to copy data from any location on a block in the LTFS-based storage system.

[0130] To implement this correspondence in Table 1230, there may be issues regarding shared blocks, a unique property of LTFS. LTFS uses larger block sizes than typical file systems to efficiently read and / or write data to and / or to tape. For example, a recommended LBS value in one scheme is 512 kilobytes (KB); however, for clarity of the illustrations shown in the various figures, the LBS can be assumed to be 256 KB in the various schemes described herein. However, depending on the scheme, the LBS can be configured to any value, such as 128 KB, 64 KB, 1024 KB, etc. To utilize tape capacity relatively efficiently with large block sizes, unlike typical file systems on drives, LTFS-based storage systems can store data from several files in a single block. This practice can also be referred to as shared blocks. Elsewhere in this document (see, for example, [link to documentation]). Figures 13A to 13B The invention further describes a technique for copying data stored on an LTFS-based storage system to blocks of a RANVM drive on a block-by-block basis, wherein at least some of the data on the LTFS-based storage system is stored in a shared block.

[0131] Figures 13A to 13B The states 1300 and 1330 of a scheme are described, which include the problem of copying data stored on an LTFS-based storage system to a RANVM drive in blocks based on shared LTFS blocks. Figures 13C to 13E The text describes mitigation during the process of copying data stored on an LTFS-based storage system to blocks of a RANVM drive, on a block-by-drive basis. Figures 13A to 13B The problems are states 1340, 1350, and 1360. Alternatively, the current states 1300, 1330, 1340, 1350, and 1360 can be implemented in combination with features from any other schemes listed herein, such as those described with reference to the other accompanying figures. However, it is of course that such states 1300, 1330, 1340, 1350, and 1360, and the other states presented herein, can be used in various applications and / or in substitutions that may or may not be specifically described in the illustrative schemes listed herein. Furthermore, states 1300, 1330, 1340, 1350, and 1360 presented herein can be used in any desired environment.

[0132] First refer to Figure 13A State 1300 includes representations of multiple blocks on an LTFS-based storage system, see, for example, LTFS blocks #10-#11. Figure 13B Status 1330 shows data being transferred from a block of an LTFS-based storage system to multiple target blocks of a RANVM driver, in units of target blocks of the driver, see target blocks #1300-#1307 for example.

[0133] Refer again Figure 13A State 1330 illustrates an example of a shared LTFS block on an LTFS-based storage system. For example, note that LTFS block #11 comprises two parts of a first file (e.g., file 1) and the entirety of a second file (e.g., file 2). In LTFS, file data locations are managed as a list of extents. Note that State 1330 reproduces the LTFS block of State 1300. In some schemes, the extent list may be stored in a corresponding table (e.g., corresponding table 1320). An extent may represent a contiguous block of data. In some schemes, an extent may include a start block number (e.g., see Start Block), a block start offset (e.g., see Byte Offset), a contiguous data length (e.g., see Byte Count), and a file extent location (e.g., see File Offset).

[0134] As mentioned above, in Figures 13A to 13BIn this configuration, LTFS block #11 is shared by file 1 and file 2. In the current scheme, file 1 stores 36KB of data from the header of LTFS block #11 and 26KB from its offset (36+106)KB. Similarly, file 2 stores 106KB of data from the offset 36KB from LTFS block #11. Thus, the shared block can store data from several files based on any boundaries (e.g., with any offset and any length). However, the general file system on the RANVM drive containing the target block does not include a mechanism for handling shared blocks. Therefore, for a scheme where one block is shared by several files and / or for a scheme where file data is stored starting from the middle of the block, it is infeasible for the drive to correctly handle the files, for example, because the RANVM drive does not include a mechanism for handling such shared blocks. Figure 13B The issue is illustrated in the example where data from a shared LTFS block #11 on an LTFS-based storage system is copied to target blocks #1304-#1306 on a RANVM drive. Specifically, because no boundary adjustments are incorporated into the data of files 1 and 2 stored on LTFS block #11 and copied to target blocks #1304-#1306 on the RANVM drive in block-by-block format, target blocks such as #1304 and #1306 contain data that cannot be managed by the drive's file system. Note that in state 1330, BSR is 4 and TBS is 64KB.

[0135] To mitigate the problems of copying shared block data (e.g., ... Figures 13A to 13B As shown, see now Figures 13C to 13D During the writing of file data on an LTFS-based storage system, data boundaries can be aligned with the block size of the file system on the RANVM drive. More specifically, the block offset (e.g., byte offset) can be adjusted such that the remainder obtained by dividing the block offset (e.g., byte offset) by the TBS becomes equal to the remainder obtained by dividing the file offset (e.g., file offset) by the TBS. An equation that can be used for this adjustment is shown below:

[0136] (Byte offset)%TBS = (File offset)%TBS Equation (1)

[0137] The "%" operator represents the remainder operator.

[0138] Because this adjustment is applied to Figure 13A The example shown establishes boundaries within a shared block, for example, as... Figure 13C As shown, data from the shared block can be copied to the target block of the RANVM driver, such as... Figure 13D As shown. In Figure 13DIn this process, data is stored in the intermediate storage of target block #1307 and then copied to target block #1304 so that the data can be managed by the file system of the RANVM driver.

[0139] This adjustment creates redundant areas on tape that are not recorded in LTFS-based storage systems, which can be flawed because it reduces the data capacity on LTFS-based storage systems. Figure 13C In the example, the unoccupied portions of LTFS block #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 cause any serious problems in the use of LTFS, assuming that the data is copied to the RANVM drive. As a result of filling all the redundant areas on the tape with zero-copy data, compression is enabled on the LTFS-based storage system drive to work efficiently, thereby suppressing the reduction of data capacity on the LTFS-based storage system.

[0140] In some schemes, each of the blocks stored on the LTFS-based storage system can be copied to the RANVM drive, and thereafter, the data locations of all files on the LTFS-based storage system can be mapped to the data locations on the drive according to a mapping table, so as to build file metadata on the drive, thereby completing the copying of all files on the LTFS-based storage system to the drive.

[0141] See now Figure 13E State 1360 illustrates a scenario where the destination file system (e.g., the destination file system for data copied from an LTFS-based storage system to a drive in blocks) is FAT.

[0142] Figures 14A to 14FStates 1400, 1410, 1420, 1430, 1440, and 1450 are depicted according to a scheme for copying data stored on an LTFS-based storage system to blocks on a RANVM drive. Alternatively, states 1400, 1410, 1420, 1430, 1440, and 1450 can be implemented by combining features from any other scheme listed herein, such as those described with reference to other figures. However, such states 1400, 1410, 1420, 1430, 1440, and 1450, and the other states presented herein, can be used in various applications and / or in substitutions that may or may not be specifically described in the illustrative schemes listed herein. Furthermore, states 1400, 1410, 1420, 1430, 1440, and 1450 presented herein can be used in any desired environment.

[0143] This is similar to how shared blocks are handled during the replication of data from an LTFS-based storage system to a RANVM drive on a drive-by-drive basis (see, for example, [link to relevant documentation]). Figures 13A to 13E During the process of copying data from an LTFS-based storage system to a RANVM drive on a drive-by-drive basis, one or more specific actions can be performed, where the data includes files that are overwritten. LTFS is a write-once file system in which record blocks on tape are not overwritten when a file is overwritten, and the data to be overwritten is appended to the file. Figures 14A to 14B This includes states 1400 and 1410, where the file is overwritten on an LTFS-based storage system. Specifically, Figure 14A Describes the state of a file on an LTFS-based storage system before it is overwritten (1400). Furthermore, Figure 14B Describes the state of a file on an LTFS-based storage system after it has been overwritten 1410. For example, when in a... Figure 14A When the 106KB following the 36KB record in the file recorded in the disk extent shown is overwritten, the disk extent will behave as follows: Figure 14B The partition is shown, and new data is added while the source data remains on LTFS block #10. Note that the extent progression can also be depicted in corresponding tables, such as tables 1402 and 1412. Thus, in an LTFS-based storage system, block data is partitioned at any boundary (e.g., any offset) due to file overwriting, and invalid regions are created within the blocks (e.g., see invalid regions in state 1410). Meanwhile, the general file system on the RANVM drive may not have the technology to manage any invalid regions within a block, and therefore the drive may not be able to correctly treat data containing such blocks as files. Figure 14C An example is shown of copying overwritten file blocks to the drive without performing boundary adjustments. For example, such as... Figure 14CAs shown, after a block containing such invalid regions is copied to the drive, blocks on the drive (e.g., target block #1400 and target block #1402) can store data that cannot be managed by the file system, which can be created on the drive. It is important to note that... Figure 14C In this case, BSR is 4 and TBS is 64KB.

[0144] In some schemes, boundary alignment can be performed additionally and / or alternatively to address issues related to handling overwritten files, for example, thereby enabling the drive to manage any invalid regions within a block. For instance, when boundary alignment adjustments are applied... Figure 14B In the example shown, the data boundaries in the shared block are as follows: Figure 14D As shown, the shared block is copied to the drive, as... Figure 14E As shown. Figure 14D This includes adjusting data boundaries to overwrite files. Figure 14E This includes examples such as copying overwritten file blocks to the drive with boundary adjustments. It should be noted that... Figure 14D The boundaries can be described in the corresponding table, for example, see corresponding table 1432. Figure 14E In the file system, there are invalid regions in the target blocks #1400 and #1402 of the drive. However, valid data from #1404 to #1400 and from #1402 to #1406 is copied to the invalid regions, thereby allowing the data to be managed in the file system.

[0145] Figure 14F This example illustrates a case where the target file system is FAT. Specifically, state 1450 indicates that FAT is the destination for data in drive target blocks #1400-#1407.

[0146] Figure 15 A sample of pseudocode 1500 for constructing file block allocations on a target file system according to one scheme is depicted. Alternatively, the current sample of pseudocode 1500 can be implemented by combining features from any other schemes listed herein (such as those described with reference to other figures). However, this sample of pseudocode 1500 and the other samples presented herein can certainly be used in various applications and / or in substitutions that may or may not be specifically described in the illustrative schemes listed herein. Furthermore, the sample of pseudocode 1500 presented herein can be used in any desired environment.

[0147] In one approach, the sample pseudocode 1500 is an algorithm for copying data from an LTFS-based storage system to a destination RANVM drive in blocks and then building file metadata (e.g., file block allocation) on the destination file system. Specifically, LB_TO_TB can be used as a function to return a block number on the destination drive corresponding to a specified block number and its position from the block header on the LTFS-based storage system. TB_COPY can be used as a function to copy a specified region of a specified block to another block on the specified destination drive. TB_ALLOC can be used as a function to allocate a specified list of blocks to a specified file in the destination file system.

[0148] Although the LTFS specification allows writing to any file region of any size, for example in Figure 14B In the example, the byte count of disk sector 2 is overwritten to 106±α, and the file offset of disk sector 3 is overwritten to 36+106±α), but the various schemes described in this paper do not handle such overwriting. More specifically, Figure 14B The diagram illustrates 106KB of old data at a file offset of 36KB, overwritten by 106KB of new data. With the Portable Operating System Interface (POSIX), 106KB of old data can be overwritten by only 106KB of new data. However, with the LTFS specification, 106KB of old data can be overwritten by new data of any size. For example, 106KB of old data can be overwritten by 110KB of new data. Note that in this example, α = +4KB. Even though overwriting is possible in the LTFS specification, it may not be possible in general file system APIs (e.g., such as the Portable Operating System Interface (POSIX)). Therefore, some schemes described in this paper can operate without handling such overwriting.

[0149] Tape containing data written using the techniques described elsewhere in this document will not deviate from the LTFS specification, and therefore the data can be read and written to by LTFS, even though the various schemes described herein may not be applicable to that LTFS. However, in tape containing data written by LTFS that does not apply such schemes, data boundary adjustments may not be available, and therefore it may be impossible to copy the data to the drive using some of the techniques described herein. Therefore, a technique is required to easily distinguish whether data was written to tape solely by LTFS. While the techniques used to achieve this distinction may vary among the schemes described herein, this can be achieved by updating, for example, the extended attribute value of a specific hidden file using the LTFS index generation number. The LTFS index can be updated when data is written to an LTFS-based storage system. In some schemes, the index generation number included in the index can also be updated. When an LTFS-based storage system using the techniques of the various schemes described herein writes an index to tape, the extended attribute value of a specific hidden file can be updated using the index generation number. However, if the extended attribute value of a specific hidden file is determined to be different from the index generation number when reading the index from the tape, subsequent extended attribute values ​​of the specific hidden file may remain unchanged. This technique can be used to determine whether the various techniques described herein are suitable for copying data from tape to a drive, where data is copied in blocks on the drive. In response to determining that such a technique is suitable, the various techniques described herein can be used to create a copy. However, in some other scenarios, in response to determining that such a technique is not suitable, other known techniques can be used to create a copy; however, using these known techniques will result in seek time.

[0150] This invention can be a system, method, and / or computer program product with any possible level of technical detail integration. The computer program product may include a computer-readable storage medium having computer-readable program instructions thereon for causing a processor to execute aspects of the invention.

[0151] Computer-readable storage media can be tangible devices capable of retaining and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer 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 disk read-only memory (CD-ROM), digital universal disk (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or having protrusions in slots on which instructions are recorded, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted through wires.

[0152] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a suitable computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or to an external computer or external storage device. The network may include copper cables, optical fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the suitable computing / processing device.

[0153] Computer-readable program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on a user's computer, partially on a user's computer, as a standalone software package, partially on a user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, 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 may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may execute computer-readable program instructions by utilizing state information from the computer-readable program instructions to perform aspects of the invention.

[0154] The present invention will now be described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0155] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create parts for implementing the functions / actions specified in one or more boxes of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that directs a computer, programmable data processing apparatus, and / or other device to operate in a particular manner, such that the computer-readable storage medium in which the instructions are stored includes an article of writing comprising instructions for implementing aspects of the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0156] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus, or other device perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0157] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the figures. For example, two blocks shown consecutively may actually be completed as a single step, executed simultaneously, substantially simultaneously, or with partial or complete temporal overlap, or the blocks may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0158] Furthermore, systems according to various embodiments may include a processor and logic integrated with and / or executable by the processor, the logic being configured to perform one or more of the process steps described herein. The processor may have any configuration as described herein, such as a discrete processor or processing circuitry comprising numerous components, such as processing hardware, memory, I / O interfaces, etc. Integrated with means that the processor has logic embedded therein as hardware logic, such as application-specific integrated circuits (ASICs), FPGAs, etc. Processor-executable means that the logic is: hardware logic; software logic, such as firmware, part of an operating system, part of an application; etc., or some combination of hardware and software logic, which is accessible to the processor and configured to cause the processor to perform some function when executed by the processor. The software logic may be stored on local and / or remote memory of any memory type, as known in the art. Any processor known in the art may be used, such as software processor modules and / or hardware processors, such as ASICs, FPGAs, central processing units (CPUs), integrated circuits (ICs), graphics processing units (GPUs), etc.

[0159] It will be clear that the various features of the aforementioned systems and / or methods can be combined in any way to create multiple combinations from the description presented above.

[0160] It should also be understood that embodiments of the present invention may be provided in the form of services deployed on behalf of customers to provide services on demand.

[0161] Various embodiments of the invention have been described for illustrative purposes, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein has been chosen to best explain the principles of the embodiments, their practical application, or technical improvements to techniques found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

Claims

1. A computer-implemented method for data migration, comprising: Data stored on a linear tape file system (LTFS) is copied from the LTFS-based storage system to blocks of random access non-volatile memory (RANVM) drives. The data is copied in blocks on the drive. The data mentioned includes file data. The location where the file data is written to the block on the LTFS-based storage system is managed by the LTFS-based storage system according to the block number in the same way that the file data is managed by the drive.

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

3. The computer-implemented method of claim 1 or 2, wherein the data copied to the block of the drive comprises all data stored between a first end and a second end of the magnetic recording magnetic tape in the LTFS-based storage system, wherein no data seek operation is performed on the magnetic recording magnetic tape during the copying of the data from the magnetic recording magnetic tape to the block of the drive.

4. The computer-implemented method according to claim 1 or 2, further comprising: During the copying of the data, a mapping table is created, wherein the mapping table maps data locations in LTFS to data locations on the drive.

5. The computer-implemented method according to claim 1, comprising: The file data is written to the block on the LTFS-based storage system before being copied to the block on the drive.

6. The computer-implemented method of claim 1, wherein the data is stored in blocks on the LTFS-based storage system, wherein during the writing of the file data to the blocks on the LTFS-based storage system, the boundaries of the file data are aligned with the size of the blocks on the drive.

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

8. The computer-implemented method of claim 1, wherein the file data corresponds to a plurality of files, wherein during the writing of the file data to the block on the LTFS-based storage system, the boundaries of the file data are aligned with the size of the block on the drive.

9. The computer-implemented method of claim 1, wherein the data includes at least some invalid data generated by an overwrite operation performed on the LTFS-based storage system.

10. The computer-implemented method according to claim 1, comprising: Build file metadata so that the data copied on the drive is accessible as one or more files.

11. A computer program product comprising program instructions capable of being read and / or executed by a controller to cause the controller to: Data stored on a Linear Tape File System (LTFS) based storage system is copied from the LTFS-based storage system to blocks of a Random Access Non-Volatile Memory (RANVM) drive, wherein the data is copied in units of blocks on the drive, wherein the data includes file data, and wherein 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 numbers in the same manner as the file data managed by the drive; and The controller constructs file metadata so that the data copied on the drive is accessible as one or more files.

12. The computer program product of claim 11, wherein the data is stored in blocks on the LTFS-based storage system, wherein the size of each of the blocks on the LTFS-based storage system is an integer multiple of the size of one of the blocks of the drive, wherein the blocks of the drive belong to the file system of the drive.

13. The computer program product of claim 11 or 12, wherein the data copied to the block of the drive comprises all data stored between a first end and a second end of the magnetic recording magnetic tape in the LTFS-based storage system, wherein no data seek operation is performed on the magnetic recording magnetic tape during the copying of the data from the magnetic recording magnetic tape to the block of the drive.

14. The computer program product of claim 11 or 12, wherein the program instructions are readable and / or executed by the controller to cause the controller to: create a mapping table during the copying of the data, wherein the mapping table maps data locations in the LTFS to data locations on the drive.

15. The computer program product of claim 11, wherein the data includes file data, and the program instructions are readable and / or executable by the controller to cause the controller to: write the file data into a block on the LTFS-based storage system before copying the data to the block on the drive.

16. The computer program product of claim 15, wherein during the writing of the file data to the block on the LTFS-based storage system, the boundaries of the file data are aligned with the size of the block on the drive.

17. The computer program product of claim 16, wherein the block offset of the file data on the LTFS-based storage system is adjusted such that the remainder of the quotient of the block offset and the size of one of the blocks of the drive becomes equal to the remainder of the quotient of the offset of the file data on the LTFS-based storage system and the size of one of the blocks of the drive.

18. The computer program product of claim 11, wherein the data comprises file data of a plurality of files, and the program instructions are readable and / or executable by the controller to cause the controller to: write the file data into the block on the LTFS-based storage system before copying the data into the block on the drive, wherein during the writing of the file data into the block on the LTFS-based storage system, the boundaries of the file data are aligned with the size of the block on the drive.

19. The computer program product of claim 11, wherein the data includes at least some invalid data generated by an overwrite operation performed on the LTFS-based storage system.

20. A system for data migration, comprising: processor; as well as Logic integrated with the processor and executable by the processor, or logic integrated with the processor and executable by the processor, wherein the logic is configured as follows: Data stored on a Linear Tape File System (LTFS) based storage system is copied from the LTFS-based storage system to blocks of a Random Access Non-Volatile Memory (RANVM) drive, wherein the data is copied in units of the blocks on the drive, wherein the data includes file data, and wherein 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 numbers in the same manner as the file data managed by the drive; and Build file metadata so that the data copied on the drive is accessible as one or more files.

21. The system of claim 20, wherein the data is stored in blocks on the LTFS-based storage system, wherein the size of each of the blocks on the LTFS-based storage system is an integer multiple of the size of one of the blocks on the drive, wherein the blocks on the drive belong to the file system of the drive.

22. The system of claim 20 or 21, wherein the data copied to the block of the drive comprises all data stored between a first end and a second end of the magnetic recording magnetic tape in the LTFS-based storage system, wherein no data seek operation is performed on the magnetic recording magnetic tape during the copying of the data from the magnetic recording magnetic tape to the block of the drive.

23. The system of claim 20 or 21, wherein the logic is configured to: create a mapping table during the copying of the data, wherein the mapping table maps data locations in LTFS to data locations on the drive.

24. The system of claim 20, wherein the data includes file data, and the logic is configured to write the file data to a block on the LTFS-based storage system before copying the data to the block on the drive.

25. The system of claim 24, wherein during the writing of the file data to the block on the LTFS-based storage system, the boundaries of the file data are aligned with the size of the block on the drive.

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

27. The system of claim 20, wherein the data is not copied on a file-by-file basis.

Images