Tiered storage using storage class memory

A write command is received to store data in a Data Storage Device (DSD). At least one of a Non-Volatile Random Access Memory (NVRAM) and a Storage Class Memory (SCM) is selected for storing the data of the write command based on a number of previously received write commands indicating an address of the write command or a priority of the write command. The SCM has at least one characteristic of being faster than the NVRAM in storing data, using less power to store data, and providing a greater usable life for repeatedly storing data in a same memory location. In one example, at least a portion of the SCM is allocated for use by a host. Logical addresses assigned to the SCM are mapped to device addresses of the NVRAM. The host is provided with an indication of the logical addresses assigned to the SCM.

BACKGROUND

Data Storage Devices (DSDs) are often used to record data onto or to reproduce data from a storage media such as a rotating magnetic disk or a solid-state memory. New types of storage media, referred to as Storage Class Media (SCM), can provide various benefits over more conventional storage media, such as a rotating magnetic disk or flash memory. SCM can include, for example, a Magnetoresistive Random Access Memory (MRAM), a Phase Change Memory (PCM), a Resistive RAM (RRAM), Ferroelectric RAM (FeRAM), Programmable Metallization Cell RAM (PMC-RAM), Chalcogenide RAM (C-RAM), Ovonic Unified Memory (OUM), or a 3D XPoint memory.

Some DSDs may include different types of storage media in the same DSD, with each type of storage media having different advantages or disadvantages. SCM is typically faster than conventional storage media in storing data, may use less power, or provide a longer usable life for storing data. However, the amount of SCM storage space may be limited, since SCM generally costs more than conventional storage media.

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. 1shows an example of Data Storage Device (DSD)106which communicates with host101according to an embodiment. Host101and DSD106may form a system, such as a computer system (e.g., server, desktop, mobile/laptop, tablet, smartphone, etc.) or other electronic device such as a Digital Video Recorder (DVR). The components ofFIG. 1may or may not be physically co-located. In this regard, host101may be located remotely from DSD106.

Those of ordinary skill in the art will appreciate that other embodiments can include more or less than those elements shown inFIG. 1and that the disclosed processes can be implemented in other environments. For example, other embodiments can include a different number of hosts communicating with DSD106.

As shown inFIG. 1, DSD106includes controller120which includes 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, controller120can include a System On a Chip (SoC).

Host interface126is configured to interface DSD106with host101via bus/network110, and may interface using, for example, Ethernet or WiFi, or a bus standard such as 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 interface126can be included as part of controller120.

As shown in the example embodiment ofFIG. 1, DSD106includes Non-Volatile Random Access Memory (NVRAM)122and Storage Class Memory (SCM)128for non-volatilely storing data across power cycles. SCM128has at least one characteristic of being faster than NVRAM122in storing data, using less power to store data than NVRAM122, and providing a greater usable life than NVRAM122for repeatedly storing data in the same memory location. SCM128can include, for example, a Magnetoresistive Random Access Memory (MRAM), a Phase Change Memory (PCM), a Resistive RAM (RRAM), Ferroelectric RAM (FeRAM), Programmable Metallization Cell RAM (PMC-RAM or PMCm), Chalcogenide RAM (C-RAM), Ovonic Unified Memory (OUM), Non-Volatile Dual In-Line Memory Module-P (NVDIMM-P), or a 3D XPoint memory.

Although SCM128can include one or more advantages over NVRAM122, the space available for storing data in SCM128may be limited as compared to the space available in NVRAM122or disk150due to a higher cost in providing SCM128. In some implementations, the storage capacity of NVRAM122or disk150can be several hundred times or several thousand times the size of SCM128.

In the example ofFIG. 1, SCM128stores system data16and user data18. System data includes data that is used by controller120for operating DSD106. Such system data may be loaded from SCM128into volatile memory140as needed during operation of DSD106. User data18includes data that has been received from host101for storage in DSD106.

As discussed in more detail below, SCM128can be used to store user data from host101for addresses that have been written more often to make better use of the advantages of SCM128. SCM128can also be used to perform higher priority write commands that can result in a greater benefit by being quickly completed in SCM128.

In addition, SCM128can be used to store user data that may not otherwise fit into a smallest writable unit of NVRAM122or disk150(e.g., non-aligned writes or runt data). In the case of disk150, SCM128can be used to store data that is smaller than a sector size on disk150(e.g., smaller than a 512 byte sector or 4 KB sector). In the case of NVRAM122, SCM128can be used to store data that is smaller than a page size of NVRAM122(e.g., smaller than a 512 byte page or 4 KB page). This smaller data can stay in SCM128or can later be migrated to disk150or NVRAM122after being grouped with other data to form a full sector or page size. The smaller size of this data can also allow for the space of SCM128to be used more effectively.

The system data stored in SCM128can also be limited based on certain criteria to conserve space in SCM128. In some implementations, the system data stored in SCM128can be limited to system data that is accessed more than a threshold frequency for reading or writing, smaller than a threshold size, and/or used during or soon after a startup period of DSD106. Examples of such smaller or more frequently accessed system data can include write pointers for NVRAM122or disk150(e.g., in Shingled Magnetic Recording (SMR) zoned storage applications), timestamps of when data was accessed, or frequently updated information about zones of storage in NVRAM122or disk150, such as which zone is open or the number of open zones in an SMR zoned storage application. By storing system data in SCM128that is more frequently accessed, the faster access, lower power, and/or greater endurance of SCM128can be taken advantage of more often. Limiting the size of the system data stored in SCM128can help in saving space in SCM128and allow for a wider range of different data sets to be stored in SCM128.

In addition to system data that is smaller or more frequently accessed, SCM128can be used to store system data that is accessed during or soon after a startup period of DSD106. Storing this type of system data can ordinarily allow for a quicker resume time for DSD106during a startup period.

In the example ofFIG. 1, NVRAM122can include a more conventional memory than SCM128, such as flash integrated circuits, NAND memory (e.g., single-level cell (SLC) memory, multi-level cell (MLC) memory, or any combination thereof), or NOR memory. As shown inFIG. 1, NVRAM122can also store system data20and user data22.

DSD106includes additional non-volatile memory with disk150. In other embodiments, DSD106may not include disk150and may instead use NVRAM122or SCM128for non-volatilely storing data that would otherwise have been stored in disk150.

In the example ofFIG. 1, disk150is rotated by a spindle motor (not shown). DSD106also includes head136connected to the distal end of actuator130, which is rotated by Voice Coil Motor (VCM)132to position head136in relation to disk150. Controller120can control the position of head136and the rotation of disk150using VCM control signal34and SM control signal38, respectively. In this regard, controller120includes servo controller circuitry for controlling the position of head136and the rotation of disk150.

As appreciated by those of ordinary skill in the art, disk150may form part of a disk pack with additional disks radially aligned below disk150. In addition, head136may 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.

Disk150includes a number of radial spaced, concentric tracks152for storing data on a surface of disk150. Tracks152on disk150may be grouped together into zones of tracks with each track divided into a number of sectors that are spaced circumferentially along the tracks.

DSD106also includes volatile memory140that can, for example, include a Dynamic Random Access Memory (DRAM). In other embodiments, DSD106may not include volatile memory140. In such embodiments, data stored in volatile memory140may instead be stored in SCM128for quick access.

Data stored in volatile memory140can include data read from NVM media (e.g., disk150, NVRAM122, or SCM128) or data to be written to NVM media. In this regard, volatile memory140can include a write buffer and a read buffer for temporarily storing data.

As shown inFIG. 1, volatile memory140stores firmware10, write table12, and mapping systems14. As discussed in more detail below with reference toFIG. 2, write table12can include information concerning data that has been stored in an NVM of DSD106. Such information can include, for example, a logical address for the data that was specified by a write command, a write count or number of previously received write commands for the address, a frequency the address has been written, or a priority for the data or the write command indicating the address. As discussed in more detail below, a priority of the write command or a number of previously received write commands indicating the address can be used to select at least one of SCM128and NVRAM122for storing data to make better use of SCM128.

Mapping systems14map logical addresses used by host101to identify data to device addresses indicating one or more locations in a memory of DSD106(e.g., SCM128, NVRAM122, or disk150) where the data is stored. In other embodiments, one or more of NVRAM122, SCM128, or disk150may store their own mapping system with or without a copy of the mapping system stored in volatile memory140.

The mapping systems can have different granularities corresponding to the addressability of the memory or the smallest writable unit of the memory. In one example, SCM128may provide for a more granular addressability with each byte of data having its own logical address in the mapping system. In contrast, the mapping system for disk150can have a different granularity corresponding to a sector size on disk150for 4 KB, and the mapping system for NVRAM122can have yet another granularity corresponding to a 512 byte page size. The different storage media can provide different tiers of granularity in their mappings. In one implementation, SCM128, NVRAM122, or disk150can be selected for storing data based on the size of the data to best fit within the granularity of its mapping system.

Volatile memory140can also store instructions loaded from firmware10for execution by controller120or data used in executing firmware10. In this regard, volatile memory140inFIG. 1is shown as temporarily storing firmware10which can include instructions for execution by controller120to implement the storage processes discussed below. Firmware10may be stored in one of the non-volatile storage media shown inFIG. 1such as NVRAM122, disk150, and/or SCM128.

In operation, host101stores data in DSD106by sending a write command to DSD106specifying one or more logical addresses (e.g., Logical Block Addresses (LBAs)) associated with the data. Host interface126receives the write command and controller120determines a location in a memory of DSD106(e.g., SCM128, NVRAM122, or disk150) for storing the data. Controller120updates mapping systems14in volatile memory140to map the logical addresses associated with the data to physical addresses of the memory location storing the data.

Host101retrieves data from DSD106by sending a read command specifying one or more logical addresses associated with the data to be retrieved from DSD106. Host interface126receives the read command and controller120uses a mapping system to translate the logical addresses of the read command to the physical addresses indicating the location of the data. Controller120then reads the requested data from the memory location specified by the physical addresses and returns the read data to host101via interface126. It should be noted that although a singular form of disk150, SCM128, NVRAM122, and volatile memory140is shown in the example ofFIG. 1, each can represent a plurality of devices of the same or similar storage media in certain embodiments, such as in a system with multiple tiers of storage devices.

FIG. 2depicts an example of write table12according to an embodiment. Other embodiments may include write table12as part of a different data structure or may include different information than that shown inFIG. 2.

In the example ofFIG. 2, write table12includes information concerning data that has been stored in a memory of DSD106as a result of a write command received from host101. A logical address is provided for the data. The logical address (e.g., LBA) can be used by host101to identify the data.

A write count provides a number of previously received write commands for the address. This information can be used to select whether to store the data for the write command in SCM128, NVRAM122, or disk150. In one implementation where NVRAM122includes a flash memory, the data for a write command is directed to SCM128if the write count for its address exceeds a threshold value (e.g., three writes) to reduce wear on NVRAM122. In this regard, NVRAM122may have a limited number of Program/Erase (P/E) cycles where a particular block of NVRAM122can be rewritten before it is no longer able to reliably store data. SCM128, on the other hand, may have a greater usable life for repeatedly storing data for the same address. In one example, SCM128can include an MRAM that can allow for repeatedly writing data to the same location and still reliably storing data in the location.

Write table12inFIG. 2also includes a frequency, which can indicate a number of times that data has been written for the address within a predetermined period of time such as within the past minute. The frequency for an address can be compared to a threshold frequency in determining whether to store data for the address in SCM128or NVRAM122. By storing data for addresses that are more frequently written in a memory that can be accessed quicker, it is ordinarily possible to improve the performance of DSD106in accessing data. In one implementation, SCM128can include a memory such as, for example, MRAM or 3D XPoint memory, that can be written to quicker than a flash memory.

In addition, storing data for frequently written addresses can also reduce power usage if NVRAM122requires more power to store data than SCM128. These power and access performance benefits can also apply to data that would otherwise be stored on disk150by redirecting the storage of such data from disk150to SCM128.

In other implementations, write table12or another data structure may indicate a number of read commands received to access data associated with a particular address or a read frequency for the address. Although the time differences between reading data from a flash memory and most SCM are not as great as the time differences between writing data in a flash memory and most SCM, a shorter time to read data from SCM128than from NVRAM122can allow for a performance advantage by storing more frequently read addresses in SCM128.

InFIG. 2, write table12also includes information indicating a priority for the address. The priority can indicate a priority of a write command received from host101when storing data for the address or a priority associated with the address. In the example ofFIG. 2, a higher number for priority can indicate a higher priority for the last write command received for that address. For example, a high priority write command can include one or more of a Forced Unit Access (FUA) write command, a Write Cache Disable (WCD) write command, a write command to store boot data for initializing host101, a write command to store state data of DSD106or host101, or a write command to store state data of DSD106or host101after an unexpected power loss. In the example ofFIG. 2, different types of high priority write commands are indicated using different values in write table12. In other embodiments, all high priority write commands can be indicated with a single value (e.g., 1).

In the case of an FUA or WCD command, storing the data for the write command quickly in SCM128can allow DSD106to report completion of the write command sooner than if the data was stored with more latency in NVRAM122or disk150. By reporting completion of these types of commands sooner, it is ordinarily possible to improve an overall performance of host101and DSD106since host101may need to wait for DSD106to report completion of a FUA or WCD command before initiating other commands.

In the case of a command to store boot data of host101or DSD106, the boot data can be accessed quicker from SCM128than from NVRAM122or disk150. This can provide for a shorter startup time or resume time for host101or DSD106. Boot data may include, for example, register settings for controller120or execution code that might otherwise be stored in NVRAM122or disk150. In some implementations, boot data may be stored in both SCM128and in another memory such as NVRAM122or disk150to provide for redundancy in case one copy of the boot data becomes unavailable or corrupted. The boot data may only be stored to disk150during a shutdown process of DSD106and later deleted or migrated to volatile memory140or another memory following a startup period to free space in SCM128.

In the case of a command to store state data (e.g., metadata) of DSD106or host101, changes in a state of DSD106or host101can be quickly stored in SCM128. In addition, by non-volatilely storing state data in SCM128, a startup or resume time can ordinarily be decreased since such state data does not need to be reconstructed in a volatile memory such as volatile memory140after starting up or resuming.

In the case of a command to store state data of DSD106or host101after an unexpected power loss, SCM128can be used to quickly store data that may otherwise be stored in volatile memory140or other data that may be lost if not quickly stored in NVM. A quicker storage of state data and/or a lower power used to store data can allow SCM128to be used to store more data or metadata after an unexpected power loss. The data or metadata can be quickly migrated or egressed from volatile memory140or from another volatile memory, such as a read or write channel of controller120, to SCM128.

In addition to being used to select a memory for storing data from a write command, write table12can also be used to determine which data should be migrated into or out of SCM128. An example of such migration is discussed below with reference to the migration process ofFIG. 5.

Memory Selection Examples

FIG. 3is a flowchart for a memory selection process that can be performed by controller120executing firmware10according to an embodiment. In block302, controller120receives a write command indicating an address for data to store in DSD106. The address can indicate a logical address that is used by host101to identify the data to be stored.

In block304, controller120selects at least one of SCM128and NVRAM122for storing the data based on a number of previously received write commands indicating the address or a priority of the write command or a priority of the write command. Storing data for high priority commands in SCM128can allow for a quicker completion time of the command or may provide for redundancy if the data is also stored in another location. Such high priority commands can include, for example, an FUA write command, a WCD write command, a write command to store boot data, or a write command to store a state of DSD106or host101after an unexpected power loss.

With respect to the number of previously received write commands for the address, controller120may use write table12to determine the number of previously received write commands for the address and compare the number to a threshold value. If the number of previously received write commands exceeds the threshold value, SCM128can be selected for storing the data. On the other hand, if the number of previously received write commands does not exceed the threshold value, NVRAM122or disk150can be selected for storing the data.

A frequency of write commands for an address in write table12may alternatively or additionally be used to determine whether to store the data in SCM128. Controller120may compare the number of previously received write commands indicating the address for a predetermined period of time (e.g., within 60 seconds) to a threshold frequency. If the frequency of previously received write commands exceeds the threshold frequency, the data can be stored in SCM128.

As noted above with reference toFIG. 2, storing data for more frequently written addresses in SCM128can ordinarily reduce the wear on NVRAM122or the risk of data corruption in portions of disk150that may, for example, be susceptible to Wide Area Track Erasure (WATER) or Adjacent Track Interference (ATI). In addition, storing data for frequently written addresses in SCM128can also improve the performance of DSD106in reducing the amount of time it takes DSD106to store data. However, since the storage capacity of SCM128may be limited, data for addresses that are not as frequently written or for lower priority write commands can be stored in NVRAM122to save space in SCM128.

In block306, controller120stores data for the write command in the selected memory or memories.

FIG. 4is a flowchart for a write caching process that can be performed by controller120executing firmware10according to an embodiment. The caching process ofFIG. 4is similar to the memory selection process ofFIG. 3, except that the data received for the write command can be first cached or temporarily stored in SCM128before writing the data to its selected location. In this regard, SCM128can serve as a power safe, write-through cache where data is first quickly written before being stored in NVRAM122or disk150.

In block402, controller120receives a write command indicating an address for data to store in DSD106. In block404, controller120caches the data for the write command in SCM128. By caching the data in SCM128, the data can ordinarily be quickly stored and later migrated or copied to another NVM if needed. In the case of data for a WCD or FUA command, non-volatilely storing such data in SCM128can allow DSD106to quickly report completion of the command and can improve system performance.

In addition, temporarily storing or caching data in SCM128that is to be later stored in NVRAM122or disk150can allow for a more efficient performance by deferring the performance of such writes to when there is less activity. In some cases, temporarily storing data for a write command in SCM128can also allow for the grouping of data for a sequential writing or the writing of a particular amount of data to NVRAM122or disk150to meet a page size or sector size.

The data for the write commands can be queued in SCM128, and queuing algorithms for NVRAM122or disk150can be used to reorder the performance of the commands to improve efficiency in performing the commands. When the data is eventually written in NVRAM122or disk150, the data can be sequentially written as a stream of data. In one example, a Rotational Position Optimization (RPO) algorithm can be used to reorder deferred write commands for disk150to reduce an overall distance that head136would need to travel in performing the write commands. The data for the write commands for NVRAM122and disk150can be kept in separate queues.

In addition, SCM128can be used to store data for out of order or random commands that would otherwise make a series of sequentially addressed commands non-sequential. For example, a first and a third write command may be addressed such that their data can be stored in the same region of NVRAM122or disk150, but a second intervening command may be out of order by having an address that would require storing the data for the second write command outside of the region. In such a case, the second command can be temporarily stored in SCM128so that the first and third commands can be sequentially written in the region to improve efficiency in performing the write commands.

Some implementations may also consider the size of an out of order write command in determining which memory to use. In one example, out of order or random write commands for data larger than a predetermined size can be stored in NVRAM122instead of SCM128to save space in SCM128. Out of order write commands larger than a second predetermined size can be stored on disk150to save space in NVRAM122.

With reference toFIG. 4, controller120in block406selects NVRAM122, disk150, and/or SCM128for storing the data based on a number of previously received write commands indicating the address or a priority of the write command. If NVRAM122or disk150is selected, controller120in block408migrates the cached data from SCM128to NVRAM122or disk150. In the case where SCM128is one of or the only selected memory, the cached data may remain in its storage location in SCM128without needing to be rewritten in SCM128.

FIG. 5is a flowchart for a data migration process that can be performed by controller120executing firmware10according to an embodiment. The process ofFIG. 5may, for example, be performed periodically to conserve space in SCM128, during periods of low activity, or in response to SCM128reaching a threshold level of data stored in SCM128.

In block502, controller120migrates data from SCM128to NVRAM122or disk150based on an updated number of previously received write commands or an updated frequency of previously received write commands. In one implementation, if the number of write commands for certain addresses exceeds a threshold number of commands, controller120determines that data for less frequently written addresses that are stored in SCM128should be migrated to NVRAM122or disk150to make room for data of more frequently written addresses. In another implementation, the frequency information for addresses in write table12may be compared to a threshold frequency to determine if any of the data should be migrated from SCM128to NVRAM122or disk150in light of an updated write frequency.

In block504, controller120optionally adjusts an amount of data that is migrated from SCM128based on at least one of an activity level of storing data in SCM128and a remaining storage capacity available in SCM128. In one example, if the available storage space remaining in SCM128has reached a low level, controller120increases the amount of data migrated from SCM128to make more space available.

Controller120may migrate a certain amount of the least recently accessed data from SCM128using information from write table12. In some embodiments, controller120can prioritize certain data in determining which data should remain in SCM128. In one implementation, metadata is assigned a highest priority for being kept in SCM128due to its generally smaller size and frequency of being rewritten. Data that has been transferred into SCM128from a volatile memory (e.g., volatile memory140) can be assigned a second highest priority for being kept in SCM128for data protection purposes. Data for frequently written addresses can be assigned a next highest priority to take greater advantage of a faster write time and/or a better endurance of SCM128. Other implementations can use different criteria for determining which data should be kept in SCM128.

Controller120may use the frequency information of write table12or other information indicating how much data has been stored in SCM128within a recent period of time to determine an activity level. In other implementations, the activity level can be determined based on whether DSD106has become idle or has not received any write commands from host101within a predetermined period of time.

For example, if DSD106has not received any write commands from host101within a predetermined period of time, controller120may determine that there is a low activity level for storing data in SCM128or DSD106. In such a case, controller120may take advantage of additional resources available during the period of low activity to increase the amount of data migrated from SCM128.

In block506, controller120optionally adjusts at least one threshold for selecting SCM128for storing or retaining data in SCM128based on at least one of a data capacity of SCM128, a number of write commands received by DSD106, and a size of data received from host101.

In one example, controller120increases a threshold number of previous write commands required to select SCM128for storing or retaining data when the remaining available data capacity for SCM128falls below a low storage threshold. This adjustment can be performed to conserve space in SCM128as it approaches a full storage capacity. The threshold number of previous write commands can later be adjusted back down when more data has been migrated or deleted from SCM128.

In another example, controller120increases the threshold number of write commands required for SCM128if there are more than a predetermined number of write commands received within a period of time. On the other hand, controller120can decrease the threshold number of write commands if there have been less than the predetermined number of write commands to allow for more data to be stored in SCM128.

In yet another example, the threshold number of write commands may be adjusted based on the size of the data being considered for storage or retention in SCM128. For example, data larger than a predetermined size may need a higher number of write counts to remain in or be stored in SCM128.

Memory Access Examples

FIG. 6is a block diagram showing direct memory access of SCM128by host101according to an embodiment. In the example ofFIG. 6, DSD106allocates at least a portion of SCM128for use by host101and also maps logical addresses assigned to SCM128to device addresses of NVRAM122and/or disk150that identify locations for storing data in NVRAM122and/or disk150. The allocated address space of SCM128can allow for read and write access to SCM128, NVRAM122, and/or disk150by host101using the logical addresses of SCM128. DSD106can provide host101with an indication of the logical addresses assigned to SCM128to allow host101to retrieve data from and store data in DSD106using the logical addresses assigned to SCM128.

The foregoing arrangement can ordinarily allow host101to access NVM of DSD106(e.g., SCM128, NVRAM122, and disk150) without a conventional storage interface such as SCSI or SATA and its associated overhead latency. In some implementations, bus/network110may include, for example, a PCIe bus or other type of fast memory bus.

In addition, the logical addresses assigned to SCM128can be addressable at a smaller size (e.g., at the byte level) than the size otherwise used for NVRAM122or disk150. This can ordinarily allow for a more granular reading and writing of data that can provide for more efficient read and write access. In one embodiment, host101may represent a CPU and the address space of DSD106may be made available with a direct memory access protocol.

DSD106can receive write commands or read commands from host101at a granularity of a mapping system for SCM128. A portion of the logical addresses assigned to SCM128can map to other memories such as NVRAM122or disk150. In one example, a 4 GB address space may be assigned to SCM128but only 2 GB of the address space may actually map to device addresses in SCM128. The remaining 2 GB of address space can map to device addresses in NVRAM122and/or disk150. The faster write and/or read access of SCM128and its greater endurance for storing data can allow SCM128to serve as a read cache for data requested by host101and a write cache for data written by host101.

In addition, DSD106may provide thin provisioning with SCM128by reporting more storage space to host101than DSD106actually has. In one example, DSD106may report the address range of SCM128as including 2 TB of storage space, but SCM128may only have 1 GB of storage space and NVRAM122and disk150may only have 100 GB of storage space. This can allow host101to store data anywhere in the 2 TB address space despite the size of the actual storage capacity. Data can be initially stored in SCM128and migrated to NVRAM122or disk150for consolidation as SCM128reaches its storage capacity. Once SCM128, NVRAM122, and disk150reach a threshold storage capacity, additional storage can be added to DSD106in the field (e.g., hot add memory).

AlthoughFIG. 6shows one host (i.e., host101) and one DSD (i.e., DSD106), other embodiments can include multiple hosts sharing DSD106, each with direct memory access to SCM128via bus/network110. The sharing of SCM among multiple hosts can ordinarily provide a more efficient use of SCM than dedicating SCM to a single host due to varying memory needs from one host to another. In yet other embodiments,FIG. 6can include multiple DSDs, each having its SCM shared by one or more hosts.

When a read command is received from host101for data that is stored in NVRAM122or disk150, the requested data is copied into SCM128and sent to host101from SCM128. When a write command is received from host101to store data in NVRAM122or disk150, the data is cached in SCM128and migrated to NVRAM122or disk150. The migration of data to NVRAM122or disk150can occur after the data meets a particular page size or sector size (e.g., 512 bytes or 4 KB) for storing the data in NVRAM122or disk150. In this way, it is ordinarily possible for host101to have access of data stored in DSD106at a more granular level than may otherwise be available without SCM128.

Page table24can be used to keep track of the data that is stored in SCM128at a given time. Page table24can also be used in arranging the data into a page or sector size that is to be stored in NVRAM122or in disk150.

In some implementations, DSD106can provide host101with access to page table24. In such an implementation, host101can indicate certain addresses for data or metadata that should be kept for persistent storage in SCM128and not flushed or migrated to NVRAM122or disk150. Such data or metadata might include boot data, host operating system data, system information, hibernate information, or other state information of host101.

The data or metadata stored in SCM128may not need to be separately saved to a file system. In some implementations, the memory allocation for SCM128is native to an operating system of host101. Host101can then access the data with addresses allocated to SCM128using a native mapping routine with an operating system of host101, rather than using a file system based on metadata.

In one example, SCM128can be used as an extension of a CPU cache of host101so that SCM128is used when lower levels of a CPU cache (e.g., L1 and L2) are full at host101. This can ordinarily provide better processing performance for host101.

In addition, host101can access data and metadata stored in SCM128without having to fully power other memories such as spinning disk150up to an operating speed, which can save power and time in accessing data or metadata. In one example, a directory structure for disk150can be stored in SCM128so that host101can access the directory structure of disk150without having to spin up disk150.

In some embodiments, host101can provide DSD106with hinting as to which user data should be stored in SCM128or evicted from SCM128. This can be done using an address inference where different designated ranges of addresses would have a different priority associated with the range. As withFIG. 1, it should be noted that although a singular form of SCM128, NVRAM122, and disk150is shown in the example ofFIG. 6, each can represent a plurality of devices of the same or similar storage media in certain embodiments, such as in a system with multiple tiers of storage devices.

FIG. 7is a flowchart for a memory allocation process that can be performed by controller120executing firmware10according to an embodiment. In block702, controller120maps logical addresses assigned to SCM128to device addresses of NVRAM122and/or disk150.

In block704, controller120allocates at least a portion of SCM128for use by host101. In some implementations, all of SCM128may be allocated to host101. In other implementations, portions of SCM128may be reserved for overprovisioning or for storing system data used by DSD106. In one example, a portion of SCM128may be used as a scratch space for temporarily storing valid data that has been garbage collected from NVRAM122or disk150. Controller120may perform a garbage collection process to reclaim obsolete portions of a region in NVRAM122or disk150that store invalid data. As part of the garbage collection process, valid data can be copied to a reserved portion of SCM128from the valid portions of the region being garbage collected. For example, in an SMR zone storage application, the zones' number of valid LBAs may be evaluated. Zones that have a larger amount of valid data may be garbage collected to another zone, but zones that have only a small amount of valid data may have the valid data copied to SCM128. This can provide performance improvement especially in the case where many zones each contain a small amount of valid data, as data can be read and written quickly into SCM128, and all such zones can be made available for re-writing without incurring the mechanical latency associated with a disk write to another zone. The same principle can be applied to other systems such as a media based cache or an NVRAM type memory (e.g., implementing a flash translation layer) where garbage collection is needed.

In block706, controller120provides host101with an indication of logical addresses assigned to SCM128to allow host101to retrieve data from and store data in DSD106using the logical addresses assigned to SCM128. As discussed above with reference toFIG. 6, this can allow host101to directly access SCM128using the address space of SCM128. The address space of SCM128can also provide host101with access to NVRAM122and disk150at a more granular level than a page or sector size corresponding to a smallest writable unit of NVRAM122or disk150.

FIG. 8is a flowchart for a read process that can be performed by controller120executing firmware10according to an embodiment where SCM128is used as a read cache.

In block802, controller120receives a read command from host101requesting data stored in NVRAM122or disk150. The read command can indicate a logical address assigned to SCM128that is mapped to a device address of NVRAM122or disk150. Controller120may check or compare the logical address using page table24to determine if the data is already cached in SCM128or stored in NVRAM or disk150.

In block804, controller120reads the requested data from the device address corresponding to the logical address indicated by the read command, and the read data is cached in SCM128from NVRAM122or disk150. Controller120may use a mapping system of mapping systems14that maps the logical addresses of SCM128to device addresses of NVRAM122or disk150. Page table24is also updated to account for the data cached in SCM128.

In block806, controller120sends the copied data from SCM128to host101. The data cached in SCM128may remain in SCM128or may be deleted after sending the data to host101. Controller120may, for example, determine whether to retain the cached data based on a remaining available capacity of SCM128and/or a frequency of access for the requested data.

FIG. 9is a flowchart for a write process that can be performed by controller120executing firmware10according to an embodiment where SCM128is used as a write cache.

In block902, DSD106receives a write command from host101to store data in NVRAM122and/or disk150. The write command can indicate a logical address assigned to SCM128that is mapped to a device address in NVRAM122and/or disk150.

In block904, the data for the write command is cached in SCM128. By caching the data in SCM128, it is ordinarily possible to quickly store the data for the write command in non-volatile memory since SCM128can be written to quicker than NVRAM122or disk150. In some implementations, a notification that the write command has been completed can be sent to host101upon caching the data in SCM128. This can ordinarily improve a performance of DSD106or host101since host101may then be allowed to proceed with other commands that may have been dependent upon the completion of the write command. This can be especially helpful for WCD commands and FUA commands where DSD106may be required to wait until the data for the command has been stored in NVM before reporting completion of the command to host101.

In block906, the data cached in SCM128is migrated from SCM128to its intended location or locations in NVRAM122and/or disk150. Using SCM128as a write cache can allow for the migration of data to its intended location or locations to occur when it is more efficient such as during a period of low activity of DSD106or when there are other commands being performed in close proximity to the intended location or locations in NVRAM122and/or disk150. Controller120in block906also updates page table24to indicate that the data for the write command has been migrated or paged out of SCM128.

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 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 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.