Data management for data storage device with different track density regions

Abstract

Managing data stored in a Data Storage Device (DSD) including at least one disk for storing data. Data is written in a first region of the at least one disk with a first track density. A frequency of access is determined for the data written in the first region, and the frequency of access is compared to a threshold. Based on the comparison, a copy of the data written in the first region is written in a second region of the at least one disk with a second track density different than the first track density.

Description

BACKGROUND

Data Storage Devices (DSDs) are often used to record data on or to reproduce data from a recording media. As one type of DSD, a disk drive can include a rotating magnetic disk and a head actuated over the disk to magnetically write data to and read data from the disk. Such disks include a plurality of radially spaced, concentric tracks for recording data.

Shingled Magnetic Recording (SMR) has been introduced as a way of increasing the amount of data that can be stored in a given area on a disk by increasing the number of Tracks Per Inch (TPI). SMR increases TPI by using a relatively wide shingle write head to overlap tracks like roof shingles. The non-overlapping portion then serves as a narrow track that can be read by a narrower read head.

Although a higher number of TPI is ordinarily possible with SMR, the higher track density can create additional problems. For example, the closer spacing of tracks in an SMR region can worsen Adjacent Track Interference (ATI) where the writing of data on an adjacent track negatively affects the data written on a target track. One way of approaching this problem includes Inter-Track Interference Cancellation (ITIC) where data is read in the adjacent track to account for its effect in the target track. However, since ITIC typically involves additional reading and accounting for data in the adjacent track, more processing resources are usually consumed in addition to either the additional time to read the adjacent track or the additional cost of providing an extra read head to read the data in the adjacent track.

Another problem encountered with SMR involves Wide Area Track Erasure (WATER). WATER results in data being erased from adjacent tracks near a track being written due to interference from the magnetic field of the write head. The problems caused by WATER are exacerbated when tracks are repeatedly rewritten. DSDs using SMR are ordinarily more susceptible to WATER than conventional disk drives due to the combination of narrower tracks and a wider shingle write head having a stronger magnetic field.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the embodiments of the present disclosure will become more apparent from the detailed description set forth below when taken in conjunction with the drawings. The drawings and the associated descriptions are provided to illustrate embodiments of the disclosure and not to limit the scope of what is claimed.

FIG. 1 is a block diagram depicting a Data Storage Device (DSD) according to an embodiment.

FIG. 2 is a flowchart for a data management process according to an embodiment.

FIG. 3 is a flowchart for a data management process where less frequently accessed data is copied from a region of lower track density to a region of greater track density according to an embodiment.

FIG. 4A is a flowchart for an Inter-Track Interference Cancellation (ITIC) operation according to an embodiment.

FIG. 4B is a flowchart for a refresh operation according to an embodiment.

FIG. 5 is a flowchart for a data management process where frequently accessed data is copied from a region of higher track density to a region of lower track density according to an embodiment.

FIG. 6 is a flowchart for a data management process where data is copied from a second region back to a first region based on an updated frequency of access according to an embodiment.

DETAILED DESCRIPTION

In the following detailed description, numerous specific details are set forth to provide a full understanding of the present disclosure. It will be apparent, however, to one of ordinary skill in the art that the various embodiments disclosed may be practiced without some of these specific details. In other instances, well-known structures and techniques have not been shown in detail to avoid unnecessarily obscuring the various embodiments.

System Overview

FIG. 1 shows system 100 according to an embodiment that includes host 101 and Data Storage Device (DSD) 106. System 100 can be, for example, a computer system (e.g., server, desktop, mobile/laptop, tablet, smartphone, etc.) or other electronic device such as a digital video recorder (DVR). In this regard, system 100 may be a stand-alone system or part of a network. Those of ordinary skill in the art will appreciate that system 100 and DSD 106 can include more or less than those elements shown in FIG. 1 and that the disclosed processes can be implemented in other environments.

In the example embodiment of FIG. 1, DSD 106 includes both solid-state memory 128 and disk 150 for storing data. In this regard, DSD 106 can be considered a Solid-State Hybrid Drive (SSHD) in that it includes both solid-state Non-Volatile Memory (NVM) media and disk NVM media. In other embodiments, each of disk 150 or solid-state memory 128 may be replaced by multiple Hard Disk Drives (HDDs) or multiple Solid-State Drives (SSDs), respectively, so that DSD 106 includes pools of HDDs or SSDs. In yet other embodiments, DSD 106 may include disk 150 without solid-state memory 128.

DSD 106 includes controller 120 which comprises circuitry such as one or more processors for executing instructions and can include a microcontroller, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), hard-wired logic, analog circuitry and/or a combination thereof. In one implementation, controller 120 can include a System on a Chip (SoC).

Host interface 126 is configured to interface DSD 106 with host 101 and may interface according to a standard such as, for example, PCI express (PCIe), Serial Advanced Technology Attachment (SATA), or Serial Attached SCSI (SAS). Host 101 may include an interface on its end for communicating with DSD 106. As will be appreciated by those of ordinary skill in the art, host interface 126 can be included as part of controller 120.

In the example of FIG. 1, disk 150 is rotated by a spindle motor (not shown). DSD 106 also includes head 136 connected to the distal end of actuator 130, which is rotated by Voice Coil Motor (VCM) 132 to position head 136 in relation to disk 150. Controller 120 can control the position of head 136 and the rotation of disk 150 using VCM control signal 30 and SM control signal 34, respectively.

As appreciated by those of ordinary skill in the art, disk 150 may form part of a disk pack with additional disks radially aligned below disk 150. In addition, head 136 may form part of a head stack assembly including additional heads with each head arranged to read data from and write data to a corresponding surface of a disk in a disk pack.

Disk 150 includes a number of radial spaced, concentric tracks (not shown) for storing data on a surface of disk 150. The tracks on disk 150 may be grouped together into zones of tracks with each track divided into a number of sectors that are spaced circumferentially along the tracks.

As shown in the example of FIG. 1, disk 150 includes first region 152 with a first track density and second region 154 with a second track density. In some implementations, such as those discussed below with reference to FIG. 3, the first track density in first region 152 is less than the second track density in second region 154 such that the centers of tracks in second region 154 are closer together and can store more data in a given area of disk 150. In such implementations, second region 154 may be written using Shingled Magnetic Recording (SMR) such that the tracks in second region 154 overlap, while first region 152 can be written using Conventional Magnetic Recording (CMR) such that the tracks in first region 152 do not overlap. In other implementations where second region 154 has a higher track density, the tracks in both first region 152 and second region 154 may be written using SMR or CMR, but with a higher track density in second region 154.

In other implementations, the first track density in first region 152 is less than the second track density in second region 154 such that the centers of tracks in second region 154 are farther apart and can store less data in a given area of disk 150. In one such implementation, the tracks in first region 152 can be written using SMR with overlapping tracks while the tracks written in second region 154 are written using CMR with non-overlapping tracks. In other implementations where first region 152 has a higher track density, the tracks in both first region 152 and second region 154 may be written using SMR or CMR, but with a higher track density in first region 152.

The example embodiment of FIG. 1 depicts first region 152 in a Middle Diameter (MD) portion of disk 150. In this regard, a region with a lower track density may be located in an MD portion since locating a higher track density region in other portions of disk 150, such as an Outer Diameter (OD) or Inner Diameter (ID) portion, can result in an increased data capacity than locating the higher track density region in an MD portion. In other embodiments, first region 152 and second region 154 may be located in other portions of disk 150 or may have different relative areas on disk 150.

The regions with different track densities may be contiguous regions or may include non-contiguous regions as in the example of FIG. 1, where second region 154 is located on both sides of first region 152. In addition, disk 150 is shown in FIG. 1 as having two regions with different track densities, however, other embodiments may include a different number of regions with different track densities.

In addition to disk 150, the NVM media of DSD 106 also includes solid-state memory 128 for storing data. While the description herein refers to solid-state memory generally, it is understood that solid-state memory may comprise one or more of various types of memory devices such as flash integrated circuits, Chalcogenide RAM (C-RAM), Phase Change Memory (PC-RAM or PRAM), Programmable Metallization Cell RAM (PMC-RAM or PMCm), Ovonic Unified Memory (OUM), Resistance RAM (RRAM), NAND memory (e.g., Single-Level Cell (SLC) memory, Multi-Level Cell (MLC) memory, or any combination thereof), NOR memory, EEPROM, Ferroelectric Memory (FeRAM), Magnetoresistive RAM (MRAM), other discrete NVM chips, or any combination thereof.

In FIG. 1, volatile memory 140 can include, for example, a Dynamic Random Access Memory (DRAM), which can be used by DSD 106 to temporarily store data. Data stored in volatile memory 140 can include data read from NVM media (e.g., disk 150 or solid-state memory 128), data to be written to NVM media, instructions loaded from firmware 16 for execution by controller 120, or data used in executing firmware 16. In this regard, volatile memory 140 in FIG. 1 is shown as temporarily storing firmware 16 which can include instructions for execution by controller 120 to implement the data management processes discussed below.

In operation, host interface 126 receives read and write commands from host 101 via host interface 126 for reading data from and writing data to the NVM media of DSD 106. In response to a write command from host 101, controller 120 may buffer the data to be written for the write command in volatile memory 140.

For data to be stored in solid-state memory 128, controller 120 receives data from host interface 126 and may buffer the data in volatile memory 140. In one implementation, the data is then encoded into charge values for charging cells (not shown) of solid-state memory 128 to store the data.

In response to a read command for data stored in solid-state memory 128, controller 120 in one implementation reads current values for cells in solid-state memory 128 and decodes the current values into data that can be transferred to host 101. Such data may be buffered by controller 120 before transferring the data to host 101 via host interface 126.

For data to be written to disk 150, controller 120 can encode the buffered data into write signal 32 which is provided to head 136 for magnetically writing data to the surface of disk 150.

In response to a read command for data stored on disk 150, controller 120 positions head 136 via VCM control signal 30 to magnetically read the data stored on the surface of disk 150. Head 136 sends the read data as read signal 32 to controller 120 for decoding, and the data is buffered in volatile memory 140 for transferring to host 101.

Data Management Examples

FIG. 2 is a flowchart for a data management process that can be performed by controller 120 executing firmware 16 according to an embodiment. In other embodiments, the process of FIG. 2 can be performed by a processor of host 101 using, for example, a driver or other application executed by host 101, or a logical partitioning of DSD 106. As discussed in more detail below, the process of FIG. 2 allows for data to be copied to a region with a different track density based on the frequency of access of the data.

In block 202, controller 120 controls head 136 to write data in first region 152 with a first track density. The writing of data can be, for example, in response to a host write command received via host interface 126 to write data in a NVM of DSD 106. In other examples, the data may be written in first region 152 as part of a maintenance operation of DSD 106 such as a garbage collection operation where data is relocated from one portion of NVM to another.

In block 204, a frequency of access is determined for the data written in first region 152. The frequency of access can be based on a number of previous read commands to access the data and/or a number of previous write commands to modify the data. In some implementations, host 101 may provide an indication through hinting or assigning a priority to data as to the frequency of access for the data. In other implementations, controller 120 may maintain a table or history of previous read or write commands for particular data so as to determine a frequency of access in block 204.

In block 206, controller 120 compares the frequency of access to a threshold. The threshold may include a total number of accesses or a number of accesses within a predetermined time period. The threshold can be set based on considerations such as, for example, the amount of data capacity available in first region 152 or second region 154 or data usage patterns of DSD 106.

In block 208, controller 120 controls head 136 to write a copy of the data in first region 152 in second region 154 with a track density different than the first track density. As discussed in more detail below with reference to FIGS. 3 and 5, the second track density may be greater or less than the first track density.

In general, more frequently accessed data can be stored in a region with a lower track density to ordinarily avoid additional operations or problems that may be encountered when using a higher track density. In contrast, less frequently accessed data can be stored in a region with a higher track density so as to take advantage of the greater space savings in terms of aerial density of disk 150 that is offered by the higher track density, while reducing the overall cost in performance by storing the more frequently accessed data in a region with a lower track density.

FIG. 3 is a flowchart for a data management process that can be performed by controller 120 executing firmware 16 where second region 154 has a greater track density than first region 152 according to an embodiment. In other embodiments, the process of FIG. 3 can be performed by a processor of host 101 using, for example, a driver or other application executed by host 101, or a logical partitioning of DSD 106.

In block 302, controller 120 controls head 136 to write data in first region 152 with a first track density that is lower than a second track density of second region 154. As with the process of FIG. 2 discussed above, the writing of data can be in response to a host write command or as part of a maintenance operation of DSD 106.

In block 304, controller 120 determines a frequency of access for the data written in first region 152. As with the process of FIG. 2, the frequency of access can be based on a number of previous read commands to access the data and/or a number of previous write commands to modify the data. Controller 120 may determine the frequency of access based on learning on the part of DSD 106 or based on information provided by host 101.

In block 306, controller 120 determines whether the frequency of access is less than the threshold. This can include determining whether a previous number of write accesses or read accesses have reached a particular threshold number of read or write accesses. In other examples, the frequency of access may be expressed as an average number of accesses in a given amount of time such as three accesses per day. If the frequency of access is not less than the threshold in block 306, the process of FIG. 3 ends in block 310.

On the other hand, if the frequency of access is less than the threshold in block 306, controller 120 controls head 136 in block 308 to write a copy of the data in second region 154 with a track density greater than the first track density. The process of FIG. 3 ends in block 310.

In one implementation, the data stored in first region 152 may be invalidated after copying the data to second region 154 to free up space in first region 152. In other implementations, the data stored in first region 152 may be kept as a backup copy. In this regard, copied data in block 308 may be considered cached, relocated or migrated into second region 154.

By not storing frequently accessed data in a region with a greater track density, it is ordinarily possible to reduce the performance impact and consumption of resources involved with accessing data in a region where data is recorded with a higher track density. FIGS. 4A and 4B illustrate two example operations that may be performed more frequently in a region with a higher track density than in a region with a lower track density.

FIG. 4A is a flowchart for an example of an Inter-Track Interference Cancellation (ITIC) operation that can be performed by controller 120 executing firmware 16 according to an embodiment. Controller 120 may be configured to perform the flowchart of FIG. 4A on its own, or in response to a command from host 101. An ITIC operation may need to be performed in cases where a high track density causes the data on an adjacent track to affect data being read on a target track. The refresh operation of FIG. 4A may be triggered on an as-needed basis by errors encountered when reading data or the operation of FIG. 4A may be continually performed as part of reading data in a region with a higher track density. In some embodiments, the ITIC operation may be performed as part of a Two Dimensional Magnetic Recording (TDMR) implementation where multiple read heads are used in head 136 to account for interference when reading data from narrow tracks.

In block 402 of FIG. 4A, controller 120 controls head 136 to read data from a target track. The data in the target track may have been requested in a read command from host 101 or may be read as part of a maintenance operation of DSD 106.

In block 404, controller 120 controls head 136 to read data from a track adjacent to the target track. In a TDMR implementation, this may be performed by reading the data in the target track and the adjacent track at approximately the same time such that blocks 402 and 404 are performed within a single revolution of disk 150. In other implementations, head 136 may read the data from the adjacent track before or after reading the data from the target track during a different revolution of disk 150. In some embodiments, head 136 may read data from two adjacent tracks to account for the effect of data on both sides of the target track.

In yet other embodiments, head 136 may instead re-read the data in the target track without reading data in an adjacent track in block 404. In such embodiments, the target track may be re-read during a subsequent revolution of disk 150 or head 136 may include two read heads arranged in series to provide two read signals from the target track that may be used to reduce the effect of data from an adjacent track.

In block 406, controller 120 accounts for the effect of data in the adjacent track on the data read in the target track. This can be performed, for example, by comparing the data read in the adjacent track with the data read in the target track for a given position along the target track.

As noted above, the ITIC operation of FIG. 4A or similar ITIC operations can typically be performed less in a region with a lower track density. In some embodiments, the ITIC operation may not be performed at all in the region with a lower track density. By storing more frequently accessed data in the region with a lower track density, it is ordinarily possible to conserve processing resources or improve an average time for performing read commands, while still providing for a greater data storage capacity with the region having a higher track density.

FIG. 4B is a flowchart for a refresh operation that can be performed by controller 120 executing firmware 16 according to an embodiment. Controller 120 may be configured to perform the flowchart of FIG. 4B on its own, or in response to a command from host 101. The refresh operation can be performed to help ensure that data is not corrupted due to repeated writing in a particular area of disk 150.

In block 408, controller 120 identifies data that is susceptible to interference from an adjacent track. This can be performed by identifying an area of disk 150, such as a particular track, that has been written to more than a predetermined amount of times. The predetermined number of writes may be set differently for different regions of disk 150 having different track densities. A region with a high track density that is more prone to having data affected by writes in adjacent tracks can have a lower number of predetermined writes in an adjacent track before triggering the refresh operation of FIG. 4B. In contrast, a region with a lower track density can have a higher number of predetermined writes in an adjacent track before triggering the refresh operation of FIG. 4B.

In block 410, controller 120 controls head 136 to rewrite the data identified in block 408 to protect the data from being corrupted by further adjacent writes. The data may be rewritten in the same location on disk 150 or it may be rewritten in a different location.

As with the ITIC operation of FIG. 4A, the refresh operation of FIG. 4B can be performed less, if at all, in a region of lower track density. Storing frequently accessed data in a region with a lower track density therefore conserves the resources of DSD 106 so that data does not need to be rewritten as frequently as in a region with a higher track density.

FIG. 5 is a flowchart for a data management process that can be performed by controller 120 where frequently accessed data is copied from a region of higher track density to a region of lower track density according to an embodiment. In other embodiments, the process of FIG. 5 can be performed by a processor of host 101 using, for example, a driver or other application executed by host 101, or a logical partitioning of DSD 106.

In block 502, controller 120 controls head 136 to write data in first region 152 with a first track density that is higher than a second track density of second region 154.

In block 504, controller 120 determines a frequency of access for the data written in block 502. The frequency of access can be based on a number of previous read commands to access the data and/or a number of previous write commands to modify the data. In some implementations, host 101 may provide an indication through hinting or assigning a priority to data as to the frequency of access for the data. In other implementations, controller 120 may maintain a table or history of previous read or write commands for particular data so as to determine a frequency of access in block 504.

In block 506, controller 120 compares the frequency of access to a threshold. The threshold may include a total number of accesses or a number of accesses within a predetermined time period. The threshold can be set based on design considerations such as, for example, the amount of data capacity available in first region 152 or second region 154, or data usage patterns of DSD 106.

In block 508, controller 120 controls head 136 to write a copy of the data in first region 152 in second region 154 with a track density less than the first track density. In the example of FIG. 5, data is first written to a region of higher track density and is then relocated or copied to a region of lower track density if the data is frequently accessed. The data left in first region 152 may then be invalidated so that it can be overwritten or the data may be kept in first region 152 as a backup copy. In this regard, copied data in block 508 may be considered cached, relocated or migrated into second region 154.

FIG. 6 is a flowchart for a data management process that can be performed by controller 120 where data is copied from second region 154 back to first region 152 based on an updated frequency of access according to an embodiment. In other embodiments, the process of FIG. 6 can be performed by a processor of host 101 using, for example, a driver or other application executed by host 101, or a logical partitioning of DSD 106. The process of FIG. 6 may take place after any of the processes of FIG. 2, 3, or 5 above. In some implementations, the process of FIG. 6 may be triggered by a new access of data stored in second region 154 or by new information provided by host 101. In other implementations, the process of FIG. 6 may be performed periodically after a predetermined amount of time or after a predetermined amount of data has been stored in DSD 106.

In block 602, controller 120 determines an updated frequency of access for data stored in second region 154 that is no longer stored in first region 152. The updated frequency of access can be based on a table or history maintained by controller 120 relating to previous read commands and/or previous write commands. In some implementations, the updated frequency of access may be based on an indication from host 101 through hinting or the assignment of a priority to the data.

In block 604, controller 120 compares the updated frequency of access to the threshold. The threshold of block 604 can be the same threshold as used above in FIG. 2, 3, or 5, or the threshold may have a different value for data to be copied back to first region 152 from second region 154. The comparison can be a check as to whether the updated frequency of access is less than, equal to, or greater than the threshold.

In block 606, controller 120 controls head 136 based on the comparison in block 604 to write a copy of the data in first region 152 with a track density different from the track density of second region 154. As discussed above with reference to FIG. 2, the first track density of first region 152 can be less than or greater than the second track density of second region 154.

Other Embodiments

Those of ordinary skill in the art will appreciate that the various illustrative logical blocks, modules, and processes described in connection with the examples disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. Furthermore, the foregoing processes can be embodied on a computer readable medium which causes a processor or computer to perform or execute certain functions.

To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, and modules have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Those of ordinary skill in the art may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

The various illustrative logical blocks, units, modules, and controllers described in connection with the examples disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

The activities of a method or process described in connection with the examples disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. The steps of the method or algorithm may also be performed in an alternate order from those provided in the examples. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable media, an optical media, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an Application Specific Integrated Circuit (ASIC).

The foregoing description of the disclosed example embodiments is provided to enable any person of ordinary skill in the art to make or use the embodiments in the present disclosure. Various modifications to these examples will be readily apparent to those of ordinary skill in the art, and the principles disclosed herein may be applied to other examples without departing from the spirit or scope of the present disclosure. The described embodiments are to be considered in all respects only as illustrative and not restrictive and the scope of the disclosure is, therefore, indicated by the following claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. A Data Storage Device (DSD), comprising: at least one disk for storing data including a first region and a second region;at least one head for reading and writing data on the at least one disk; anda controller configured to: control the at least one head to write data in the first region with a first track density;determine a frequency of access for the data written in the first region;compare the frequency of access for the data written in the first region to a threshold; andbased on the comparison, control the at least one head to write a copy of the data written in the first region in the second region with a second track density different than the first track density.

2. The DSD of claim 1, wherein the frequency of access is based on a number of previous read commands to access the data.

3. The DSD of claim 1, wherein the frequency of access is based on a number of previous write commands to modify the data.

4. The DSD of claim 1, wherein the frequency of access is based on information provided from a host in communication with the DSD.

5. The DSD of claim 1, wherein the controller is further configured to: determine whether the frequency of access for the data written in the first region is less than the threshold; andif the frequency of access is less than the threshold, control the at least one head to write a copy of the data written in the first region in the second region with the second track density, wherein the second track density is greater than the first track density.

6. The DSD of claim 1, wherein the controller is further configured to: determine whether the frequency of access for the data written in the first region is greater than or equal to the threshold; andif the frequency of access is greater than or equal to the threshold, control the at least one head to write a copy of the data written in the first region in the second region with the second track density, wherein the second track density is less than the first track density.

7. The DSD of claim 1, wherein the controller is further configured to adjust the threshold based on a remaining available data capacity of the first region.

8. The DSD of claim 1, wherein the second track density is greater than the first track density, and wherein the controller is further configured to perform an Inter-Track Interference Cancellation (ITIC) operation for data stored in the second region without performing the ITIC operation for data stored in the first region, and in performing the ITIC operation, the controller is further configured to: control the at least one head to read data from a target track in the second region;control the at least one head to read data from an adjacent track in the second region that is adjacent the target track; andaccount for an effect of the data in the adjacent track on the data in the target track.

9. The DSD of claim 1, wherein the second track density is greater than the first track density, and wherein the controller is further configured to perform a refresh operation for data stored in the second region without performing the refresh operation for data stored in the first region, and in performing the refresh operation, the controller is further configured to: identify data in the second region that is susceptible to interference from an adjacent track; andcontrol the at least one head to rewrite the data that is susceptible to interference from the adjacent track on the at least one disk.

10. The DSD of claim 1, wherein the first track density is lower than the second track density and the first region is located in a middle diameter portion of the at least one disk.

11. The DSD of claim 1, wherein the controller is further configured to: determine an updated frequency of access for data written in the second region that is no longer stored in the first region;compare the updated frequency of access to the threshold; andbased on the comparison, control the at least one head to write a copy of the data stored in the second region in the first region with the first track density.

12. A method for managing data stored in a Data Storage Device (DSD) including at least one disk for storing data, the method comprising: writing data in a first region of the at least one disk with a first track density;determining a frequency of access for the data written in the first region;comparing the frequency of access for the data written in the first region to a threshold; andbased on the comparison, writing a copy of the data written in the first region in a second region of the at least one disk with a second track density different than the first track density.

13. The method of claim 12, wherein the frequency of access is based on a number of previous read commands to access the data.

14. The method of claim 12, wherein the frequency of access is based on a number of previous write commands to modify the data.

15. The method of claim 12, wherein the frequency of access is based on information provided from a host in communication with the DSD.

16. The method of claim 12, further comprising: determining whether the frequency of access for the data written in the first region is less than the threshold; andif the frequency of access is less than the threshold, writing a copy of the data written in the first region in the second region with the second track density, wherein the second track density is greater than the first track density.

17. The method of claim 12, further comprising: determining whether the frequency of access for the data written in the first region is greater than or equal to the threshold; andif the frequency of access is greater than or equal to the threshold, writing a copy of the data written in the first region in the second region with the second track density, wherein the second track density is less than the first track density.

18. The method of claim 12, further comprising adjusting the threshold based on a remaining available data capacity of the first region.

19. The method of claim 12, wherein the second track density is greater than the first track density, and wherein the method further comprises performing an Inter-Track Interference Cancellation (ITIC) operation for data stored in the second region without performing the ITIC operation for data stored in the first region, and in performing the ITIC operation, the method further comprises: reading data from a target track in the second region;reading data from an adjacent track in the second region that is adjacent the target track; andaccounting for an effect of the data in the adjacent track on the data in the target track.

20. The method of claim 12, wherein the second track density is greater than the first track density, and wherein the method further comprises performing a refresh operation for data stored in the second region more frequently than for data stored in the first region, and in performing the refresh operation, the method further comprises: identifying data that is susceptible to interference from an adjacent track; andrewriting the data that is susceptible to interference from the adjacent track on the at least one disk.

21. The method of claim 12, wherein the first track density is lower than the second track density and the first region is located in a middle diameter portion of the at least one disk.

22. The method of claim 12, further comprising: determining an updated frequency of access for data written in the second region that is no longer stored in the first region;comparing the updated frequency of access to the threshold; andbased on the comparison, writing a copy of the data stored in the second region in the first region with the first track density.

23. A non-transitory computer readable medium storing computer-executable instructions for managing data stored in a Data Storage Device (DSD) including at least one disk for storing data, wherein when the computer-executable instructions are executed by a controller, the computer-executable instructions cause the controller to: write data in a first region of the at least one disk with a first track density;determine a frequency of access for the data written in the first region;compare the frequency of access for the data written in the first region to a threshold; andbased on the comparison, write a copy of the data written in the first region in a second region of the at least one disk with a second track density different than the first track density.

24. A host in communication with a Data Storage Device (DSD), the host comprising: an interface for communicating with the DSD; anda processor configured to: store data in a first region of at least one disk of the DSD with a first track density;determine a frequency of access for the data stored in the first region;compare the frequency of access for the data stored in the first region to a threshold; andbased on the comparison, store a copy of the data written in the first region in a second region of the at least one disk with a second track density different than the first track density.