Power safe write buffer for data storage device

Description

BACKGROUND

Data Storage Devices (DSDs) are often used to record data onto or to reproduce data from a storage media. One type of storage media includes a rotating magnetic disk where a magnetic head of the DSD can read and write data in tracks on a surface of the disk, such as in a Hard Disk Drive (HDD). Another type of storage media can include a solid-state memory where cells are charged to store data.

In writing data to a disk, a DSD may temporarily store the data in a volatile memory before the data is written to the disk. In some cases, the volatile memory can be used as a write cache to queue or defer write commands received from a host until a more beneficial time from a performance perspective of the DSD. Such a mode of deferring write commands can be referred to as a Write Cache Enable (WCE) mode of performing write commands. In such a WCE example, the DSD may notify the host of the performance of the write command after the write command has been queued in the volatile memory but before the write command is actually performed on the disk. Although this arrangement can ordinarily allow for an improved performance from the perspective of the host, the write commands in the volatile memory are usually lost in the event of an unexpected power loss at the DSD.

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 management of a Power Safe Write Buffer (PSWB) after receiving data from a host according to an embodiment.

FIG. 3 is a flowchart for management of a PSWB after storing PSWB identified data on a disk according to an embodiment.

FIG. 4 is a diagram illustrating a command queue according to an embodiment.

FIG. 5 is a flowchart for a power loss process according to an embodiment.

FIG. 6A illustrates segments of a Non-Volatile Solid-State Memory (NVSM) according to an embodiment.

FIG. 6B illustrates segments of an NVSM according to another embodiment.

FIG. 7 is a flow chart for a power-up process 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 depicts a block diagram of Data Storage Device (DSD) 106 according to an embodiment where DSD 106 includes Non-Volatile Memory (NVM) in the form of rotating magnetic disk 150 and Non-Volatile Solid-State Memory (NVSM) 128. In this regard, DSD 106 can be considered a Solid-State Hybrid Drive (SSHD) since it includes both solid-state and disk media. In other embodiments, each of disk 150 or NVSM 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 and/or SSDs.

DSD 106 includes controller 120 which includes circuitry such as one or more processors for executing instructions and can include a microcontroller, a DSP, an ASIC, an 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, Serial Advanced Technology Attachment (SATA), PCI express (PCIe), Small Computer System Interface (SCSI), 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. Although FIG. 1 depicts the co-location of host 101 and DSD 106, in other embodiments the two need not be physically co-located. In such embodiments, DSD 106 may be located remotely from host 101 and connected to host 101 via a network interface.

In the example of FIG. 1, disk 150 is rotated by a Spindle Motor (SM) 154 and head 136 is positioned to read and write data on the surface of disk 150. In more detail, head 136 is connected to the distal end of actuator 130 which is rotated by Voice Coil Motor (VCM) 132 to position head 136 over disk 150 to read or write data in tracks 152. Servo system 121 controls the rotation of disk 150 with SM control signal 31 and controls the position of head 136 using VCM control signal 30.

DSD 106 also includes NVSM 128 for storing data across power cycles. 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 (non-volatile memory) chips, or any combination thereof.

As shown in FIG. 1, DSD 106 includes volatile memory 140, which can include, for example, a Dynamic Random Access Memory (DRAM). Volatile memory 140 can be used by DSD 106 to temporarily store data. Data stored in volatile memory 140 can include data read from NVM such as disk 150 or NVSM 128, data to be stored in NVM, instructions loaded from DSD firmware 10 for execution by controller 120, and/or data used in executing DSD firmware 10. Volatile memory 140 can also be used to temporarily store data for write commands intended for disk 150.

In the example of FIG. 1, volatile memory 140 also stores Power Safe Write Buffer (PSWB) 12, PSWB count 14, PSWB log 16, command queue 18, and write cache 20. As discussed in more detail below, data included in PSWB 12 is transferred to NVSM 128 in the event of an unexpected power loss of DSD 106. In one implementation, kinetic energy from the rotation of SM 154 can be used to temporarily power NVSM 128 to facilitate the transfer of data from volatile memory 140 to NVSM 128. The transfer of data to NVSM 128 ordinarily prevents loss of the data included in PSWB 12.

In addition, DSD 106 can notify host 101 that write commands for data identified for inclusion in PSWB 12 has been stored before actually storing the identified data on disk 150. This ordinarily allows for an improved performance of DSD 106 in terms of the number of host commands that can be performed in a given period of time (e.g., increased Input/Output Operations Per Second (IOPS)) and a reduced latency in performing the commands from the perspectives of both host 101 and DSD 106. In more detail, more write commands can be queued for performance in command queue 18 (an increased queue depth) which increases IOPS and reduces latency from the perspective of host 101 to allow host 101 to send more write commands to DSD 106. From the perspective of DSD 106, having more commands in command queue 18 can reduce the overall mechanical latency in performing the queued commands by using a Rotational Position Optimization (RPO) algorithm that rearranges the order for performing the commands to reduce the movement of head 136 over disk 150 in performing the commands. The use of PSWB 12 can therefore improve the efficiency in performing write commands, while still protecting the data for the write commands in the event of an unexpected power loss.

In one implementation, data for performing host write commands is stored in write cache 20 and some or all of the data from write cache 20 is identified or marked through the use of a flag or other indicator as being included in PSWB 12. Controller 120 keeps track of the amount of data identified for inclusion in PSWB 12 with the use of PSWB count 14. The amount of data that can be included in PSWB 12 can be based on an amount of data that can be transferred from volatile memory 140 to NVSM 128 after an unexpected power loss. This amount may be based on an energy budget that considers the energy available from the spinning of disk 150 and the energy needed to transfer data from volatile memory 140 to NVSM 128. In one implementation, controller 120 can compare PSWB count 14 to a number of sectors on disk 150 representing a maximum amount of data that could be safely transferred to NVSM 128 in the event of a power loss. In some implementations, use of PSWB 12 is temporarily disabled when the rotation of disk 150 falls below a threshold rotational speed such as during a low speed or a low power mode of disk 150.

In operation, host interface 126 receives host read and write commands from host 101 via host interface 126 for reading data from and writing data to NVM. In response to a write command from host 101, controller 120 may queue the write commands in command queue 18 and buffer the data to be written for the write commands in PSWB 12 or write cache 20.

For data to be written on disk 150, a read/write channel (not shown) of controller 120 may encode the buffered data into write signal 32 which is provided to head 136 for magnetically writing data on disk 150. Servo system 121 can provide VCM control signal 30 to VCM 132 to position head 136 over a particular track 152 for writing the data.

In response to a read command for data stored on disk 150, servo system 121 positions head 136 over a particular track 152. Controller 120 controls head 136 to magnetically read data stored in the track and to send the read data as read signal 32. A read/write channel of controller 120 can then decode and buffer the data into volatile memory 140 for transmission to host 101 via host interface 126.

For data to be stored in NVSM 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 NVSM 128 to store the data.

In response to a read command for data stored in NVSM 128, controller 120 in one implementation reads current values for cells in NVSM 128 and decodes the current values into data that can be transferred to host 101 via host interface 126.

Power Safe Write Buffer Examples

FIG. 2 is a flowchart for management of a PSWB that can be performed by controller 120 executing DSD firmware 10 according to an embodiment. In block 202, controller 120 receives data from host 101 via host interface 126 for storage on disk 150. The received data may form part of a write command from host 101 to store data on disk 150.

In block 204, controller 120 determines whether the received data meets certain eligibility requirements for PSWB 12. Since the capacity of PSWB 12 is limited, controller 120 in one implementation can check the data as it is received for whether the data is eligible for PSWB 12. In one implementation, controller 120 checks whether the received data is larger than a predetermined size that may consume too much space in PSWB.

In another implementation, controller 120 checks in block 204 whether the received data is considered sequential to a certain degree (e.g., sequentially addressed beyond a certain number of logical addresses). If the data is considered sufficiently sequential, the performance benefit of storing the sequential data in PSWB 12 may not be as great as storing other data in PSWB 12 that is to be written in more random locations on disk 150. In other words, the reordering of command queue 18 by an RPO algorithm can have a greater effect on random writes than on sequential writes. Sequentially addressed data can usually be efficiently written with a sequential write such that head 136 does not need to be repositioned to distant portions of disk 150. Other implementations may consider both the size of the received data and whether the data is sequentially addressed to a certain degree. Yet other implementations may consider different eligibility requirements in block 204.

If controller 120 determines in block 204 that the received data does not meet the eligibility requirements for PSWB 12, controller 120 in block 206 excludes the received data from PSWB 12 and identifies the received data for inclusion in write cache 20. Data can be identified or inclusion in write cache 20 with a flag or other indicator of inclusion in write cache 20. In such an implementation, the flag or other indicator can prevent the received data from future inclusion in PSWB 12 in an embodiment where controller 120 can add data from write cache 20 into PSWB 12 as discussed in more detail below with reference to FIG. 3. In other implementations, inclusion of the received data in write cache 20 can be a default such that the absence of a flag or indicator of inclusion in PSWB 12 identifies the received data as included in write cache 20. The process of FIG. 2 then ends in block 214.

If controller 120 determines in block 204 that the received data meets the eligibility requirements (e.g., received data is less than a predetermined size and/or not sequentially addressed), controller 120 determines in block 208 whether there is space available in PSWB 12 for the received data. Controller 120 may compare the size of the received data, for example, in terms of a number of data blocks or a number of sectors and compare the size to an available space in PSWB 12 based on PSWB count 14. In one implementation, PSWB count 14 can provide controller 120 with the amount of data (e.g., a number of data blocks or sectors) already included in PSWB 12. Controller 120 can then compare the PSWB count 14 to a maximum amount of data that can be included in PSWB 12 to determine whether there is room to include the received data in PSWB 12. In other implementations, PSWB count 14 may represent a remaining available space in PSWB 12 rather than the amount of data already included in PSWB 12. If there is not enough room in PSWB 12, the received data is identified for inclusion in write cache 20 in block 211 and the process ends in block 214. This may be accomplished by using a flag or indicator to associate the received data with write cache 20, or the absence of a flag or indicator of inclusion in PSWB 12 can serve in some implementations as identifying the received data for inclusion in write cache 20.

If it is determined in block 208 that there is enough space available in PSWB 12, controller 120 in block 210 identifies the received data for inclusion in PSWB 12 and increments PSWB count 14 to account for the inclusion of the received data in PSWB 12. In block 212, an indication is sent to host 101 to indicate storage of the received data identified for inclusion in PSWB 12 and the process ends in block 214. As noted above, sending this indication can ordinarily improve a performance of system 100 in that host 101 can proceed with sending other write commands to DSD 106 and DSD 106 can make greater use of an RPO algorithm in reordering a larger number of commands in command queue 18.

FIG. 3 is a flowchart for management of a PSWB after storing PSWB identified data on a disk according to an embodiment. In one implementation, the process of FIG. 3 can be performed by controller 120 executing DSD firmware 10. In block 312, controller 120 stores data on disk 150 that has been identified for inclusion in PSWB 12. After storing the data on disk 150, controller 120 updates PSWB count 14 to reflect that the data is no longer included in PSWB 12. In implementations where PSWB count 14 represents an available space in PSWB 12, controller 120 may increase PSWB count 14. In implementations where PSWB count 14 represents the amount of data included in PSWB 12, controller 120 may decrease PSWB count 14. Controller 120 in block 312 may also update PSWB log 16, if needed, to reflect that the data has been stored on disk 150. PSWB log 16 can be used by controller 120 to indicate which of the data in PSWB 12 has been stored on disk 150 since a power-up of DSD 106. As discussed in more detail below with reference to FIG. 6A, PSWB log 16 can provide a way to maintain coherency between PSWB 12 and disk 150 in the event of successive power losses where not all of the data from PSWB 12 can be written to disk 150 before a next power loss.

In block 314, controller 120 determines whether there is space available in PSWB 12 to include additional data from write cache 20. The determination may also include determining whether additional data in write cache 20 meets eligibility requirements for PSWB 12 such as the size of the additional data or the degree of sequential addressing. In addition, data in write cache 20 that has already been identified as excluded from PSWB 12 may not be considered in block 314.

If it is determined in block 314 that there is no space for including additional data from write cache 20, the process ends at block 318. In this regard, there may not be any eligible data in write cache 20 or all eligible data may be too large to fit into the remaining space for PSWB 12.

If it is determined in block 314 that there is space available in PSWB 12, controller 120 in block 316 identifies the additional data for inclusion in PSWB 12 and sends an indication to host 101 indicating storage of the additional data. The process then ends in block 318.

By adding more data to PSWB 12 from write cache 20, a system performance can ordinarily be improved since notification of the storage of the additional data can be sent sooner to host 101. In addition, including additional data from write cache 20 in PSWB 12 can also help protect or back-up the additional data from loss. In a case where the additional data from write cache 20 has been written in a Write Cache Disable (WCD) mode, host 101 is not notified of the storage of data from write cache 20 until the data has been written on disk 150. In this case, adding data from write cache 20 into PSWB 12 can also reduce the amount of recovery that host 101 may need to perform after an unexpected power loss.

In an implementation where an RPO algorithm is not performed on commands for data in write cache 20, adding data from write cache 20 into PSWB 12 can also improve the efficiency of DSD 106's write performance, especially when there may be a shortage of incoming write commands from host 101. This is discussed in more detail below with reference to FIG. 4.

FIG. 4 is a diagram illustrating an example of command queue 18 according to an embodiment. Command queue 18 can include a number of write commands queued for writing on disk 150. In the example of FIG. 4, the order of performance for the write commands in command queue 18 starts with Forced Unit Access (FUA) command 1 at the top of command queue 18 and ends with Write Cache (WC) command 3 at the bottom of command queue 18. FUA commands 1 to 3 and commands corresponding to data stored in PSWB 12 (i.e., PSWB commands 1 to 4) are prioritized over commands corresponding to data stored in write cache 20 (i.e., WC commands 1 to 3). FUA commands can be given a high priority by an application or file system of host 101 to help ensure that certain data is quickly written to disk 150. In other embodiments, command queue 18 may only include PSWB commands and WC commands without FUA commands.

The PSWB commands are given a higher priority over the WC commands to make better use of the performance benefit offered by PSWB 12 in notifying host 101 of the storage of data in PSWB 12 before it is stored on disk 150. In addition, an RPO algorithm can be performed on the higher priority FUA and PSWB commands to reorder the order of performance of the FUA and PSWB commands with respect to each other.

FIG. 5 is a flowchart for a power loss process that can be performed by controller 120 executing DSD firmware 10 according to an embodiment. In block 502 an unexpected power loss is detected by controller 120. This may come from, for example, a notification from host 101, monitoring of a power supply of DSD 106, or an indication from power supply circuitry of DSD 106.

In block 504, controller 120 optionally stores PSWB log 16 in NVSM 128. As noted above, PSWB log 16 can provide a way to maintain coherency between PSWB 12 and disk 150 in the event of successive power losses where not all of the data from PSWB 12 can be written to disk 150 before a next power loss.

With reference to the example of FIG. 6A, NVSM 128 can include first segment 156 for storing a first PSWB log (i.e., PSWB 1) after a first power loss and second segment 158 for storing a second PSWB log (i.e., PSWB 2) after a second power loss. During the first power loss, controller 120 can copy PSWB log 16 from volatile memory 140 to first segment 156 of NVSM 128 to record which data in PSWB 12 had been stored on disk 150 before the first power loss. In some implementations, PSWB log 16 can include addresses (e.g., logical block addresses) associated with data that has been stored on disk 150 or addresses for data not yet stored on disk 150.

In initializing DSD 106 after the first power loss, second segment 158 can be erased to make room for a new PSWB log in the event of another power loss. By only having to erase first segment 156 or second segment 158, a time to ready for DSD 106 is typically improved. The smaller size of either first segment 156 or second segment 158 when compared to third segment 160 allows first segment 156 or second segment 158 to be erased faster during initialization than third segment 160. Moreover, the ability to quickly erase either of first segment 156 or second segment 158 can help protect against an inconsistency between PSWB 12 and disk 150 if there is not enough time between power losses to erase third segment 160 to make room for storing a current state of PSWB 12.

After powering up, the PSWB log from first segment 156 can be evaluated to determine if any of the data stored in third segment 160 has already been stored on disk 150 so that such data is not rewritten to disk 150 or restored to PSWB 12 in volatile memory 140. As data is written to disk 150, PSWB log 16 is updated to reflect which data from third segment 160 has been written to disk 150. Once all of the data from third segment 160 has been written to disk 150, controller 120 can clear PSWB log 16 and erase the PSWB data from third segment 160.

On the other hand, if a second power loss occurs before all of the data restored from third segment 160 has been written on disk 150, PSWB log 16 can be stored in the previously erased second segment 158. After powering up from the second power loss, controller 120 can evaluate PSWB log 2 from second segment 158 when determining which PSWB data, if any, from third segment 160 should be restored to PSWB 12 or written to disk 150.

In other implementations, the size of PSWB 12 and/or the speed at which segments of NVSM 128 can be erased may allow for storing a current state of PSWB 12 without using PSWB log 16. In the implementation shown in FIG. 6B, NVSM 128 includes first segment 162 for storing a first instance of PSWB 12 after a first power loss and second segment 164 for storing a second instance of PSWB 12 after a second power loss. Although the example of FIG. 6B may require more overall space in NVSM 128 when compared to the example of FIG. 6A for the same size of PSWB 12, there is no need to maintain or store PSWB log 16.

In the example of FIG. 6B, controller 120 erases one of first segment 162 or second segment 164 after powering up to make room for storing PSWB 12 in the event of another power loss. If another power loss follows, controller 120 can egress or copy the data from PSWB 12 to the free segment of first segment 162 or segment 164.

Returning to block 506 in the example power loss process of FIG. 5, controller 120 encrypts the data identified for inclusion in PSWB 12 for storage on disk 150. In some embodiments, encrypting the data for storage on disk 150 during the power loss process can allow controller 120 to write the encrypted data transferred to NVSM 128 directly to disk 150 after power-up of DSD 106.

In block 508, the data identified for inclusion in PSWB 12 is transferred from volatile memory 140 to NVSM 128. Controller 120 in block 508 may also transfer or store metadata in NVSM 128 including addresses (e.g., logical block addresses) for the identified data. In some implementations, this metadata can be used after a power-up following an unexpected power loss to write the data to disk 150.

FIG. 7 is a flow chart for a power-up process that can be performed by controller 120 executing DSD firmware 10 according to an embodiment. In block 702, power is restored to DSD 106 after an unexpected power loss, and in block 704, controller 120 optionally evaluates a PSWB log stored in NVSM 128. As discussed above with reference to FIG. 6A, evaluating the PSWB log can help maintain coherency between data stored on disk 150 and data stored in PSWB 12 when there has been a second power loss soon after a first power loss. Controller 120 can evaluate the PSWB log to determine which PSWB data stored in NVSM 128 should be written to disk 150 or restored to PSWB 12 in volatile memory 140. In certain cases, block 704 may not need to be performed since the PSWB log may have already been cleared after all of the previous PSWB data restored from NVSM 128 had been stored on disk 150. In other implementations, block 704 can be omitted if PSWB log 16 is not used, as in the example of FIG. 6B discussed above.

In block 706, the PSWB data previously transferred to NVSM 128 (e.g., the PSWB data transferred in block 508 of FIG. 5) is stored on disk 150 or restored to PSWB 12 in volatile memory 140. In an implementation where the PSWB data is stored on disk 150, controller 120 stores the PSWB data on disk 150 before performing other commands involving the PSWB data to ensure coherency of the data.

In block 708, controller 120 erases at least one segment in NVSM 128. In the example of FIG. 6A, the erased segments can include first segment 156 or second segment 158 storing a PSWB log, and eventually segment 160 storing the PSWB data from a previous instance of PSWB 12. In the example of FIG. 6B, an erased segment can include segment 162 or segment 164 storing a previous instance of PSWB 12.

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.