Improved reliability of SSDs

Abstract

To provide an improved storage system with reliability in a variable level.SOLUTION: A solid state drive (SSD) is disclosed. An SSD can include an interface for receiving a request of reading from and writing in an application on a host. A storage including at least one chip can store data. An SSD controller can process the request of reading and writing from the application. A setting module can set the SSD. The storage can include a reliability table including an entry to designate the setting of the SSD and the reliability for that setting.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The inventive concept relates generally to storage systems, and more particularly to storage systems that provide variable levels of reliability. [Background technology]

[0002] Ideally, storage devices such as Solid State Drives (SSDs) would be perfect, with every recorded bit being read without error. However, the real world is not perfect, which means that despite the best efforts of SSD manufacturers, errors do occur from time to time.

[0003] To help consumers, manufacturers can provide reliability estimates for their devices. For example, they can report a reliability of 99.99% (or an equivalent average error rate of 1 bit per 1000 bits written and / or read). (In practice, this reliability is relatively low, suggesting at least one error in nearly every page written to an SSD, but this reliability level is merely exemplary.)

[0004] However, this reliability is tied to the number of bits recorded to and read from the SSD, and may not accurately reflect the reliability of the data from the time of application. Other functions performed by the SSD may also affect the true reliability.

[0005] There remains a need to more accurately determine the reliability of storage systems and to control the reliability of storage systems. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] U.S. Patent No. 8,533,558 [Patent Document 2] U.S. Patent No. 8,631,306 [Patent Document 3] U.S. Patent No. 8,719,665 [Patent Document 4] U.S. Patent No. 8,892,980 [Patent Document 5] U.S. Patent No. 9,032,245 [Patent Document 6] U.S. Pat. No. 9,317,362 [Patent Document 7] US Patent Application Publication No. 2019 / 0164599 Summary of the Invention [Problem to be solved by the invention]

[0007] The present invention has been made in view of the above-mentioned conventional techniques, and an object of the present invention is to provide an improved storage system that provides variable levels of reliability. [Means for solving the problem]

[0008] A solid state drive (SSD) according to an embodiment of the present invention includes an interface for receiving read and write requests from a first application on a host, storage for data including at least one chip, a solid state drive (SSD) controller for processing read and write requests from the first application on the host using the storage, a configuration module for configuring the SSD, and storage for a reliability table, the reliability table including at least a first entry and a second entry, the first entry identifying a first configuration of the SSD and a first reliability for the first configuration of the SSD, and the second entry identifying a second configuration of the SSD and a second reliability for the second configuration of the SSD.

[0009] A method according to an embodiment of the present invention includes determining a reliability for a solid state drive (SSD) for data including at least one chip, accessing a first entry of a reliability table from the SSD, and configuring the SSD based on the first entry, the reliability table including at least a first entry and a second entry, the first entry identifying a first configuration of the SSD and a first reliability for the first configuration of the SSD, and the second entry identifying a second configuration of the SSD and a second reliability for the second configuration of the SSD.

[0010] A method according to an embodiment of the present invention includes the steps of transmitting a reliability request from an application on the host to the SSD, requesting valid reliability for the SSD; receiving a valid reliability for the SSD from the SSD by the application on the host; transmitting a reliability table request from the application on the host to the SSD, requesting a reliability table stored in the SSD; receiving the reliability table from the SSD by the application on the host; selecting an entry from the reliability table based on at least a desired reliability for the application on the host; and transmitting a setting request from the application on the host to the SSD, wherein each entry in the reliability table identifies a setting for the SSD and a reliability for the setting for the SSD, and the setting request identifies an entry in the reliability table. Effect of the Invention

[0011] According to an embodiment of the present invention, an improved storage system is provided that provides variable levels of reliability. [Brief description of the drawings]

[0012] [Figure 1] 1 illustrates a system including a client and a server having a solid state drive (SSD) according to one embodiment of the present invention. [Diagram 2] The details of the server in FIG. [Diagram 3] FIG. 2 shows details of the SSD. [Figure 4] 2 shows a reliability table for the SSD of FIG. [Diagram 5] FIG. 1 shows an alternative view of an SSD. [Figure 6] 6 illustrates messages exchanged between the application of FIG. 5 and the SSD of FIG. 1; [Figure 7] 2 shows a flowchart of an example procedure for the SSD of FIG. 1 to self-configure itself to provide a desired reliability, according to one embodiment of the present invention. [Figure 8] 2 shows a flowchart of an example procedure for the SSD of FIG. 1 to configure itself (SELF). [Figure 9A] 2 shows a flowchart of an example procedure for determining a desired reliability for the SSD of FIG. 1 . [Figure 9B] 2 shows a flowchart of an example procedure for determining a desired reliability for the SSD of FIG. 1 . [Figure 10] 2 shows a flowchart of an example procedure for determining the effective reliability of the SSD of FIG. 1 . [Figure 11A] 6 shows a flowchart of an example procedure for the application of FIG. 5 to direct the SSD of FIG. 1 to provide a desired reliability according to one embodiment of the present invention. [Figure 11B] 6 shows a flowchart of an example procedure for the application of FIG. 5 to direct the SSD of FIG. 1 to provide a desired reliability according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Reference will now be made in detail to the embodiments of the present invention, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the inventive concepts. However, it should be understood by those skilled in the art that the inventive concepts may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

[0014] Terms such as first, second, etc. may be used herein to describe various elements, but it will be understood that these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, a first module may be referred to as a second module, and similarly, a second module may be referred to as a first module without going beyond the category of the concept of the present invention.

[0015] The terms used in describing the inventive concept herein are intended to describe particular embodiments only and are not intended to limit the inventive concept. As used in describing the inventive concept and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural, unless the context clearly dictates otherwise. As used herein, the term "and / or" will be understood to refer to and include any and all possible combinations of one or more associated, listed items. When "comprises" and / or "comprising" are used herein, it will be understood that the terms "comprises" and / or "comprising" specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. Components and features in the drawings are not necessarily drawn to scale.

[0016] Consider data compression as an example of how the reliability listed by a manufacturer may not accurately reflect the true reliability of a storage device. When a solid state drive (SSD) compresses data before recording it, a single bit error in the compressed data may actually affect many bits of the raw data. For example, if data is compressed at an effective ratio of 2:1 (i.e., the size of the recorded data is half the size of the raw data), a single bit error is expected to affect two bits of raw data, effectively doubling the average error rate. And, in the worst case scenario, an error may prevent the SSD from successfully decompressing the raw data, resulting in the loss of the entire raw data.

[0017] You can also consider data deduplication. With data deduplication, the SSD attempts to improve storage efficiency by identifying identical chunks of data (or even entire files that are stored identically multiple times) among many files. Instead of storing many copies of the data, the SSD can store just one copy and reference it from the various files that contain that chunk of data. However, if there is an error in the deduplicated data, that error will become an error in every file that uses the data, again magnifying the error rate. For example, if the same data is used for three different files, a single error in the duplicated data is actually three errors in three different files.

[0018] It should be noted that different applications may have different reliability requirements. For example, one application may want only one error per MB recorded by the application, while another application may want only one error per GB of data recorded by the application. Applications may specify such reliability ratios to help select among different storage devices available, but currently no single storage device can support many different reliability levels.

[0019] Depending on the implementation, an SSD may include multiple levels at which reliability can be managed, including the memory chips themselves (where the data is actually stored), which may be flash memory chips such as NAND flash memory chips, non-volatile memory chips, or other types of memory chips, the use of Error Correcting Code (ECC) modules (which detect and / or correct errors read from the memory chips), and RAID / erasure coding implementations (where data is stored across multiple memory chips over multiple channels for some redundancy).

[0020] There are various ways to provide error detection and correction using RAID (Redundant Array of Independent Disks) or erasure coding. For example, RAID1, RAID5, RAID6, or alternative erasure coding implementations that support error correction can be used. Each implementation provides various levels of reliability.

[0021] An ECC module may also be used and may implement any desired ECC algorithm. Example algorithms that may provide error detection and / or correction include basic parity check, Cyclic Redundancy Check (CRC), Hamming Codes, and the like, all of which are well-known schemes for performing error detection and / or correction. Each implementation provides various levels of reliability.

[0022] Finally, NAND flash memory chips can also offer several options in relation to reliability. For example, we can consider the Single-Level Cell (SLC). SLC allows to store one bit of data. By applying the appropriate voltage to the cell, the SSD can read the bit (i.e., applying one voltage to the cell determines the cell to store a "0" (zero), while applying a different voltage to the cell determines the cell to store a "1" value). Multi-Level Cells (MLC) store two bits of data, so up to four different voltage levels are required to determine the value stored in the cell. Triple-Level Cells (TLC) store up to three bits of data, so up to eight different voltage levels are required to determine the value stored in the cell. Quad-Level Cells (QLC) store up to four bits of data, so up to 16 different voltage levels are required to determine the value stored in the cell.

[0023] As the number of bits stored in a cell increases, the voltage range that separates the different possible stored values ​​becomes smaller. Thus, QLC is more likely to return errors due to errors arising from the applied voltage processing than SLC (as is the case with MLC and TLC). Also, cells tend to support fewer writes as the number of bits stored increases. Thus, SLC can support the writing of up to 100,000 pieces of data, whereas QLC can only support the writing of up to 100 pieces of data (after which errors in recording the data become more likely). (Also, it may take longer to read data from a QLC cell than from an SLC cell, since the number of voltages that must be applied to the cell to determine its value increases with the number of bits stored in the cell.)

[0024] Since there is a relationship between the number of bits stored in a cell and the likelihood of an error due to incorrect handling of the input voltage, it can be concluded that QLC is more likely to experience such errors than other cell types, and SLC is the least likely to experience such errors (and, in turn, QLC is the least reliable cell type, and SLC is the more reliable cell type). Of course, unless a NAND flash memory chip offers all of both types of cells, data cannot be stored in a desired cell type to achieve a certain reliability. However, reliability can be improved by using cells that store fewer bits than they can store.

[0025] Consider the type of QLC. When the QLC stores 4 bits of data, reliability is as known. However, when the QLC stores, for example, only one bit (leaving the other three bits at default values ​​or "don't care" values), the QLC effectively emulates an SLC. Errors that occur due to voltage processing errors that distinguish the value of the "don't care" bit become irrelevant; that is, there are effectively only two input voltages that must be applied to determine the value of the cell. (Embodiments of the present invention do not suggest that the QLC is implemented to potentially store and read only one bit, but rather that, in conjunction with the "don't care" bit, both the returned information and the errors associated with that information can be ignored. Embodiments of the present invention also do not suggest that storing only one bit at a time in a QLC can result in a QLC that supports an increased number of record operations.) Thus, when a QLC stores only one bit, the error rate can be reduced and reliability can be improved. The same is true for any cell type that is used to store fewer bits than it was designed for. Thus QLC can emulate TLC, MLC or SLC, TLC can emulate MLC or SLC, MLC can emulate SLC, all with improved reliability. (It cannot be done the other way around; no cell type can store more than the number of bits of information designated for it without reducing reliability.)

[0026] It is possible to take a QLC and empirically test it to determine how reliable it is when storing fewer than 4 bits; that is, the same is true for TLC and MLC. This testing is no different from the way QLCs (or other cell types) are tested to determine their reliability in general, except for the amount of data that is recorded in the QLC. Thus, for each cell, it is possible to determine its reliability when storing any number of bits, even if it is less than the maximum number supported by the cell.

[0027] In the case of RAID / erasure coding and ECC modules, there are mathematical models by which their reliability can be estimated, or the reliability is determined empirically through actual use (very similar to how the reliability of individual cell types can be determined).

[0028] The fact is that the error correction schemes at various levels of SSDs are not completely independent of each other. That is, the error rate of RAID implementations and ECC modules are not always equal to 10 -10 If you use QLC to store only one bit, the error rate is 10 -10 If all three are used, then 10 -30 However, the various levels of solutions are at least partially complementary. Using a combination of error correction schemes at one or more levels of an SSD can provide a higher reliability ratio than would be provided by any individual level separately.

[0029] During manufacture of the SSD device, the reliability of each error correction combination can be tested at various levels to determine the overall reliability of any individual combination. Thus, for example, if a NAND flash memory includes QLC, i.e., there are four possible variants (using QLC to store 4 bits, 3 bits, 2 bits, or 1 bit), the ECC provides three different error correction schemes, and the RAID / erasure coding implementation provides 10 different error correction variants, there may be a total of 120 different combinations (4 x 3 x 10 = 120). The manufacturer can test each such combination and determine the individual reliability of each combination. This information can be stored in storage (e.g., a configuration module) within the SSD. The configuration module can also be responsible for selecting the appropriate error correction combination at various levels to achieve the desired reliability.

[0030] In some embodiments of the present invention, an application can specify the reliability to be applied to the data. For example, some applications may require high reliability of the data, while other applications may not care much if data is lost (e.g., transient data or data that is easily restored if lost). Given the reliability specified for the application, the configuration module can configure the SSD to achieve the target reliability of the application data using a ratio of reliability to various error correction combinations. If multiple applications record data to the same SSD, the configuration module can configure all SSDs to operate at the highest reliability required by any one of the applications, or the configuration module can configure different regions of the SSD to operate at different reliability levels. For example, without changing the RAID or ECC implementation, the SSD can store only 1 bit in the QLC for data that requires higher reliability and 4 bits for data that tolerates lower reliability. It is noted that embodiments of the present invention can support reliability management at any desired unit of data (e.g., page, block, plane, die, chip, or the entire SSD).

[0031] In other embodiments of the present invention, the application may not provide reliability requirements for the data, but simply provide the data. In such embodiments of the inventive concept, and more particularly in the case of embodiments of the inventive concept where the SSD may use compression, data deduplication, or any other transaction that may affect reliability, the SSD may track what the effective reliability is for any particular data unit. Thus, if the application's raw data is compressed, the SSD may track the effective compression ratio of the data, which may be used to determine a multiplier for the error rate. Also, if the SSD uses data deduplication, the SSD may track the number of files that share a particular data unit, which may be used (again) to determine a multiplier for the error rate. The configuration module may then use this information in combination with the reliability ratios for the various error correction combinations to select the appropriate combination that provides the advertised reliability (taking into account how errors are multiplied based on the operation of the SSD) to ensure that the advertised reliability is achieved.

[0032] It should be noted that reliability is not the only variable that can be considered when selecting an error correction combination to achieve a target reliability (although it can be the main variable). If reliability were the only consideration, the SSD could simply be configured to use the error correction combination that provides the highest reliability and that would be the end of it. That is, no higher reliability could be achieved. However, various error correction combinations also have other implications. These other implications include space overhead and performance. For example, if QLC is used to store only one bit of information, it will operate more reliably but will be only one-fourth as efficient from a storage perspective (because QLC can only store four bits). Performance is also a consideration. Other error correction combinations may require more time to process data, which can affect the latency of the SSD.

[0033] Thus, taking into account other considerations, the configuration module can select an error correction combination to use to configure the SSD that provides a target reliability ratio. For example, if space overhead is considered a significant factor, an error correction combination that causes the QLC to store 4 bits of data (and also relies more on ECC modules or RAID / erasure coding) may be preferred over an error correction combination that stores only 1 bit in the QLC. Also, if performance is a bigger issue than space overhead, an error correction combination that stores only 1 bit of data but does not rely as much on ECC modules and / or RAID / erasure coding to correct the data is preferred.

[0034] FIG. 1 illustrates a system including clients and a server with SSDs, according to an embodiment of the present invention. In FIG. 1, the clients (105-1, 105-2) are shown communicating with a server 110 over a network 115. The clients (105-1, 105-2) and the server 110 may be in a client-server relationship, that is, the clients (105-1, 105-2) may issue commands and the server 110 may carry out the commands. Alternatively, the server 110 may be a computer used directly by an end user, avoiding the involvement of the clients (105-1, 105-2).

[0035] The network 115 can be any type or variety of network. For example, the network 115 can include, among other possibilities, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), or a global network such as the Internet. Data can be transmitted directly through the network 115 or can be protected, for example, using encryption or a virtual private network (VPN). The network 115 can include wired or wireless connections. The network 115 can also include any desired combination of this alternative. For example, the clients (105-1, 105-2) can be connected to a LAN via a wireless connection, which is ultimately connected to the Internet via a wired connection, which is ultimately connected to another LAN that is connected to the server 110. The connections between the clients (105-1, 105-2) and the server 110 can be diverse. That is, the connections need not be the same in all situations.

[0036] Server 110 may include a processor 120, memory 125, and a solid state drive (SSD) 130. Processor 120 may include a software stack including an operating system, applications, storage software (such as a file system), and controller software for managing devices attached to server 110 (e.g., memory 125 and SSD 130). Processor 120 may be any type of processor, such as an Intel Xeon, Celeron, Itanium or Atom processor, an AMD Opteron processor, an ARM processor, etc. Although FIG. 1 shows a single processor 120, server 110 may include any number of processors, each of which may be a single-core or multi-core processor, and may be mixed in any desired combination.

[0037] Memory 125 may be a typical memory used in server 110. Memory 125 may be any type of memory such as flash memory, dynamic random access memory (DRAM), static random access memory (SRAM), persistent random access memory (Persistent RAM), non-volatile random access memory (NVRAM) such as ferroelectric random access memory (FRAM) or magnetoresistive random access memory (MRAM). Memory 125 may be volatile or non-volatile memory. Memory 125 may also be any desired combination of different memory types. Memory 125 is managed (or controlled) by a memory controller (not shown in FIG. 1), which may be a separate component of server 110 with a driver that is part of the software stack. Memory 125 is used to store what is called "short-term" data, i.e., data that is not expected to be stored for a long period of time. Examples of short-term data may include temporary files, data used locally by an application (which may have been copied from another storage location), etc.

[0038] The processor 120 and memory 125 may also support an operating system on which various applications may run. The applications may issue requests to read data from or write data to the memory 125 or the SSD 130. The memory 125 may be used to store data that is considered "short-term," while the SSD 130 may be a storage device used to store data that is considered "long-term," i.e., data that is expected to be stored for an extended period of time. The SSD 130 may be accessed using controller software in a software stack running on the processor 120. Although FIG. 1 illustrates only one SSD 130, embodiments of the invention may include any type of storage device and be connected via any desired connection. Thus, the SSD 130 may be substituted with a Serial AT Attachment (SATA) hard disk drive, an Ethernet SSD, or other type of storage device. It is noted that embodiments of the invention may include any number (zero or more) of storage devices, each of which may be of any desired type, such that multiple different types of storage devices may be intermixed in the server 110.

[0039] FIG. 2 shows details of the server 110 of FIG. 1. As shown in FIG. 2, the server 110 may generally include one or more processors 120. The processor 120 includes a memory controller 205 and a clock 210, which are used to coordinate the operation of the machine's components. The processor 120 is also coupled to memory 125, which may include, for example, random access memory (RAM), read-only memory (ROM), or other state storage media. The processor 120 is also coupled to a storage device 130 and a network connector 215, which may be, for example, an Ethernet connector or a wireless connector. The processor 120 is also connected to a bus 220, which is attached to a user interface 225 and input / output interface ports. The input / output interface ports are managed using an input / output engine 230, among other components.

[0040] FIG. 3 shows details of the SSD 130 of FIG. 1. In FIG. 3, the SSD 130 may include a host interface logic (HIL) 305, an SSD controller 310, and various memory chips (315-1 through 315-8) (also referred to as "memory storage"), which are organized into various channels (320-1 through 320-4). The host interface logic 305 may manage communications between the SSD 130 and other components (e.g., the processor 120 of FIG. 1 or other SSDs). Such communications may include read requests to read data from the SSD 130 and write requests to write data to the SSD 130. The host interface logic 305 may manage the interface using only a single port or may manage the interface through multiple ports. Alternatively, SSD 130 may include multiple ports, each of which may have separate host interface logic 305 to manage the interface through that port. Embodiments of the invention may also mix possibilities (e.g., an SSD with three ports may have one host interface logic to manage one port, and a second host interface logic to manage the other two ports).

[0041] The SSD controller 310 may use a memory controller (not shown in FIG. 3) to manage read and write operations along with garbage collection and other operations on the memory chips (315-1 through 315-8). The memory chips (315-1 through 315-8) may be any type of memory chip, such as NAND flash memory chips or other non-volatile memory chips, although embodiments of the present invention may be extended to other storage systems, such as Non-Volatile RAM (NVRAM).

[0042] The SSD controller 310 may include a translation layer 325, an error correction code module 330, a RAID / erasure coding module 335, a configuration module 340, and a reliability table storage 345. The translation layer 325 may manage the mapping from logical block addresses (LBAs) used by applications executing on the processor 120 of FIG. 1 to physical block addresses (PBAs) where the data is actually stored on the SSD 130. Using the translation layer 325 (which in some embodiments of the invention may be referred to as a flash translation hierarchy 325), the SSD 130 may move data between memory chips (315-1 through 315-8) without the application having to maintain knowledge of where the data currently resides. (For example, this can occur when an application requests to overwrite data with a new value (storing the new data in a new location because SSDs generally do not support overwriting data in place). It can also occur when a block containing some valid data is subject to garbage collection.) The translation layer 325 can be implemented as a table stored in some (preferably) non-volatile storage somewhere within the SSD 130.

[0043] An error correction code (ECC) module 330 can apply error correction codes to data recorded in memory chips (315-1 through 315-8). In some embodiments of the invention, the ECC module 330 is applied to data regardless of which memory chip (315-1 through 315-8) the data is stored in, and thus in another embodiment, each of the channels (320-1 through 320-4) (or each of the memory chips (315-1 through 315-8)) can have its own ECC module 330. The ECC module 330 can implement any desired error correction algorithm and thus can support detection and / or correction of a variety of errors (based on the implemented algorithm). Example algorithms used by the ECC module 330 include such as parity codes, Cyclic Redundancy Check (CRC) codes, or Hamming codes. The ECC module 330 may be implemented using a general-purpose processor executing appropriate instructions, or using a Field Programmable Gate Array (FPGA), an Application-Specific Integrated Circuit (ASIC), a Graphics Processing Unit (GPU), or any other desired implementation.

[0044] The RAID / erasure coding module 335 may implement any desired RAID or erasure coding scheme to store data on the memory chips (315-1 through 315-8). (Because RAID (Redundant Array of Independent Disks) describes a specific implementation of erasure coding, the RAID / erasure coding module 335 may be more generally described as an erasure coding module without reduction in functionality.) In general, the RAID / erasure coding module 335 may take data to be recorded on the SSD 130, split the data into various units, and store these units on different memory chips (315-1 through 315-8). To introduce redundancy, the same data may be stored on multiple memory chips (315-1 through 315-8) or error correction information (such as parity codes, CRC codes, or Hamming codes) may be used. In this manner, errors are detected and corrected. (The same basic approach may be used for both the RAID / erasure coding module 335 and the ECC module 330, but at different scales; thus the solutions may complement each other.) The erasure coding module 335 may be implemented using a general-purpose processor executing appropriate instructions, or using an FPGA, ASIC, GPU, or other desired implementation.

[0045] The configuration module 340 is used to program what techniques are used to improve reliability. The question of how different reliability techniques can be used is answered simply: the ECC module 330 and the RAID / erasure coding module 335 can provide support for different error correction techniques, each with (potentially) different reliability ratios. The configuration module 340 is used to instruct the ECC module 330 and / or the RAID / erasure coding module 335 what error correction technique can be used at a given time.

[0046] However, this answer leads to a follow-up question: if there are different error correction techniques that provide various levels of reliability, why not always use the most stable (reliable) approach? The answer is that different techniques may have other effects on the operation of the SSD 130, which may offset the benefits of higher reliability. For example, consider the possibility that identical data is stored in each memory chip (315-1 through 315-8). This approach introduces an 8-fold duplication of the data, and the failure of a single memory chip does not result in data loss. The drawback of this approach is that because the identical data is stored eight times, the total usable storage of the SSD 130 is not greater than the storage of a single memory chip. In other words, the total available storage provided by the SSD 130 is only one-eighth of the physical storage provided by the SSD 130, or 87.5% of the available storage is reserved for duplicated copies of the data. If the data is too sensitive and 8-fold duplication is required, this trade-off may be acceptable. However, for most users, these redundancies are excessive and the reduction in usable storage is unacceptable.

[0047] Thus, the configuration module 340 is used to instruct (or program or configure, i.e., whatever terminology may be preferred) the ECC module 330 and the RAID / erasure coding module 335 to use particular techniques from those provided by the ECC module 330 and the RAID / erasure coding module 335.

[0048] In addition to the ECC module 330 and the RAID / erasure coding module 335, there are other components, specifically the memory chips (315-1 through 315-8), that are configured by the configuration module 340. Different memory chips may offer different ways of storing data, which may affect the reliability of the memory chip. To appreciate this fact, it is important to understand the different types of memory storage.

[0049] Memories manage data at various levels of granularity depending on what is going on. For example, the basic access unit for reading and writing data is a page (this can be any desired size, e.g., 4KB of data). If the page is in a free state, it can be written to. However, when new data replaces existing data, it may not be possible to overwrite the page. In this case, the original page is marked as invalid and the new data is written to a new page. Pages are organized into groups called blocks (and blocks contain multiple pages). For example, a block may have 64 or 128 pages. A block (or a superblock, which is a group of blocks) is typically the unit in which data is erased (which returns the page to a free state where it can be updated). Therefore, if there is any valid data in the block selected for erasure, the valid data must be copied out of the block (or to another block) before erasing the block (valid data must not be lost when erasing a block).

[0050] But even at a finer level, there are variations on data storage: individual units called cells store data at a finer granularity than a page. (Individual cells cannot be accessed directly; an entire page can be read or written as a unit.) Each cell is designed to respond when various voltages are applied to it; values ​​can be read and written to the cell using these different responses.

[0051] In its simplest form, a cell has a single trigger voltage (which may be thought of as a boundary point) at which its response changes; that is, if you apply a voltage below that trigger voltage, the response is different from applying a voltage above that trigger voltage. So, for example, if the input voltage can vary from 0V to 5V, the point at which the cell can begin to respond can be 2.5V. (The way the cell responds depends on the value stored in the cell. For example, if the cell represents a binary "0", the cell can output one voltage (e.g., a first voltage), but if the cell represents a binary "1", the cell can output another voltage (e.g., a second voltage).) Cells that store only a single bit have also come to be called Single Level Cells (SLC).

[0052] A Multi-Level Cell (MLC) refers to a cell that stores more than one bit. Although "multi" is understood to mean "two or more," in practice, MLCs can generally store two bits, while Triple Level Cells (TLCs) can store three bits, and Quad-Level Cells (QLCs) can store four bits. Because MLCs (and all other types of cells that store more than one bit) store a large number of bits, MLCs have a large number of trigger voltages. For example, if the input voltage can vary from 0V to 5V, MLCs can have trigger voltages at 1V, 2V, 3V, and 4V. Depending on the trigger voltage, the flash memory chip can determine the actual value stored in the cell. Thus, for example, if the trigger voltage is 1V, the cell can store a value 00, if the trigger voltage is 2V, the cell can store a value 01, if the trigger voltage is 3V, the cell can store a value 10, and if the trigger voltage is 4V, the cell can store a value 11.

[0053] Various cell types have different advantages / disadvantages. Obviously, being able to store more than one bit of information per cell means that fewer cells are needed to store the same amount of data. Thus, when data is stored in SLC, more SLC is needed than MLC, TLC, or QLC would need to store the same amount of data. Although individual cells that store more bits tend to be more expensive than cells that store fewer bits, the increased cost may be offset by the need for fewer such cells. Thus, to store the same amount of data, QLC is generally cheaper than TLC, which is cheaper than MLC, which is cheaper than SLC.

[0054] However, there are other factors that can offset the cost. First, because an SSD must test a cell against several other voltages to determine the value stored in the cell, the more such tests that must be performed, the worse the cell's performance may be. Consider QLC, for example. Since QLC stores 4 bits of data, it can take any one of 16 possible values. Reading a QLC may therefore require testing it against 16 possible trigger voltages, which takes longer than testing the cell against two trigger voltages. Thus, QLC is read slower than TLC, which is read slower than MLC, which is slower than SLC. Note that the more bits a cell can store, the fewer program / erase cycles it may have over its lifetime. For example, SLC may guarantee 100,000 program / erase operations before the cell fails, but that may fall to 10,000 for MLC, 1,000 for TLC, and 100 for QLC. Thus, different types of cells are better used for different storage profiles. That is, QLC is more commonly used to store data that changes rarely, while SLC is used for data that changes relatively frequently.

[0055] A final drawback of the cell type is again associated with the number of trigger voltages required for a cell to store higher density data. The more trigger voltages there are, the closer they are to each other. However, the closer the trigger voltages are to each other, the greater the cell's vulnerability to potential errors. For example, consider QLC. QLC can store 4 bits of data, so there are 16 possible values ​​for QLC. 16 trigger voltages may be required to distinguish between the 16 possible values, which means that the gap between trigger voltages may be slightly larger than 0.25V. While the cell may think it is responding to a different voltage than what was actually intended, no sudden voltage dip or surge is required, which means that QLC may respond incorrectly to an attempt to read the cell. (This same analysis can also be applied to MLC and TLC cell types, even though there is a larger margin of error due to the fewer trigger voltages to consider.)

[0056] So, going back to the reliability issue, QLC can store a higher data density, but at the cost of a reduced margin for error. However, even though a QLC (or any type of cell that stores more than one bit of data) can store a large number of bits, it does not mean that the QLC must store a large number of bits. Such a QLC may be used to store less than four bits of data, and any values ​​assigned to other bits of the QLC are ignored in a read operation. Storing fewer bits in a QLC reduces the number of effective trigger voltages, increasing the margin for error. (A QLC may still be hardwired to test all 16 trigger voltages, but the time required to access the cell is not reduced, only the likelihood of an error.)

[0057] For example, suppose a QLC was used to store just one bit of data. This value (0 or 1) is stored in one of the four bits of the QLC, and the other bits are effectively ignored by the SSD (i.e., the bit is assigned an arbitrary value when the cell is written, any value read from it is ignored, and only the bit of interest is returned). Because the QLC now effectively has only one trigger voltage, the chances of a cell being written incorrectly (e.g., due to voltage fluctuations) or read incorrectly are reduced.

[0058] Therefore, even by changing the operational behavior of the flash memory chips (315-1 to 315-8), it is possible to affect the reliability of the SSD. However, there are some caveats to consider. First, whether changing the operational behavior of the flash memory chips (315-1 to 315-8) affects the reliability of the SSD depends on the type of cells used in the flash memory chips (315-1 to 315-8). The higher the data density of the cells, the more options there are that can affect the reliability of the SSD. For example, SLC stores only one bit of data, so changing the behavior of the SLC may not improve the reliability of an SSD that uses only SLC.

[0059] It should be noted that the above improvements only work in one direction. A cell capable of storing higher density data can be used to store lower density data by ignoring some bits of the cell. However, one cannot decrease the reliability of the SSD by trying to store more bits in the cell than the cell can store. For example, one cannot store 2 bits in an SLC (regardless of the decrease in reliability that can be tolerated) because an SLC can only store 1 bit of data. (Of course, a cell that stores fewer bits than it can store can have its data density increased, provided that the increase does not exceed the cell's capabilities. So, for example, if a QLC that can store 4 bits currently stores only 2 bits, the data density can be increased to 3 or 4 bits, but not to 5 bits.)

[0060] Second, storing fewer bits than can be stored in a cell, such as using the flash memory chips (315-1 through 315-8) to store all of the same data, can reduce the usable storage in the SSD. For example, consider an SSD with a total available storage capacity of 1 TB using QLC cells. If only one bit per cell is stored using QLC, the effective capacity of the SSD is only 256 GB (25% of the total available storage capacity). The remaining 768 GB of storage is "lost" in unused bits of QLC.

[0061] However, different flash memory chips may be configured to achieve different overall reliability. Thus, for example, assume that flash memory chips 315-1 through 315-8 all use QLC cells. Flash memory chip 315-1 may be configured to store only one bit in each cell, thereby providing increased reliability at the expense of reduced available storage. Meanwhile, flash memory chip 315-2 may be configured to store four bits in each cell, thereby providing maximum available storage at the expense of reduced reliability.

[0062] The configuration module 340 may be implemented using a general purpose processor executing appropriate instructions, or using an FPGA, ASIC, GPU, or any other desired implementation. In FIG. 3, the ECC module 330, the RAID / erasure coding module 335, and the configuration module 340 are illustrated as different components. These components are implemented as separate components because they may be manufactured and installed separately in the SSD 130. Also, such components may actually be in different physical locations. For example, as described above with reference to FIG. 5 and further discussed, the ECC module 330 may be applied to an individual channel (but to multiple memory chips), while the RAID / erasure coding module 335 is applied across multiple channels. In such a configuration, it is unlikely that any of the ECC module 330, the RAID / erasure coding module 335, and the configuration module 340 will be implemented using common hardware. However, in some embodiments of the inventive concept, some or all of these components are implemented using common hardware.

[0063] While the above discussion has focused on what configuration module 340 can do to configure memory chips (315-1 through 315-8), ECC module 330, and RAID / erasure coding module 335, nothing has yet been discussed regarding how configuration module 340 can be triggered to perform such operations. Figures 5 and 6 below discuss the operations that configuration module 340 can be triggered to perform.

[0064] Finally, to support the configuration module 340, the SSD 130 may include a reliability table storage 345. The reliability table storage 345 may store a reliability table that may provide information regarding the reliability provided by the combination of the various schemes used by the memory chips (315-1 through 315-8), the ECC module 330, and the RAID / erasure coding module 335.

[0065] FIG. 4 illustrates a reliability table for the SSD 130 of FIG. 1. In FIG. 4, a reliability table 405 is shown. The reliability table 405 includes various columns such as a storage scheme 410, an ECC scheme 415, and an erasure coding scheme 420. Collectively, the storage scheme 410, the ECC scheme 415, and the erasure coding scheme 420 constitute a configuration 425. That is, for a given entry in the reliability table 405, the storage scheme 410, the ECC scheme 415, and the erasure coding scheme 420 specifically specify how the memory chips (315-1 to 315-8) of FIG. 3, the ECC module 330 of FIG. 3, and the RAID / erasure coding module 335 of FIG. 3 may be configured. Other columns may include reliability 470 (which may specify the overall reliability of a given configuration), space overhead 430 (which may specify any space limitations that arise from using a particular configuration), and performance 435 (which may specify any performance limitations that arise from using a particular configuration). If reliability is the only strong consideration for how to configure the SSD 130 of FIG. 1, then space overhead 430 and performance 435 may be omitted from the reliability table 405.

[0066] The reliability table 405 may include an entry for each possible configuration of the SSD 130 of FIG. 1. For example, FIG. 4 illustrates a reliability table including six entries (440, 445, 450, 455, 460, 465), each of which represents a different possible configuration of the SSD 130 of FIG. 1. Thus, for example, entry 440 identifies the reliability for a configuration that uses a first storage scheme (Storage1) for the memory chips (315-1 through 315-8) of FIG. 3, a first ECC scheme (ECC1) for the ECC module 330 of FIG. 3, and a first erasure coding scheme (EC1) for the RAID / erasure coding module 335 of FIG. 3. For this configuration, the overall reliability is calculated based on the total number of reads or writes that have been recorded or read. 123, a one error in one bit. This configuration also does not impose any space or performance overhead (e.g., entry 440 may indicate a basic configuration for SSD 130 of FIG. 1, where the reliability ratio for entry 440 may be the advertised reliability ratio for SSD 130 of FIG. 1). In contrast, entry 445 indicates a configuration that uses a second storage scheme (Storage2) for the memory chips (315-1 through 315-8) of FIG. 3, a first ECC scheme (ECC1) for ECC module 330 of FIG. 3, and a first erasure coding scheme (EC1) for RAID / erasure coding module 335 of FIG. 3. This configuration is used to determine the reliability of 10000 bits written or read. 14 A single error in a bit has a certain reliability ratio and imposes a 50% reduction in the available storage capacity (but no performance overhead) of SSD 130 of Figure 1. For example, entry 445 may indicate a configuration in which, for redundancy, data is recorded to two different memory chips, which improves the overall reliability of SSD 130 but at the cost of reducing the amount of available storage.

[0067] Entries (450, 455) are similar to entries (440, 445), but have the ECC module 330 of FIG. 3 using a second ECC scheme (ECC2). As can be seen, this configuration provides 10 16 and 10 18 1 error in 1 bit, i.e., 10 4 However, because the second ECC scheme (ECC2) may require more computational resources than the first ECC scheme (ECC1), the configuration represented by entries (450, 455) may impose a 25% performance hit (i.e., SSD 130 of FIG. 1 may require 25% more time to process read and / or write requests using the configuration represented by entries (450, 455) than the configuration represented by entries (440, 445).

[0068] Entries (460, 465) are similar to entries (440, 445), but have the RAID / erasure coding module 335 of FIG. 3 using a second erasure coding scheme (EC2). As can be seen, these configurations are 10 14 and 10 17 The second erasure coding scheme (EC2) may require more computational resources than the first erasure coding scheme (EC1), so the configuration indicated by entries (460, 465) may impose a 10% performance hit (i.e., SSD 130 of FIG. 1 may require 10% more time to process read and / or write requests using the configuration indicated by entries (460, 465) than the configuration indicated by entries (440, 445).

[0069] Note that the improvement provided by only the second erasure coding scheme (EC2) is not the same for all of the configurations shown by entries (460, 465). Entries (460, 465) illustrate the fact that combining different schemes for different components of SSD 130 of FIG. 1 can provide improvements over just one component providing any reliability, but the benefits of combining schemes for different components are not completely orthogonal. In other words, using the reliability options of multiple components can be superior to using one reliability option of a single component, but when using all of both components to improve reliability, the reliability of both components is not simply multiplied to determine the reliability ratio. Thus, for example, the 10 bits read or written from memory chips (315-1 to 315-8) of FIG. 3, ECC module 330 of FIG. 3, and RAID / erasure coding module 355 of FIG. 3 may be combined to provide improvements over just one component providing any reliability. 10Even if a particular scheme provides an error rate of one error in a bit, using all three schemes together does not necessarily result in a 10% error in a read or recorded bit. 30 It does not result in an error rate of having one error in a bit.

[0070] Therefore, if the reliability ratio of a combination of schemes is not calculated as the product of the reliability ratios of the individual schemes, how is the reliability ratio of a particular configuration determined for an entry in reliability table 405? The answer is that the manufacturer of SSD 130 of FIG. 1 tests all possible configurations individually. That is, various SSDs are configured to use each possible combination of configurations. Such SSDs are then tested to ascertain their respective error rates (and space and performance overheads). This information is then stored in reliability table 405 for all SSDs manufactured to the same specifications.

[0071] It is noted that while Figure 4 illustrates only a combination of different schemes for reliability using each of the memory chips (315-1 through 315-8) of Figure 3, the ECC module 330 of Figure 3, and the RAID / erasure coding module 335 of Figure 3, the reliability table 405 could also be used to indicate the reliability ratios (and space and performance overhead, if desired) of the individual schemes. For example, the reliability table 405 could include entries for the first and second storage schemes (Storage1, Storage2) of the memory chips (315-1 through 315-8) of Figure 3 without the associated schemes for the ECC module 330 of Figure 3 or the RAID / erasure coding module 335 of Figure 3, in which case these entries could indicate the reliability ratios using the first and second storage schemes (Storage1, Storage2), respectively (without adding any reliability boost from the ECC module 330 of Figure 3 or the RAID / erasure coding module 335 of Figure 3). Similarly, the reliability table 405 may simply include entries for the first and second ECC schemes (ECC1, ECC2) and / or the first and second erasure coding schemes (EC1, EC2).

[0072] The reliability table 405 may be searched along a number of axes. For example, the reliability table 405 is used to determine the reliability (and other consequences such as space overhead and / or performance) of a particular configuration. The reliability table 405 is also used to determine configurations that support a particular reliability. That is, given a particular desired reliability ratio, the reliability table 405 is searched to find a particular configuration that provides that reliability ratio (or a superior reliability ratio).

[0073] If multiple settings can provide a desired reliability ratio (or a superior reliability ratio), the settings module 340 of FIG. 3 can select among the options using any desired approach. For example, the settings module 340 of FIG. 3 can select the setting that provides the lowest reliability ratio or the highest reliability ratio that meets or exceeds the desired reliability ratio. The settings module 340 of FIG. 3 can also select the setting that provides a sufficient reliability ratio with the fewest other consequences using the space overhead and / or performance consequences of the settings (if included in the reliability table 405). The settings module 340 of FIG. 3 can also use any other desired technique to select among the multiple settings that provide sufficient reliability.

[0074] To aid in identifying a particular combination in the trust table 405, the trust table 405 may also include an identifier 475. The identifier 475 may be a unique identifier assigned to each entry in the trust table 405. Thus, for example, entry 440 may be assigned the identifier "1", entry 445 may be assigned the identifier "2", etc. Note that the identifier 475 need not be numeric or sequential. For example, the identifier 475 may be any string, or a hash of the information represented in the entry, or any other desired identifier. The only useful element is that the identifier 475 is unique, so that a unique entry in the trust table 405 can be found using a given identifier.

[0075] Returning to Figure 3, although Figure 3 illustrates SSD 130 including eight memory chips (315-1 through 315-8) organized into four channels (320-1 through 320-4), embodiments of the present invention may support any number of memory chips organized into any number of channels. Similarly, while Figure 3 illustrates the structure of an SSD, other storage devices (e.g., hard disk drives) may be implemented using different structures but with similar potential advantages.

[0076] Figure 5 illustrates an alternative view of the SSD 130 of Figure 1. In Figure 5, the SSD 130 is illustrated as including a RAID / erasure coding module 335, an ECC module (330-1, 330-2, 330-3), and can operate along respective channels (320-1, 320-2, 320-3). The channels (320-1, 320-2, 320-3) include memory chips (315-1, 315-3, 315-5). Thus, data is organized using RAID or erasure coding to be stored on multiple memory chips, each of which may be on a different (or the same) channel.

[0077] Data is received from applications (505-1, 505-2) (although there can be any number of applications (one or more)). Each application can have its own desired reliability (510-1, 510-2). The desired reliability of each application indicates the reliability ratio that the application desires. The desired reliability (510-1, 510-2) does not have to be in agreement (or even identical); each application can expect a different reliability ratio.

[0078] Each application (505-1, 505-2) may have its own associated namespace (515-1, 515-2). The namespaces (515-1, 515-2) provide a way to organize the data coming in from each application so that it can be easily identified and / or grouped. The use of namespaces (515-1, 515-2) is optional.

[0079] Figure 5 illustrates the concept of data deduplication and compression. Data deduplication refers to the idea that there may be multiple copies of a particular piece of data stored on the SSD 130. Instead of storing multiple copies, a single copy is stored and the other copies reference the stored copy. In this way, the amount of space used to store multiple files is reduced.

[0080] For example, consider image files such as photographs. It is not uncommon for the same photograph to be stored multiple times, perhaps under different file names (as it is easy to forget that a photograph was previously stored under a different name). However, it is easy enough for the host machine or SSD 130 to recognize that a particular file is a duplicate of a previously stored file (assuming SSD 130 includes some processing power to identify duplicate files). There is no need to store the same photograph multiple times; a single copy (with a reference from another folder where a duplicate is stored) is sufficient.

[0081] An example of how duplicate data may be identified is where a cryptographic hash is generated for each file. If the cryptographic hashes of both files are identical, then there is a (possibly strong) possibility that both files contain identical data. Thus, determining whether a new file is a duplicate of a file already stored on SSD 130 simply involves generating a cryptographic hash for the new file, comparing it to the cryptographic hashes of other files (possibly using a hash table), and, if there is a match, comparing (in detail) the data of the matching file.

[0082] It should be noted that data deduplication can operate on any desired unit of data. A file is a common unit for data deduplication, but other units could be blocks or pages (units of data within SSD 130). Other units of data may also be used.

[0083] On the other hand, compression refers to the technique whereby data is stored in a way that takes up less space than the raw data. For example, the number 10 100 (commonly known as googol). To store this number as a raw value, it takes about 2 300 Bit or 2 38 bytes would be needed (assuming a computer was designed to store such a large integer). Alternatively, this number could be represented as a "1" followed by a "1" followed by 100 "0". Using an encoding scheme such as Run Length Encoding, this value could be represented using the four bytes 1, 1, 100, 0 (i.e., one copy of the "1" value and 100 copies of the "0" value). The four bytes would take 2 38 Since it's much smaller than a byte, the space savings of using an encoding on this value are no exaggeration. (The term "compression" commonly refers to algorithms that encode data using structures like Huffman codes, but in this context "compression" refers to any technique used to reduce the amount of space that data takes up, and thus includes techniques commonly referred to using terms like "encoding.")

[0084] While data deduplication and compression have their own advantages in terms of reducing the "footprint" of data that can occupy on a storage device, they also have potential disadvantages, especially when discussing errors. For example, assume that a particular file stored on SSD 130 actually contains data for five different files (one original and four copies). Because the four copies point to the same data as the original file, if there is a single bit error anywhere in the stored file, the error will be read every time any other file is accessed. Thus, a single bit error on the data stored on SSD 130 would actually be realized as a five bit error; that is, an identical bit error in the original file and each of the copies. In other words, data deduplication techniques magnify the error rate of SSD 130 by the number of referenced copies of the file.

[0085] Similarly, compression can affect what the true error rate is. 100 Consider again the example of how to store 10. If a value of '0' changes to '1' (single bit error), the error will be propagated over the entire length of the encoding. 100 , the encoding shows the digit "1" repeated 101 times - i.e. a very different value. Thus, a single bit error in the compressed data can actually mean a much larger number of bit errors. As a general guide, a single (single) bit error can be roughly magnified in proportion to the compression ratio of the technique used. Thus, if a compression technique compresses the data by 2 (i.e., takes up half the space), a single bit error effectively means two bits of error in the data. If a compression technique compresses the data by 3 (i.e., takes up one-third the space), a single bit error effectively means three bits of error in the data (in the worst case, a single bit error in the compressed data may actually not recover the raw data at all).

[0086] Thus, while the entries in the reliability table 405 of FIG. 4 may be a useful starting point for the reliability of the SSD 130, they may not be completely indicative of the true reliability of the SSD 130. To that end, the SSD 130 (perhaps via the configuration module 340) may track transactions (data deduplication and compression are two examples) performed on behalf of the applications (505-1, 505-2). The SSD 130 then uses such transactions to determine a multiplier. The reliability of the SSD 130 (determined from the reliability table 405 of FIG. 4 based on the configuration of the SSD 130) is multiplied by this multiplier to determine the effective reliability ratio of the SSD 130.

[0087] The multiplier for the reliability ratio may be determined using any desired approach. For example, the SSD 130 may track a particular transaction, determine the applicable multiplier for that transaction, and then maintain the greater of that multiplier and the previous multiplier. However, this method assumes that the multipliers are independent of each other. Such an assumption may be reasonable if data deduplication is the only technique used that can introduce a multiplier, or if compression is the only technique used that can introduce a multiplier. However, if data deduplication is applied to a compressed file, single bit errors may be magnified as a result of both space-saving techniques.

[0088] Thus, SSD 130 can track not only the highest multiplier to date, but also the highest multiplier applicable to each space saving scheme individually. In this manner, SSD 130 can consider not only whether the new multiplier is the highest multiplier for a single scheme, but also whether the multiplier can cross schemes. For example, assume that SSD 130 is currently tracking the following conditions (assuming that the compressed file has not been stored more than once on SSD 130): highest compression multiplier 2.0, highest data deduplication multiplier 5.0, and highest overall multiplier 5.0. So, if SSD 130 tracks that a previously compressed and deduplicated file has been recorded a third time, this means that three copies of that file have now been stored (deduplicated) on SSD 130. Thus, this transaction does not increase the highest compression multiplier (because no new compression has occurred) or the highest deduplication multiplier (because the current maximum number of copies of all files is 5), but the highest overall multiplier is increased to 6.0. Thus, whatever the reliability ratio (as known from reliability table 405 of FIG. 4 ) is, that reliability ratio is multiplied by 6.0 to determine the effective reliability of SSD 130 (because there are three copies of the compressed file subject to a multiplier of 2.0). Alternatively, SSD 130 tracks the highest multiplier for each of compression and data deduplication, and applies all two to the reliability to determine the minimum effective reliability of SSD 130. (This calculation may overemphasize the impact of transactions, since there may not be data stored on SSD 130 to which compression and data deduplication are all applied, but a conservative calculation may be used nonetheless.)

[0089] Such an effect of a transaction on the effective reliability of SSD 130 may also be considered in the selection of settings for SSD 130. For example, knowing that there is a multiplier due to the data stored in SSD 130, the settings module 340 may use the multiplier when comparing the reliability of various settings to the desired reliability (510-1, 520-2) of the application (505-1, 505-2). That is, simply comparing the reliability listed in the reliability table 405 of FIG. 4 to the desired reliability (510-1 and 520-2) may not be sufficient. That is, the reliability listed in the reliability table 405 of FIG. 4 may need to be adjusted according to the multiplier to reflect the effective reliability of SSD 130, given the data currently stored in SSD 130.

[0090] FIG. 6 illustrates messages exchanged between the application (505-1) of FIG. 5 and the SSD 130 of FIG. 1. In one embodiment of the inventive concept, the application (505-1) can transmit a reliability message 605 to the SSD 130. That is, the reliability message 605 can include the desired reliability (510-1) of FIG. 5. (Although not illustrated in FIG. 6, the application (505-2) of FIG. 5 can also transmit their own desired reliability along with other applications that use the SSD 130.) The SSD 130 can then configure itself (using the configuration module 340 of FIG. 3) to satisfy all the offered desired reliability (i.e., by satisfying the strictest offered reliability), as illustrated by self configuration 610.

[0091] However, in another embodiment of the inventive concept, the application (505-1) can transmit a reliability request 615, which can request the valid reliability of the SSD 130 (determined as described above), which is returned as a message 620. The application (505-1) can also transmit a reliability table request 625, which can request the reliability table 405 of FIG. 4 from the SSD 130. The SSD 130 can respond by returning the reliability table 405 of FIG. 4 in a message 630. The application (505-1) can then select a configuration that provides sufficient reliability (the desired reliability (510-1) of FIG. 5 or some better configuration) and transmit a configuration request 635 to the SSD 130, which allows the application (505-1) to identify the desired reliability table 405 of FIG. 4 entry. The SSD 130 can then self-configure based on the identified reliability table 405 entry, as illustrated by self-configure 640.

[0092] However, note that the self configuration 640 is shown with a dotted line. This is for two reasons. First, the application (505-1) would likely compare the effective reliability ratio received in message 620. That is, if the effective reliability ratio is higher than the desired reliability (510-1) of FIG. 5, the application (505-1) would not transmit the configuration request 635 (in which case no self configuration 640 is required). However, in some embodiments of the inventive concept, the application (505-1) may not request an effective reliability from the SSD 130, but instead select a desired configuration from the reliability table 405 of FIG. 4, and transmit the configuration request 635 accordingly. In such an embodiment of the inventive concept, the SSD 130 (possibly via the configuration module 340) may compare the effective reliability with the configuration identified in the configuration request 635. If the effective reliability of the SSD 130 is greater than the reliability of the configuration identified in the configuration request 635, the SSD 130 may skip self configuration 640 (because the current configuration is already sufficient).

[0093] Second, as mentioned above, the application (505-1) may not operate independently. Other applications (such as application (505-2) in FIG. 5) may transmit their own configuration requests 635. In this case, the SSD 130 may select a self-configuration in a manner that satisfies all applications, and may therefore configure according to the configuration with the highest reliability ratio (under the assumption that the application requesting that configuration may not be satisfied with a less reliable configuration). Thus, the SSD 130 may perform a self-configuration 640, but the self-configuration 640 may include (accompany) a different configuration than that specified in the configuration request 635.

[0094] In FIG. 6, the configuration module 340 may be responsive to an application (505-1) when configuring the SSD 130 of FIG. 1. However, the configuration module 340 may also act "autonomously" to configure the SSD 130 of FIG. 1. For example, given a desired reliability (which may be the desired reliability (510-1) of FIG. 5 received from the application (505-1) in a reliability message 605, among other possibilities, or the advertised reliability of the SSD 130 of FIG. 1 by the manufacturer), the configuration module 340 may track the effective reliability of the SSD 130 of FIG. 1. If the effective reliability of the SSD 130 of FIG. 1 falls below the desired reliability, in order to ensure that the reliability of the SSD 130 of FIG. 1 is maintained at an acceptable level, the configuration module 340 may select a new configuration that provides the desired reliability (taking into account any multipliers).

[0095] It is worth mentioning how the configuration module 340 can configure the SSD 130 of FIG. 1. As mentioned above, the entries in the reliability table 405 of FIG. 4 specify the particular scheme to be used by the memory chips (315-1 to 315-8) of FIG. 3, the ECC module 330 of FIG. 3, and the RAID / erasure coding module 335 of FIG. 3. To configure the SSD 130 of FIG. 1, the configuration module 340 can instruct these components as to what scheme to use. That is, the configuration module 340 can instruct the memory chips (315-1 to 315-8) of FIG. 3 to store a particular number of bits in each cell, can instruct the ECC module 330 of FIG. 3 to use a particular ECC scheme, and / or can instruct the RAID / erasure coding module 335 of FIG. 3 to use a particular erasure coding scheme. It is noted that changing the scheme where data is already present (in place) may involve reading the data from the SSD 130 of FIG. 1 and changing the scheme applied to the data such that sufficient reliability is maintained. Thus, for example, if data is currently stored using 4 bits in each QLC cell, but now needs to be stored in only 2 bits in each QLC cell, the data would be read out of the memory chips (315-1 through 315-8) of Figure 3, temporarily buffered somewhere (in some local storage or in the main memory of server 110), and then re-recorded in the memory chips (315-1 through 315-8) using the new storage scheme. Similarly, applying a new ECC or erasure coding scheme may involve reading the data from and recording the data to SSD 130 to apply the changes.

[0096] FIG. 7 illustrates a flow chart of an example procedure for the SSD 130 of FIG. 1 to self-configure to provide a desired reliability, according to an embodiment of the present invention. Referring to FIG. 7, in block 705, the configuration module 340 of FIG. 3 may determine a desired reliability for the SSD 130 of FIG. 1. As described above, the configuration module 340 of FIG. 3 may select the desired reliability itself or may receive the desired reliability (510-1) of FIG. 5 from the application (505-1) of FIG. 5 via a reliability message 605 of FIG. 6. In block 710, the configuration module 340 of FIG. 3 may determine an effective reliability of the SSD 130 of FIG. 1. In block 715, the configuration module 340 of FIG. 3 may compare the desired reliability with the effective reliability of the SSD 130 of FIG. 1 (taking into account any multipliers due to transactions). If the effective reliability is sufficient to satisfy the desired reliability, the process is completed and the configuration module 340 of FIG. 3 does not need to operate further.

[0097] On the other hand, if the effective reliability is less than the desired reliability, then at block 720, configuration module 340 of Figure 3 may access (or access) reliability table 405 of Figure 4 to consider entries therein. At block 725, configuration module 340 of Figure 3 may select an entry from reliability table 405 of Figure 4 that has a reliability at least as high (taking into account any multipliers) as the desired reliability. At block 730, configuration module 340 of Figure 3 may configure SSD 130 of Figure 1 according to the settings of the selected entry from reliability table 405 of Figure 4 before processing can complete.

[0098] FIG. 8 illustrates a flow chart of an example procedure for self-configuring SSD 130 of FIG. 1. Referring to FIG. 8, at block 805, configuration module 340 of FIG. 3 may configure one or more memory chips (315-1 through 315-8) of FIG. 3 to use a particular storage scheme. At block 810, configuration module 340 of FIG. 3 may configure ECC module 330 of FIG. 3 to use a particular error correction code scheme. At block 815, configuration module 340 of FIG. 3 may configure RAID / erasure coding module 335 of FIG. 3 to use a particular erasure coding scheme. Blocks (805, 810, 815) are all individually optional and may be omitted as illustrated by dashed lines (820, 825, and 830).

[0099] 9A-9B show a flowchart of an example procedure for the SSD 130 of FIG 1 to determine a desired reliability. Referring to FIG 9A, at block 905, the SSD 130 of FIG 1 may receive a reliability message 605 of FIG 6, which may specify a desired reliability of the SSD 130.

[0100] Alternatively, referring to Figure 9B, in block 910, the SSD 130 of Figure 1 may receive a reliability request 615 of Figure 6 from the application (505-1) of Figure 5. In block 915, the SSD 130 of Figure 1 may determine an effective reliability of the SSD 130 of Figure 1. In block 920, the SSD 130 may transmit the effective reliability to the application (505-1) of Figure 5 as a message 620 of Figure 6. As illustrated by dotted line 925, blocks (910, 915, 920) are optional.

[0101] In block 930, the application (505-1) of FIG. 5 may transmit a request 625 for a reliability table of FIG. 6. In block 935, the SSD 130 of FIG. 1 may also retrieve the reliability table 405 of FIG. 4 from the storage 345 for reliability tables of FIG. 3. In block 940, the SSD 130 of FIG. 1 may transmit the reliability table 405 of FIG. 4 to the application (505-1) of FIG. 5 as a message 630. Finally, in block 945, the application (505-1) of FIG. 5 may transmit a configuration request 635 to the SSD 130 of FIG. 1. The configuration request 635 may request the configuration module 340 of FIG. 3 to configure the SSD 130 of FIG. 1 based on the entries of the reliability table 405 identified in the configuration request 635 of FIG. 6.

[0102] FIG. 10 illustrates a flowchart of an example procedure for the SSD 130 of FIG. 1 to determine the effective reliability of the SSD 130 of FIG. 1. Referring to FIG. 10, in block 1005, the SSD 130 of FIG. 1 may determine the advertised reliability of the SSD 130 of FIG. 1 (at least in response to the current settings of the SSD 130 of FIG. 1). In block 1010, the SSD 130 may track a current transaction requested by (or on behalf of) the application (505-1) of FIG. 5. In block 1015, the SSD 130 of FIG. 1 may determine a multiplier (or one or more multipliers) in response to the current transaction (and previous transactions). Finally, in block 1020, the SSD 130 of FIG. 1 may multiply the advertised reliability by the multiplier to determine the effective reliability of the SSD 130 of FIG. 1.

[0103] 11A and 11B show a flowchart of an example procedure for an application (505-1) of FIG. 5 to instruct the SSD 130 of FIG. 1 to provide a desired reliability, according to an embodiment of the present invention. Referring to FIG. 11A, in block 1105, the application (505-1) of FIG. 5 can transmit a desired reliability (510-1) of FIG. 5 to the SSD 130 of FIG. 1 (as a reliability message 605 of FIG. 6). At this point, the application (505-1) of FIG. 5 is left to complete on the SSD 130 of FIG. 1 to ensure that the desired reliability (510-1) of FIG. 5 is provided.

[0104] Alternatively, in block 1110, the application (505-1) of FIG. 5 can transmit a reliability request 615 of FIG. 6 to the SSD 130 of FIG. 1. In block 1115, the application (505-1) of FIG. 5 can receive the current effective reliability of the SSD 130 of FIG. 1 in message 620 of FIG. 6. In block 1120, the application (505-1) of FIG. 5 can compare the desired reliability (510-1) of FIG. 5 with the effective reliability of the SSD 130 of FIG. 1 (received in message 620 of FIG. 6). If the effective reliability of the SSD 130 of FIG. 1 is at least as high as the desired reliability (510-1) of FIG. 5, the process is terminated (nothing needs to be done).

[0105] On the other hand, if the effective reliability of the SSD 130 of FIG. 1 is less than the desired reliability (510-1) of FIG. 5 (or if the application (505-1) of FIG. 5 requests that the SSD 130 of FIG. 1 be set to a particular setting regardless of the effective reliability, as indicated by the dashed arrow 1125), then, referring to FIG. 11B, in block 1130, the application (505-1) of FIG. 5 may transmit a request 625 of a reliability table of FIG. 6 to the SSD 130 of FIG. 1. In block 1135, the SSD 130 of FIG. 1 may transmit the reliability table 405 of FIG. 4 as a message 630 to the application (505-1) of FIG. 5. In block 1140, the application (505-1) of FIG. 5 may select an entry from the reliability table 405 of FIG. 4 that provides the desired reliability. Finally, in block 1145, the application (505-1) of FIG. 5 can transmit a configuration request 635 of FIG. 6, requesting that the SSD 130 of FIG. 1 be configured according to the entry selected from the reliability table 405 of FIG. 4.

[0106] With reference to Figures 7-11B, some embodiments of the inventive concept are illustrated. However, one skilled in the art will appreciate that other embodiments of the inventive concept are possible by changing the order of blocks, omitting blocks, or including links not shown in the drawings. All such variations of the flow charts, whether or not explicitly described, are considered to be embodiments of the present invention.

[0107] Embodiments of the present invention provide technical advantages over the prior art. In a typical system, the reliability of a storage device is set by the manufacturer and is essentially outside the control of the user. Embodiments of the present invention not only provide the customer with some degree of control over the reliability of the storage device, but also allow such management to be automated. An application can specify a desired reliability (or can specify a particular setting of the storage device that achieves the desired reliability). The storage device can maintain that level of reliability by changing the settings as needed based on usage of the storage device.

[0108] The following discussion is intended to provide a brief, general description of a suitable machine or machines on which certain aspects of the inventive concept may be implemented. The machine or machines may be controlled, at least in part, by input from traditional input devices such as a keyboard, mouse, etc., as well as instructions received from other machines, interaction with a virtual reality (VR) environment, biometric feedback, or other input signals. As used herein, the term "machine" is intended to broadly include a single machine, a virtual machine, or a system of communicatively coupled machines, virtual machines, or devices operating together. Exemplary machines may include computing devices such as personal computers, workstations, servers, portable computers, handheld devices, phones, tablets, etc., as well as transportation devices such as personal or public transportation (e.g., automobiles, trains, taxis, etc.).

[0109] The machine or machines may include embedded controllers such as programmable or non-programmable logic devices or arrays, Application Specific Integrated Circuits (ASICs), embedded computers, smart cards, and the like. The machine or machines may utilize one or more connections to one or more remote machines, such as a network interface, modem, or other communications coupling, and the like. The machines are interconnected by physical and / or logical networks, such as an intranet, the Internet, a local area network, or a wide area network. Those skilled in the art will recognize that network communications can utilize a variety of wired and / or wireless local area networks and long distance carriers and protocols, including radio frequency (RF), satellite, microwave, IEEE (Institute of Electrical and Electronics Engineers) 802.11, Bluetooth, optical, infrared, cable, laser, and the like.

[0110] Embodiments of the inventive concept are described in conjunction with and refer to associated data including functions, procedures, data structures, application programs, etc. that when accessed by a machine cause the machine to perform tasks or define an abstract data type or low level hardware context. The associated data may be stored in other storage devices and associated storage media including, for example, volatile and / or non-volatile memory such as RAM, ROM, etc., hard drives, floppy disks, optical storage devices, tape, flash memory, memory sticks, digital video disks, or biological storage devices. The associated data may be conveyed over transmission environments including physical and / or logical networks in the form of packets, serial data, parallel data, propagated signals, etc., and may be used in compressed or encrypted formats. The associated data may be used in a distributed environment and may be stored locally and / or remotely for machine access.

[0111] Embodiments of the inventive concept include a tangible, non-transitory, machine-readable medium that includes instructions executable by one or more processors, the instructions including instructions for performing elements of the inventive concept as described herein.

[0112] The various operations of the methods described above may be performed by any suitable means capable of performing operations such as various hardware and / or software configurations, circuits, and / or modules. The software includes an ordered list of executable instructions to perform logical functions and may be implemented on any "processor-readable medium" using or in connection with an instruction execution system, apparatus, or device, such as a single or multi-core processor or a system including a processor.

[0113] The blocks or steps of the methods or algorithms and functions in connection with the embodiments disclosed herein may be implemented directly in hardware and / or software modules executed on a processor. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a non-transitory computer-readable medium. The software modules may be stored on a random access memory (RAM), flash memory, ROM, EPROM, EEPROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0114] Although the principles of the inventive concept have been described and illustrated with reference to the illustrated embodiments, it will be recognized that the illustrated embodiments can be modified in arrangement and detail and can be combined in any suitable manner without departing from such principles. Also, while the above description has focused on specific embodiments, other configurations are contemplated. In particular, although expressions such as "in accordance with an embodiment of the inventive concept" have been used herein, these phrases are intended to generally refer to possible embodiments and are not intended to limit the inventive concept to the configuration of a particular embodiment. As used herein, these terms can refer to the same or different implementations that can be combined with other embodiments.

[0115] The above-described exemplary embodiments should not be construed as limiting the inventive concept. However, although several embodiments have been described, those skilled in the art will readily appreciate that various modifications to these embodiments are possible without substantially departing from the novel teachings and advantages of the present disclosure. Accordingly, all such modifications are intended to be included within the scope of the inventive concept defined in the claims.

[0116] The embodiments of the present invention extend, but are not limited to, the following description.

[0117] Description 1. An embodiment of the present invention includes a solid state drive (SSD). SSDs are an interface for receiving read and record requests from a first application on the host; a storage for data including at least one chip; an SSD controller that uses the storage to process the read requests and the write requests from the first application on the host; a configuration module for configuring the SSD; The system includes storage for a reliability table including at least a first entry and a second entry, the first entry identifying a first configuration of the SSD and a first reliability for the first configuration of the SSD, and the second entry identifying a second configuration of the SSD and a second reliability for the second configuration of the SSD.

[0118] Description 2. An embodiment of the present invention comprises an SSD according to Description 1, wherein the interface is capable of receiving a configuration request from the first application on the host.

[0119] Description 3. An embodiment of the present invention includes an SSD according to description 2, and the configuration request includes an identifier of either a first entry or a second entry in a reliability table.

[0120] Description 4. An embodiment of the present invention includes an SSD according to Description 3, and the configuration module can reconfigure the SSD according to the identifier of either one of the first entry and the second entry in the reliability table.

[0121] Description 5. An embodiment of the present invention has an SSD according to Description 1, wherein the interface is capable of receiving a reliability message from the first application on the host, the reliability message including a first desired reliability for the first application on the host.

[0122] Description 6. An embodiment of the present invention includes an SSD according to Description 5, wherein the configuration module is capable of configuring the SSD according to any one of the first entry and the second entry in the reliability table based on at least the first desired reliability.

[0123] Description 7. An embodiment of the present invention includes an SSD according to Description 6, wherein the configuration module is capable of configuring the SSD in accordance with one of a first entry and a second entry of the reliability table based on at least the first desired reliability for the first application on the host and the second desired reliability for the second application on the host.

[0124] Description 8. An embodiment of the present invention comprises an SSD according to Description 1, in which at least one chip provides a first storage scheme having at least the reliability of the first chip and a second storage scheme having the reliability of the second chip.

[0125] Description 9. An embodiment of the present invention comprises an SSD according to Description 8, wherein a first configuration of the SSD identifies the first storage scheme and a second configuration of the SSD identifies the second storage scheme.

[0126] Description 10. An embodiment of the present invention has an SSD according to Description 1, further including an Error Correcting Code (ECC) module, the ECC module providing at least a first ECC scheme having a first ECC reliability and a second ECC scheme having a second ECC reliability.

[0127] Description 11. An embodiment of the present invention comprises an SSD according to Description 10, wherein the first configuration of the SSD identifies the first ECC scheme and the second configuration of the SSD identifies the second ECC scheme.

[0128] Description 12. An embodiment of the present invention has an SSD according to Description 1, and further includes at least one of an erasure coding module or a RAID (Redundant Array of Independent Disks) module, the erasure coding module providing a first erasure coding scheme having at least a first erasure coding reliability and a second erasure coding scheme having a second erasure coding reliability, and the RAID module providing a first RAID scheme having at least a first RAID reliability and a second RAID scheme having a second RAID reliability.

[0129] Description 13. An embodiment of the inventive concept includes an SSD according to Description 12, wherein the first configuration of the SSD identifies at least one of the first erasure coding scheme or the first RAID scheme, and the second configuration of the SSD identifies at least one of the second erasure coding scheme or the second RAID scheme.

[0130] Description 14. An embodiment of the inventive concept includes an SSD according to Description 1, wherein the first entry of the reliability table identifies at least one of a first spatial overhead or a first performance for the first configuration of the SSD, and the second entry of the reliability table identifies at least one of a second spatial overhead or a second performance for the second configuration of the SSD.

[0131] Description 15. An embodiment of the present invention has an SSD according to Description 1, and the at least one chip includes at least one NAND flash chip.

[0132] Description 16. An embodiment of the present invention includes a method. The method includes: determining a desired reliability for a solid state drive (SSD), the SSD including storage for data, the storage including at least one chip; accessing a first entry of a reliability table from the SSD, the reliability table including at least the first entry and the second entry, the first entry identifying a first configuration of the SSD and a first reliability for the first configuration of the SSD, and the second entry identifying a second configuration of the SSD and a second reliability for the second configuration of the SSD; and configuring the SSD according to the first entry.

[0133] Description 17. An embodiment of the present invention comprises a method according to description 16, the first entry includes a first storage scheme for the chip; a second entry including a second storage scheme for the chip; Configuring the SSD based on the first entry includes configuring the chip according to the first storage scheme or a second storage scheme.

[0134] Description 18. An embodiment of the present invention comprises a method according to description 16, The SSD includes an error correcting code (ECC) module; the first entry includes a first ECC scheme for the ECC module; the second entry includes a second ECC scheme for the ECC module; Configuring the SSD based on the first entry includes configuring the ECC module according to the first ECC scheme or a second ECC scheme.

[0135] Description 19. An embodiment of the present invention comprises a method according to description 16, The SSD includes at least one of an erasure coding module or a redundant array of independent disks (RAID) module; the first entry includes at least one of a first erasure coding scheme for the erasure coding module or a first RAID scheme for the RAID module; a second entry including at least one of a second erasure coding scheme for the erasure coding module or a second RAID scheme for the RAID module; Configuring the SSD based on the first entry includes configuring at least one of the erasure coding module according to the first erasure coding scheme or the second erasure coding scheme, or the RAID module according to the first RAID scheme or the second RAID scheme.

[0136] Remark 20. An embodiment of the present invention comprises a method according to remark 16, wherein determining a desired reliability for the SSD includes receiving the desired reliability at the SSD from an application on the host.

[0137] Description 21. An embodiment of the present invention comprises a method according to Description 20, wherein the step of accessing a first entry of a reliability table from the SSD comprises: accessing the first entry and the second entry of the reliability table; and identifying whether the first entry includes a reliability at least as high as the desired reliability.

[0138] Description 22. An embodiment of the present invention comprises a method according to description 16, receiving, at the SSD, a reliability request from the application on the host for valid reliability of the SSD; determining an effective reliability for the SSD; transmitting the valid reliability from the SSD to the application on the host.

[0139] Description 23. An embodiment of the present invention includes a method according to Description 22, wherein the step of determining an effective reliability for the SSD includes: determining an advertised reliability for the SSD; tracking activity on the SSD; determining a multiplier based on activity on the SSD; and multiplying the advertised reliability by the multiplier to determine the effective reliability.

[0140] Description 24. An embodiment of the present invention comprises a method according to description 16, wherein the step of accessing a first entry of a reliability table from the SSD includes receiving, in the SSD, an identifier of the first entry of the reliability table from the application on the host.

[0141] Description 25. An embodiment of the present invention includes a method according to Description 24, wherein transmitting the valid reliability from the SSD to the application on the host includes transmitting the first entry and the second entry of the reliability table from the SSD to the application on the host.

[0142] Description 26. An embodiment of the present invention comprises a method according to description 16, the first entry in the reliability table identifies at least one of a first spatial overhead or a first performance for the first configuration of the SSD; the second entry in the reliability table identifies at least one of a second spatial overhead or a second performance for a second configuration of the SSD; Accessing a first entry of a reliability table from the SSD includes accessing the first entry of the reliability table from the SSD based at least on a desired reliability and based on at least one of a desired space overhead or a desired performance.

[0143] Description 27. An embodiment of the present invention comprises a method according to description 16, wherein the at least one chip includes at least one NAND flash chip.

[0144] Description 28. An embodiment of the present invention includes a method. The method includes: transmitting a reliability request from an application on the host to the SSD, the reliability request requesting a valid reliability for the SSD; receiving, at the application on the host, from the SSD, a valid reliability for the SSD; transmitting a request for a reliability table from the application on the host to the SSD, the request for the reliability table requesting a reliability table stored in the SSD; receiving, at the application on the host, the reliability table from the SSD, each entry in the reliability table identifying a reliability for a setting of the SSD and a configuration of the SSD; selecting an entry from the trust table based at least on a desired trust for the application on the host; transmitting a configuration request from the application on the host to the SSD, the configuration request identifying the entry in the reliability table.

[0145] Description 29. An embodiment of the present invention comprises a method according to description 28, comparing an effective reliability for the SSD with a desired reliability for the application on the host; The method further includes not transmitting the configuration request to the SSD if the desired reliability for the application on the host is exceeded based at least on an effective reliability for the SSD.

[0146] Description 30. An embodiment of the present invention comprises a method according to description 28, wherein selecting an entry in the reliability table based on at least a desired reliability for the application on the host comprises selecting (for the entry) the entry in the reliability table for which the reliability for a configuration of the SSD is at least as high as the desired reliability.

[0147] Description 31. An embodiment of the present invention comprises a method according to description 28, each entry in the reliability table further identifies at least one of a first spatial overhead or a first performance for the configuration of the SSD; a second entry in the reliability table further identifying at least one of a second spatial overhead or a second performance; Selecting an entry in a reliability table based on at least a desired reliability for the application on the host includes selecting an entry in the reliability table based on at least a desired reliability for the application on the host and based on at least one of the desired space overhead or desired performance.

[0148] Description 32. An embodiment of the present invention is an article including a non-transitory storage medium having stored thereon instructions that, when executed by a machine, perform the following steps: determining a desired reliability for a solid state drive (SSD), the SSD including storage for data, the storage including at least one chip; accessing a first entry of a reliability table from the SSD, the reliability table including at least a first entry and a second entry, the first entry identifying a first configuration of the SSD and a first reliability of the SSD for the first configuration, and the second entry identifying a second configuration of the SSD and a second reliability of the SSD for the second configuration; and configuring the SSD according to the first entry.

[0149] Description 33. An embodiment of the present invention comprises an article according to description 32, the first entry includes a first storage scheme for the chip; the second entry includes a second storage scheme for the chip; Configuring the SSD based on the first entry includes configuring the chip based on the first storage scheme or a second storage scheme.

[0150] Description 34. An embodiment of the present invention comprises an article according to description 32, The SSD includes an error correcting code (ECC) module; the first entry includes a first ECC scheme for the ECC module; the second entry includes a second ECC scheme for the ECC module; Configuring the SSD based on the first entry includes configuring the ECC module according to the first ECC scheme or a second ECC scheme.

[0151] Description 35. An embodiment of the present invention comprises an article according to description 32, The SSD includes at least one of an erasure coding module or a redundant array of independent disks (RAID) module; the first entry includes at least one of a first erasure coding scheme for the erasure coding module or a first RAID scheme for the RAID module; a second entry including at least one of a second erasure coding scheme for the erasure coding module or a second RAID scheme for the RAID module; Configuring the SSD based on the first entry includes configuring at least one of the erasure coding module according to the first erasure coding scheme or the second erasure coding scheme, or the RAID module according to the first RAID scheme or the second RAID scheme.

[0152] Remark 36. An embodiment of the present invention includes an article according to Remark 32, wherein determining a desired reliability for the SSD includes receiving the desired reliability at the SSD from an application on the host.

[0153] Description 37. An embodiment of the present invention includes an article according to Description 36, wherein the step of accessing a first entry of a reliability table from the SSD includes: accessing the first entry and the second entry of the reliability table; Identifying whether the first entry includes a reliability at least as high as the desired reliability.

[0154] Description 38. An embodiment of the present invention includes an article according to description 32, the article including a non-transitory storage medium having stored thereon instructions which, when executed by a machine, further perform the following steps: receiving, at the SSD, a reliability request from the application on the host for valid reliability of the SSD; determining an effective reliability for the SSD; transmitting the valid reliability from the SSD to the application on the host.

[0155] Description 39. An embodiment of the present invention includes an article according to description 38, wherein the step of determining the effective reliability for the SSD includes: determining an advertised reliability for the SSD; tracking activity on the SSD; determining a multiplier based on activity on the SSD; and multiplying the advertised reliability by the multiplier to determine the effective reliability.

[0156] Description 40. An embodiment of the present invention includes an article according to description 38, wherein accessing a first entry in a reliability table from the SSD includes receiving, at the SSD, an identifier of the first entry in the reliability table from the application on the host.

[0157] Description 41. An embodiment of the present invention includes an article according to description 40, wherein transmitting the valid reliability from the SSD to the application on the host includes transmitting the first entry and the second entry of the reliability table from the SSD to the application on the host.

[0158] Description 42. An embodiment of the present invention comprises an article according to description 32, the first entry in the reliability table identifies at least one of a first spatial overhead or a first performance for the first configuration of the SSD; the second entry in the reliability table identifies at least one of a second spatial overhead or a second performance for a second configuration of the SSD; Accessing a first entry of a reliability table from the SSD includes accessing the first entry of the reliability table from the SSD based at least on a desired reliability and based on at least one of a desired space overhead or a desired performance.

[0159] Description 43. An embodiment of the present invention includes an article according to description 32, wherein the at least one chip includes at least one NAND flash chip.

[0160] Description 44. An embodiment of the present invention is an article including a non-transitory storage medium having stored thereon instructions that, when executed by a machine, perform the following steps: transmitting a reliability request from an application on the host to the SSD, the reliability request requesting a valid reliability for the SSD; receiving, at the application on the host, from the SSD, a valid reliability for the SSD; transmitting a request for a reliability table from the application on the host to the SSD, the request for the reliability table requesting a reliability table stored in the SSD; receiving, at the application on the host, the reliability table from the SSD, each entry in the reliability table identifying a reliability for a setting of the SSD and a configuration of the SSD; selecting an entry from the trust table based at least on a desired trust for the application on the host; The method includes transmitting a configuration request from the application on the host to the SSD, the configuration request identifying the entry in the reliability table.

[0161] Description 45. An embodiment of the present invention comprises an article according to description 44, the article including a non-transitory storage medium having stored thereon instructions which, when executed by a machine, further perform the following steps: comparing an effective reliability for the SSD with a desired reliability for the application on the host; The method further includes not transmitting the configuration request to the SSD if the desired reliability for the application on the host is exceeded based at least on an effective reliability for the SSD.

[0162] Description 46. An embodiment of the present invention includes an article according to description 44, wherein selecting an entry in the reliability table based on at least a desired reliability for the application on the host includes selecting an entry in the reliability table where the reliability for a configuration of the SSD is at least as high as the desired reliability.

[0163] Description 47. An embodiment of the invention comprises an article according to description 44, each entry in the reliability table further identifies at least one of a first spatial overhead or a first performance for the configuration of the SSD; a second entry in the reliability table further identifying at least one of a second spatial overhead or a second performance; Selecting an entry in a reliability table based on at least a desired reliability for the application on the host includes selecting an entry in the reliability table based on at least a desired reliability for the application on the host and based on at least one of the desired space overhead or desired performance.

[0164] In conclusion, in view of the various modifications to the embodiments described herein, this detailed description and the accompanying materials are intended to be exemplary only and should not be deemed to limit the scope of the inventive concepts. What is claimed as the inventive concepts, therefore, is all modifications that may come within the scope and spirit of the following claims and equivalents thereto.

Claims

1. an interface for receiving read and write requests from a first application on the host; storage for data including at least one chip; a controller of a solid state drive (SSD) that uses the storage to process the read requests and the write requests from the first application on the host; A configuration module for configuring the SSD; storage for a reliability table; the reliability table includes at least a first entry and a second entry, the first entry identifying a first configuration of the SSD and a first reliability for the first configuration of the SSD, and the second entry identifying a second configuration of the SSD and a second reliability for the second configuration of the SSD; The interface receives a configuration request from the first application on the host.

2. The configuration request includes an identifier of one of the first entry and the second entry in the reliability table.

2. The SSD of claim 1 .

3. the interface receiving a reliability message from the first application on the host, the reliability message including a first desired reliability for the first application on the host; 2. The SSD of claim 1 .

4. the configuration module configures the SSD based on at least the first desired reliability based on one of the first entry and the second entry in the reliability table; The SSD of claim 3.

5. the at least one chip providing at least a first storage scheme having a reliability of a first chip and a second storage scheme having a reliability of a second chip; 2. The SSD of claim 1 .

6. a first configuration of the SSD identifying a first storage scheme and a second configuration of the SSD identifying a second storage scheme; The SSD of claim 5.

7. An error correcting code (ECC) module is further provided, the ECC module provides at least a first ECC scheme having a first ECC reliability and a second ECC scheme having a second ECC reliability; 2. The SSD of claim 1 .

8. a first configuration of the SSD identifying a first ECC scheme and a second configuration of the SSD identifying a second ECC scheme; 8. The SSD of claim 7.

9. further comprising at least one of an erasure coding module or a RAID module; the erasure coding module provides a first erasure coding scheme having at least a first erasure coding reliability or a second erasure coding scheme having a second erasure coding reliability, and the RAID module provides a first RAID scheme having at least a first RAID reliability or a second RAID scheme having a second RAID reliability.

2. The SSD of claim 1 .

10. a first configuration of the SSD identifying at least one of a first erasure coding scheme or a first RAID scheme, and a second configuration of the SSD identifying at least one of a second erasure coding scheme or a second RAID scheme; 10. The SSD of claim 9.

11. determining a desired reliability for a solid state drive (SSD) including storage for data including at least one chip; accessing a first entry of a reliability table from the SSD; and configuring the SSD based on the first entry. the reliability table includes at least the first entry and a second entry, the first entry identifying a first configuration of the SSD and a first reliability for the first configuration of the SSD, and the second entry identifying a second configuration of the SSD and a second reliability for the second configuration of the SSD; determining a desired reliability for the SSD includes receiving a desired reliability for the SSD from an application on a host; method.

12. the first entry includes a first storage scheme for the chip; the second entry includes a second storage scheme for the chip; configuring the SSD based on the first entry includes configuring the chip based on the first storage scheme or the second storage scheme. The method of claim 11.

13. the SSD includes an error correcting code (ECC) module; the first entry includes a first ECC scheme for the ECC module; the second entry includes a second ECC scheme for the ECC module; configuring the SSD based on the first entry includes configuring the ECC module according to the first ECC scheme or a second ECC scheme. The method of claim 11.

14. the SSD includes at least one of an erasure coding module or a RAID module; the first entry includes at least one of a first erasure coding scheme for the erasure coding module or a first RAID scheme for the RAID module; the second entry includes at least one of a second erasure coding scheme for the erasure coding module or a second RAID scheme for the RAID module; configuring the SSD based on the first entry includes configuring at least one of the erasure coding module according to the first erasure coding scheme or a second erasure coding scheme, or the RAID module according to the first RAID scheme or the second RAID scheme. The method of claim 11.

15. The step of accessing a first entry of a reliability table from the SSD includes: accessing the first entry and the second entry in the reliability table; and identifying whether the first entry includes a reliability at least as high as the desired reliability. The method of claim 11.

16. and accessing a first entry in a reliability table from the SSD includes receiving, at the SSD, an identifier of the first entry in the reliability table from an application on a host. The method of claim 11.

17. transmitting a reliability request from an application on a host to the SSD, the reliability request requesting valid reliability for the SSD; receiving, at the application on the host, from the SSD, the effective reliability for the SSD; transmitting a reliability table request from the application on the host to the SSD, the reliability table requesting a reliability table stored in the SSD; receiving, at the application on the host, the reliability table from the SSD; selecting an entry from the trust table based on at least a desired trust for the application on the host; transmitting a configuration request from the application on the host to the SSD; each entry in the reliability table identifies a configuration of the SSD and a reliability of the SSD for the configuration, and the configuration request identifies the entry in the reliability table. method.

18. selecting an entry from the reliability table based on at least a desired reliability for the application on the host includes selecting the entry in the reliability table where the reliability for the configuration of the SSD is at least as high as the desired reliability.

20. The method of claim 17.

Images