Check-pointing of metadata

Description

BACKGROUND

Data Storage Devices (DSDs) are used to record data onto or to reproduce data from a storage media. Metadata such as a translation table is often used by a DSD to keep track of a current location of data by mapping a logical address for the data to a physical address where the data is stored in the DSD.

The translation table is typically stored in a volatile memory to allow quick access to the translation table. In such an arrangement, the translation table can be check-pointed or stored to a non-volatile memory so that it is available across power cycles of the DSD. However, given the generally increasing data capacity of today's DSDs, the size of metadata such as translation tables is increasing. As a result, the amount of space needed to store the metadata in non-volatile memory is greater and the amount of time it takes to check-point the metadata increases.

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 conceptual diagram illustrating an example of blocks of metadata according to an embodiment.

FIG. 3 illustrates an example of a circular buffer storing blocks of metadata according to an embodiment.

FIG. 4 is a flowchart for a metadata check-pointing process according to an embodiment.

FIG. 5 is a flowchart for a metadata check-pointing process according to another 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, the NVM media of DSD 106 may only 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). 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 from an Inside Diameter (ID) portion to an Outside Diameter (OD) portion 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 FIG. 1, disk 150 also includes circular buffer 152 and root area 154. As discussed below in more detail, circular buffer 152 can be used to store data objects or metadata that is updated during operation of DSD 106. The term “metadata” is used generally herein to include information related to operation of a storage media such as information about data stored in the storage media or information obtained during operation of the storage media. Metadata can, for example, indicate a location, structure, history, or contents of data stored in a storage media or can indicate an environmental condition or state of the storage media.

In some embodiments, disk 150 or portions of disk 150 can include Shingle Magnetic Recording (SMR). SMR has recently been introduced as a way of increasing the amount of data that can be stored in a given area on the disk by increasing the number of Tracks Per Inch (TPI) by overlapping tracks on the disk to result in narrow tracks at the non-overlapping portion of the tracks. Although SMR generally increases the recording density of the disk, SMR typically requires that the tracks are sequentially written since a new write to a previously overlapped track could also affect data in an adjacent track.

Due to the sequential writing of SMR, updates to previously written data are typically written in a new location rather than overwriting the previously written data in the same location. A translation table, such as translation table 22, can be used to keep track of a current location for the data since there may be several previous or obsolete versions of the data on disk 150.

Translation table 22 is stored in volatile memory 140 to allow quick access to translation table 22. As discussed in more detail below, translation table 22 is check-pointed or stored to non-volatile memory such as disk 150 or solid-state memory 128 so that it is available across power cycles of DSD 106.

However, due to the large size of translation table 22, it may take a significant amount of time to save it to non-volatile memory and may slow performance of host 101. To help address these concerns, the present disclosure provides for the storing of portions of metadata or blocks of metadata in circular buffer 152 that have changed since a previous check-point so as to ordinarily avoid having to check-point a large amount of metadata.

In addition, circular buffer 152 can utilize SMR to increase the amount of metadata that can be check-pointed to circular buffer 152. As noted above, SMR typically requires that tracks are sequentially written since a new write to a previously overlapped track could also affect data in an adjacent track. The data objects or metadata written in circular buffer 152 can be sequentially written toward one end of circular buffer 152 before wrapping back to the beginning of circular buffer 152 to overwrite previously written data objects and metadata.

This sequential writing of circular buffer 152 allows for the use of SMR in circular buffer 152 and therefore a greater space savings on disk 150 in storing data objects or metadata. In addition, the use of SMR in circular buffer 152 allows for circular buffer 152 to be treated similarly to other SMR zones on disk 150 without having to make additional accommodations for a zone of non-overlapping tracks using a conventional write-in-place policy.

Root area 154 stores mapping data identifying locations of the data objects or metadata stored in circular buffer 152. In other embodiments, the location of circular buffer 152 and root area 154 may differ from the locations shown in FIG. 1. For example, circular buffer 152 and root area may be stored more towards an OD or ID portion of disk 150.

In the embodiment of FIG. 1, root area 154 and circular buffer 152 are depicted in close proximity to each other on disk 150. This can allow for quicker updating of root area 154 or quicker access of data objects or metadata in circular buffer 152 since head 136 has less distance to travel between root area 154 and circular buffer 152. In other embodiments, root area 154 and circular buffer 152 may not be in close proximity to each other on disk 150. For example, in an embodiment where disk 150 is part of a disk pack, root area 154 and circular buffer 152 may be on different disk surfaces accessed by different heads 136. In another embodiment, root area 154 may be located in solid-state memory 128.

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.

As with SMR portions of disk 150, solid-state memory 128 may also use a logical to physical mapping for keeping track of the location of data. In this regard, solid-state memory 128 may use an indirection system to map data to various physical locations in the storage media of solid-state memory 128 to provide for wear leveling. Such wear leveling can ordinarily prolong the service life of solid-state memory 128 by providing a more even usage of the storage media in solid-state memory 128. However, the indirection system of solid-state memory 128 generates additional metadata such as a logical to physical mapping that can be stored in translation table 22.

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 of DSD 106 for execution by controller 120, or data used in executing firmware of DSD 106.

As shown in the embodiment of FIG. 1, volatile memory 140 stores translation table 22, which can provide a mapping between logical addresses (e.g., Logical Block Addresses (LBAs)) used by host 101 and physical locations (e.g., Physical Block Addresses (PBAs)) indicating physical locations on disk 150 or in solid-state memory 128. As discussed in more detail below, a back-up copy of translation table 22 or a portion of translation table 22 is stored in circular buffer 152. The circular buffer 152 is updated to account for changes to translation table 22 as stored in volatile memory 140. In other embodiments, circular buffer 152 may store other data objects or metadata in addition to or without translation table 22.

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.

Translation Table Example

FIG. 2 is a conceptual diagram illustrating an example of blocks of metadata according to an embodiment. In the example of FIG. 2, translation table 22 has been logically divided into blocks A to H of metadata. Each of blocks A to H represent data stored in DSD 106 that is associated within a range of LBAs from translation table 22 as shown in FIG. 2. Although not shown in FIG. 2, translation table 22 can also include PBAs, ranges of PBAs, or PBA offsets associated with each LBA range.

In different embodiments, other metadata besides translation table 22 may be logically divided into blocks of metadata. Such metadata may include, for example, information indicating a structure, history, or contents of data or can indicate an environmental condition or state of the storage media.

In addition, FIG. 2 includes an indication of whether or not a change has been made in a particular block of metadata. In the example of FIG. 2, a flag indicating whether a change has been made for each block may be stored as a part of translation table 22 in volatile memory 140 or may be kept in another location such as in solid-state memory 128. As shown in FIG. 2, changes have been made to blocks B, E, and F, as indicated by their flags being set to “1.” These changes may result from the performance of write commands or maintenance operations for data in the range of LBAs associated with the block. The flags may be reset to “0” after the metadata for the changed blocks of metadata have been stored to non-volatile memory (i.e., check-pointed). Other embodiments may use a different indication of whether a particular block has changed since a last check-pointing of the metadata.

As discussed in more detail below, by keeping track of the portions of translation table 22 that have changed, it is ordinarily possible to reduce the time and resources needed to check-point or store translation table 22 to non-volatile memory such as disk 150 or solid-state memory 128. This can be accomplished by only check-pointing or storing the portions of translation table 22 that have changed without having to check-point or store all of translation table 22. As the amount of data stored in DSD 106 increases, the size of translation table 22 generally increases to account for the locations of the data and the advantage of only saving the changed blocks becomes more significant.

Check-Pointing Examples

FIG. 3 illustrates an example of circular buffer 152 storing blocks A to H of metadata from FIG. 2 in respective blocks 3 to 13 of circular buffer 152 according to an embodiment. Writing in circular buffer 152 can begin at one block in circular buffer 152 and continue sequentially until the end of circular buffer 152 is reached before resuming writing back at the beginning of circular buffer 152.

Data objects A to H can include data objects or metadata that is stored in volatile memory 140 that is changed during the operation of DSD 106. One example of such data, can include translation table 22 or portions of translation table 22. In this example, translation table 22 may be updated with new physical addresses when data is rewritten on disk 150 or solid-state memory 128. Translation table 22 is updated in volatile memory 140 and changed blocks of translation table 22 are later stored in circular buffer 152 to provide locations of data upon a startup of DSD 106.

As shown in FIG. 3, updated or changed blocks B, E, and F are rewritten in circular buffer 152 so as to follow a sequential writing of circular buffer 152 in accordance with SMR. In this regard, updated or changed blocks of metadata can be written at head location 302 in circular buffer 152. The cross-hatched versions of blocks B, E, and F indicate a previous version of a metadata block stored at circular buffer blocks 4, 7, and 8, respectively. Although FIG. 3 depicts one example order for rewriting a more recent version of metadata blocks B, F, and E, the particular locations or order of rewriting the blocks can vary.

To keep track of the new locations of the metadata, controller 120 can update mapping data in root area 154 to identify the new locations for metadata blocks B′, E′, and F′. As noted above, root area 154 can be located on disk 150 as in the embodiment of FIG. 1, or root area 154 may be located in a different storage media such as solid-state memory 128. An example of mapping data stored in root area 154 can be found in co-pending U.S. patent application Ser. No. 14/335,539, filed on Jul. 18, 2014, which is hereby incorporated by reference in its entirety.

The writing of circular buffer 152 continues until block 15 has been written and then writing returns to circular buffer block 0 and advances toward the end of circular buffer 152.

Free space in circular buffer 152 is indicated with X's in blocks 0 to 2 and in blocks 14 and 15. The free space in circular buffer 152 can include previous versions of metadata, such as previous versions of metadata blocks A to H, or empty blocks without data. In other embodiments, the number of circular buffer blocks and metadata blocks stored in circular buffer 152 may differ.

In the example of FIG. 3, circular buffer 152 is sized so as to allow enough space to store a previous version of data objects A to H in addition to the most recent version of data objects A to H. In other words, the size of circular buffer 152 is at least twice the size needed to store data objects A to H. The use of SMR in circular buffer 152 can make such redundancy more practical in terms of available space on disk 150. Circular buffer 152 may also include additional space for overprovisioning or for providing boundary buffers between circular buffer 152 and zones outside of circular buffer 152 on disk 150.

In addition, each of the blocks in circular buffer 152 can be the same size so as to facilitate the relocation of data from one of blocks 0 to 15 to any of the other blocks in circular buffer 152. Controller 120 may pad data or increase a size of data to be stored in circular buffer 152 in order to meet a modular size for each of blocks 0 to 18.

FIG. 4 is a flowchart for a metadata check-pointing process that can be performed by controller 120 according to an embodiment. The process of FIG. 4 can be performed, for example, by controller 120 executing a firmware of DSD 106 or computer-executable instructions stored in volatile memory 140.

In block 402, controller 120 logically divides metadata stored in volatile memory 140 into blocks of metadata. In the example of FIG. 2, this can include dividing translation table 22 into ranges of LBAs.

In block 404, controller 120 identifies at least one block of metadata that has changed during operation of DSD 106. The identification of block 404 may be accomplished through the use of flags as in the example of FIG. 2 or through a different indication that a block has changed since a last check-pointing of the metadata.

In block 406, controller 120 stores the at least one changed block in circular buffer 152 to check-point the changed metadata. By only storing the changed blocks of metadata, it is ordinarily possible to reduce the time and required resources to check-point the metadata.

FIG. 5 is a flowchart for a metadata check-pointing process that can be performed by controller 120 according to an embodiment. The process of FIG. 5 can be performed, for example, by controller 120 executing a firmware of DSD 106 or computer-executable instructions stored in volatile memory 140.

In block 502, controller 120 counts a predetermined number of write commands received from host 101 or waits a predetermined amount of time since not receiving any read or write commands from host 101. In this way, the check-pointing of the metadata can take place after there have been a certain number of changes to the metadata stored in volatile memory 140 or if there is an idle time when DSD 106 is not otherwise servicing read and write commands from host 101.

In block 504, controller 120 identifies at least one block of metadata that has changed during operation of DSD 106. The identification of block 504 may be accomplished through the use of flags as in the example of FIG. 2 or through a different indication that a block has changed since a last check-pointing of the metadata.

In block 506, controller 120 ensures coherency between the at least one changed block of metadata stored in volatile memory 140 and the copy of the at least one changed block being stored in circular buffer 152. In the embodiment of FIG. 5, controller 120 blocks further changes to the at least one changed block of metadata identified in block 504. In other words, changes to the metadata stored in volatile memory 140 are prevented while the metadata is being check-pointed. In one example implementation, performance of a write command can be deferred by temporarily storing the data for the write command in volatile memory 140 until the block of metadata becomes available for changes. In another example, controller 120 may account for changes to be made to the metadata while it is check-pointed and then later update the metadata in volatile memory 140 after check-pointing.

In block 508, controller 120 stores the at least one changed block of metadata in circular buffer 152. When writing the at least one changed block of metadata in circular buffer 152, controller 120 may write the at least one changed block of metadata sequentially in a next available circular buffer block to allow for SMR in circular buffer 152. By using SMR in circular buffer 152, it is ordinarily possible to save space on disk 150 and in some embodiments to simplify operation of DSD 106 by not having to manage both non-overlapping tracks in Conventional Magnetic Recording (CMR) zones and overlapping tracks in SMR zones. In other words, sequential writing in circular buffer 152 can in some embodiments allow controller 120 to treat all of disk 150 similarly as SMR zones.

In block 510, controller 120 updates mapping data in root area 154 to account for storing the at least one changed block of metadata in block 508. As discussed above, the mapping data in root area 154 can identify locations in circular buffer 152 for the metadata or data objects stored in circular buffer 152. In the example where the metadata stored in circular buffer 152 is from translation table 22, the mapping data of root area 154 can be used upon startup of DSD 106 to locate metadata used to rebuild translation table 22 in volatile memory 140 or to recover a previous version of translation table 22.

In block 512, controller 120 clears flags indicating changes to the at least one changed block of metadata stored in block 508. This resets the status of the blocks of metadata to allow for the identification of changed blocks in a subsequent iteration of the metadata check-pointing process. In block 514, controller 120 allows changes to once again be made to the at least one changed block of metadata.

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.