Systems and methods for classifying data in solid state drives

Systems and methods for writing data to a storage are disclosed. The disclosed systems and methods can receive, by a target device in communication with a host, a first write request from the host to write first data to the storage in communication with the target device. The disclosed systems and methods can determine, by a storage controller in the target device, a data type of the first data based on a first flag set corresponding to the first data. The disclosed systems and methods can store the first data to a location in the storage based at least on the data type of the first data.

FIELD OF THE DISCLOSURE

The present disclosure relates to systems and methods for classifying data for efficient storage in solid state drives (SSDs), and more specifically to systems and methods for classifying data based on information in the file system about the data and using that information for efficient data storage in SSDs.

BACKGROUND

An SSD storage controller manages both stored data and data to be stored in SSD storage, such as non-volatile memory, and can process read/write requests from a host computer. The host computer can issue read and write commands to the SSD storage controller to read data from or write data to the SSD storage. Knowledge about the type of data to be stored in the SSD storage can help the SSD controller improve the lifetime and the performance of the SSD storage. For example, by storing frequently-updated data in the same erase block in NAND flash and separately from infrequently-updated data, overhead associated with write amplification and garbage collection in the SSD device can be reduced. Therefore, it is desirable for SSD controllers to classify the data based on their characteristics, e.g., frequency of updates. After characterizing the data, the SSD storage controller can store the data with similar characteristics in the same erase block.

Prior art methods for classifying data utilize only limited information about the data. Based on this limited information, the SSD storage controller cannot accurately determine various characteristics of data, including data type and data activity. A file system driver implemented in a host computer can have information about the data to be stored in the SSD storage, but such information is not utilized by the storage controller in prior art methods.

SUMMARY

Systems and methods for writing data to a storage are provided. According to aspects of the present disclosure, a method for writing data to a storage can include receiving, by a target device in communication with a host, a first write request from the host to write first data to the storage in communication with the target device. The method can also include determining, by a storage controller in the target device, a data type of the first data based on a first flag set corresponding to the first data. The method can also include storing the first data to a location in the storage based at least on the data type of the first data.

According to some embodiments, storing the first data to a location can include storing the first data to a first location in the storage when the data type of the first data corresponds to a first data type; and storing the first data to a second location in the storage when the data type of the first data corresponds to a second data type.

According to some embodiments, the first data type can correspond to user data and the second data type can correspond to metadata.

According to some embodiments, the storage can include a plurality of non-volatile memories, the first location can be in a first non-volatile memory (NVM) in the storage, and the second location can be in a second NVM in the storage.

According to some embodiments, the first NVM can include a NAND flash memory and the second NVM can include at least one of a phase-change memory (PCM), a magnetoresistive RAM (MRAM) and a resistive RAM (RRAM or ReRAM).

According to some embodiments, the first flag set can include at least one flag bit, and the at least one flag bit can indicate at least one characteristic of the first data based on information from a file system operating on the host.

According to some embodiments, the first flag set can include a first flag bit that indicates the data type of the first data; a second flag bit that indicates whether the first data is read-intensive; a third flag bit that indicates whether the first data is write-intensive; and a fourth flag bit that indicates whether the first data is update-intensive.

According to some embodiments, the storing the first data to a location in the storage can be further based at least on the second flag bit of the first flag set, the third flag bit of the first flag set, and the fourth flag bit of the first flag set.

According to some embodiments, the method can further include moving the first data to a second location in the storage; and retrieving the first data from the second location in response to a first read request from the host.

According to some embodiments, the second location in the storage can be selected based at least on characteristics of the first data.

According to aspects of the present disclosure, a system for writing data to a storage can include a target device in communication with a host configured to receive a first write request from the host to write first data to the storage. The target device can include a storage controller configured to determine a data type of the first data based on a first flag set corresponding to the first data, and store the first data to a location in the storage based at least on the data type of the first data.

According to some embodiments, the storage controller can be configured to store the first data to a location by storing the first data to a first location in the storage when the data type of the first data corresponds to a first data type; and storing the first data to a second location in the storage when the data type of the first data corresponds to a second data type.

According to some embodiments, the first data type can correspond to user data and the second data type can correspond to metadata.

According to some embodiments, the storage can include a plurality of non-volatile memories, the first location can be in a first non-volatile memory (NVM) in the storage, and the second location can be in a second NVM in the storage.

According to some embodiments, the storage controller can be further configured to store the first data to a location by storing the first data to a third location in the storage when the data type of the first data corresponds to a third data type, and the third location can be in a third NVM in the storage.

According to some embodiments, the first NVM can include a NAND flash memory, and the second NVM can include at least one of a phase-change memory (PCM), a magnetoresistive RAM (MRAM) and a resistive RAM (RRAM or ReRAM).

According to some embodiments, the first flag set can include at least one flag bit, and the at least one flag bit can indicate at least one characteristic of the first data based on information from a file system operating on the host.

According to some embodiments, the first flag set can include a first flag bit that indicates the data type of the first data; a second flag bit that indicates whether the first data is read-intensive; a third flag bit that indicates whether the first data is write-intensive; and a fourth flag bit that indicates whether the first data is update-intensive.

According to some embodiments, the storing the first data to a location in the storage can be further based at least on the second flag bit of the first flag set, the third flag bit of the first flag set, and the fourth flag bit of the first flag set.

According to some embodiments, the target device can be further configured to move the first data to a second location in the storage and retrieve the first data from the second location in response to a first read request from the host.

According to some embodiments, the second location in the storage can be selected based at least on characteristics of the first data.

These and other embodiments will be described in greater detail in the remainder of the specification referring to the drawings.

DETAILED DESCRIPTION

FIG. 1illustrates an exemplary system100, in accordance with embodiments of the present disclosure. System100can include host102in communication116with target device104and storage122. Host102can include applications106, operating system108, device controller107, and host memory112. Operating system108can include file system driver110, block I/O layer113, which can include I/O scheduler111and queues118a, and device driver105, which can include communication protocol114a. Target device104can include interface controller117, which includes communication protocol114b, and storage controller120, which includes queues118b. Target device104also is in communication with storage122. Various components that are part of system100can be implemented as hardware, software, or combinations of both. For example, host memory112can be electronic hardware and/or software-implemented virtual memory. Moreover, these various components can be arranged in different ways. For example, although applications106are shown in a box separate from operating system108, some or all of applications106can be part of operating system108, according to some embodiments. As another example, although queues118aare shown as part of operating system108, some or all of the queues can be implemented outside operating system108. Furthermore, system100can include only some of these components and can also include other components not shown inFIG. 1.

Host102can run applications106, for example, user-level applications, on operating system108. According to some embodiments, operating system108can include user-level applications106, which can be run as part of operating system108. According to embodiments of the present disclosure, file system driver110can be a part of operating system108. File system driver110can organize, manage, monitor, and/or control data in host102. File system driver110can provide functionality related to storing data to, and retrieving data from, storage122. File system driver110can also provide functionality to applications106to perform data storage and retrieval. File system driver110can have a large amount of information about the data in the host. The information can include, for example, information about the data type, e.g., whether the data is metadata or user data, and data activity, e.g., how frequently the data is used or accessed by an application running on the host. File system driver110can interact with block I/O layer113, which can be part of operating system108. Block I/O layer113can include I/O scheduler111, which can in turn include queues118a. Write and read request instructions can be enqueued at queues118abefore being scheduled to be sent to target device104by I/O scheduler111. Device driver105can implement communication protocol114afor communicating with target device104over interface116via device controller107. According to some embodiments, operating system108can contain one or more device drivers105that can implement different types of communication protocols114afor interacting with different target devices104. According to some embodiments, device driver105can be implemented as software that communicates with device controller107, which can be implemented as hardware. Device driver105can control one or more devices, such as target device104, via device controller107. Device controller107can control one or more devices by sending and receiving electric signals to and from the one or more devices, such as target device104.

Methods and data of operating system108and applications106can be loaded in host memory112. According to embodiments of the present disclosure, memory112can be dynamic random access memory (DRAM). Queues118acan also be loaded in host memory112to store commands from host102for target device104to process. Examples of stored or enqueued commands can include read and write operations directed to storage122. Storage controller120can process these read and write commands to retrieve and store data. Host102can use communication protocol114ato communicate over interface116with target device104using interface controller117. Examples of interface116include Peripheral Component Interconnect Express (PCIe), Serial Advanced Technology Attachment (SATA), Small Computer System Interface (SCSI), Non-Volatile Memory Express (NVMe), and Serial Attached SCSI (SAS).

According to embodiments of the present disclosure, a solid state drive (SSD) is an example of a storage system that can include target device104and storage122. Host102can send write and read request instructions to target device104with information about the data. An SSD storage controller, e.g., storage controller120, can analyze and use the received information about the data to classify the data.

Target device104can communicate with host102using interface controller117, which can implement communication protocol114b. Target device104can place received write request instructions in queues118b. Storage controller120can include queues118b, and retrieve the write request instructions from queues118bto process them. Target device104can implement the disclosed methods described herein.

As discussed above, prior art methods for classifying data for storage by the SSD storage controller do not utilize information about the data from the file system. Some methods include logical block addressing (LBA) clustering algorithms, Two-level Least Recently Used (LRU) Lists, Multiple Bloom Filters, and Dynamic Data Clustering. The LBA clustering algorithms can be used to monitor LBA history, such as LBA statistics.

All of these prior art methods have drawbacks: the mis-predication rate can be high because the storage system cannot differentiate between metadata and user data, and the limited information about the data arriving at the storage device is not sufficient to predict data activity. The present disclosure overcomes these issues by classifying data at the host, e.g., by file system driver, and transmitting information related to the classification of the data from the host to the storage device. Based on this information, storage controller120can set and/or use a policy to write data to storage122.

FIG. 2illustrates an exemplary data classification scheme, in accordance with embodiments of the present disclosure. File system driver110can classify data into one of two principal types, for example, metadata202and user data206. Metadata202can fall into one or more subtypes, for example, read-intensive203, write-intensive204, and update-intensive205.

According to some embodiments of the present disclosure, metadata202can be read-intensive203if the storage system receives a large number of read requests for the LBA(s) associated with metadata202. In other embodiments, metadata202can be read-intensive203if the storage system is expected or forecast to receive a large number of read requests for the LBA(s) associated with metadata202. A number of read requests can be large if it exceeds a pre-defined or dynamically-defined threshold number. The pre-defined or dynamically-defined threshold number can be an absolute or relative number.

According to some embodiments of the present disclosure, metadata202can be write-intensive204, if the file(s) associated with metadata202is growing intensively such that metadata202is also growing intensively. The file(s) can grow in terms of size and/or number. For example, metadata can be a folder, which describes files contained in the folder. These files' descriptors can be located across one or more file system volume's blocks. When the number of new files created in the folder is growing, the metadata structure, which is used to represent the folder's content, is updated by adding these newly-created files' descriptors. This results in the number of file system volume's blocks, which the folder owns, to grow. In this case, the metadata can be said to be write-intensive204.

According to embodiments, metadata202can be update-intensive205if the storage system receives a large number of write requests for the same LBA(s) associated with metadata202. This can result in the new content of the LBA(s) to be stored in a new physical location(s), such as a new NAND flash page(s). In other embodiments, metadata202can be update-intensive205if the storage system is expected or forecast to receive a large number of write requests for the same LBA(s) associated with metadata202. According to embodiments, a number of write requests for the same LBA(s) associated with metadata202can be large if it exceeds a pre-defined or dynamically-defined threshold number. The pre-defined or dynamically-defined threshold number can be an absolute or relative number.

According to embodiments, metadata202can either be write-intensive204or update-intensive205, when these two subtypes are mutually exclusive.

According to embodiments, metadata202can be classified into read-intensive203, write-intensive204, or update-intensive205based on the architecture of the file system, qualitative nature of data, and/or statistical analysis. This classification can be performed with or without taking into account the threshold numbers discussed above. For example, if the file system is a journaling file system that uses a journal as a structure for metadata202, metadata202can be classified as read-intensive203and write-intensive204. The journal can be implemented as a circular buffer, which can be used to write journal transactions to the tail and read journal transactions from the head. As another example, the file system can utilize an inode table as a structure for metadata202, where metadata202can be classified as read-intensive203and update-intensive205. The inode table can have a fixed size, and can generally receive a large number of read and update requests. According to some embodiments, an extents tree is a type of metadata202. The extents tree can describe the placement of another type of metadata (e.g. content of a folder) and/or the placement of user data (e.g. a file) on a file system volume. The extents tree can be classified into read-intensive203, write-intensive204, or update-intensive205based on the nature of the file it describes. For instance, if the extents tree describes a video, archive, or picture file, the extents tree can be classified as neither read-intensive203nor write-intensive204nor update-intensive205. On the other hand, if the extents tree describes a WINDOWS™ registry file, the extents tree can be classified as read-intensive203. According to some embodiments, file system driver110can collect file operation history and perform statistical analysis. For example, if an LBA range is associated with metadata202and read requests from a certain volume area that is represented by the LBA range are received in a large number, metadata202can be classified as read-intensive203.

User data206can fall into one or more of the subtypes, for example, “cold” data207, “one writer, many readers”208, “many writers, one reader”209, and “update-intensive”210.

According to an illustrative example shown inFIG. 2, user data206can be “cold” data207if user data206is neither read-intensive nor write-intensive nor update-intensive. Archived data can be an example of “cold” data207. According to the example shown inFIG. 2, user data206can be “one writer, many readers”208if user data206is read-intensive but neither write-intensive nor update-intensive. According to some embodiments, when a system contains a small number of write thread(s) and a large number of read threads (e.g. one or several write thread(s) and tens, hundreds, thousands, or more read threads), user data206can be “one writer, many readers”208. In this case, the user data206file(s) can grow because of the activity by the write thread(s). According to the example shown inFIG. 2, user data206can be “many writers, one reader”209if user data206is write-intensive but neither read-intensive nor update-intensive. According to some embodiments, when a system contains a small number of read thread(s) and a large number of write threads (e.g. one or several read thread(s) and tens, hundreds, thousands, or more write threads), user data206can be “many writers, one reader”209. In this case, read and write requests can be issued simultaneously.

According to embodiments, user data206can be read-intensive if the storage system receives a large number of read requests for the LBA(s) associated with user data206. In other embodiments, user data206can be read-intensive if the storage system is expected or forecast to receive a large number of read requests for the LBA(s) associated with user data206. A number of read requests can be large if it exceeds a pre-defined or dynamically-defined threshold number. The pre-defined or dynamically-defined threshold number can be an absolute or relative number.

According to some embodiments, user data206can be write-intensive, if the user data206file(s) is growing intensively. In these embodiments, the LBA(s) associated with the file(s) can change in each write request for the file(s). This can result in the storage system using a different block(s) for each write request.

According to some embodiments, user data206can be update-intensive210, if the user data206file(s) is updated frequently. In these embodiments, many write requests for user data206are for the same LBA(s) associated with the file(s). This can result in the storage system using the same logical block(s) as addressed by LBA(s) but a different physical page(s) for each write request. According to embodiments, the user data206file(s) is updated frequently if the number of write requests with the same LBA(s) associated with the file(s) exceeds a pre-defined or dynamically-defined threshold number. The pre-defined or dynamically-defined threshold number can be an absolute or relative number. In other embodiments, user data206can be update-intensive210if the storage system is expected or forecast to receive a large number of write requests for the same LBA(s) associated with user data206.

According to embodiments, user data206can be classified into “cold” data207, “one writer, many readers”208, “many writers, one reader”209, or update-intensive210based on the architecture of the file system, qualitative nature of data, and/or statistical analysis, similar to the metadata classification described above. This classification for user data206can also be performed with or without taking into account the threshold numbers discussed above. For example, if user data206is in a temporary file(s), user data206can be classified as read-intensive, write-intensive, and/or update-intensive210. Temporary files can be small files with a short lifetime and updated frequently. As another example, if user data206is in a video, archive, or picture file(s), user data206can be classified as “cold” data207. Yet, in another example, if user data206is part of a word processing document, user data206can be classified as update-intensive210and/or write-intensive. According to some embodiments, the file system can collect file operation history, and perform statistical analysis based on the number of read and write requests. The statistical analysis can show distributions based on the frequency of read and write requests. According to some embodiments, the threshold numbers discussed above can be calculated based on the statistical analysis.

A person of ordinary skill would understand that the two principal types and seven subtypes in file system driver110ofFIG. 2are presented for illustrative purposes only. Some or all of these types and subtypes can be modified or removed. Other types and subtypes can also be defined and used in a file system.

FIG. 3illustrates an exemplary set of flags300based on the data classification scheme inFIG. 2, in accordance with embodiments of the present disclosure. According to embodiments, host102(FIG. 1) can send the flags to target device104. A flag can be used to provide information about data. For example, the seven subtypes (203-205and207-210) described inFIG. 2can be represented using the set of flags300, which are labelled as “Data Type,” “Read-intensive,” “Write-intensive,” and “Update-intensive.” For example, each flag can have a bit of information as follows. The “Data Type” flag can be set to “0” or “1” to respectively indicate that the data is metadata or user data. The “Read-intensive” flag can be set to “1” to indicate that the data is read-intensive; otherwise, it can be set to “0.” The “Write-intensive” flag can be set to “1” to indicate that the data is write-intensive; otherwise, it can be set to “0.” The “Update-intensive” flag can be set to “1” to indicate that the data is update-intensive; otherwise, it can be set to “0.” Exemplary values of the four flags that correspond to the example ofFIG. 2are shown at301,302,303,304,305,306, and307. As an example, for read-intensive metadata203, the “Data Type,” “Read-intensive,” “Write-intensive,” and “Update-intensive” flags can be set to “0,” “1,” “0,” and “0,” respectively. The flags can be grouped together to represent a four-bit number.

A person of ordinary skill would understand that the set of flags300inFIG. 3is presented for illustrative purposes only. Other numbering systems for flags can be implemented for the same data classification scheme, or for any other data classification schemes. For example, a flag can include other attributes related to the current workload activity at the host, access control information about the data, and priority levels for storing the data. Thus, flags can provide information about data that is not present in the storage system.

FIG. 4illustrates an exemplary system400with an SSD system, in accordance with embodiments of the present disclosure. In some embodiments, system400can be based on system100ofFIG. 1. System400can include host system102and SSD system404. Host102can include applications106, operating system108, file system driver110, block I/O layer113, device driver105, and communication protocol114a. SSD system404can include interface controller117, storage controller120, queues118b, and storage122. System400can also include other modules, such as one or more modules that are described in connection withFIG. 1but are not shown inFIG. 4.

When file system driver110receives write requests from applications106or operating system108, file system driver110can initiate write requests to block I/O layer113. Block I/O layer113can create a packet(s) of communication protocol114abased on the write requests. Using these packet(s), host102can transmit the write requests407to SSD system404via interface116. For example, a write request407from host system102to SSD system404can include different portions, such as an instruction (e.g. a write command), one or more LBA numbers, a number indicating the length of data requested to be written, the data to be written into SSD404, and one or more flags associated with the data.

According to embodiments, storage controller120can receive and process the contents of write request407. For example, storage controller120can read, parse, and/or interpret the contents of write request407. For example, storage controller120can parse out the flag set portion of write request407. According to some embodiments, storage controller120can execute the instruction based on the value(s) in the flag set. For example, storage controller120can write the data at a specific physical location in storage122, based on the data being read-intensive, write-intensive, and/or update-intensive, as indicated in the flag. According to some embodiments, if storage122is a hybrid storage system, e.g., including more than one memory types, storage controller120can also determine which memory type to store the data into, based on the flag. Additional details are discussed below in connection withFIG. 6below, which describes a hybrid SSD storage system.

According to some embodiments, interface controller117can receive the packet(s) containing write request407from host102, check validity of the packet(s), and enqueue write request407in queues118b. Storage controller120can receive a request from queues118bto process write request407. Storage controller120can process write request407.

FIG. 5provides exemplary host commands or instructions501-504, according to embodiments of the disclosure. As illustrated inFIG. 5, each instruction can include four elements, for example, the type of command505, the LBA number506, the length507, and the flag set508. Command503, for example, can represent an instruction to write data to storage122(FIG. 1). The particular instruction further specifies that the data has an LBA number of 12 and length of 48, e.g., storage units, such as bytes, packets, blocks, and lines. Assuming for exemplary purposes the flag scheme ofFIG. 3, the flag set of command503, “1010” matches flag set306(FIG. 3), which corresponds to user data with the “many writers, one reader” subtype.

According to embodiments, target device104(FIG. 1) can execute the received commands from the host sequentially. For example, the received commands can be executed by the storage controller based on a first in, first out mechanism. According to alternative embodiments, target device104(FIG. 1) can execute the received commands based on the contents of the instructions. For example, the commands can be executed according to the corresponding flags in each commands. According to alternative embodiments, the received commands can be executed by the storage controller based on the length information in each received command. According to alternative embodiments, the received commands can be executed by the storage controller based on the LBA number in each received command.

FIG. 6illustrates an exemplary hybrid SSD device600, in accordance with embodiments of the present disclosure. Hybrid SSD device600can include NVM memory602and NAND flash memory603. NVM memory602can be of a different type than NAND flash memory. Types of non-volatile memories, other than NAND flash, can include phase-change memory (PCM), magnetoresistive RAM (MRAM) and resistive RAM (RRAM or ReRAM). Types of non-volatile memories, other than NAND flash, can further include any future generation of NVM memory types. NVM memory602can provide fast-write and fast-read access604to data. NVM memory602can be byte-addressable, and can also provide better endurance than NAND flash memory603. Compared to NVM memory602, NAND flash memory603can provide slow-write and slow-read access606to data. Within hybrid SSD system600, data can move (608) from NVM memory602to NAND flash memory603. Hybrid SSD system600can provide fast-write and slow-read access605to data by: (1) writing data to NVM memory602, (2) moving the data to NAND flash memory603, and (3) reading the data from NAND flash memory603. Within hybrid SSD system600, data can also move (609) from NAND flash memory603to NVM memory602. Hybrid SSD system600can provide fast-read and slow-write access607to data by: (1) writing data to NAND flash memory603, (2) moving the data to NVM memory602, and (3) reading the data from NVM memory602.

According to embodiments of the present disclosure, hybrid SSD device600can take into account data characteristics to distribute data between NVM memory602and NAND flash memory603. According to embodiments, the storage controller of hybrid SSD device600can be configured using hardware and/or software to analyze the information in the flags of instructions or commands received from the host and distribute the received data within the hybrid SSD device600according to specific rules. According to embodiments, the rules can depend on one or more factors, including for example, the current or expected workload of the host system, the size of the NVM memory, the size of the NAND flash memory, the size of the free space in the NVM memory, the size of the free space in the NAND flash memory, the performance difference between the NVM memory and the NAND flash memory, the expected amount of incoming data, the expected amount of data removal, instructions from the host, and instructions implemented within the hybrid SSD system.

For example, the “cold” user data207, shown inFIG. 2, can be stored in NAND flash memory603because such data will not be accessed frequently. The overall system performance can be improved by storing data that will be accessed frequently in NVM memory602, because it can provide fast-read and fast-write access604. For example, the update-intensive user data210and the write-intensive user data, shown inFIG. 2, can be stored in NVM memory602because such data will be written frequently.

Read-intensive user data that is written rarely (e.g. the “one writer, many readers” user data208shown inFIG. 2) can have fast-read and slow-write access607. The user data can be written to NAND flash memory603first and then moved to NVM memory602. According to embodiments, the user data can be moved to NVM memory602during the first read. In other embodiments, the user data can be moved at another time, such as when hybrid SSD device600is moderately or not busy or when NVM memory602has sufficient free space. In yet other embodiments, the user data can be written directly to NVM memory602. According to some embodiments, the SSD controller can be configured to check queues118b(FIG. 1). If both read and write requests for the same LBA number exist in queues118b(FIG. 1), then the user data, represented by the LBA number, can be configured to write directly to NVM memory602.

In some embodiments, write-intensive user data that is read rarely, for example, the “many writers, one reader” user data209, can have fast-write and slow-read access605. The user data can first be written to NVM memory602. Once most or all of the write operations are completed, the user data can be moved608to NAND flash memory603. The user data can be read from either NVM memory602or NAND flash memory603, depending on whether the user data has been moved to NAND flash memory603.

According to embodiments, all the metadata can be stored in NVM memory602because the size of the metadata is typically substantially smaller than the user data.

By using hybrid SSD device600, or a similar system, all the drawbacks and limitations related to the traditional methods, as explained above, can be reduced or eliminated. Also, the overhead associated with write amplification and garbage collection can also be reduced or eliminated. Thus, the overall SSD device performance and lifetime can be improved.

The methods described above in connection with hybrid SSD device600can also apply to other types of storage systems. NAND flash memory603can be replaced with a first NVM memory, which is not NAND flash memory, where the first NVM memory provides slower read/write access than NVM memory602(which can be referred to as a second NVM memory). For example, the first NVM memory can be PCM memory and the second NVM memory can be MRAM memory. As another example, NAND flash memory603can be replaced with a mechanical disk drive. According to embodiments, hybrid SSD device600can contain more than two memory types. For example, hybrid SSD device can contain three memory types, where the first memory type is MRAM, the second memory type is 3D XPoint, and the third type is NAND flash. MRAM can provide faster read/write access than 3D XPoint, which can provide faster read/write access than NAND flash. In other embodiments, the storage system can be a non-hybrid system with a single memory type. For example, in a non-hybrid storage device, NVM memory602can be replaced with a DRAM memory.

FIG. 7illustrates an exemplary method700for storing data in a hybrid SSD device, in accordance with embodiments of the present disclosure. Method700can include receiving a request command from a command queue (701). The request can be originated from the host and can be a write request. The flag associated with the request command can be analyzed (702). The flag can specify whether the data associated with the request command is metadata. If the data is metadata, the data can be stored in the NVM memory (703,707). The flag can specify whether the data is write-intensive, update-intensive, or read-intensive. If the data is not metadata and if the data is write-intensive or update-intensive, the data can be stored in the NVM memory (703,704,707). If the data is not metadata and if the data is not write-intensive or update-intensive but is read-intensive, the data can be stored in the NVM memory (703,704,705,707).

The command queue can be checked to determine whether there are other read and write requests for the same LBA as the LBA of the data associated with the write request command. If there are other read and write requests for the same LBA, the data can be stored in the NVM memory (706,707). If there is no other read and write requests for the same LBA, the data can be stored in the NAND flash memory and moved to the NVM memory at the first read request (706,708). According to embodiments, method700can be implemented in the SSD controller as hardware and/or software. In other embodiments, method700can be implemented outside the SSD controller.

The embodiments of the present disclosure were primarily discussed in connection with NAND flash memories. Those of skill in the art would appreciate, however, that the systems and methods disclosed herein are applicable to all memories that can utilize information about data associated with command requests, as well as to different types of storage comprising one or more memory types.

The embodiments of the present disclosure were primarily discussed in connection with making and processing write requests. Those of skill in the art would appreciate, however, that the systems and methods disclosed herein can be used or can be altered to be used in connection with making and processing read requests. For example, when data associated with read requests reside in NAND flash memory in a hybrid SSD system, the read-intensive flag and the update-intensive flag inFIG. 3can be used to determine whether to copy or move the data to NVM memory. For instance, if a read request is sent with at least one of the read-intensive flag and update-intensive flag set to “1” and the data associated with the read request resides in NAND flash memory, then the data can be copied or moved to the NVM memory before receiving a write request. In another example, if data resides in NVM memory in a hybrid SSD system and read requests for the data stops being sent with the read-intensive flag set to “1,” the data can be moved to the NAND flash memory.

Those of skill in the art would appreciate that the various illustrations in the specification and drawings described herein can be implemented as electronic hardware, computer software, or combinations of both. To illustrate this interchangeability of hardware and software, various illustrative blocks, modules, elements, components, methods, and algorithms have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware, software, or a combination depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application. Various components and blocks can be arranged differently (for example, arranged in a different order, or partitioned in a different way) all without departing from the scope of the subject technology.

Furthermore, an implementation of the communication protocol can be realized in a centralized fashion in one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system, or other apparatus adapted for carrying out the methods described herein, is suited to perform the functions described herein.

The communications protocol has been described in detail with specific reference to these illustrated embodiments. It will be apparent, however, that various modifications and changes can be made within the spirit and scope of the disclosure as described in the foregoing specification, and such modifications and changes are to be considered equivalents and part of this disclosure.