Selective hardware and software rewrites

Abstract

The present disclosure includes systems and methods for reducing rewrite overhead in sequential access storage systems. The method may include writing a data set to a sequential access medium using a magnetic head, the data set having a plurality of encoded data blocks, classifying each of the plurality of encoded data blocks on the sequential access medium into one of at least three classes of write quality, and rewriting the encoded data blocks in a rewrite area of ​​the sequential access medium based at least in part on the write quality class. In some embodiments, the at least three classes of write quality may include a hard rewrite class in which rewriting is required to prevent data loss, a soft rewrite class in which rewriting is desirable but not necessary, and a no rewrite class in which rewriting is not necessary or desired.

Description

[Technical Field]

[0001] The present disclosure relates to data storage systems, and more particularly, the present disclosure relates to selectively rewriting code words in data storage systems. [Background technology]

[0002] The development of the EDVAC computer system in 1948 is often cited as the beginning of the computer age. Since that time, data processing systems (DSPs) have evolved into extremely complex devices. Modern DPSs typically include a combination of sophisticated hardware and software components, application programs, operating systems, processors, buses, memory, input / output devices, etc. As advances in semiconductor processing and computer architectures pushed computer performance ever higher, more advanced computer software was developed to take advantage of the higher performance of the hardware, resulting in today's computer systems that are far more powerful than those of just a few years ago.

[0003] These improved capabilities have led to an exponential growth in data, which is commonly stored in non-volatile storage systems. A magnetic storage system is a type of non-volatile storage system in which a magnetic transducer reads data from and writes data to a magnetic recording medium. Data can be written to a magnetic recording medium by positioning a magnetic recording transducer at a location on the medium where the data is to be stored. The magnetic recording transducer can then generate a magnetic field that reversibly encodes the data in the magnetic medium. Data can then be read from the medium by positioning a magnetic read transducer over the data location and then sensing the magnetic field emanating from the magnetic medium. Read and write operations can be independently synchronized with the movement of the medium to ensure that data can be read from and written to the desired location on the medium.

[0004] For many years, tape storage has offered advantages in terms of cost and storage density compared to other storage technologies such as magnetic disk storage or solid-state storage. In tape storage, data may be encoded on a sequential-access medium (e.g., magnetic tape) in a data set (DS), where DS generally refers to an internal physical data block on the tape. A "user data segment," in turn, generally refers to a chunk of data that a user is interested in storing cohesively.

[0005] Cloud drive generally refers to a type of tape storage in which user data segments are protected by some scheme external to the tape drive (e.g., error correction code (or "ECC") encoding with different pieces of ECC-encoded data sent to different tapes, duplicate copies of data sent to different tapes, etc.). Such protection schemes are typically designed to withstand a specified level of loss (e.g., loss of "n" data blocks). Summary of the Invention

[0006] According to an embodiment of the present disclosure, A system is provided that includes a magnetic head and a controller communicatively coupled to the magnetic head. The controller may be adapted to use the magnetic head to write a data set to a sequential access medium, the data set comprising a plurality of encoded data blocks. One or more controllers may also be adapted to classify the encoded data blocks into three or more classes of write quality. The one or more controllers may also be adapted to selectively rewrite one or more of the encoded data blocks in a rewritten area of ​​the sequential access medium based at least in part on the write quality class. In some embodiments, the three or more classes of write quality include a hard rewrite class, in which rewriting is required to prevent data loss, a soft rewrite class, in which rewriting is desirable but not necessary, and a no rewrite class, in which rewriting is not necessary or desired.

[0007] According to an embodiment of the present disclosure, a method for reducing rewrite overhead in a sequential access storage system is provided. The method may include writing a data set to a sequential access medium using a magnetic head, wherein the data set has a plurality of encoded data blocks. The method may further include classifying each of the plurality of encoded data blocks on the sequential access medium into one of at least three classes of write quality. The method may further include selectively rewriting the encoded data blocks in a rewrite area of ​​the sequential access medium based at least in part on the write quality class. In some embodiments, the at least three classes of write quality may include a hard rewrite class, in which rewriting is required to prevent data loss, a soft rewrite class, in which rewriting is desirable but not necessary, and a no rewrite class, in which rewriting is not necessary or desired.

[0008] According to an embodiment of the present disclosure, a computer program product is provided. The computer program product may include a computer-readable storage medium having program instructions embodied thereon. The program instructions may be executable by an apparatus to cause the apparatus to: write a data set to a sequential access medium using a magnetic head, the data set having a plurality of encoded data blocks; classify each of the plurality of encoded data blocks on the sequential access medium into one of at least three classes of write quality; and selectively rewrite the encoded data blocks in a rewrite area of ​​the sequential access medium based at least in part on the write quality class. In some embodiments, the at least three classes of write quality may include a hard rewrite class in which rewriting is required to prevent data loss, a soft rewrite class in which rewriting is desirable but not necessary, and a no rewrite class in which rewriting is not necessary or desired.

[0009] According to an embodiment of the present disclosure, an apparatus is provided that includes a controller and logic integrated with, executable by, or integrated with and executable by the controller. The logic may be configured to: write a data set to a sequential access medium using a magnetic head, the data set having a plurality of encoded data blocks; classify each of the plurality of encoded data blocks on the sequential access medium into one of at least three classes of write quality; and selectively rewrite the encoded data blocks in a rewrite area of ​​the sequential access medium based at least in part on the write quality class. In some embodiments, the at least three classes of write quality may include a hard rewrite class in which rewriting is required to prevent data loss, a soft rewrite class in which rewriting is desirable but not necessary, and a no rewrite class in which rewriting is not necessary or desired.

[0010] Any of these embodiments may be implemented in a magnetic data storage system, such as a tape drive system, which may include one or more magnetic heads, a drive mechanism for passing a magnetic medium (e.g., a magnetic tape) through the magnetic heads, and a controller operably coupled to the magnetic heads.

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

[0012] The drawings included in this application are incorporated into and constitute a part of this specification. They illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the disclosure. The drawings are only illustrative of particular embodiments and are not intended to limit the disclosure.

[0013] [Figure 1A] FIG. 1 is a schematic diagram of a simplified tape drive system consistent with some embodiments.

[0014] [Figure 1B] 1 is a schematic diagram of a tape cartridge consistent with some embodiments.

[0015] [Figure 2A] 1 illustrates a side view of a flat-wrap bidirectional two-module magnetic tape head consistent with some embodiments.

[0016] [Figure 2B] 2B is a view of the tape bearing surface taken from line 2B of FIG. 2A.

[0017] [Figure 2C] FIG. 2C is a detailed view taken from circle 2C of FIG. 2B.

[0018] [Figure 2D] FIG. 10 is a detailed view of the partial tape bearing surface of a pair of modules.

[0019] [Figure 3] FIG. 2 is a partial tape bearing surface view of a magnetic head having a write-read-write configuration consistent with some embodiments.

[0020] [Figure 4] FIG. 2 is a partial tape bearing surface view of a magnetic head having a read-write-read configuration consistent with some embodiments.

[0021] [Figure 5] 2 is a representation of files and indexes stored on magnetic tape consistent with some embodiments.

[0022] [Figure 6] FIG. 1 is a diagram of a tiered data storage system consistent with some embodiments.

[0023] [Figure 7] 1 illustrates an embodiment of a data processing system (DPS) suitable for use with a host system consistent with some embodiments.

[0024] [Figure 8] Figure 8A is a schematic diagram of a magnetic tape configured to store a DS consistent with some embodiments, and Figure 8B shows an exemplary rewrite list table consistent with some embodiments.

[0025] [Figure 9] FIG. 2 is a high-level block diagram illustrating one example of data flow for a tape drive consistent with some embodiments.

[0026] [Figure 10] FIG. 1 is a high-level block diagram illustrating allocation of incoming variable-length records to a fixed-size DS before recording the data on tape, consistent with some embodiments.

[0027] [Figure 11] FIG. 1 is a high-level block diagram illustrating data from a sub data set (SDS) organized into a two-dimensional data array consistent with some embodiments.

[0028] [Figure 12] FIG. 1 is a high-level block diagram illustrating ECC code appended to an SDS data array, consistent with some embodiments, where each row of the expanded ECC-protected data array is a codeword interleave (CWI).

[0029] [Figure 13] 1 is a flowchart illustrating one method for reducing rewrite overhead in a sequential access storage system consistent with some embodiments.

[0030] While the invention is susceptible to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It is to be understood, however, that there is no intention to limit the invention to the particular embodiments described. On the contrary, it is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention. DETAILED DESCRIPTION OF THE INVENTION

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

[0032] Unless otherwise specifically defined herein, all terms are to be given their broadest possible interpretation, including the meaning implied from the specification and the meaning as understood by a person skilled in the art and / or as defined in dictionaries, treatises, etc. Additionally, it should also be noted that when used in the specification and the appended claims, the singular forms "a," "an," and "the" include plural referents unless otherwise specified.

[0033] A common use of tape storage is backup and archival storage of "records" of data (which can be variable-sized blocks of data). Typically, a host sends / receives records to / from a tape drive. As a sequential storage device, the tape drive maps the records into a Data Set (DS), which is written to / read from the tape medium. The DS, in turn, typically refers to the drive's internal format for the data on the tape medium.

[0034] Data archiving operations typically specify a high degree of reliability when accessing the DS during readback. One technique that helps provide this high reliability is a read-while-write operation. During a read-while-write operation, faulty and / or potentially faulty error-correcting code (ECC)-protected data segments (hereinafter referred to as faulty "code-word interleaves" or "CWIs") may be stored in a buffer and then rewritten to the media at the end of the Data Set (DS) to ensure that the data is written correctly during the write process. This feature may be desirable because it can significantly improve the reliability of write operations. In some embodiments, a four-way interleaved data segment (or "CWI-4") may be used, with approximately 3% of each tape reserved for such rewriting. In such an embodiment, the media will not achieve its listed full capacity if rewritten beyond the 3% capacity reservation.

[0035] One way to boost the capacity of a storage medium is to lower its signal-to-noise ratio (SNR) operating point. However, at low SNR operating points, such as those specified in many "cloud tape drives," the random byte error rate can increase rapidly, resulting in a significant number of "C1" codewords (e.g., Reed-Solomon codewords with N1=240 and K1=228 bytes) having errors in seven or more bytes and therefore uncorrectable in "read-while-write" mode. Also, because rewrite units are conventionally CWI interleaved, an even larger number of C1 CWs are flagged for rewrite, which conventionally results in an excessive number of rewrites.

[0036] To achieve a low SNR, high capacity operating point, one possible solution is to turn off "rewrites" completely. However, completely disabling rewrites has serious potential consequences (e.g., data loss due to uncorrectable DS) or very large overhead (e.g., due to DSSs repeated throughout them) because many conventional implementations rely on rewrites to avoid uncorrectable data sets (e.g., to handle "stripe errors" caused by off-track / stoplight events). An alternative possible low SNR solution could allow rewrites, but because read-while-write verification is typically performed using a relatively weak C1 code to verify write quality, low SNR operating conditions could quickly result in an excessive number of rewrites.

[0037] Accordingly, one aspect of the present disclosure is a selective rewriting method that mitigates capacity loss due to excessive rewriting, for example, in cloud drives, and better utilizes potential gains from iterative error correction code (ECC) decoding. Thus, some embodiments may use iterative ECC decoding to successfully decode a sub-data set (SDS) in many situations, even at C1 uncorrectable rates of 50% or higher.

[0038] Some embodiments may effectively and significantly reduce rewrite overhead (e.g., of a cloud drive) while reducing the risk of data loss by simultaneously identifying three different classes (or categories) of rewrites, e.g., by classifying rewrites and / or distinguishing between them. Class A) Essential / significant rewrites, also known as "hard" rewrites. Class B) Optional / configurable rewriting, also known as "soft" rewriting. Class C) No rewriting required. In an exemplary embodiment, the "unit of rewrite" is a CWI, where all data is equal. A CWI that is incompletely written during the first write, for example, due to a short stoplight event, and / or remains unverified, may be classified as a hard rewrite. A CWI classified as a hard rewrite will always be rewritten to avoid data loss in this embodiment. In contrast, a CWI that is verified but does not meet a desired write quality metric may be classified as a soft rewrite. A soft rewrite CWI may or may not be rewritten depending on additional criteria or algorithms, such as the space remaining in the rewrite area, a specified reliability operating point, etc. Other embodiments include, but are not limited to, a configurable parameter (N) of the CWI per DS. max ), and sorting and rewriting the soft rewrites by additional quality metrics / thresholds, such as the number of RLL decoding errors in the CWI or SNR (Signal to Noise Ratio) during detection. CWIs that are written and successfully verified with high write quality do not need to be rewritten and therefore may be classified in class C (i.e., no rewriting required) in some embodiments.

[0039] Accordingly, one aspect of some embodiments is a data flow enhancement that can potentially significantly reduce rewrite overhead (e.g., for cloud drives) while simultaneously reducing the possibility of data loss. These technical advantages can be realized by measuring a write quality metric for each CWI and then using it to classify the CWI as either hard rewrite, soft rewrite, or no rewrite. Hard rewrites must be performed by the system, while soft rewrites may or may not be performed depending on factors such as space in the rewrite area, the importance of the data, predefined service commitments, etc.

[0040] Some embodiments may identify and distinguish between more than three categories of rewrites, such as four or five categories. Still other embodiments may assign priority scores to specific CWI rewrites and then prioritize the CWI rewrites based on the scores. The lower the estimated quality / reliability of the CWI, the higher the priority score of the rewrite. Still other embodiments may identify and / or prioritize subclasses of rewrites. For example, in some embodiments, class b) "soft" rewrite category may be divided into multiple categories such as: Subclass B1): more than 20 RLL decoding errors; Subclass B2): RLL decoding errors between 6 and 20; Subclass B3): Fewer than 6 RLL decoding errors. In these embodiments, subclass B1 may be given higher priority than subclass B2, which has higher priority than subclass B3.

[0041] One technical advantage of some embodiments is that they may allow for relatively lower SNR operating points while still providing a relatively higher degree of data reliability, particularly in embodiments that utilize both row and column parity and / or where a significant percentage of errors are readback errors. In particular, some embodiments may allow mitigation of excessive rewrites caused by random byte errors by defining one or more predetermined thresholds (e.g., “threshS” and “threshH,” described in more detail below), selecting a high value for “threshS” and / or preventing data loss due to correlated byte errors, and stopping writes / dead tracks by selecting a low value for “threshH.” Another technical advantage of some embodiments is that they may effectively and significantly reduce rewrite overhead (e.g., by not performing rewrites classified as soft rewrites), while also mitigating the risk of data loss (e.g., by always performing rewrites classified as hard rewrites).

[0042] One feature and advantage of some embodiments is that they may enable an administrator to select a desired mode from among a wide range of operating conditions and / or quality of service, including, but not limited to, a relatively higher reliability medium capacity mode (e.g., maximizing a reliability metric) and a relatively higher capacity medium reliability mode (e.g., maximizing a capacity metric). This feature and advantage may be enabled by adjusting and / or modifying one or more of the predetermined thresholds (i.e., threshS and threshH) described below.

[0043] 1A illustrates a simplified tape drive 100 of a tape-based data storage system consistent with certain embodiments of the present disclosure. While one particular embodiment of a tape drive is illustrated in FIG. 1A, it should be noted that the aspects and techniques described herein may be implemented in the context of any type of tape drive system.

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

[0045] Guide 125 guides tape 122 over tape head 126. Such tape head 126 is in turn 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 may control head functions such as servo following, data writing, data reading, etc. Controller 128 may include at least one servo channel and at least one data channel, each of which includes data flow processing logic configured to process and / or store information to be written to and / or read from tape 122. Controller 128 may operate under the logic disclosed herein and, therefore, in various embodiments, may be implemented as an application specific integrated circuit ("ASIC") or using a general-purpose processor for any of the tape drive descriptions contained herein. Controller 128, in some embodiments, may be coupled to memory 136, which may store instructions executable by controller 128. Additionally, controller 128 may be configured and / or programmable to execute or control some or all of the methodologies presented herein. For example, controller 128 may be configured to perform various operations as logic programmed into one or more chips, modules, and / or blocks; software, firmware, and / or other instructions available to one or more processors; and the like, and combinations thereof.

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

[0047] An interface 134 may also be provided for communication between tape drive 100 and a host (internal or external) to send and receive data, to control the operation of tape drive 100, and to communicate the status of tape drive 100 to the host.

[0048] FIG. 1B illustrates an exemplary tape cartridge 150 consistent with some embodiments. Such a tape cartridge 150 may be used with a system such as that shown in FIG. 1A. As shown, the tape cartridge 150 includes a housing 152, a tape 122 within the housing 152, and a non-volatile memory 156 coupled to the housing 152. In some embodiments, the non-volatile memory 156 may be incorporated within the housing 152, as shown in FIG. 1B. In other embodiments, the non-volatile memory 156 may be attached to the interior or exterior of the housing 152 without modification of the housing 152. For example, the non-volatile memory 156 may be incorporated into a self-adhesive label 154. In some embodiments, the non-volatile memory 156 may be a solid-state (e.g., flash) memory device, a read-only memory (ROM) device, or the like, incorporated within or coupled to the interior or exterior of the tape cartridge 150. The non-volatile memory may be accessible by a tape drive and tape operating software / driver software, and / or another device.

[0049] By way of example, FIG. 2A shows a side view of a flat-wrap, bi-directional, two-module magnetic tape head 200 consistent with some embodiments. As shown, the head includes a pair of bases 202, each of which includes a module 204 and is fixed at a small angle α relative to one another. The bases may be "U-beams" adhesively coupled together. Each module 204 includes a substrate 204A and a closed portion 204B having a thin film portion, commonly referred to as a "gap," in which a read transducer and / or write transducer 206 is formed. In use, a tape 208 moves across the modules 204 along a media (tape) support surface 209 in the manner shown to read and write data on the tape 208 using the read and write transducers. The wrap angle θ of the tape 208 at its edges entering and exiting the flat media support surface 209 may be between about 0.1 degrees and about 3 degrees, respectively, in some embodiments.

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

[0051] The read transducer and write transducer may be arranged in a piggyback or merged configuration. An exemplary piggyback configuration includes a (magnetically inductive) write transducer on top of (or below) a (magnetically shielded) read transducer (e.g., a magnetoresistive reader), where the write transducer pole and read transducer shield are generally separate. An exemplary merged configuration includes one reader shield as one writer pole on the same physical layer (hence "merged"). The read transducer and write transducer may also be arranged in an interleaved configuration. Alternatively, each array of channels may be only read or write transducers. Either of these arrays may include one or more servo readers for reading servo data on the medium.

[0052] Figure 2B shows the tape-bearing surface 209 of one of the modules 204 as viewed from line 2B in Figure 2A. A representative tape 208 is shown in dashed lines. The module 204 is shown long enough to be able to support the tape as the head steps and / or moves between data bands.

[0053] Data bands are defined between servo tracks 210. Each data band may include a number of data tracks, such as 1024 data tracks (not shown). During read / write operations, a read transducer and / or write transducer 206 is positioned at a specific track location within one of the data bands. An outer reader, sometimes called a servo reader, reads the servo tracks 210. Signals from the servo reader are then used to keep the read transducer and / or write transducer 206 aligned with a specific set of tracks during read / write operations.

[0054] In this example, the tape 208 includes 4 to 32 data bands, as shown for a 1 / 2 inch (1.27 centimeter) wide tape 208 in Figure 2B, with, for example, 16 data bands and 17 servo tracks 210. Other embodiments may use, for example, 4 data bands (and therefore 5 servo bands) on a 1 / 2 inch wide tape, and store 2000 or more tracks per data band.

[0055] 2C shows multiple read and / or write transducers 206 formed in gaps 218 on module 204 at circle 2C in FIG. 2B. As shown in FIG. 2C, the array of read and write transducers 206 may include, for example, 16 write transducers 214, 16 read transducers 216, and two servo readers 212, although the number of elements may vary. Other exemplary approaches include 8, 16, 32, 40, and 64 active read and / or write transducers 206 per array, and alternatively interleaved designs having an odd number of read or write transducers, such as 17, 25, 33, etc. An exemplary approach includes 32 read transducers per array and / or 32 write transducers per array, where the actual number of transducer elements may be greater, for example, 33, 34, etc. Multiple simultaneously operated transducers can allow the tape to run at a moderate speed while maintaining a high data transfer rate. A lower speed may be desirable to reduce mechanical difficulties from velocity-induced tracking.

[0056] 2C, the read transducers and write transducers 216 and 214 may be arranged in other configurations, such as an interleaved configuration. In other embodiments, each array of read and / or write transducers 206 may be only read or write transducers, and the array may include one or more servo readers 212. As shown in FIGS. 2A-2C, each module 204 may include complementary sets of read and / or write transducers 206 to allow for bidirectional reading and writing, read-while-write functionality, backward compatibility, etc.

[0057] FIG. 2D shows a partial tape-bearing surface view of complementary modules of magnetic tape head 200 consistent with some embodiments. In FIG. 2D, each module has multiple read / write (R / W) pairs in a piggyback configuration formed on a common substrate 204A and optional electrical insulating layer 236. Write transducer 214 and read transducer 216 are aligned parallel to the intended direction of travel of the tape media straddling them, forming an R / W pair 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 may be used interchangeably. Such tape travel direction may be inferred from the system design, for example, by examining a guide; observing the actual direction of tape travel relative to a reference point; etc. Also, in a system operable for bidirectional reading and / or writing, the direction of tape travel in both directions may be parallel, and thus both directions may be considered equivalent to each other.

[0058] There may be several R / W pairs 222 in some embodiments, such as 8, 16, 32 pairs, etc. The R / W pairs 222 in Figure 2D are shown as being linearly aligned in a direction generally perpendicular to the direction of tape travel across them. However, the pairs may also be aligned diagonally, etc. The servo reader 212 may be positioned outside the array of R / W pairs.

[0059] In some embodiments, the magnetic tape medium may move in either a forward or reverse direction as indicated by arrow 220. The magnetic tape medium and head assembly 200 may operate in a transducing relationship. Head assembly 200 includes two thin-film modules 224 and 226 of generally identical construction.

[0060] Modules 224 and 226, joined together with the space between their closing portions 204B (partially shown), form a single physical unit and can provide read-while-write functionality by activating the write transducer of the preceding module and the read transducer of the succeeding module aligned with the write transducer of the preceding module parallel to the direction of tape travel relative thereto. When modules 224, 226 of magnetic tape head 200 are constructed, for example, layers of aluminum-titanium-carbon may be formed within gap 218 created above conductive substrate 204A (partially shown), generally in the following order for R / W pair 222: insulating layer 236; first shield 232 comprising an iron alloy such as NiFe (e.g., approximately 80 / 20 at% NiFe, also known as Permalloy), cobalt zirconium tantalum (CZT) or aluminum-iron-silicon (sendust); sensor 234; second shield 238, typically an iron-nickel based alloy (e.g., Permalloy); first and second writer poles 228, 230; and a coil (not shown). The sensor may be any device adapted to sense data tracks on magnetic media, including, but not limited to, a magneto-resistive (MR) sensor, a giant magneto-resistive (GMR) sensor, an anisotropic magneto-resistive (AMR) sensor, a tunneling magneto-resistance (TMR) sensor, etc.

[0061] The first and second writer poles 228, 230 may be made from a high magnetic moment material, such as cobalt iron. 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 surrounding the sensor and / or insulation between the pole tip and an insulating layer. Exemplary materials for insulation include alumina and other oxides, insulating polymers, etc.

[0062] One approach to tape head 126 configuration includes multiple modules, such as three or more in some embodiments. In a write-read-write (WRW) head, an outer module for writing flanks one or more inner modules for reading. Referring to FIG. 3 , which shows a WRW configuration, outer modules 252, 256 may each include one or more arrays of write transducers 260. The inner module 254 of FIG. 3 may include one or more arrays of read transducers 258 in a similar configuration. Variations of multi-module heads include, but are not limited to, RWR heads ( FIG. 4 ), RRW heads, WWR heads, etc. In yet other variations, one or more of the modules may have read / write pairs of transducers. There may also be more than three modules. In a further approach, two outer modules may flank two or more inner modules, e.g., a WRRW, RWWR arrangement, etc. For simplicity of explanation, WRW heads are primarily used herein to illustrate the techniques of the present disclosure, and embodiments of the present disclosure may be applied to configurations other than WRW configurations.

[0063] Advantageously, the tape is run across the modules so that it passes close enough to the magnetic transducers on the modules that reading and / or writing is performed efficiently, eg, with a low error rate.

[0064] The magnetic tapes may be stored in tape cartridges that may then be stored in storage slots or the like within a data storage library. The tape cartridges are stored in the library so that they may be accessible for physical retrieval. In addition to the magnetic tapes and tape cartridges, the data storage library may include data storage drives that store and / or retrieve data from the magnetic tapes. Tape libraries and components contained therein may also implement file systems that allow access to the tapes and data stored on the tapes.

[0065] A file system may be used to control how data is stored in memory and retrieved from memory. As such, a file system may include the processes and data structures that an operating system uses to keep track of files in memory, e.g., how files are organized in memory. The Linear Tape File System (LTFS) is an exemplary file system format that may be implemented in a library to enable access to compliant tapes. It should be understood that the various techniques herein may be implemented in a wide range of file system formats. However, to provide context and to assist the reader only, some of the following techniques may be described with reference to the LTFS file system format. This is by way of example only and should not be considered limiting of the scope of the present disclosure.

[0066] A tape cartridge may be "loaded" by inserting the cartridge into a tape drive, and may be "unloaded" by removing the tape cartridge from the tape drive. Once loaded into a tape drive, the tape in the cartridge may be "threaded" through the drive by physically pulling the tape (magnetic recording portion) from the tape cartridge and passing it over the magnetic head of the tape drive. Additionally, the tape may be attached to a take-up reel (see, e.g., 121 in FIG. 1A above), which moves the tape over the magnetic head.

[0067] Once threaded into a tape drive, the tape in the cartridge may 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. Conversely, to "unmount" a tape, metadata may first be written to the tape (e.g., as an index), after which the tape may be removed from a state where LTFS can use the tape as a component of the file system. The tape may then be "unthreaded." To unthread a tape, the tape may be removed from the take-up reel and physically positioned back inside the tape cartridge. The cartridge may remain loaded in the tape drive even after the tape has been unthreaded, e.g., awaiting another read and / or write request. However, in other embodiments, the tape cartridge may be unloaded from the tape drive when the tape is unthreaded, e.g., as described above.

[0068] Magnetic tape is a sequential access medium. As such, new data is written to the tape by appending the data at the end of previously written data. Typically, when data is recorded on a tape with only one partition, metadata (e.g., allocation information) is frequently updated and rewritten to the tape accordingly, so that it can be continuously appended to the end of the previously written data. As a result, when a tape is first mounted to access the most recent copy of the metadata corresponding to the tape, the most recent information is read. However, this can result in a significant amount of delay in the process of mounting a given tape.

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

[0070] Referring now to Figure 5, a representation of files and indexes stored on a magnetic tape is shown consistent with some embodiments. In Figure 5, a magnetic tape 500 has an index partition 502 and a data partition 504. As shown, data files and indexes are stored on the tape. The LTFS format may be desirable because it allows index information to be recorded in index partition 502 at the beginning of the tape 506.

[0071] When index information is updated, it may be written over the previous version of the index information, thereby allowing the current, updated index information to be accessible at the beginning of the tape in the index partition. According to the specific exemplary embodiment shown in Figure 5, the most recent version of metadata, Index 3, is recorded in index partition 502 at the beginning of tape 506. Conversely, all three versions of metadata, Index 1, Index 2, and Index 3, and data, File A, File B, File C, and File D, are recorded in data partition 504 of the tape. Although Index 1 and Index 2 are old (e.g., outdated) indexes, because information is written to tape by appending it to the end of previously written data, as described above, these old indexes, Index 1 and Index 2, are not overwritten and remain stored on tape 500 in data partition 504.

[0072] Metadata may be updated in the index partition 502 and / or the data partition 504 in the same or different manner depending on the desired approach. In some embodiments, metadata in the index partition and / or the data partitions 502, 504 may be updated in response to a tape being dismounted, for example, so that the index can be quickly read from the index partition when the tape is remounted. Metadata may also be written to the data partition 504 so that a tape can be mounted, for example, as a backup option, using the metadata recorded in the data partition 504.

[0073] By way of one non-limiting example, the Linear Tape File System - Library Edition (LTFS LE) may be used to provide the ability to write indexes to a data partition when the user explicitly commands the system to do so or at times specified by a predefined period (which may be set by the user, e.g., so that data loss in the event of a sudden power outage can be mitigated). LTFS LE, in turn, generally refers to a multi-drive variant of LTFS that presents each cartridge in a library as a subdirectory of the LTFS file system.

[0074] Referring now to FIG. 6 , a tiered data storage system 600 consistent with some embodiments is illustrated. Note that some of the elements illustrated in FIG. 6 may be implemented as hardware and / or software according to various approaches. The storage system 600 may include a storage system manager 612 for communicating with multiple media and / or drives in at least one upper storage tier 602 and at least one lower storage tier 606. The upper storage tier 602 may include one or more random-access and / or direct-access media 604, such as hard disks in a hard disk drive (HDD), nonvolatile memory (NVM), solid-state memory in a solid-state drive (SSD), flash memory, SSD arrays, flash memory arrays, etc. The lower storage tier 606 may include one or more lower-performance storage media 608, including sequential-access media, such as magnetic tape in a tape drive and / or optical media, slow-access HDDs, slow-access SSDs, etc. The one or more additional storage tiers 616 may include any combination of storage memory media as desired by the designer of the system 600. Also, either the upper storage tier 602 and / or the lower storage tier 606 may include some combination of storage devices and / or storage media.

[0075] The storage system manager 612 may communicate with the drives and / or storage media 604, 608 in the upper storage tier 602 and the lower storage tier 606 via a network 610, such as a storage area network (SAN) as shown in FIG. 6 or some other suitable network type. The storage system manager 612 may also communicate with one or more host systems (see FIG. 7) via a host interface 614, which may or may not be part of the storage system manager 612. The storage system manager 612 and / or any other components of the storage system 600 may be implemented in hardware and / or software and may use a processor (not shown) to execute commands of a type known in the art, such as a central processing unit (CPU), field programmable gate array (FPGA), application specific integrated circuit (ASIC), etc. Of course, any arrangement of storage systems may be used, as would be apparent to one of ordinary skill in the art upon reading this specification.

[0076] In some embodiments, storage system 600 may include any number of data storage tiers, and may include the same or different storage memory media within each storage tier. For example, each data storage tier may include the same type of storage memory media, such as HDDs, SSDs, sequential access media (e.g., tape in a tape drive, optical disk in an optical disk drive), direct access media (e.g., CD-ROMs, DVD-ROMs), or any combination of media storage types. In one non-limiting example, upper storage tier 602 may include a majority of SSD storage media for storing data in a higher performing storage environment, while the remaining storage tiers, including lower storage tier 606 and additional storage tier 616, may include any combination of SSDs, HDDs, tape drives, etc. for storing data in a lower performing storage environment. In this manner, more frequently accessed data, data having a higher priority, data that needs to be accessed more quickly, etc. may be stored in upper storage tier 602, while data that does not have one of these attributes may be stored in additional storage tier 616, including lower storage tier 606.

[0077] According to some approaches, a storage system (such as storage system 600) may include logic configured to receive a request to open a data set, logic configured to determine whether the requested data set is stored in a lower storage tier 606 of the tiered data storage system 600 in multiple associated portions, logic configured to move each associated portion of the requested data set to an upper storage tier 602 of the tiered data storage system 600, and logic configured to assemble the requested data set from the associated portions in the upper storage tier 602 of the tiered data storage system 600.

[0078] FIG. 7 illustrates an embodiment of a data processing system (DPS) 700 suitable for use with a host system consistent with some embodiments. In some embodiments, the DPS 700 is implemented as a personal computer; a server computer; a portable computer, such as a laptop or notebook computer, a PDA (personal digital assistant), a tablet computer, or a smartphone; a processor integrated into a larger device, such as an automobile, an airplane, a teleconferencing system, or an appliance; a smart device; or any other suitable type of electronic device. Also, components other than or in addition to those shown in FIG. 7 may be present, and the number, type, and configuration of such components may vary. Also, FIG. 7 illustrates only representative major components of the DPS 700, and individual components may have greater complexity than those depicted in FIG. 7.

[0079] 7 includes multiple central processing units 710a-710d (collectively referred to herein as processors 710 or CPUs 710) connected to memory 712, a mass storage interface 714, a terminal / display interface 716, a network interface 718, and an input / output ("I / O") interface 720 via a system bus 722. The mass storage interface 714 in this embodiment connects the system bus 722 to one or more mass storage devices, such as a direct access storage device 740, a universal serial bus ("USB") storage device 741, or a readable / writable optical disk drive 742. The network interface 718 enables the DPS 700 to communicate with other DPSs 700 over a communications medium 706. The memory 712 also includes an operating system 724, multiple application programs 726, and program data 728.

[0080] The embodiment of data processing system 700 in FIG. 7 is a general-purpose computing device. Accordingly, processor 710 may be any device capable of executing program instructions stored in memory 712, which may itself be constructed from one or more microprocessors and / or integrated circuits. In this embodiment, DPS 700 includes multiple processors and / or processing cores, as is typical of larger, more powerful computer systems; however, in other embodiments, computing system 700 may comprise a single processor system and / or a single processor designed to emulate a multiprocessor system. Furthermore, processor 710 may be implemented using multiple heterogeneous data processing systems 700 in which a main processor resides on a single chip with secondary processors. As another illustrative example, processor 710 may be a symmetric multiprocessor system including multiple processors of the same type.

[0081] When data processing system 700 boots up, the associated processor 710 initially executes program instructions that make up operating system 724, which manages the physical and logical resources of DPS 700. These resources include memory 712, mass storage interface 714, terminal / display interface 716, network interface 718, and system bus 722. As with processor 710, some DPS 700 embodiments may utilize multiple system interfaces 714, 716, 718, 720 and bus 722, which, in turn, may each include their own separate and fully programmed microprocessor.

[0082] Instructions for the operating system, applications, and / or programs (collectively referred to as “program code,” “computer-usable program code,” or “computer-readable program code”) may initially be located on mass storage devices 740, 741, 742, which are in communication with the processor 710 via the system bus 722. The program code in different embodiments may be embodied on different physical or tangible computer-readable media, such as the system memory 712 or the mass storage devices 740, 741, 742. In the illustrative example of FIG. 7 , the instructions are stored in a functional form on persistent storage on the direct-access storage device 740. These instructions are then loaded into memory 712 for execution by the processor 710. However, the program code may also be located in a functional form on a computer-readable medium that is selectively removable and can be loaded or transferred to the DPS 700 for execution by the processor 710.

[0083] The system bus 722 may be any device that facilitates communication between and among the processor 710, memory 712, and interfaces 714, 716, 718, 720. Also, although the system bus 722 in this embodiment is a relatively simple single bus structure that provides a direct communication path between the system bus 722, other bus structures are consistent with this disclosure, including, but not limited to, point-to-point links in hierarchical, star, or web configurations, multiple hierarchical buses, parallel and redundant paths, etc.

[0084] Memory 712 and mass storage devices 740, 741, and 742 work cooperatively to store operating system 724, application programs 726, and program data 728. In this embodiment, memory 712 is a random-access semiconductor device capable of storing data and programs. While FIG. 7 conceptually depicts the device as a single monolithic entity, memory 712 in some embodiments may be a more complex arrangement, such as a hierarchy of caches and other memory devices. For example, memory 712 may exist in multiple levels of caches, and these caches may be further divided by function, such that one cache may hold instructions, while another cache holds non-instruction data used by the processor or processors. Memory 712 may be further distributed and associated with different processors 710 or sets of processors 710, as known in any of a variety of so-called non-uniform memory access (NUMA) computer architectures. Additionally, some embodiments may utilize a virtual addressing mechanism that allows the DPS 700 to behave as if it has access to a large single storage entity instead of access to multiple smaller storage entities, such as memory 712 and mass storage devices 740, 741, 742.

[0085] Although operating system 724, application programs 726, and program data 728 are shown as being contained within memory 712, some or all of them may, in some embodiments, be physically located on different computer systems and may be accessed remotely, for example, via communications medium 706. Thus, although operating system 724, application programs 726, and program data 728 are shown as being contained within memory 712, these elements are not necessarily all contained entirely on the same physical device at the same time, and may even reside in the virtual memory of another DPS 700.

[0086] System interfaces 714, 716, 718, 720 support communication for a variety of storage and I / O devices. Mass storage interface 714 supports the attachment of one or more mass storage devices 740, 741, 742, which are typically rotating magnetic disk drive storage devices; solid-state storage devices (SSDs) that use integrated circuit assemblies as memory, typically using flash memory, to persistently store data; or a combination of the two. However, mass storage devices 740, 741, 742 may also comprise other devices, including arrays of disk drives configured to appear as a single large storage device to a host (commonly referred to as RAID arrays) and / or archival storage media (such as hard disk drives, tape (e.g., mini-DV), writable compact discs (e.g., CD-R and CD-RW), digital versatile discs (e.g., DVD, DVD-R, DVD+R, DVD+RW, DVD-RAM), holographic storage systems, Blue Laser Discs, IBM Millipede devices, and the like).

[0087] Terminal / display interface 716 is used to connect one or more display units 780, such as monitors, directly to data processing system 700. These display units 780 may be non-intelligent (i.e., dumb) terminals, or may themselves be fully programmable workstations used to allow IT administrators and customers to communicate with DPS 700. However, it should be noted that while display interface 716 is provided to support communication with one or more display units 780, computer system 700 does not necessarily require a display unit 780, as all necessary interaction with customers and other processes can occur via network interface 718.

[0088] The communication medium 706 may be any suitable network or combination of networks and may support any appropriate protocol suitable for communicating data and / or code between the multiple DPSs 700. Accordingly, the network interface 718 may be any device that facilitates such communication, regardless of whether the network connection is made using current analog and / or digital technology or via some future network mechanism. Suitable communication media 706 include, but are not limited to, networks implemented using one or more of the “InfiniBand” or IEEE (Institute of Electrical and Electronics Engineers) 802.3x “Ethernet” specifications; cellular transmission networks; wireless networks implementing one of the IEEE 802.11x, IEEE 802.16, General Packet Radio Service (GPRS), Family Radio Service (FRS), or Bluetooth specifications; ultra-wideband (“UWB”) technologies such as those described in FCC 02-48; or the like. Those skilled in the art will appreciate that many different network and transport protocols may be used to implement the communications medium 706. The Transmission Control Protocol / Internet Protocol ("TCP / IP") suite includes suitable network and transport protocols.

[0089] 8A is a schematic diagram of a magnetic tape 800 configured to store a data set (DS) consistent with some embodiments. The DS 800 in this example includes a Data Set Separator sequence (DSS) at location 820 and multiple CWI code word sets 825(1)...825(384), each including multiple CWI code words 825(1)-1, 825(1)-2...825(384)-16, such as CWI-4 code words (only some code word sets 825(n) and code words 825(n)-m are labeled for clarity). For each CWI code word 825(n)-m, a write head 810 writes associated data to the tape 800, which is subsequently read back by a read head 815, enabling read-while-write data verification. In this example, some of these CWI codewords 825-1-3, CWI 825-2-11, etc. will fail verification (e.g., readback under a desired write quality metric). These unverified CWI codewords 825(1)-3, CWI 825(2)-11 may be classified as soft rewrites and may or may not be (re)written in the rewrite area 850 depending on additional criteria or algorithms, such as the space remaining in the rewrite area 850, a specified reliability operating point, etc.

[0090] 8A , an off-track event occurred at location 830 (again, assuming the servo position of tape 800 is known). In response, writing is interrupted / paused until heads 810, 815 return to desired track location 840. Writing then resumes at the new DSS, and so on. In this example, all of CWI code words 825(3)-1...825(3)-16 in code word set 825(3) are affected by the off-track event. These CWI code words are uncorrectable (e.g., incomplete / have too many byte errors due to the writing stop at location 830) and therefore can be classified as "hard rewrites" that will be rewritten in rewrite area 850.

[0091] 8A , a dead track event occurs, for example, from a faulty write head 810. In response, some embodiments may detect strings of unverified CWI code words, such as CWI 825(1)-1, CWI 825(2)-1, etc., that are greater than a predetermined length and classify them as “hard rewrites.” In response, the affected CWI code words will also be rewritten in rewrite area 850. The rewrite of a CWI occurs on a different track than where it was originally written.

[0092] 8A also shows CWI codewords that have been both written and verified to a predetermined write quality level, e.g., CWI825(6)-2. These CWI codewords can be classified as "no rewrites" required.

[0093] During operation, some embodiments may use ECC, such as iterative C1-C2 decoding, to protect rows of CWI codewords (i.e., CWI codewords written by the same head 810), such as CWI-4 codewords. At low SNRs, nearly all CWIs in a DS / SDS may be rewritten and therefore read from tape. Iterative decoding may be used to process rows of CWI codewords. Iterative decoding may handle byte error rates of up to a few percent at the input, as long as all CWI codewords are available for decoding, e.g., written to tape at least once.

[0094] Since the DS was originally written to tape 800, a CWI rewrite list / table may be populated with metadata (e.g., which CWI blocks require rewriting, what type of rewrite, etc.). One exemplary rewrite list table 870 consistent with some embodiments is shown in FIG. 8B. Unique identifiers (shown as “1,” “4,” and “77” in FIG. 8B for clarity of the drawing, although many embodiments may use more complex identifiers) for CWI codewords requiring rewriting (e.g., CWI825(1)-1, CWI825(1)-3, etc.) may be listed in the first column of table 870. The second and third columns of table 870 may comprise tags indicating the CWI codewords identified for “hard” or “soft” rewriting. In some embodiments, during the rewriting process, the CWI codewords identified in table 870 are: If "hard_flag" is equal to "true" (e.g., 1), it must be (re)written. · May be rewritten (or lowered by a threshold scheme) if "soft_flag" equals "true" (e.g., "1") AND "hard_flag" equals "false" (e.g., "0"). If any other combination (e.g., ELSE), then there is no rewriting. In some embodiments, when the (pipelined) dataflow writes a DS to tape, it may generate / update a list / table 870 that "flags" those CWI codewords that need to be rewritten. Some embodiments may implement these flags, for example, by extending the current "rewrite flag" from 1 bit to 2 bits to comprise a "soft flag" and a "hard flag".

[0095] "Hard rewrites" generally refer to those rewrites that are most critical or even necessary to avoid data loss. Events in which some CWI code words are not written or written incompletely (and therefore cannot be read / used for decoding in a reading device) include, for example: stoplight events (where writing is abruptly stopped to avoid overwriting adjacent tracks), dead tracks (due to a very poor or non-functional writer). In these events, to avoid the risk of data loss / uncorrectable DS, some embodiments may ensure that missing / incomplete CWIs are (re)written. These CWIs may be considered "hard rewrites" (or essential / critical rewrites).

[0096] In some embodiments, the CWI codeword satisfies the following conditions: (#RLL_decoding_errors in CWI are greater than "threshH") AND ((#byte_errors are greater than "threshB") OR (uncorrectable)) A "hard rewrite" may be considered if the following two conditions are met: the total number of RLL decoding errors in the CWI codeword (maximum: 243 errors in some embodiments) exceeds a first configurable / adjustable threshold "threshH" (where 0≦threshH≦255), and either (i) the number of byte errors per C1 codeword exceeds a second configurable / adjustable threshold "threshB" (where 0≦threshB≦T=255); or (ii) the C1 codeword is uncorrectable. This dual condition may be desirable in low SNR environments where more errors may be present. In other embodiments, the CWI may be considered "hard rewrite" if the following single condition is met: #RLL_decoding_errors_in_CWI4>threshH If the above condition is met, it may be considered a "hard rewrite." For the above example C1 code (Reed-Solomon codeword with N1=240 and K1=228 bytes), the C1 decoder may detect / correct up to six byte errors per codeword, so threshB≦T=5 works as expected. If there are more than six byte errors in the C1 codeword (6≦T), then C1 decoding will fail, and thus the second condition will be true (uncorrectable). Additionally, if a CWI codeword is not written / verified, for example, due to an off-track event, then some embodiments may set the above #RLL_decoding_errors_in_CWI4 variable to 244 (i.e., a value greater than the maximum possible number of errors or a similar flag), thus forcing the CWI codeword to be classified as a "hard rewrite."

[0097] Other tests for determining "hard rewrite" conditions are within the scope of this disclosure and may be used in addition to or instead of the conditions described above. For example, CWI codewords on a "dead track" (e.g., due to a very poor or non-functional writer) may be classified as "hard rewrite" based on, for example, read channel statistics such as mean squared error (MSE) or signal-to-noise ratio (SNR), or statistics of C1 decoding performance. Additionally, some embodiments may optionally allow rewrites to be disabled (e.g., for testing) by setting a first threshold, threshH, equal to 255.

[0098] "Soft rewrites" generally refer to those rewrites that are desirable for reliability purposes but are unlikely to result in data loss. In some embodiments, a CWI codeword may be classified as "soft rewritten" if it is "not hard rewritten" AND one of the following "soft rewrite" conditions is met: A) The CWI codeword has at least one C1 codeword with #byte_errors > threshB; B)#RLL_decoding_errors_in CWI>threshS;OR C) a combination of A) and B); where "threshS" is the third configurable / adjustable threshold and is lower than threshH.

[0099] If neither the hard nor the soft rewrite condition is met, then no rewrite is required, eg, the CWI codeword has been both written and verified.

[0100] 9 is a high-level block diagram illustrating one example of a data flow 900 for a tape drive consistent with some embodiments. This data flow 900 is presented by way of example only and is not intended to be limiting. Indeed, tape drives implementing other data flows may also benefit from the rewriting techniques disclosed herein and, as such, are intended to be encompassed within the scope of the present invention. Data flow 900 is presented merely to illustrate one approach for performing a process for recording data on magnetic tape.

[0101] The CRC module 902 receives a series of bytes contained within variable-length blocks of data (also known as "records") from the host device. These blocks of data can be of any size up to the maximum size supported by the tape drive. The cyclic redundancy check (CRC) module 902 may add CRC information to these blocks. The compression module 904 may then compress the blocks, and the encryption module 906 may optionally encrypt the blocks. The blocks of data may then be divided into fixed-size data sets, which may then be divided into fixed-size sub-data sets (SDSs). Each SDS may be organized into a two-dimensional array of data and passed through a column error correction code (ECC) encoder 908, which then generates parity bits for each column in the data array and appends the column ECC parity to the array.

[0102] Once the column ECC parity is generated and added to the array, multiplexer 910 may add headers to the rows in the array. These headers may identify the location of the rows within the subdataset and the larger data set in which they reside. The expanded array may then be passed to row ECC encoder 912, which generates row ECC parity (typically including an 8-bit symbol (byte) or the like) for each row in the array. Generally, the ECC parity symbol has n bits, where n is a positive integer. The ECC parity may be of any conventional type, such as C1 parity, C1' parity, etc., where C1 parity is generated from the rows of the SDS and C1' parity is generated from both the rows of the SDS and the headers added to the rows. Thus, C1 parity protects against failures in the rows of the SDS, while C1' parity protects against failures of both the rows of the SDS and the headers added to the rows. The tape layout module 914 may then distribute the data array, ECC parity, and header across M different tracks and in different orders for recording on the magnetic tape. M is typically a multiple of 8, such as 8, 16, 32, 64, etc. In general, M can be any positive integer. The data sequence may then be processed by a randomizer 916, which performs additional signal processing on the data in a conventional manner. A run-length limited (RLL) encoder 918 may then convert the information to make it better suited for magnetic recording. A multiplexer 920 may multiplex synchronization information, such as a variable frequency oscillator (VFO) sequence for timing acquisition, sync characters, or the like, onto the information to enable it to be synchronized upon reading. The resulting data may then be sent to a write driver (not shown), which drives a current through the recording head elements to generate a magnetic flux, thereby writing the data to the magnetic recording medium. Generally, each block or module to the right of row ECC encoder 912 performs a different transformation on the data to make it more suitable for magnetic recording.

[0103] FIG. 10 is a high-level block diagram showing allocation of incoming variable-length records to fixed-size DSs 1008 before recording data on tape, consistent with some embodiments. In FIG. 10, a tape drive may be configured to allocate incoming variable-length records to fixed-size DSs 1008 before recording data on tape. The number of bytes in a DS 1008 may be drive technology dependent and may be invisible to the host. Incoming host data may start filling a first DS 1008 at the first byte of the DS 1008, continue to the last byte of the DS 1008, and then continue into subsequent DSSs 1008 as needed. In certain cases, a tape drive may combine multiple small host records 1000 into a single DS 1008 or generate multiple DSSs 1008 from a larger host record 1000. As described above, each DS 1008 may interleave some number S of smaller, fixed-size data entities, referred to as sub-DSSs 1004 (SDSs), to improve ECC decoder performance.

[0104] 11 is a high-level block diagram illustrating data in a sub data set (SDS) 1004 organized into a two-dimensional data array consistent with some embodiments. As shown, the SDS 1004 is organized into a matrix with d2 rows and d1 columns. Data from the DS 1008 may fill the SDS 1004 row by row, starting at row 0, byte 0 and continuing through row d2-1, byte d1-1.

[0105] FIG. 12 is a high-level block diagram illustrating ECC code appended to an SDS data array consistent with some embodiments, where each row of the expanded ECC-protected data array is a codeword interleave (CWI). As shown in FIG. 12, a p2 column ECC parity byte 1202 (also known as "C2" parity) may be appended to each column in the SDS 1004 array, and after appending a header 1204 to each row, a p1 row ECC parity byte 1200 (also known as C1 parity or C1' parity) is appended to each row in the SDS 1004 array. C1 parity is generated from the SDS row, while C1' parity is generated from both the SDS row and the header appended to the row. The row ECC parity 1200 protects each row of the SDS 1004 array, while the column ECC parity 1202 protects each column in the SDS array 804, except for the appended header portion. Each SDS row, including a row of column ECC parity data 1202, may be considered a C1 codeword. In a selected approach, row ECC parity 1200 and / or column ECC parity 1202 are constructed with Reed-Solomon codes.

[0106] In some approaches, each row contains multiple C1 codewords interleaved in some fashion. Therefore, for purposes of this description, each row of the ECC-protected SDS array 1210 will hereafter be referred to as a codeword interleave (CWI), where a CWI contains at least one codeword. Each column of the ECC-protected SDS 1004 array may be referred to as a C2 codeword. Each SDS 804 is an independent ECC-protected entity, meaning that the C1 ECC parity 1200 and C2 ECC parity 1202 of an SDS 804 protect only the SDS 804. The DS 1008 includes "S" SDSs 1004, each containing N=d2+p2 CWIs. Therefore, the number of CWIs in the DS 808 is Q=N×S.

[0107] FIG. 13 is a flowchart illustrating a method 1300 for reducing rewrite overhead in a sequential access storage system, consistent with some embodiments. In some embodiments, method 1300 may be performed via logic integrated into, executable by, or integrated into and executable by a controller. In operation 1305, the controller may cause a write transducer to write a DS to the sequential access medium. The DS may comprise multiple encoded data blocks. In operation 1310, the controller may cause a read transducer to read the DS (e.g., the encoded data block) written by the write transducer. Then, in operation 1315, the controller may measure and / or estimate a write quality metric by comparing the encoded data block written by the write transducer with the encoded data block read by the read transducer in a read-while-write process.

[0108] Optionally, in operation 1320, the controller may receive one or more thresholds from a system administrator, such as, for example, threshH, threshB, and / or threshS, which may be used to either tune the system to optimize for relatively higher capacity or to tune the system to optimize for relatively higher reliability.

[0109] In operation 1325, the controller may classify each of a plurality of encoded data blocks on the sequential access medium into one of at least three classes of write quality. The at least three classes of write quality may include a hard rewrite class, in which rewriting is required to prevent data loss, a soft rewrite class, in which rewriting is desirable but not necessary, and a no rewrite class, in which rewriting is not necessary or desired. An encoded data block may be classified into the hard rewrite class if the number of run-length limited (RLL) decoding errors is greater than a first predetermined threshold, threshH, and either: (i) the number of byte errors is greater than a second predetermined threshold, threshB; or (ii) a decoding error (uncorrectable codeword) is detected. An encoded data block may be classified into the soft-rewrite class if at least one condition is met from the group of conditions consisting of: (i) the encoded data block has at least one codeword for which the number of RLL decoding errors is greater than a third predetermined threshold, threshS; and (ii) the encoded data block has at least one codeword for which the number of byte errors is greater than a second predefined threshold, threshB.

[0110] In operation 1330, the controller may cause the write transducer to selectively rewrite some of the encoded data blocks in a rewritten area of ​​the sequential access media based at least in part on the write-quality class. In some embodiments, at least some of the encoded data blocks in the soft-rewrite class are not rewritten.

[0111] Although the present invention has been described in detail with reference to specific examples thereof, it may be embodied in other specific forms without departing from its essential spirit or attributes. For example, the present invention may be a system, method, and / or computer program product at any possible level of technical detail of integration. A computer program product may include one or more computer-readable storage media having computer-readable program instructions for causing a processor to perform aspects of the present invention. The computer-readable program instructions may be stored and executed in a single computer, or may be divided among different computers, at the same or different locations for storage and execution.

[0112] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, 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 versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or raised structures in grooves in which instructions are recorded, and any suitable combination of the foregoing. Computer-readable storage medium, as used herein, should not be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted through a wire.

[0113] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may comprise copper transmission cables, optical fiber transmissions, 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 transfers the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

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

[0115] 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, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium having instructions stored thereon has an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

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

[0117] Additionally, some embodiments may be delivered as part of a service engagement with a client company, nonprofit organization, government agency, internal organizational structure, or the like. Aspects of these embodiments may include configuring a computer system to perform some or all of the methods described herein and deploying software, hardware, and web services that implement them. Aspects of these embodiments may also include analyzing client behavior, generating recommendations in response to the analysis, building a system that implements some of the recommendations, integrating the system into existing processes and infrastructure, metering use of the system, allocating costs to users of the system, and billing for use of the system.

[0118] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions, that implement the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be realized as a single step and executed concurrently, substantially concurrently, partially, or fully in a time-overlapping manner, or the blocks may possibly be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware and computer instructions.

[0119] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions. The flowcharts and block diagrams in the figures also illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions that implement the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by special-purpose hardware-based systems that perform the specified functions or operations or execute a combination of special-purpose hardware and computer instructions.

[0120] Any particular program terminology used in this description is for convenience only, and the present invention should not be limited to use solely in any particular application specified and / or implied by such terminology. Thus, for example, routines executed to implement embodiments of the present invention may be referred to as a "program," "application," "server," or other meaningful terminology, whether implemented as part of an operating system or as a particular application, component, program, module, object, or sequence of instructions. Indeed, other alternative hardware and / or software environments may be used without departing from the scope of the present invention.

[0121] Additionally, systems according to various approaches may include a processor and logic integrated into and / or executable by the processor, the logic configured to perform one or more of the process steps described herein. The processor may be any of the configurations described herein, such as a discrete processor or processing circuitry including many components, such as processing hardware, memory, I / O interfaces, etc. By integrated, it is meant that the processor has logic embedded in it as hardware logic, such as an application-specific integrated circuit (ASIC), FPGA, etc. By executable by the processor, it is meant that the logic is hardware logic; software logic, such as firmware; part of an operating system; part of an application program; or some combination of hardware and software logic that is accessible by the processor and configured to cause the processor to perform some function when executed by the processor. Software logic may be stored in 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 a software processor module and / or hardware processor, such as an ASIC, FPGA, central processing unit (CPU), integrated circuit (IC), graphics processing unit (GPU), etc.

[0122] The presently described embodiments are therefore to be considered in all respects as illustrative and not restrictive, and reference should be made to the appended claims to determine the scope of the invention.

Claims

1. magnetic head; a controller communicatively coupled to the magnetic head, the controller comprising: writing a data set to a sequential access medium using the magnetic head, the data set having a plurality of encoded data blocks; classifying the encoded data blocks into three or more classes of write quality; and Selectively rewriting one or more of the encoded data blocks in a rewrite area of ​​the sequential access medium based at least in part on the write-quality class. is adapted to perform A system comprising:

2. The system of claim 1 , wherein the controller is further adapted to measure a write quality metric for each of the encoded data blocks.

3. 10. The system of claim 1, wherein the magnetic head comprises at least one write transducer and at least one read transducer adapted for parallel data transfer.

4. The system of claim 1 , wherein each of the encoded data blocks has codewords in an interleaved or non-interleaved arrangement.

5. 5. The system of claim 4, wherein each codeword includes a predetermined number of symbols having a size of at least 8 bits for each symbol.

6. 2. The system of claim 1, wherein the three or more classes of write quality comprise a hard rewrite class where rewriting is required to prevent data loss, a soft rewrite class where rewriting is desirable but not necessary, and a no rewrite class where rewriting is not necessary or desired.

7. The encoded data block is the number of run-length limited decoding errors is greater than a first predetermined threshold; and The following, namely: if the number of byte errors is greater than a second predetermined threshold; or If an uncorrectable error is detected The system according to claim 6, wherein the system is classified into the hard rewrite class if either of the following is true:

8. The encoded data block is The encoded data block is not classified into the hard rewrite class; and the encoded data block having at least one codeword for which the number of run-length-limited decoding errors is greater than a third predetermined threshold; It is classified into the soft rewrite class under the condition The system of claim 7.

9. The system of claim 8 , wherein the third predetermined threshold is greater than the first predetermined threshold.

10. The encoded data block is The encoded data block is not classified into the hard rewrite class; and the encoded data block having at least one codeword for which the number of byte errors is greater than a second predefined threshold; It is classified into the soft rewrite class under the condition The system of claim 7.

11. The system of claim 6 , wherein at least some of the encoded data blocks in the soft-rewrite class are not rewritten.

12. 1. A method for reducing rewrite overhead in a sequential access storage system, the method comprising: writing a data set to a sequential access medium using a magnetic head, wherein the data set comprises a plurality of encoded data blocks; classifying each of the plurality of encoded data blocks on the sequential access medium into one of at least three classes of write quality; and selectively rewriting the encoded data blocks in a rewrite area of ​​the sequential access medium based at least in part on the write-quality class. A method comprising:

13. The magnetic head comprises a write transducer and a read transducer, and the method further comprises: writing at least one of the plurality of encoded data blocks with the write transducer; reading, by the read transducer, the at least one encoded data block written by the write transducer; and measuring a write quality metric, wherein the measuring comprises comparing the at least one encoded data block written by the write head to the at least one encoded data block read by the read transducer in a read-while-write process; The method of claim 12, comprising:

14. The at least three classes of write quality include a hard rewrite class that requires rewriting to prevent data loss; Soft-rewrite classes, where rewriting is desirable but not necessary; and No-rewrite classes where rewriting is not necessary or desired The method of claim 12 comprising:

15. The encoded data block is the number of run-length limited decoding errors is greater than a first predetermined threshold; and The following, namely: the number of byte errors is greater than a second predetermined threshold; or Were any uncorrectable errors detected? Either 15. The method of claim 14, wherein the hard rewrite class is classified under the condition that:

16. The encoded data block is: the encoded data block has at least one codeword for which the number of RLL decoding errors is greater than a third predetermined threshold; and the encoded data block having at least one codeword in which the number of byte errors is greater than a second predefined threshold; 16. The method of claim 15, wherein classification into the soft-rewrite class is conditional on whether at least one condition is met from a group of conditions consisting of:

17. 17. The method of claim 16, further comprising adjusting the first predetermined threshold to optimize for higher capacity.

18. 17. The method of claim 16, further comprising adjusting the first predetermined threshold to optimize for higher reliability.

19. The method of claim 14 , wherein at least some of the coded data blocks in the soft rewriting class are not rewritten.

20. 1. A computer program product comprising a computer-readable storage medium having program instructions embodied thereon, the program instructions causing an apparatus to: writing a data set to a sequential access medium using a magnetic head, wherein the data set comprises a plurality of encoded data blocks; classifying each of the plurality of encoded data blocks on the sequential access medium into one of at least three classes of write quality; and Selectively rewriting the encoded data blocks in a rewrite area of ​​the sequential access medium based at least in part on the write-quality class. a computer program product executable by said device to cause said device to perform the steps of:

21. The at least three classes of write quality include a hard rewrite class that requires rewriting to prevent data loss; Soft-rewrite classes, where rewriting is desirable but not necessary; and No-rewrite classes where rewriting is not necessary or desired 21. The computer program product of claim 20, comprising:

22. a controller; and Logic integrated into, executable by, or integrated into and executable by the controller 12. An apparatus comprising: writing a data set to a sequential access medium using a magnetic head, wherein the data set comprises a plurality of encoded data blocks; classifying each of the plurality of encoded data blocks on the sequential access medium into one of at least three classes of write quality; and Selectively rewriting the encoded data blocks in a rewrite area of ​​the sequential access medium based at least in part on the write-quality class. An apparatus configured to:

23. The at least three classes of write quality include a hard rewrite class that requires rewriting to prevent data loss; Soft-rewrite classes, where rewriting is desirable but not necessary; and No-rewrite classes where rewriting is not necessary or desired 23. The apparatus of claim 22, comprising:

24. The encoded data block is the number of run-length limited decoding errors is greater than a first predetermined threshold; and The following, namely: if the number of byte errors is greater than a second predetermined threshold; or If an uncorrectable error is detected If either of the above is true, the hard rewrite class is established. The encoded data block is The encoded data block is not classified into the hard rewrite class; and the encoded data block having at least one codeword for which the number of run-length-limited decoding errors is greater than a third predetermined threshold; It is classified into the soft rewrite class under the condition 24. The apparatus of claim 23.

25. The encoded data block is the number of run-length limited decoding errors is greater than a first predetermined threshold; and The following, namely: if the number of byte errors is greater than a second predetermined threshold; or If an uncorrectable error is detected If either of the above is true, the hard rewrite class is established. The encoded data block is The encoded data block is not classified into the hard rewrite class; and the encoded data block having at least one codeword for which the number of byte errors is greater than a second predefined threshold; It is classified into the soft rewrite class under the condition 24. The apparatus of claim 23.

Images