Patent Application
20130342929
This invention relates generally to the field of rotating, data-storage devices, and more particularly, to correcting repeatable run out errors in disk drives.
Rotating data-storage devices, commonly referred to as hard disk drives (HDD), read and write information along concentric tracks formed on disks. To navigate to a particular track on a disk, disk drives may use servo fields on the disk. These fields are utilized by a servo subsystem to position a head over a particular track. Servo writers write the servo fields onto the disk in tracks when the disk drive is manufactured and these fields are then accessed by the disk drive to determine position. Hereinafter, the path defined by the servo fields shall be referred to as the “servo track” to distinguish it from a data track. Ideally, a head following the center of a servo track moves along a perfectly circular path around the disk. In such an ideal case, the servo track and data track would be identical.
In reality, however, as a head attempts to follow a track it will not follow a perfect circular path. Instead, the head will deviate from the desired circular path due to a variety of factors including disk irregularity, disk eccentricity, and/or misalignments of the spindle axis assembly. This deviation from the desired path is referred to as “runout.” Repeatable runout (RRO) refers to deviation that is non-random and occurs with some predictability. During disk drive manufacture, RRO can be measured and corresponding RRO offset values can be determined. Such RRO correction data can be generated for each track, or even each sector, and then stored on the disk within the servo pattern.
There are two types of RRO, synchronous RRO and Non-synchronous RRO. Synchronous RRO has minimal variation from track to track and is predictable. It can usually be easily compensated for through calibration factors applied globally to the entire disk. These global calibration factors are often stored in the reserved area of the disk. Non-synchronous RRO is more problematic because it is unpredictable and varies from track to track. It is corrected through RRO correction data generated for each track or sector and typically stored on the disk in the same area as the servo pattern for each track sector. When the HDD is operational, the correctional data is read and applied in the servo-control loop.
Determining the offset values for each sector and writing the RRO data to the RRO field portion of the individual sector servo patterns is a very time consuming process. Because the data is stored within each track sector, the RRO data takes up disk surface area that could be used to store user data. Typically about 20-50% of the servo sector overhead is for RRO data. Further, the RRO data is also spread out, so there is no efficient way to compress all of the RRO data to save on disk space.
Accordingly there is a need for an improved method to compensate for storing and accessing non-synchronous RRO data.
Preferred embodiments of the present invention are directed at a method of correcting repeatable run out (RRO) errors for a HDD in which RRO data is instead stored in consolidated form within the reserved area of the disk, instead of storing RRO data in the servo patterns for each HDD track or sector. RRO data is preferably stored in reserved area of hard disk drive in compressed form. The compressed RRO data is subsequently read into DRAM in compressed form and then decompressed for use. Predictive techniques determine what compressed RRO-data is needed for upcoming read/write operations.
In some preferred embodiments, shingled magnetic recording (SMR) is utilized with data written in a shingled fashion so that data writes are predictable and deterministic. RRO data, which is used to control write operations, can be prefetched from the reserved area (RA) to dynamic random access memory (DRAM) so that it will be ready when needed. The sequential nature of SMR write operations means that a relatively small data cache can be used. When RRO-data is needed to write specific tracks, data can be decompressed on the fly to reduce latency.
The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter. It should be appreciated by those skilled in the art that the conception and specific embodiments disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims.
The accompanying drawings are not intended to be drawn to scale. In the drawings, each identical or nearly identical component that is illustrated in various figures is represented by a like numeral. For purposes of clarity, not every component may be labeled in every drawing.
In preferred embodiments of the present invention, instead of storing RRO data in the servo patterns for each HDD track or sector, RRO data is instead stored in consolidated form within the reserved area of the disk. RRO data is preferably stored in reserved area of hard disk drive in compressed form. The compressed RRO data is subsequently read into DRAM in compressed form and then decompressed for use. Predictive techniques determine what compressed RRO-data is needed for upcoming read/write operations.
In some preferred embodiments, shingled magnetic recording (SMR) is utilized with data written in a shingled fashion so that data writes are predictable and deterministic. RRO data, which is used to control write operations, can be prefetched from the reserved area (RA) to dynamic random access memory (DRAM) so that it will be ready when needed. The sequential nature of SMR write operations means that a relatively small data cache can be used. When RRO-data is needed to write specific tracks, data can be decompressed on the fly to reduce latency.
As described above, repeatable runout error (RRO) refers to repeating, non-random errors in the servo signal that controls read/write head position in a HDD. Ideally, a head following the center of a servo track moves along a perfectly circular path around the disk.
In reality, however, as a head attempts to follow a track it will not follow a perfect circular path. Instead, the head will deviate from the desired circular path due to a variety of factors including disk irregularity, disk eccentricity, and/or misalignments of the spindle axis assembly.
If the deviation between the desired and actual track positions becomes too large, subsequent read operations may not be able to find the data. Also, subsequent data may actually erase previously written data. Track squeeze, seen within circle 60, occurs when the actual paths of the read/write head gets too close together in adjacent tracks. This can result in demagnetization of track 40 as subsequent track 50 is written.
As described above, at least a portion of the TMR shown in
During manufacturing time, RRO (whether written-in RRO or RRO caused by other factors) can be measured and corresponding RRO offset values can be determined. Such RRO correction data can be generated for each track, or even each sector, and then stored on the disk within the servo pattern. RRO data can be used to generate a correction signal that can be injected into the drive servo-loop to correct imperfections in the concentricity of the drive head path, which is useful to increase performance of the HDD.
During HDD manufacturing, RRO is typically measured and corresponding offset values determined. This is done for each HDD, for each track on every disk, and for each sector ID in each track (for example, each track might be divided into 500 individual sectors). The offset or correction values are stored on the disk in the same area as the servo pattern for each track sector. When the HDD is operational, the correctional data is read and applied in the servo-control loop.
Determining the offset values for each sector and writing the RRO data to the RRO field portion of the individual sector servo patterns is a very time consuming process. A benefit of this known error compensation scheme is that the RRO data is always available for the current data track since it is stored with the servo patterns for each data track. Also, only the current track's or sector ID's RRO data needs to be in DRAM or SRAM at any one time.
There are some significant disadvantages, however, to the current method of storing RRO data alongside the sector servo patterns. Because the data is stored within each track sector, the RRO data takes up disk surface area that could be used to store user data. Typically about 20-50% of the servo sector overhead is for RRO data.
Also, because the RRO data is written sector by sector, the process of encoding the data onto the HDD is relatively slow. Typically in order to write this RRO data to a disk, once a correction value for a track or sector was determined, it would then be written in that same track or sector. The correction value would then have to be checked by reading the value on another disk revolution. Although this additional time is small for any given track or sector, it adds up to a significant amount of time given the increasing capacities of disk drives today. The time expended is even more significant when considered in light of the large numbers of HDDs that are manufactured and sold each year.
Further, the RRO data is also spread out, so there is no efficient way to compress all of the RRO data to save on disk space. Also, smaller amounts of data written at large numbers of locations for a given HDD results in wasted space due to data fragmentation, and associated overheads of starting and ending locations on the disk where such data can be stored.
In contrast, preferred embodiments of the present invention, RRO data is stored within a consolidated area of the disk called the reserved area (also referred to as the maintenance area). The term “reserved area” refers to space on a typical disk drive that is kept in reserve for storing data that is unavailable to the user or to software other than host BIOS code. Certain types of critical information are typically stored in the disk reserved area, including firmware for the HDD, drive state information, log information, etc. This type of critical information is required to operate the disk drive and is used by the operating system or hardware in the operation of the drive.
In some preferred embodiments, at least part of the RRO data can be stored in Write Twice Cache (W2C) regions of the disk. Write Twice Caching use provides a fail-safe in the event of a write failure by utilizing specially arranged reserved portions of disks to write the cached data during HDD idle time before finally writing the data to its intended ultimate disk location. Because the W2C regions are numerous and distributed equally throughout the disk surface, they provide a convenient location to store small collections of RRO data, each for several servo tracks.
Storing RRO data in the reserved area is advantageous for a number of reasons. It allows the RRO data to be written in bulk rather than distributed across the disk. This single collection of data results in less wasted space, consumes less surface area on the disk, and thus increases areal density.
The reserved area on a HDD also typically makes use of error correcting codes (ECC) and cyclic redundancy checks (CRC) that improve readability and reliability of data stored in this area. Where RRO data is written to individual tracks or sectors, the data is more susceptible to read errors caused by, for example, damage to the disk surface or track mis-registration. Various types of error checking can be employed to make sure the correct data is written to the disk and that some types of damage can be corrected. Increased readability also increases performance. Where any type of read error occurs, the next step is to wait for the disk to spin and to try to read the data again. Error checking in the reserve area helps avoid the delays caused by read errors for data stored in each track or sector.
Preferred embodiments of the present invention also provide a decreased manufacturing time. As described above in prior art, when RRO data is distributed among tracks and sectors, the correction value for a given track or sector is first determined, then immediately written to that same track. The data must then be checked on a subsequent disk revolution to make sure the data was successfully written to the track.
By storing the RRO data in the reserved area according to embodiments of the present invention, it is not necessary to immediately write the data to the disk. Instead, as the correction values for tracks and sectors are determined, they can be stored for example in a memory, and then periodically written to the RA in bulk. Also, because the RA preferably has an error checking mechanism, such as CRC and ECC, the step of confirming the write operation by spinning the disk and reading the data can be eliminated, resulting in a non-trivial time savings.
Also, because the RRO data is consolidated in one location, or at least a small number of locations, rather than distributed across the disk, the RRO data can be more efficiently compressed, which will obviously allow the HDD to have a higher capacity for user data. As discussed in greater detail below, any suitable prior art compression algorithm can be used.
Embodiments of the present invention are especially advantageous for use with Shingled Magnetic Recording (SMR) drives, although embodiments of the present invention could also be practiced using Perpendicular Magnetic Recording (PMR) drives or Longitudinal Magnetic Recording (LMR) drives. Shingled Magnetic Recording is based on partially overlapping, or shingling, adjacent tracks, leaving only a relatively small strip of the previous write track untouched. While this strip is a fraction of the feasible write size, it is still sufficiently large to be read with current read heads. As a result, shingled writing can place tracks closer together, and data density within a track can also be increased. Shingled writing is described, for example, by Kasiraj et al., in U.S. Pat. No. 6,967,810, for “System and method for writing HDD depending on direction of head skew,” which is incorporated by reference for all purposes as if fully set forth herein.
The increase in areal density comes at a price, however. Specifically, rewriting a sector on a track that has been shingled over cannot be done without overwriting subsequent (“down-band”) tracks. SMR is thus ideally suited for long, sequential operations, while random writes and deletes are more problematic. Although a variety of strategies have been developed to address SMR's problems with random writes and deletes, it is typically advantageous for data on a shingled disk to be organized into bands of shingled tracks with a non-shingled guard region between bands.
As shown in the schematic of
In the embodiment of
A number of tracks near the MD are also grouped together into regions referred to as E-regions 414. In the HDD of
The HDD surface layout shown in
The RA and W2C regions are preferably unshingled, and therefore have approximately twice the track width as the shingled tracks. RRO correction may not be needed for reading or writing data to these unshingled regions. In some embodiments, the RRO data will be written exclusively in the RA, which has the advantage of relative simplicity.
In other embodiments, the RRO data can be written partially in the RA and partially in one or more W2C regions. In some cases this second option can result in increased performance due to the closer proximity of W2C regions to the I-regions where data is being written using the RRO corrections that are obtained from the W2C regions. The data reliability of this option is somewhat lower, however, due to potential Far Track Interference (FTI) and Adjacent Track Interference (ATI), as write operations to the W2C over time may disturb the stored RRO correction values.
Finally, in some embodiments, the RRO data can be written entirely in the RA and partially in the W2C. This option is more complex, but highly reliable. Under this embodiment, the RRO header and data information can be stored in the RA, while the RRO data information can also be stored distributedly in the W2C. In the event of any FTI or ATI issues, backup copies of data stored in the RA can be used to refresh the data in the W2C by rewriting the data.
During HDD operation, in order to make use of the RRO data stored in the RA or W2C areas, the data is preferably read into DRAM so it is accessible to control the HDD head positioning. Reading the RRO data directly from the RA before a read/write operation at each data track would typically have an unacceptable I/O latency. In most cases, the amount of RRO data will be too large to be stored in the DRAM cache at one time. As a result, it will usually be desirable to cache only selective portions of the RRO data in DRAM at any one time. This type of selective caching works particularly well for SMR because the sequential nature of the shingled recording process means that the tracks in which data will be written are known ahead of time. For example, when writing to track_N, the RRO data for track_N+1 can be located and loaded into DRAM.
For non-SMR drives, it would be desirable to make use of various known predictive techniques to determine what RRO data needs to be loaded into DRAM. For example, various types of scheduling algorithms such as rotational position optimization (RPO) are commonly used to make read/write operations more efficient. A common feature of many such scheduling algorithms is a queue of scheduled read/write operations organized to make the disk operation more efficient. Such a queue of upcoming read/write operations can also be used to determine which RRO data should be pre-loaded into DRAM so that it will be available when the read/write command is executed. Obviously, in the same fashion, the queue can be used to determine which data already loaded into DRAM can be evicted to make room for the new data.
In preferred embodiments of the present invention, a Look-Up Table (LUT) can be used to determine the location in the RA for the desired track's or sector's RRO data.
When the RRO data for a new track or sector needs to be loaded into DRAM (determined for example as described above) the RA LUT will be used to determine the location of the desired data in the RA. The data can then be loaded and placed into DRAM. When the desired data is actually placed into DRAM, preferably an entry will be made into the DRAM LUT, which reflects the precise location of the data loaded into DRAM. Once the RRO data for a track or sector is ready to be used, the DRAM LUT can be accessed to determine the data location, then the desired RRO data can be read or decompressed from DRAM and injected into the drive servo-loop to correct the drive's head positioning.
In preferred embodiments of the present invention, the RRO data can be stored in the RA in compressed form to further save disk storage space. Preferably, the compensation data is stored and compressed as time-domain compensation values. There are a large number of well known compression algorithms that can be applied to compression/decompression of time-domain compensation values.
In some preferred embodiments, for example, the RRO data can be compressed using a delta encoding scheme, which stores only the difference between samples along with an initial sample value. A limited set of delta values are allowed, and these values are encoded using a fixed Huffman code. The actual compression algorithm will be implemented in firmware for maximum flexibility. As will be appreciated by those of ordinary skill in the art, selecting a compression level requires a trade-off between amount of data storage required and the RRO data fidelity. Lower compression levels result in greater amounts of stored data, while at higher compression levels the data takes up less room but greater error is introduced into the decompressed data.
Preferably, tracks are grouped into RRO bundles of several (e.g. 16 or 32) tracks to improve memory efficiency. LUT entries can indicate the starting and ending addresses of each group of tracks. In some preferred embodiments, the data stored in the RA can be indexed with a file ID header that points to locations where the RRO bundles are stored. This RA ID header (RID) includes each bundle's starting offset address (from the beginning of the storage area) and the length of the specific RRO bundle. The stored RRO data is contained in a separate storage area, with the data for each bundle including LUT data and compressed data. An example of this type of data format is shown in
Once the compressed data is retrieved from the RA and stored in DRAM, a hardware based decompression engine can be invoked to pull compressed data out of DRAM, decompress the specified track, and place the RRO information into a memory mapped SRAM, according to preferred embodiments. The particular compression algorithm used can be implemented in software.
The preferred decompression engine relies on properly formatted data placed in two regions of DRAM space. These regions are the look-up table region and the compressed data region. The look-up table contains entries that point to groups of tracks within the compressed data region. The compressed data region contains compressed RRO data for groups of tracks. The decompression engine, once properly configured and enabled, will fetch an entry out of the look-up table that corresponds to the group associated with the selected track and head. This entry gives the engine the compression header, such as type and size, of the group and the offset into the compressed data region where the group is located. After the offset and size of the group's compressed data is calculated, the engine begins fetching data from the compressed data region and placing it into a cache. The decompression core is activated and it begins pulling data out of the cache and decompressing. Once it reaches the specified track within the group, the decompressed data is placed into an output buffer. After the entire track is decompressed, the output buffer can be flagged as valid, and the engine can shut down.
The amount of time required for a decompression operation will vary based on the following factors.
If not, a suitable DRAM location may first be selected for caching the data. The Firmware will then request the LUT entry. If the LUT entry does not exist, the Firmware will then read the RA ID header (RID) and then locate the appropriate LUT or RRO bundle, comprised of LUT and RRO data. Once the LUT entry exists, the Firmware will use the LUT to index into DRAM (710) to find the location of the target RRO data (712). As described above, in some instances RRO data may also be stored in W2C, in which case the appropriate data can be retrieved from W2C. The resultant RRO data can then be cached into DRAM at the appropriate address. If a previous RRO bundle's data is currently in DRAM, the new RRO bundle's data will overwrite it.
Once the desired compressed RRO data is available in DRAM, the decompression engine will then be started (714). In the flowchart of
The process can then continue with the next data location to be decompressed 724, which returns the process back to step 706, or the decompression hardware can shutdown (726). Significantly, the processes of fetching compressed data to DRAM and of decompressing the RRO data can overlap with other steps in the process. Preferably, before the system has finished the read/write operation at one track, the RRO data for the next read/write location has already been retrieved from the RA to DRAM and has been decompressed with the relevant RRO data placed into the SRAM output buffer for access by the servo microprocessor.
Embodiments of a read/write head 110 may be moved across the disk surface by an actuator assembly 106, allowing the head 110 to read and/or write magnetic data to a particular track 113. The actuator assembly 106 may pivot on a pivot 114. The actuator assembly 106 may form part of a closed loop feedback system, known as servo control loop, which dynamically positions the read/write head 110 to compensate for thermal expansion of the magnetic recording media 111 as well as vibrations and other disturbances or irregularities. Also involved in the servo control system is a complex computational algorithm executed by a microprocessor, digital signal processor, or analog signal processor 116 that receives data address information from a computer, converts it to a location on the disk 111, and moves the read/write head 110 accordingly.
To reposition a read/write head, a set point signal 412 is input by a controller (not shown). Based on the set point signal, the controller generates an actuator current signal, which is input to the actuator assembly 106. The actuator current signal drives the voice coil motor (not shown), which moves the read/write head 110 to a position on the disk 111. The read/write head 110 typically includes a sensor (not shown) for reading servo data on a servo track. The sensor provides an actual position signal that is indicative of the actual position of the head relative to the disk. The actual position signal is directly fed back to adjust the set point signal via the servo loop.
In a typical hard disk drive system, read/write heads 110 periodically reference servo patterns recorded on the disk to ensure accurate head 110 positioning. Servo patterns may be used to ensure a read/write head 110 follows a particular track 113 accurately, and to control and monitor transition of the head 110 from one track to another. Upon referencing a servo pattern, the read/write head 110 obtains head position information that enables the control circuitry 116 to subsequently realign the head 110 to correct any detected error.
As described above, in a typical prior art HDD, RRO data can also be written along with the servo patterns or servo sectors. This RRO data can be accessed for each track or sector to compensate for RRO present during the HDD manufacturing process.
This written description uses examples to disclose the embodiments, including the best mode, and also to enable those of ordinary skill in the art to make and use the invention. The patentable scope is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal languages of the claims.
Note that not all of the activities described above in the general description or the examples are required, that a portion of a specific activity may not be required, and that one or more further activities may be performed in addition to those described. Still further, the order in which activities are listed are not necessarily the order in which they are performed.
In the foregoing specification, the concepts have been described with reference to specific embodiments. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of invention.
As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of features is not necessarily limited only to those features but may include other features not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive-or and not to an exclusive-or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).
Also, the use of “a” or “an” are employed to describe elements and components described herein. This is done merely for convenience and to give a general sense of the scope of the invention. This description should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise.
Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any feature(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature of any or all the claims.
After reading the specification, skilled artisans will appreciate that certain features are, for clarity, described herein in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features that are, for brevity, described in the context of a single embodiment, may also be provided separately or in any subcombination. Further, references to values stated in ranges include each and every value within that range.
