Storage device

Abstract

This invention discloses a storage device. The storage device may include a host interface for receiving write requests from a host, the write requests including data and logical addresses of the data. The storage device may further include a first storage for the data. The storage device may further include a retention period determiner for determining the retention period of the data. The storage device may further include a translation layer for selecting physical addresses in the first storage for storing data, at least in part based on the retention period. The storage device may further include a second storage for a logic-to-physical mapping table for mapping logical addresses to physical addresses and retention periods. Finally, the storage device may include a controller for programming data to physical addresses in the first storage.

Description

Technical Field

[0001] The present invention is generally related to storage devices, and more particularly to supporting fine-grained data retention in storage devices. [Relevant application materials]

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 187,919, filed May 12, 2021, which is incorporated herein by reference for all purposes. Prior Technology

[0003] As Not-And (NAND) flash technology continues to scale down and store more bits in cells, storage density has improved. However, increasing the cell density in NAND flash memory can also affect the reliability, programming speed, and endurance of flash memory. To meet industry-standard retention requirements, solid-state drive (SSD) controllers may spend time on complex flash translation layer (FTL) block management and data protection designs. According to industry standards, NAND flash may require data retention of 1 to 10 years. Meeting retention requirements may involve the use of flash channel bandwidth, power, and other resources.

[0004] It is still necessary to support the host that specifies how long data will be retained in the storage device. Summary of the Invention

[0005] The embodiments disclosed herein include a storage device capable of supporting a data retention period. When the storage device receives a write request, it can determine the retention period for the data. This information can be used to select where (and / or how) the data is programmed onto the storage device. Simple Explanation of the Diagram

[0006] The drawings described below are examples of how embodiments of this disclosure may be implemented and are not intended to limit the embodiments of this disclosure. Individual embodiments of this disclosure may include elements not shown in a particular drawing and / or elements that may be omitted from a particular drawing. The drawings are intended to provide illustration and may not be drawn to scale. Figure 1 illustrates a system including a storage device that supports a data retention period according to an embodiment of the present disclosure. Figure 2 illustrates details of the machine of Figure 1 according to an embodiment of the present disclosure. Figure 3 illustrates a solid-state drive (SSD) supporting data retention cycle according to an embodiment of the present disclosure. Figure 4 illustrates the structure of the flash memory chip of Figure 3 according to an embodiment of the present disclosure. Figure 5 illustrates details of the flash translation layer of Figure 3 according to an embodiment of the present disclosure. Figure 6 illustrates information that may be included in a write request sent to the storage device of Figure 1 according to an embodiment of the present disclosure. Figure 7 illustrates information that may be included in a write request sent to the storage device of Figure 1 according to an embodiment of the present disclosure. Figure 8 illustrates details of the logic-to-entity mapping table of Figure 5 according to an embodiment of this disclosure. Figure 9 illustrates details of the table of Figure 5 according to an embodiment of the present disclosure, the table storing information about how data is programmed according to a retention period. Figure 10 illustrates details of the flash controller of Figure 3 according to an embodiment of the present disclosure. Figure 11 illustrates the exchange of information between the machine of Figure 1 and the storage device of Figure 1 regarding the data retention period log generated by the automatic recorder of Figure 5, according to an embodiment of the present disclosure. Figure 12 illustrates a flowchart of an example procedure for the storage device of Figure 1, according to an embodiment of the present disclosure, to process a write request for data with a retention period. Figure 13A illustrates a flowchart of another example procedure for the storage device of Figure 1, according to an embodiment of the present disclosure, to process a write request for data with a retention period. Figure 13B continues the flowchart of Figure 13A of another example procedure for the storage device of Figure 1, according to an embodiment of the present disclosure, to process a write request for data with a retention period. Figure 14 illustrates a flowchart of an example program in which the flash translation layer of Figure 3, according to an embodiment of the present disclosure, sends a request to the flash controller of Figure 3 to use a retained cycle programmable data. Figure 15 illustrates a flowchart of an example procedure for caching data in the buffer of Figure 5 according to an embodiment of the present disclosure until the buffer of Figure 5 stores enough data to fill a block in the storage device of Figure 1. Figure 16 illustrates a flowchart of an example procedure for determining different methods for data retention periods using the flash translation layer of Figure 5 according to an embodiment of the present disclosure. Figure 17A illustrates a flowchart of an example procedure for determining whether to update the retention period for data in the storage device of Figure 1, according to an embodiment of the present disclosure. Figure 17B continues the flowchart of Figure 17A of the example procedure for determining whether to update the retention period of data in the storage device of Figure 1 according to the embodiments of this disclosure. Figure 18 illustrates a flowchart of an example procedure for tracking an extension of the retention period for data in the storage device of Figure 1, according to an embodiment of the present disclosure. Figure 19 illustrates a flowchart of an example procedure for the host learning of Figure 1 to invalidate data via the storage device of Figure 1 according to an embodiment of the present disclosure. Figure 20 illustrates a flowchart of an example procedure for the storage device of Figure 1, according to an embodiment of the present disclosure, to process a read request for data with a retention period. Figure 21 illustrates a flowchart of an example program according to an embodiment of the present disclosure, which provides a further detailed description of the flowchart of the example program illustrated in Figure 20. Figure 22 illustrates a flowchart of an example procedure for the storage device of Figure 1, according to an embodiment of the present disclosure, to process a request for the data retention period log of Figure 11. Implementation

[0007] Reference will now be made to embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. Numerous specific details are set forth in the following detailed description in order to provide a thorough understanding of the present disclosure. However, it should be understood that those skilled in the art can practice the present disclosure without such 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 the nature of the embodiments.

[0008] It should be understood that although the terms first, second, etc., may be used herein to describe various elements, such elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, without departing from the scope of this disclosure, a first module may be referred to as a second module, and similarly, a second module may be referred to as a first module.

[0009] The terminology used in the description of this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the disclosure. As used in the description of this disclosure and the appended claims, the singular forms "a / an" and "described" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and / or" as used herein refers to and covers any and all possible combinations of one or more of the associated listed items. It will be further understood that the term "comprises / comprising," when used in this specification, indicates the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude 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.

[0010] Many applications know (exactly or approximately) how long data will be retained when written to storage, which can be measured in hours or days (and other possible times). For example, some application messages may be automatically erased after 24 hours, or spam emails may be deleted after one month. Without receiving such information from applications, storage devices may perform unnecessary data movements, redundant garbage collection operations, and longer data processing and programming times. These operations can impact the performance of the storage device.

[0011] The embodiments disclosed herein support applications that specify a data retention period for data to be written to a storage device. The storage device can then use this information to program the data: for example, using other data that is expected to expire at the same time. Instead of managing storage to retain data available for applications, the storage device can then automatically invalidate the data when the retention period expires.

[0012] The embodiments disclosed herein may also include applications specifying several extensions. If several extensions are specified, the storage device may automatically update the data retention period for the data until all extensions are used, after which the data may automatically expire. Updating the data retention period may involve programming the data to another location within the storage device.

[0013] Figure 1 illustrates a system including an accelerator supporting dictionary decoding according to an embodiment of the present disclosure. In Figure 1, machine 105 (which may also be referred to as a host) may include processor 110, memory 115, and storage device 120. Processor 110 may be any type of processor. (For ease of illustration, processor 110 and other components discussed below are shown external to the machine: embodiments of the present disclosure may include such components internally.) Although Figure 1 illustrates a single processor 110, machine 105 may include any number of processors, each of which may be a single-core processor or a multi-core processor, each of which may implement a Reduced Instruction Set Computer (RISC) architecture or a Complex Instruction Set Computer (CISC) architecture (and other possible architectures), and may be combined and mixed in any desired manner.

[0014] Processor 110 may be coupled to memory 115. Memory 115 may be any type of memory, such as flash memory, dynamic random access memory (DRAM), static random access memory (SRAM), persistent random access memory, ferroelectric random access memory (FRAM), or non-volatile random access memory (NVRAM), such as magnetoresistive random access memory (MRAM). Memory 115 may also be any desired combination of different memory types and may be managed by memory controller 125. Memory 115 may be used to store data that can be termed "short-term": that is, data for which it is not intended to store for a longer period of time. Examples of short-term data may include temporary files, data used by the application itself (which may have been copied from other storage locations), and the like.

[0015] Processor 110 and memory 115 may also support operating systems under which various applications can run. These applications may issue requests (also referred to as commands) to read data from memory 115 or storage device 120 or to write data to memory 115 or storage device 120. Storage device 120 may be accessed using device driver 130. Although FIG1 uses the general term "storage device," embodiments of this disclosure may include any storage device format that can benefit from the use of data quality metrics, examples of which may include hard disk drives and solid-state drives (SSDs). Any reference to "SSD" below should be understood to include such other embodiments of this disclosure. Furthermore, although FIG1 illustrates a storage device 120, embodiments of this disclosure may include any number (one or more) of storage devices.

[0016] Figure 2 illustrates details of the machine 105 of Figure 1 according to an embodiment of this disclosure. In Figure 2, typically, machine 105 includes one or more processors 110, which may include a memory controller 125 and a clock 205 for coordinating the operation of the machine's components. As an example, processor 110 may also be coupled to memory 115, which may include random access memory (RAM), read-only memory (ROM), or other state-retaining media. Processor 110 may also be coupled to storage device 120 and to network connector 210, which may be, for example, an Ethernet connector or a wireless connector. Processor 110 may also be connected to bus 215, to which user interface 220 and input / output (I / O) ports, as well as other components, may be attached. These I / O ports may be managed using I / O engine 225.

[0017] Figure 3 illustrates a dictionary-decoding-enabled solid-state drive (SSD) according to an embodiment of this disclosure. In Figure 3, SSD 120 may include an interface 305. Interface 305 may be an interface for connecting SSD 120 to machine 105 of Figure 1. SSD 120 may include more than one interface 305: for example, one interface may be used for block-based read and write requests, and another interface may be used for key-value read and write requests. Although Figure 3 shows interface 305 as a physical connection between SSD 120 and machine 105 of Figure 1, interface 305 may also represent protocol differences that can be used across a common physical interface. For example, SSD 120 may be connected to machine 105 using a U.2 or M.2 connector, but may support both block-based and key-value requests: handling different types of requests may be performed by different interfaces 305.

[0018] The SSD 120 may also include a host interface layer 310, which manages interfaces 305. If the SSD 120 includes more than one interface 305, a single host interface layer 310 can manage all interfaces. The SSD 120 may include a host interface layer for each interface, or a combination thereof.

[0019] SSD 120 may also include SSD controller 315, various channels 320-1, 320-2, 320-3, and 320-4, and various flash memory chips 325-1, 325-2, 325-3, 325-4, 325-5, 325-6, 325-7, and 325-8 arranged along the channels. SSD controller 315 can manage the sending of read and write requests along channels 320-1 to 320-4 to flash memory chips 325-1 to 325-8. Although Figure 3 illustrates four channels and eight flash memory chips, embodiments disclosed herein may include any number (one or more, without constraint) of channels containing any number (one or more, without constraint) of flash memory chips.

[0020] Within each flash memory chip, space can be organized into blocks, which can be further subdivided into pages, and these can be grouped into superblocks. As illustrated in Figure 4, a flash memory chip can contain superblocks 405-1 and 405-2; superblock 405-1 can contain blocks 410-1 and 410-2; and block 410-1 can contain pages 415-1, 415-2, 415-3, and so on. A page is typically the smallest unit of data that can be read or written on an SSD. Page size can vary as needed: for example, a page can contain 4,000 bytes of data. If the page to be written is smaller than one page, the extra space is "unused".

[0021] Although Figure 4 illustrates two superblocks 405-1 and 405-2, two blocks 410-1 and 410-2 within superblock 405-1, and three pages 415-1, 415-2, and 415-3 within block 410-1, the embodiments disclosed herein may, without limitation, include any number of superblocks (one or more), each superblock may, without limitation, include any number of blocks (one or more), and each block may, without limitation, include any number of pages (one or more). Furthermore, flash memory chips may not organize data into superblocks, but rather into blocks and pages.

[0022] Returning to Figure 3, although pages can be written to and read from, SSDs typically do not allow data to be overwritten: that is, existing data may not be able to be replaced "in-situ" with new data. Instead, when data is ready to be updated, the new data is written to a new page on the SSD, and the original page becomes invalid (marked as ready to be erased). Therefore, SSD pages typically have one of three states: free (ready to be written), valid (contains valid data), and invalid (no longer contains valid data, but is not usable until erased) (the exact names of these states may vary).

[0023] However, although pages can be written to and read from individually, blocks are the basic units of erasable data. That is, pages are not erased individually: typically all pages in a block are erased simultaneously. For example, if a block contains 256 pages, all 256 pages in that block are erased simultaneously. This configuration can lead to some SSD management issues: if blocks that still contain some valid data are chosen to be erased, it may be necessary to copy the valid data to other free pages on the SSD before erasing the blocks. (In some embodiments disclosed herein, the unit of erasure may differ from a block: for example, it may be a superblock, as discussed above, which can be a collection of multiple blocks.)

[0024] Because the units for writing and erasing data are different (pages versus blocks), if an SSD waits until a block contains only invalid data before erasing it, the SSD may actually run out of available storage space, even if the amount of valid data is less than the advertised capacity of the SSD. To avoid this, the SSD controller 315 may include a scrap collection controller (not shown in Figure 3, but discussed further in Figure 5 below). The scrap collection function may identify blocks containing all or most invalid pages and release those blocks so that valid data can be written to them again. However, if the block selected for scrap collection contains valid data, the valid data will be erased by the scrap collection logic (because the unit of erasure is a block, not a page). To avoid this data loss, the scrap collection logic may program the valid data from such blocks into other blocks. Once the data has been programmed into the new block (and the table mapping logical block addresses (LBAs) to physical block addresses (PBAs) has been updated to reflect the new location of the data), the block can be erased, thus returning the state of the pages in the block to an idle state.

[0025] SSDs also have a limited number of programming / erase cycles that may be written to each cell before the cell is trusted to properly retain data. This number is typically measured by the count of programming / erase cycles a cell undergoes. Generally, the number of programming / erase cycles a cell can support means that the SSD will remain reliably functional for a reasonable period of time: for individual users, they are more likely to replace the SSD due to insufficient storage capacity than if the number of programming / erase cycles has been exceeded. However, in enterprise environments where data is written and erased more frequently, the risk of a cell exceeding its programming / erase cycle count may be more significant.

[0026] To help mitigate this risk, the SSD controller 315 can use a wear leveling controller (not shown in Figure 3). Wear leveling can involve selecting data blocks to program data based on the block's programming / erase cycle count. By selecting blocks with lower programming / erase cycle counts to program new data, the SSD can prevent some blocks from having their programming / erase cycle counts increase beyond their reliable operating point. By making the wear levels of each block as similar as possible, the SSD can remain reliable over a longer period of time.

[0027] SSD controller 315 may include a flash translation layer (FTL) 330 (which may be more commonly referred to as a translation layer for storage devices that do not use flash memory) and a flash controller 335 (which may be more commonly referred to as a controller for storage devices that do not use flash memory). FTL 330 handles the translation of LBAs or other logical IDs (such as those used by processor 110 of FIG1) and physical block addresses (PBAs) or other physical addresses where data is stored in flash chips 325-1 to 325-8. FTL 330 may also be responsible for relocating data from one PBA to another, which may occur during scrap collection and / or wear leveling. FTL 330 is further discussed with reference to FIG5 below. Flash controller 335 may use the information provided by FTL 330 to handle actual communication with flash memory chips 325-1 to 325-8 along channels 320-1 to 320-4. The flash controller 335 is discussed further with reference to Figure 10 below.

[0028] Figure 5 illustrates details of the FTL 330 of Figure 3 according to an embodiment of the present disclosure. In Figure 5, the FTL 330 may include a host write request processor 505 and a host read request processor 510. As the descriptive terms suggest, the host write request processor 505 may process write requests, such as write request 515, received from host 105 of Figure 1 (or from other hosts, at or away from host 105 of Figure 1), and the host read request processor 510 may process read requests, such as read request 520, from host 105 of Figure 1 (or from other hosts, at or away from host 105 of Figure 1).

[0029] The host write request handler 505 may include commit queues 525-1, 525-2, and 525-3. Each commit queue 525-1 to 525-3 can be used for write requests with different associated retention periods. Thus, for example, commit queue 525-1 can be used for write requests with a 1-day data retention period, commit queue 525-2 can be used for write requests with a 1-week data retention period, commit queue 525-3 can be used for write requests with a 1-month data retention period, and so on. Other data retention periods can also be used: for example, one year, more than one year, two weeks, etc. Although Figure 5 illustrates three commit queues 525-1 to 525-3, the embodiments disclosed herein can support any number of commit queues, each of which can be associated with a different retention period. Furthermore, commit queues 525-1 to 525-3 can also fully utilize technology. For example, each commit line 550-1 to commit line 550-3 can be associated with a combination of data retention period and device stream ID, thus allowing the combination of stream ID and data retention period.

[0030] The retention period for a specific write request can be determined using a retention period determiner 530. The retention period determiner can determine the retention period for specific data in several different ways. In some embodiments of this disclosure, write request 515 can specify a data retention period to be applied to the data in that write request. For example, an application whose data retention is no more than 24 hours can specify a 1-day retention period as part of write request 515. In other embodiments of this disclosure, storage device 120 of FIG1 can include a preset retention period that can be applied to all data written to storage device 120 of FIG1 (unless another retention period is specified, such as by including it in write request 515). In still other embodiments of this disclosure, attributes of write request 515 can be identified, which can then be used to determine the retention period for the data. Examples of such features may include LBA ranges, command identifiers, namespace identifiers, stream identifiers, zone namespace identifiers, identifiers for commit queues 525-1 to 525-3, date, time, protocol, media access control identifiers, network parameters or storage device parameters, and other possibilities. For example, an application may have a specific LBA range assigned to it. FTL 330 may map any LBA within that LBA range to a specific retention period. Applications with different LBA ranges may have different retention periods. Furthermore, it is not necessary for an application to have only one LBA range associated with a retention period: a single application may have multiple LBA ranges, each with a different retention period associated with it. (However, even if write request 515 contains an address in an LBA range with an associated retention period, this assignment may be overridden by the specific retention period contained within write request 515).

[0031] The retention cycle determiner 530 can be implemented in any desired manner. The retention cycle determiner 530 can be implemented using hardware such as a central processing unit (CPU), graphics processing unit (GPU), general purpose GPU (GPGPU), field programmable gate array (FPGA), or application-specific integrated circuit (ASIC), and other possibilities. The retention period determiner 530 may also be implemented as software that can run on some equivalent hardware within the processor or storage device 120 of FIG1; when not in use (e.g., if the storage device 120 of FIG1 is powered off), some or all of the software implementing the retention period determiner 530 may be retained somewhere in the storage: for example, in a dedicated storage within FTL 330, within flash memory chips 325-1 to 325-8 of FIG3, or as firmware within some form of ROM (including Programmable ROM (PROM), Erasable PROM (EPROM), Electrically Erasable PROM (EEPROM), and other possibilities).

[0032] In some embodiments of this disclosure, data can be written to flash memory chips 325-1 to 325-8 of FIG3 after a write request is placed in one of the submission queues 525-1 to 525-3, wherein each write request has data stored in one or more pages of the storage device 120 of FIG1. ​​However, in other embodiments of this disclosure, it may be necessary to write data in blocks. By writing an entire block at once, all data written to the block can have the same retention period and can be processed simultaneously. This method helps minimize the impact of scrap collection: in the event that all data in a block becomes invalid at once, there will be no data that would need to be programmed as scrap collection.

[0033] To store data until a block is full, FTL 330 may include buffer 535. Buffer 535 may temporarily store data used for commit queues 525-1 to 525-3 until a given commit queue has enough data to fill a block. At that point, all data filling the block of that commit queue may then be written to flash memory chips 325-1 to 325-8 of FIG3 and that data may be cleared from buffer 535. It should be noted that this fact also means that a single block in storage device 120 may store data from two (or more) different write requests 515: in fact, it may be true that a single block may store data from two or more write requests 515, regardless of whether buffer 535 is used to write a complete block at once.

[0034] In some embodiments of this disclosure, FTL 330 may include a single buffer 535. In these embodiments, buffer 535 may include sufficient storage equivalent to one (or more) block per commit queue 525-1 to commit queue 525-3. In other embodiments, FTL 330 may include multiple buffers 535, with one buffer for each of commit queues 525-1 to 525-3. In still other embodiments, these options may be combined: for example, commit queue 525-1 may have one buffer 535 for its data, while commit queues 525-2 and 525-3 may share another buffer 535.

[0035] The FTL 330 can select the physical address of data based on its retention period, which is why using multiple commit lines 525-1 to 525-3 may be desirable. By using multiple commit lines, data with the same retention period can be programmed into the same block in flash memory chips 325-1 to 325-8 of Figure 3, which can cause all data in the block to be invalidated simultaneously. By causing all data in the block to be invalidated simultaneously, it is possible to avoid programming data from the block during scrap collection, which can help reduce the write amplification factor. However, it should be noted that if the FTL 330 could track the retention period of data in some other way, the FTL 330 could select the physical address of the data to achieve this result without using multiple commit lines 525-1 to 525-3.

[0036] The FTL 330 can also use wear leveling information to attempt to extend the lifespan of storage device 120. As discussed above, wear leveling can attempt to place data into blocks to prevent blocks from quickly exceeding their maximum number of defined programmable / erase cycles. In addition to placing data into blocks with lower programmable / erase cycle counts, the FTL 330 can also attempt to optimize data placement based on data retention periods. Whether data is placed in blocks with low or high programmable / erase cycle counts involves balancing factors. Blocks with higher programmable / erase cycle counts may be closer to their "end of life," at which point failures may be more probable, indicating that placing data with a longer expected retention time is better. However, blocks with higher programmable / erase cycle counts may also be more likely to suffer from errors that may occur when data is stored for longer periods.

[0037] One solution is to identify threshold values. For blocks whose programming / erase cycle count has not yet exceeded this threshold, data can be stored based on wear-out considerations: that is, blocks with a relatively high programming / erase cycle count (but less than the threshold) can be used to store data with a longer expected retention period. However, for blocks whose programming / erase cycle count has exceeded this threshold, data can be stored based on retention time considerations: that is, blocks with a relatively high programming / erase cycle count (exceeding the threshold) can be used to store data with a shorter expected retention period. In this way, various issues related to both wear-out balance and accurate data retention time can be taken into account.

[0038] The threshold can be a fixed number—for example, 50,000 programming / erase cycles—or a percentage of the expected number of programming / erase cycles a block will undergo—for example, 50%. The threshold can also be variable, taking into account the number of programming / erase cycles experienced by other blocks on the storage device. Therefore, for example, if blocks on the storage device are expected to undergo 100,000 programming / erase cycles before a foreseeable error, and if all blocks have approximately 75,000 programming / erase cycles, then the blocks are expected to be in roughly the same state, so the threshold could be set to 50% of the average remaining programming / erase cycles on the storage device: in this example, 75,000 + ½ x (100,000 - 75,000) = 87,500.

[0039] The storage device 120 of Figure 1 can be designed to meet certain data retention standards. For example, the storage device 120 of Figure 1 can meet the standard that data is required to be retrievable one, five, or ten years after being written. To meet these standards, the storage device 120 of Figure 1 can always support fully encoded data and can program the data into the flash memory chips 325-1 to 325-8 of Figure 3 as carefully as possible. However, for data that is not expected to be retained for that length, the storage device 120 of Figure 1 may not need to take such measures to ensure data reliability. The storage device 120 of Figure 1, through the FTL 330 and flash controller 335, can be designed to make full use of the data retention period when selecting how to program the data, in order to reduce the workload (power, time, and bandwidth) used when the data is not expected to be retained to the maximum retention supported by the storage device 120 of Figure 1.

[0040] One way to fully utilize data retention time is to select an error correction code (ECC) mode based on the expected retention time of the data. For example, the storage device 120 of Figure 1 can implement two or more different ECC modes. The two common ECC modes used in the storage device include Bose-Chaudhuri-Hocquenghem (BCH) and low-density parity check (LDPC), but other ECC modes can also be used. Different ECC modes can have different power requirements, involving different bandwidths (which means the amount of data sent across various buses within the storage device 120), different latency (which means the time required to encode and / or decode data using the ECC mode), and different levels of data recovery support. For example, LDPC often requires more power to implement than BCH and may take longer to encode and decode data than BCH. However, LDPC can also allow for the recovery of more errors than BCH, and therefore can support longer data reliability. Therefore, LDPC is a more suitable option for encoding data that is expected to be retained for a longer period of time.

[0041] ECC selector 540 can be used to select the ECC mode of data based on the data's retention period. Therefore, after the retention period determiner 530 has determined the data's retention period, ECC selector 540 can use that information to select the data's ECC mode. Subsequently, flash controller 335 can encode the data using the selected ECC mode before programming the data to a specified location in flash memory chips 325-1 to 325-8 of FIG. 3.

[0042] ECC selector 540 can select an ECC mode in any desired manner. For example, ECC selector 540 may include a table 545 that maps a specific retention period to a target ECC mode. ECC selector 540 may also use other techniques to select an ECC mode based on a retention period: for example, ECC selector 540 may implement functionality that can (more generally) map retention periods to specific values ​​that indicate the ECC mode to be used. It should also be noted that in some embodiments disclosed herein, even if the storage device 120 of FIG1 supports ECC, the data may be programmed without coding: that is, even if ECC is available, it may be skipped.

[0043] Another way to fully utilize the data retention period is to select the programming step voltage for the data. Flash memory chips 325-1 to 325-8 can support two or more different programming step voltages. When programming data into flash memory chips 325-1 to 325-8, the flash controller 335 can increment the voltage in the cell by a step voltage (which may be represented as ΔV) until the voltage in the cell meets or exceeds a target voltage (which may represent the value stored in the cell). A smaller programming step voltage allows for more accurate data storage, which means that the data can be reliably stored for a longer period of time. On the other hand, a smaller programming step voltage may take longer to program the value into the cell. For example, if the larger ΔV is twice the smaller ΔV, it can be expected that using the smaller ΔV will require approximately twice as long to program the value into the cell. Therefore, the selection of the programming step voltage may involve a trade-off between accuracy (and reliability) and speed. For data that is expected to be retained for a longer period of time, a smaller programmed step voltage may be required, while for data that is expected to fail earlier, a larger programmed step voltage can be used.

[0044] The programmed step voltage selector 550 can be used to select the programmed step voltage of the data based on the data's retention period. Therefore, after the retention period determiner 530 has determined the data's retention period, the programmed step voltage selector 550 can use that information to select the programmed step voltage of the data. Subsequently, the flash controller 335 can use the selected programmed step voltage to program the data into the flash memory chips 325-1 to 325-8 of FIG. 3.

[0045] The programmed step voltage selector 550 can select the programmed step voltage in any desired manner. For example, the programmed step voltage selector 550 may include a table 545 that maps a specific hold period to a target programmed step voltage. The programmed step voltage selector 550 may also use other techniques to select the programmed step voltage based on the hold period: for example, the programmed step voltage selector 550 may implement functionality that can (more typically) map hold periods to a specific value that indicates the programmed step voltage to be used.

[0046] It should be noted that Figure 5 illustrates table 545 for both the ECC selector 540 and the programmed step voltage selector 550. In some embodiments of this disclosure, the ECC selector 540 and the programmed step voltage 550 may share table 545 (because both map retention periods to values ​​that will be used to program data into flash memory chips 325-1 to 325-8 of Figure 3). In other embodiments of this disclosure, the ECC selector 540 and the programmed step voltage 550 may each have their own table 545. In still other embodiments of this disclosure, the ECC selector 540 and the programmed step voltage 550 may be implemented as a module (rather than separately as illustrated). In still other embodiments of this disclosure, table 545 may be stored elsewhere, rather than as part of the ECC selector 540 and / or the programmed step voltage 550. Other combinations are also possible and are considered embodiments of this disclosure. See Figure 9 below for a discussion of Table 545 and its variants.

[0047] Similar to the retention cycle determiner 530, the ECC selector 540 and / or the programmable step voltage 550 can be implemented using hardware such as a CPU, GPU, GPGPU, FPGA, or ASIC, among other possibilities. The ECC selector 540 and / or the programmable step voltage 550 can also be implemented as software that can run on some equivalent hardware within the processor or storage device 120 of FIG1; when not in use (e.g., if the storage device 120 of FIG1 is powered off), some or all of the software implementing the retention cycle determiner 530 can be retained somewhere in the storage: for example, in a dedicated storage within the FTL 330, within the flash memory chips 325-1 to 325-8 of FIG3, or as firmware within some form of ROM (including PROM, EPROM, and EEPROM, among other possibilities). Since the FTL 330 is operable with the option to use a hold period and not necessarily fully utilize the ECC or programmed step voltage, the ECC selector 540 and / or programmed step voltage 550 can be omitted.

[0048] Once the physical address, ECC mode, and / or programming step voltage of the data have been determined, the host write request processor 505 provides this information (along with the data) to the flash controller 335. The flash controller 335 can then program the data into flash memory chips 325-1 to 325-8 based on this information. The flash controller 335 can then return the result of the programming operation, which can be returned by the host write request processor 505 to the host 105 of FIG. 1. The operation of the flash controller 335 is further discussed below with reference to FIG. 10.

[0049] In some embodiments of this disclosure, data can be automatically invalidated by the storage device 120 of FIG1 once the retention period expires. However, in other embodiments of this disclosure, the data may also have an associated extension number. When the retention period expires, the data is not automatically invalidated, but the retention period can be updated up to the extension number associated with the data. The retention period determiner 530 can determine the extension number in a similar manner to how the retention period determiner 530 determines the retention period. In this way, the application can specify the required retention period for the data and also ensure that the data does not immediately become invalid after the retention period expires (in case the application underestimates how long the data needs to be retained).

[0050] Updating the retention period may simply involve "resetting the clock" for data retention. However, in some embodiments disclosed herein, updating the retention period may involve reprogramming the data to a newly selected block (selected by FTL 330 in the same manner as the original block selection). There are at least two reasons why data may be reprogrammed when updating the retention period. First, updating the retention period of only one piece of data in a block does not automatically mean that every piece of data in the block will update its retention period. If the data remains in place, it can be programmed to a new block regardless if that block undergoes scrap collection. By reprogramming the data when updating the retention period, FTL 330 can be assured that the data is placed in a block with other data having the same retention period, while also ensuring that when the block undergoes scrap collection, there may be no remaining valid data in the block (which may need to be programmed). Second, as discussed above, depending on the ECC mode used and the programming step voltage, the data reliability may be less than the maximum that the storage device 120 of FIG. 1 may be able to support. In other words, the data may have been programmed into flash memory chips 325-1 to 325-8 of Figure 3 in a way that ensures the reliability of the data retention period, but it is not necessary. Leaving the data in place may cause the data to become unreadable when the application requests it again. Reprogramming the data into a new block helps ensure that the data can continue to be read during the (updated) retention period.

[0051] The extended tracker 555 can handle these responsibilities. The extended tracker 555 can determine when a specific retention period schedule expires (meaning all data in that block is overdue if data is written one block at a time to flash memory chips 325-1 to 325-8 of Figure 3). The extended tracker 555 can pre-determine the data's expiration time (since the retention period should be known before the data is programmed into flash memory chips 325-1 to 325-8 of Figure 3) and can schedule when to check for data failure or reprogramming (depending on whether any remaining extended time exists). If the retention period is updated, the extended tracker 555 can update information about how many further updates the retention period can be performed (or, alternatively, track how many extended times are needed to update the retention period). For data that is expected to be updated during its retention period, the extension tracker 555 (possibly in combination with the host write request handler 505) may treat the data as a new write request from the host; or the extension tracker 555 may simply adjust the number of remaining extension times or the number of extensions used, select a suitable new block for the data, and instruct the flash controller 335 to reprogram the data (or, alternatively, copy the data from its original physical address to its new physical address, which avoids data decoding and re-encoding).

[0052] As noted above, in some cases—especially when the retention period has expired and no specified extension or remainder exists—the extension tracker 555 may instruct the flash controller 335 to invalidate the data. Because such data invalidation may occur without an application requesting invalidation, the application may not be aware that the data has expired. (This concept contrasts with the abstract knowledge that data will be automatically invalidated via the storage device 120 of Figure 1: the application may know that the data will expire at some point, but may not know when the failure will occur.) The extension tracker 555 may use the automatic logger 560 to record that the data has expired. The automatic logger 560 may record the data failure (which can be recorded using the logical address of the data as specified by the application) in the data retention period log.

[0053] Once the data has expired, the extended tracker can update the logic to entity mapping table 565 to reflect that the data is no longer valid. Refer further to Figure 8 below for a discussion of the logic to entity mapping table 565.

[0054] Therefore, if an application attempts to read data and is notified that no data was found (error status), the host 105 of Figure 1 can request a data retention period log. A review of the data retention period log can show data expired due to the retention period (and any possible extensions). In this way, the host 105 of Figure 1 can distinguish between read errors caused by automatic data failure and read errors caused by problems that may be related to underlying hardware (e.g., units that do not store or return the original value).

[0055] This raises questions about the use of retention periods and extensions. Is a one-week retention period and three chronological extensions not equivalent to a four-week retention period? The answer is that in terms of the overall data retention, the two methods are the same, but the way the data is programmed and how waste collection might be affected may differ.

[0056] First, compared to data with an associated retention period of four weeks, data with an associated retention period of one week can be programmed using a lower power consumption ECC mode and / or a larger programming step voltage. In other words, by specifying a shorter data retention period, even with extensions, the power consumed and time spent programming data with a one-week retention period may be less than the power consumed or time spent programming data with a four-week retention period. In fact, if the retention period is extended, this can be offset by the need to reprogram the data. However, if the retention period is an accurate measure of how long the application actually wants to store the data on storage device 120, the logical conclusion is that the data is more likely to expire in about a week rather than about four weeks. In other words, using extended periods acts as a fallback method to prevent (hopefully occasionally) the need for longer data retention times than expected. If data is programmed into a block with a four-week retention period and then expires only after one week, the block is more likely to contain data that needs to be programmed if the block is selected for scrap collection.

[0057] Turning temporarily to Figure 6, one can see the information contained in write request 515. Write request 515 may contain data 605, which may be data to be written to storage device 120 of Figure 1. Write request 515 may also contain logical address 610, which may be a logical address used by host 105 of Figure 1 to identify the data. (Logical address 610 may be distinguished from the physical address where the data is actually stored in storage device 120 of Figure 1.)

[0058] As discussed above, one way to determine the retention period (and / or extension number) of data 605 is by including such information in the write request 515. That is, the write request 515 may include fields that specify the retention period 615 and / or extension number 620. However, if the data retention period is determined in another way, the write request 515 may omit the retention period 615 and / or extension number 620.

[0059] Returning to Figure 5, similar to the extended tracker 555, the waste collection controller 570 can also be scheduled, much like the extended tracker 555. If it is expected that a block will fail at a specific time (and recalling that even if data is retained due to the extended cycle, the data will be reprogrammed to ensure data reliability), then it is expected that the block will have no valid data when the retention period expires. Therefore, the waste collection controller 570 can use this idea to schedule when waste collection might occur, thereby targeting the time when the block has no valid data.

[0060] The scrap collection logic may select blocks for scrap collection that store data with assigned retention periods. For example, for a specific block with a one-month retention period, most of the data can be manually invalidated by writing that data to the application on storage device 120 of Figure 1, leaving one block as a good candidate for scrap collection. In that case, the scrap collection logic may attempt to determine the retention period of the data (which can be retrieved from logic-to-entity mapping table 565, further discussed in Figure 8 below) and may attempt to program the data into blocks with similar retention periods. In this way, it is hoped that data segmentation (based on retention period) can be avoided.

[0061] As discussed above, the host 105 of FIG1 can use the logical address 610 of FIG6 to refer to the data 605 of FIG6. However, the logical address 610 of FIG6 may not necessarily be related to the physical address where the data is actually stored on storage device 120. In fact, the logical address 610 of FIG6 may not even be a valid address on storage device 120 of FIG1 (for example, if the logical address 610 of FIG6 is considered a physical address, it could be an address in the boot section of storage device 120, which would typically not be addressable by the application). Furthermore, if the data 605 of FIG6 is reprogrammed (due to retention cycle updates or scrap collection), the physical address may change. Therefore, FTL 330 may include a logical-to-physical mapping table 565. The logical-to-physical mapping table 565 can store information about the location of data 605 in Figure 6, such as the logical address 610 of Figure 6 used by the host 105 of Figure 1, the physical address where the data is stored in the storage device 120 of Figure 1, and other relevant information about data 605 in Figure 6, such as the retention period 615 of Figure 6. When the FTL 330 of Figure 3 receives a write request 515 from the host 105 of Figure 1 and programs the data 605 of Figure 6 into the flash memory chips 325-1 to 325-8 of Figure 3, the FTL 330 can update the logical-to-physical mapping table 565 to store this information. The logical-to-physical mapping table 565 is further discussed with reference to Figure 8 below.

[0062] The logic-to-entity mapping table 565 may be stored somewhere within the storage device 120 of FIG1. ​​In some embodiments, the logic-to-entity mapping table 565 of FIG5 may be stored in memory 575. Memory 575 may be non-volatile memory, such as another flash memory or NVRAM, thereby preventing any information loss when the storage device 120 of FIG1 is turned off (normally or abnormally). Alternatively, memory 575 may be volatile memory: to prevent data loss, the logic-to-entity mapping table 565 may be mirrored to flash memory chips 325-1 to 325-8 of FIG3. Finally, memory 575 may be an area on flash memory chips 325-1 to 325-8 of FIG3, rather than a separate memory.

[0063] It should be noted that memory 575 can be used to store more than just logic-to-entity mapping table 565. For example, memory 575 can also store table 545 that maps retention periods to target ECC modes and / or programmed step voltages.

[0064] Earlier, the handling of read requests was addressed, as read request 520 could lead to an error if the data is invalid. The operation of the host read request handler 510 can now be discussed. As illustrated in Figure 7, read request 520 may include logical address 610. Since read request 520 is a request for the storage device 120 of Figure 1 to transfer data back to the application, the other elements illustrated in Figure 6 can be omitted from read request 520. (This does not mean that the read request consists only of logical address 610; however, read request 520 can omit data 605, retention period 615, and / or extension number 620 of Figure 6.)

[0065] Returning to Figure 5, the host read request processor 510 can receive a read request 520 from the host 105 in Figure 1. Using logical address 610, the host read request processor 510 can determine the entity address of the stored data from the logical-to-entity mapping table 565. The host read request processor 510 can also determine the ECC mode used to encode the data from the logical-to-entity mapping table 565. The host read request processor 510 can then provide this information to the flash controller 335, which can then read data from flash memory chips 325-1 to 325-8 in Figure 3, decode the data (if necessary), and send the data back to the host read request processor 510, which can then send the data back to the host 105 in Figure 1.

[0066] As discussed above, in some cases, read request 520 may request expired data. In that case, host read request processor 510 may directly return an error (if logical-to-entity mapping table 565 does not have an entry for logical address 610 of FIG. 7). Alternatively, host read request processor 510 may send a request to flash controller 335 to read data from the entity address; flash controller 335 may determine that the data is expired and may return an error to host read request processor 510, which may be forwarded to host 105 of FIG. 1. As discussed above, in the event of an error in read request 520, host 105 of FIG. 1 may request a data retention periodic log to check if the data has automatically expired.

[0067] Figure 8 illustrates details of the logical-to-entity mapping table 565 of Figure 5 according to an embodiment of the present disclosure. In Figure 8, the logical-to-entity mapping table 565 is illustrated as comprising seven rows and five columns (excluding columns with row names). Embodiments of the present disclosure may have a logical-to-entity mapping table 565 comprising any number (zero or greater than zero) of columns, depending on the amount of data stored in the storage device 120 of Figure 1. Embodiments of the present disclosure may also vary the number of rows in the logical-to-entity mapping table 565: different embodiments may contain less information than that illustrated in Figure 8 and / or additional information not illustrated in Figure 8.

[0068] Each column in the logical-to-entity mapping table 565 may contain various fields, such as logical address 610, entity address 805, retention period 615, extension number 620, ECC mode 810, programmed step voltage 815, and refresh time 820. Logical address 610 may be the logical address of data used by host 105 of FIG1. ​​Entity address 805 may be the entity address of data stored in storage device 120 of FIG1. ​​Retention period 615 may be the retention period of data associated with logical address 610, and may be determined by retention period determiner 530 of FIG5. Extension number 620 may be the extension number for the retention period of data associated with logical address 610, and may be determined by retention period determiner 530 of FIG5. ECC mode 810 can identify the ECC mode selected by ECC selector 540 of FIG5 for data associated with logical address 610. The programmed step voltage 815 can identify the programmed step voltage selected by the programmed step voltage 550 of Figure 5 for the data associated with the logic address 610. Finally, the refresh time 820 can identify the number of times the data has been refreshed (and it can be compared with the extension number 620, which can represent the upper limit of the refresh time 820).

[0069] It should be noted that some data in the logic-to-entity mapping table 565 can be determined from the write request 515 of Figure 5, and some can be filled by the FTL 330 of Figure 3. For example, the logical address 610, retention period 615, and extension number 620 can be accessed from the write request 515 of Figure 5, while the entity address 805, ECC mode 810, programming step voltage 815, and refresh time 820 can be filled by the FTL 330 of Figure 3. (Of course, depending on how the storage device 120 of Figure 1 is used, the retention period 615 and / or extension number 620 can also be filled by the FTL 330 of Figure 3.) The information in the logic-to-entity mapping table 565 provides an image of how data is stored in the storage device 120 of Figure 1, which supports data retrieval when requested by the host 105 of Figure 1 in the read request 520 of Figure 5 and data reprogramming when indicated by the extension tracker 555 of Figure 5.

[0070] Figure 9 illustrates details of Table 545 of Figure 5 according to an embodiment of the present disclosure, which stores information about how data is programmed based on retention periods. In Figure 9, a Table 545 is illustrated that maps retention periods to both ECC modes and programming step voltages. As discussed above, embodiments of the present disclosure may include a separate table for mapping retention periods to ECC modes and programming step voltages. Additionally, Table 545 may be expanded to include this additional information, or may not include information not used by the storage device 120 of Figure 1, if other variations exist in how data is programmed to flash memory chips 325-1 to 325-8 of Figure 3. Embodiments of the present disclosure may have Table 545 containing any number (zero or greater than zero) of columns, depending on the number of different retention periods supported by the storage device 120 of Figure 1.

[0071] Each column in Table 545 may contain various fields, such as retention period 615, ECC mode 810, and programming step voltage 815. Retention period 615 identifies the retention period supported by storage device 120 of FIG1. ​​ECC mode 810 identifies the ECC mode used when programming data with retention period 615. Programming step voltage 815 identifies the programming step voltage used when programming data with retention period 615. Therefore, after retention period determiner 530 of FIG5 determines the retention period of data 605 of FIG6 to be used in write request 515 of FIG5, Table 545 may be accessed by ECC selector 540 and / or programming step voltage selector 550 of FIG5 to determine the appropriate ECC mode and / or programming step voltage for programming data 605 of FIG6 to flash memory chips 325-1 to 325-8 of FIG3.

[0072] Figure 10 illustrates details of the flash controller 335 of Figure 3 according to an embodiment of this disclosure. In Figure 10, the flash controller 335 can receive requests from FTL 330. (Two paths from FTL 330 to flash controller 335 are illustrated to mirror two paths—one for writing data and one for reading data—from FTL 330 to flash controller 335, as illustrated in Figure 5.) Flash command interface 1005 can receive these requests. Since writing data and reading data involve different procedures, these procedures are discussed separately.

[0073] As discussed with reference to Figure 5 above, when data is written to the storage device 120 of Figure 1, the programming request received by the flash controller 335 may include the data and the physical address of the data to be written. In some embodiments disclosed herein, such requests may also include an ECC mode for encoding the data and / or a programming step voltage for programming the data.

[0074] The flash command interface 1005 can automatically request the identification of the ECC mode to be used, and can subsequently use ECC encoder / decoder 1010-1 or ECC encoder / decoder 1010-2 to encode data (producing encoded data). Although Figure 10 illustrates two ECC encoder / decoders 1010-1 or ECC encoder / decoder 1010-2, embodiments disclosed herein may include any number (zero or greater than zero) of ECC encoders / decoders.

[0075] Once the data has been encoded, the encoded data (or raw data, if the data will be unencoded), the physical address of the data to be programmed, and the programming step voltage (if used) can be delivered to flash interface 1015. Flash interface 1015 can be responsible for interfacing with die 1020-1 and / or die 1020-2 to program the data as directed. Although Figure 10 illustrates two dies 1020-1 and die 1020-2, embodiments disclosed herein may include any number (one or more) dies in which data can be programmed.

[0076] Once the flash interface 1015 has completed programming the data into die 1020-1 and / or die 1020-2, the flash interface can transmit the result of the programming operation back to the flash command interface 1005, which can then return the result to FTL 330.

[0077] On the other hand, as discussed with reference to Figure 5 above, when data is to be read from the storage device 120 of Figure 1, the programmed request received by the flash controller 335 may include the physical address of the data to be read. In some embodiments disclosed herein, such requests may also include an ECC mode for decoding the data. The flash command interface 1005 may pass the physical address to the flash interface 1015 to read data from die 1020-1 and / or die 1020-2. This data (which may be encoded) may be returned from the flash interface 1015.

[0078] The Flash Command Interface 1005 can identify the ECC mode to be used from a read request and can subsequently use ECC encoder / decoder 1010-1 or ECC encoder / decoder 1010-2 to decode the encoded data (producing the raw data). Although Figure 10 illustrates two ECC encoder / decoders 1010-1 or ECC encoder / decoder 1010-2, the embodiments disclosed herein may include any number (zero or greater than zero) of ECC encoders / decoders. The Flash Command Interface 1005 can then transmit the unencoded data back to FTL 330, which can transmit the data back to the host 105 of Figure 1.

[0079] If the data has expired for some reason before the read request is processed, the flash interface 1015 may return an error (because the data may be unavailable). In that case, the flash command interface 1005 may return the error to the FTL 330, which may then return the error to the host 105 of FIG1.

[0080] Figure 11 illustrates the exchange of information between the machine 105 of Figure 1 and the storage device 120 of Figure 1 regarding a data retention period log generated by the automatic logger 560 of Figure 5, according to an embodiment of this disclosure. In Figure 11, the host 105 may send a read request 520 to the storage device 120. If the data has expired (as discussed above with reference to Figure 5, this can occur even without the application issuing a request to expire the data), the subsequent read request 520 may result in an error 1105, which may be returned to the host 105. The host 105 may then send a data retention period log request 1110 to the storage device 120: the storage device 120 may then respond with a data retention period log response 1115, which may include the data retention period log 1120. The host 105 may then use the data retention period log 1120 to determine that the data has automatically expired due to an overdue retention period (as opposed to some other errors that may indicate a problem with the storage device 120).

[0081] Figure 12 illustrates a flowchart of an example procedure for processing a write request 515 of Figure 5 for data 605 of Figure 6 having a retention period 615 of Figure 6, according to an embodiment of the present disclosure, by the storage device 120 of Figure 1. In Figure 12, at block 1205, the storage device 120 of Figure 1 may receive the write request 515 of Figure 5 from the host 105 of Figure 1. The write request 515 of Figure 5 may include data 605 of Figure 6 and a logical address 610 of Figure 6, as specified by the host 105 of Figure 1. At block 1210, the retention period determiner 530 of Figure 5 may determine the retention period 615 of Figure 6 associated with the write request 515 of Figure 5. As discussed above with reference to Figure 5, the retention period 615 of Figure 6 may be included in the write request 515 of Figure 5. The retention period 615 of Figure 6 may be determined based on some attributes of the write request 515 of Figure 5, or the retention period 615 of Figure 6 may be the preset retention period of the storage device 120 of Figure 1.

[0082] At block 1215, FTL 330 of Figure 3 can select entity address 805 of Figure 8, where data 605 of Figure 6 is to be programmed into storage device 120 of Figure 1. The selection of entity address 805 of Figure 8 by FTL 330 of Figure 3 can be at least partially based on the retention period 615 of Figure 6. At block 1220, FTL 330 of Figure 3 (or host write request handler 505 of Figure 5) can update the logical-to-entity mapping table 565 of Figure 5 to store the logical address 610 of Figure 6, the entity address 805 of Figure 8, and the retention period 615 of Figure 6. Finally, at block 1225, flash controller 335 of Figure 3 can program the data 605 of Figure 6 into entity address 805 of Figure 8 in storage device 120 of Figure 1.

[0083] Figures 13A and 13B illustrate flowcharts of another example procedure for processing a write request 515 of Figure 5 for data 605 of Figure 6 with a retention period 615 of Figure 6, according to an embodiment of the present disclosure. Figures 13A and 13B are similar to Figure 12, but more general and have some additional blocks. In Figure 13A, at block 1305, the storage device 120 of Figure 1 can receive configuration commands from the host 105 of Figure 1. The configuration commands enable the host to manage the use of retention periods within the storage device 120 of Figure 1. For example, the host 105 of Figure 1 can use the configuration commands to learn whether the storage device 120 of Figure 1 supports data retention periods and to enable or disable the use of data retention periods per I / O request within the storage device 120 of Figure 1. The host 105 of Figure 1 can use the configuration commands to establish a preset retention period and / or a preset extension number for write requests sent to the storage device 120 of Figure 1. The host 105 in Figure 1 can use configuration commands to establish the characteristics of write requests, such as LBA range, command identifier, namespace identifier, stream identifier, zone namespace identifier, identifiers of commit columns 525-1 to 525-3 in Figure 5, date, time, protocol, media access control identifier, network parameters or storage device parameters, and how these various characteristics can be associated with different retention periods and / or extension numbers. Finally, the host 105 in Figure 1 can use configuration commands to retrieve the data retention period log 1120 of Figure 11 from the storage device 120 in Figure 1 to determine whether read errors are due to automatic data expiration or some other reason.

[0084] At block 1205, storage device 120 of FIG1 may receive write request 515 of FIG5 from host 105 of FIG1. ​​Write request 515 of FIG5 may include data 605 of FIG6 and logical address 610 of FIG6, as specified by host 105 of FIG1. ​​Write request 515 of FIG5 may also include retention period 615 of FIG6 and / or extension number 620 of FIG6. At block 1210, retention period determiner 530 of FIG5 may determine retention period 615 of FIG6 associated with write request 515 of FIG5. As discussed above with reference to FIG5, retention period 615 of FIG6 may be included in write request 515 of FIG5, retention period 615 of FIG6 may be determined based on some attributes of write request 515 of FIG5, or retention period 615 of FIG6 may be a preset retention period of storage device 120 of FIG1. At block 1310, the host write request handler 505 of Figure 5 can place the write request 515 of Figure 5 into one of the commit queues 525-1 to 525-3 of Figure 5.

[0085] At block 1315, the retention period determiner 530 of FIG5 determines the extension number 620 of FIG6. Block 1315 can be omitted, as shown by the dashed line 1320. At block 1215, the FTL 330 of FIG3 selects the entity address 805 of FIG8, where the data 605 of FIG6 is to be programmed into the storage device 120 of FIG1. ​​The selection of the entity address 805 of FIG8 by the FTL 330 of FIG3 can be at least partially based on the retention period 615 of FIG6.

[0086] At block 1325 (Figure 13B), the ECC selector 540 of Figure 5 can select either ECC mode 1010-1 or ECC mode 1010-2 of Figure 10 when encoding data 605 of Figure 6. Block 1325 can be omitted, as illustrated by dashed line 1330. At block 1335, the programming step voltage selector 550 of Figure 5 can select the programming step voltage used when programming data 605 of Figure 6 into flash memory chips 325-1 to 325-8 of Figure 3. Block 1335 can be omitted, as illustrated by dashed line 1340.

[0087] At block 1220, the FTL 330 of FIG3 (or the host write request processor 505 of FIG5) can update the logic-to-entity mapping table 565 of FIG5 to store the logical address 610 of FIG6, the entity address 805 of FIG8, and the retention period 615 of FIG6. In embodiments of this disclosure using different ECC modes 1010-1 or 1010-2 or different programmed step voltages of FIG10, the FTL 330 of FIG3 (or the host write request processor 505 of FIG5) can also update the logic-to-entity mapping table 565 of FIG5 to store the ECC mode 810 and / or the programmed step voltage 815 of FIG8. At block 1225, the flash controller 335 of FIG3 can program the data 605 of FIG6 into the entity address 805 of FIG8 in the storage device 120 of FIG1.

[0088] At block 1345, the waste collection controller 570 of Figure 5 can be scheduled to operate based on the retention period 615 of Figure 6. Finally, at block 1350, the flash controller 335 of Figure 3 can return the results of the programmed operation, and the FTL 330 of Figure 3 can return the results of the write request 515 of Figure 5 to the host 105 of Figure 1.

[0089] Figure 14 illustrates a flowchart of an example program of an FTL 330 of Figure 3 sending a request to a flash controller 335 of Figure 3 to program the data 605 of Figure 6 using a retention period 615 of Figure 6, according to an embodiment of the present disclosure. In Figure 14, at block 1405, the FTL 330 of Figure 3 may send a programming request to the flash controller 335 of Figure 3 to program the data into flash memory chips 325-1 to 325-8 of Figure 3. At block 1410, the flash controller 335 of Figure 3 may use the ECC encoder / decoder 1010-1 or ECC encoder / decoder 1010-2 of Figure 10 to encode the data. Block 1410 can be omitted, as shown by the dashed line 1415. Finally, at block 1420, the flash controller 335 of FIG3 can program the data into the flash memory chips 325-1 to 325-8 of FIG3.

[0090] Figure 15 illustrates a flowchart of an example procedure for buffer 535 of Figure 5 caching data according to an embodiment of the present disclosure until buffer 535 of Figure 5 stores enough data to fill a block in storage device 120 of Figure 1. In Figure 15, at block 1505, buffer 535 of Figure 5 may buffer data received in write request 515 of Figure 5. At block 1510, buffer 535 of Figure 5 may buffer data from another write request 515 of Figure 5, which has been programmed into the same block. At block 1515, FTP 330 of Figure 3 may check to see if buffer 535 of Figure 5 contains enough data to fill the block (at least the value of the block of data to be programmed into a single block: buffer 535 of Figure 5 may buffer data to be written to multiple different blocks). If not, control returns to block 1510 to wait for more data to be stored in buffer 535 of Figure 5.

[0091] If there is sufficient data in buffer 535 of Figure 5 to fill a specific block, then at block 1520, flash controller 335 of Figure 3 can program the data 605 of Figure 6 from the first write request 515 of Figure 5 to the target block, and at block 1525, flash controller 335 of Figure 3 can program the data 605 of Figure 6 from the second write request 515 of Figure 5 to the target block. (If there is more data from other write requests to be programmed into the target block, other operations similar to those in blocks 1520 and 1525 can also be performed.) Finally, at block 1530, buffer 535 of Figure 5 may have been cleared (at least, the data programmed into the target block is cleared: if buffer 535 of Figure 5 stores other data to be programmed into other blocks, that data can remain in buffer 535 of Figure 5).

[0092] Figure 16 illustrates a flowchart of an example procedure for determining the retention period 615 of Figure 6 for data 605 of Figure 6 using the FTL 330 of Figure 3 according to an embodiment of the present disclosure. In Figure 16, at block 1605, the retention period determiner 530 of Figure 5 can access the retention period 615 and / or extension number of Figure 6 from the write request 515 of Figure 5. Alternatively, at block 1610, the retention period determiner 530 of Figure 5 can determine the attributes of the write request 515 of Figure 5 and use those attributes to determine the retention period 615 and / or extension number 620 of Figure 6. Alternatively, at block 1615, the retention period determiner 530 of Figure 5 can access the preset retention period 615 and / or preset extension number 620 of Figure 6 for the storage device 120 of Figure 1. It should be noted that these options can be combined: for example, the retention period determiner can use a preset extension number but access the retention period 615 of Figure 6 from the write request 515 of Figure 5. Other combinations are also possible.

[0093] Figures 17A and 17B illustrate flowcharts of an example procedure for determining whether to update the retention period 615 of the data 605 of Figure 6 in the storage device 120 of Figure 1, according to an embodiment of the present disclosure. In Figure 17A, at block 1705, the extended tracker 555 of Figure 5 can schedule a check to determine whether the retention period 615 of Figure 6 has expired. At block 1710, after the scheduled time has elapsed, the extended tracker 555 of Figure 5 can check to see if the retention period 615 of Figure 6 has expired. If not, the process can return to block 1705 to schedule another check later.

[0094] If the retention period 615 of Figure 6 has expired, the extension tracker 555 of Figure 5 can check at block 1715 to see if any extension remains. If not, the flash controller 335 of Figure 3 can invalidate the data 605 of Figure 6 at block 1720, and the automatic logger 560 of Figure 5 can record the data invalidation in the data retention period log 1120 of Figure 11 at block 1725. (The extension tracker 555 of Figure 5 can also remove the entry for the data 605 of Figure 6 from the logic-to-entity mapping table 565 of Figure 5, since the data is no longer effectively stored in the storage device 120 of Figure 1.)

[0095] On the other hand, if there is remaining expansion, at block 1730 (Fig. 17B), the FTL 330 of Fig. 3 can select another entity address 805 of Fig. 8 for the data 605 of Fig. 6. At block 1735, the flash controller 335 of Fig. 3 can program the data 605 of Fig. 6 to the new entity address 805 of Fig. 8. At block 1740, the flash controller 335 of Fig. 3 can invalidate the data 605 of Fig. 6 at the original entity address 805 of Fig. 8. At block 1745, the FTL 330 of Fig. 3 can update the logical-to-entity mapping table 565 of Fig. 5 to reflect the entity address 805 of Fig. 8, where the data 605 of Fig. 6 can be stored. Finally, at block 1750, the expansion tracker 555 of Fig. 5 can update the retention period, as discussed with reference to Fig. 18 below.

[0096] Figure 18 illustrates a flowchart of an example procedure for tracking the extension of the retention period 615 of Figure 6 for data 605 of Figure 6 in the storage device 120 of Figure 1 according to an embodiment of the present disclosure. In Figure 18, at block 1805, the extension tracker 555 of Figure 5 can decrement the extension number 620 of Figure 6. Alternatively, at block 1810, the extension tracker 555 of Figure 5 can increment the refresh time 820 of Figure 8.

[0097] Figure 19 illustrates a flowchart of an example procedure by which the host 105 of Figure 1 learns to invalidate data 605 of Figure 6 via the storage device 120 of Figure 1 according to an embodiment of the present disclosure. In Figure 19, at block 1905, the host 105 of Figure 1 may send a read request 520 of Figure 5 to the storage device 120 of Figure 1. At block 1910, the host 105 of Figure 1 may receive a read result from the storage device 120 of Figure 1.

[0098] At block 1915, host 105 of Figure 1 can check whether the read result is the read error 1105 of Figure 11. If the read result is the read error 1105 of Figure 11, then at block 1920, host 105 of Figure 1 can send the data retention period log request 1110 of Figure 11. At block 1925, host 105 of Figure 1 can receive the data retention period log response 1115 of Figure 11 from storage device 120 of Figure 1. The data retention period response 1115 of Figure 11 may include the data retention period log 1120 of Figure 11, so that host 105 of Figure 1 can check whether the read error 1105 of Figure 11 is due to the automatic invalidation of data 605 of Figure 6 by storage device 120 of Figure 1 or due to some other reason.

[0099] Figure 20 illustrates a flowchart of an example procedure for processing a read request 520 of Figure 5 for data 605 of Figure 6 having a retention period 615 of Figure 6, according to an embodiment of the present disclosure, by the storage device 120 of Figure 1. In Figure 20, at block 2005, the FTL 330 of Figure 3 may receive the read request 520 of Figure 5 from the host 105 of Figure 1. The read request 520 of Figure 5 may include the logical address 610 of Figure 7 of the data 605 of Figure 6 to be read from the storage device 120 of Figure 1. At block 2010, the host read request processor 510 of Figure 5 may use the logical address 610 of Figure 7 to determine the physical address 805 of Figure 8 of the data 605 of Figure 6. The host read request processor 510 of Figure 5 may use the logical-to-physical mapping table 565 of Figure 5 to determine the physical address 805 of Figure 8 of the data 605 of Figure 6. At block 2015, the host read request processor 510 of FIG5 can use the logical address 610 of FIG7 to determine the ECC mode 810 of FIG8 for encoding the data 605 of FIG6. The host read request processor 510 of FIG5 can use the logical-to-entity mapping of FIG5 to determine the ECC mode 810 of FIG8 for the data 605 of FIG6. It should be noted that in some embodiments of this disclosure, block 2015 may be omitted.

[0100] At block 2020, the flash controller 335 of FIG3 can read the encoded data at physical address 805 of storage device 120 of FIG8 in FIG1. ​​At block 2025, the flash controller 335 of FIG3 can use ECC encoder / decoder 1010-1 or ECC encoder / decoder 1010-2 of FIG10 to decode the encoded data, thereby producing data 605 of FIG6. It should be noted that in some embodiments of this disclosure, if no data is encoded (and block 2015 is omitted), block 2025 may also be omitted. Finally, at block 2030, the flash controller 335 of FIG3 can transmit the data 605 of FIG6 back to FTL 330 of FIG3, which in turn can transmit the data 605 of FIG6 back to host 105 of FIG1.

[0101] Figure 21 illustrates a flowchart of an example procedure according to an embodiment of the present disclosure, providing a further detailed description of the flowchart of the example procedure illustrated in Figure 20. In Figure 21, at block 2105, the FTL 330 of Figure 3 can send a read request to the flash controller 335 of Figure 3. At block 2110, the flash controller 335 of Figure 3 can read the encoded data. At block 2115, the flash controller 335 of Figure 3 can use the ECC encoder / decoder 1010-1 or ECC encoder / decoder 1010-2 of Figure 10 to decode the encoded data. It should be noted that if the data 605 of Figure 6 is stored unencoded, block 2115 can be omitted, as illustrated by the dashed line 2120. Finally, at block 2125, the flash controller 335 of Figure 3 can return the data to the FTL 330 of Figure 3.

[0102] Figure 22 illustrates a flowchart of an example procedure for the storage device 120 of Figure 1, according to an embodiment of the present disclosure, to process a data retention period log request 1110 for the data retention period log 1120 of Figure 11. At block 2205, the storage device 120 of Figure 1 may receive the data retention period log request 1110 of Figure 11 from the host 105 of Figure 1. At block 2210, the storage device 120 of Figure 1 may transmit the data retention period log 1120 of Figure 11 back to the host 105 of Figure 1, for example, as part of the data retention period log response 1115 of Figure 11.

[0103] Figures 12 through 22 illustrate some embodiments of this disclosure. However, those skilled in the art will recognize that other embodiments of this disclosure are possible by changing the order of blocks, by omitting blocks, or by including links not shown in the figures. All such variations of the flowcharts are considered embodiments of this disclosure, whether or not explicitly described.

[0104] Solid-state drives (SSDs), such as the storage device 120 in Figure 1, are used more extensively in data center applications than previously thought. SSD performance may become critical for data storage and processing. SSDs store data in NAND flash memory. Different types of flash memory exist, such as single-level cell (SLC), multi-level cell (MLC), triple-level cell (TLC), quad-level cell (QLC), etc., and various manufacturing processes. The SSD controller manages the flash memory and provides data access to the host computer to which the SSD is attached.

[0105] The host interface can be used by the host to communicate with the SSD. Data write and read input / output (I / O) commands, as well as various media management commands such as Identify and Get Log, can be issued through this interface. The same interface can be used by the SSD to perform data transfer to and from the host system memory.

[0106] The Flash Translation Layer (FTL) provides a mapping between logical addresses used by the host and physical addresses of data on flash memory. NAND flash memory can be read or written at the granularity of flash pages, typically 8 kilobytes to 16 kilobytes in a typical NAND flash device, but smaller and / or larger page sizes can also be used. Flash memory pages can be erased before they can be reprogrammed with new data. The granularity of erasure is per NAND block: each block may contain 128 to 256 pages, but a block may also contain fewer or more pages. Because the granularity of erasure and programming differs, additional work can be performed to migrate valid pages to new blocks before erasing older blocks. Garbage collection (GC) is the process of freeing up partially filled blocks and creating space for more data. The primary goal of garbage collection is to identify one of the fragmented flash blocks in which most of the flash blocks are invalid and to erase the entire block. Once waste collection is complete, the pages can be recycled and added to the free table in FTL.

[0107] Flash memory can be programmed and erased a limited number of times. This limit can be described as the maximum number of programming / erasing cycles (P / E cycles) that can be maintained over the lifetime of the flash memory. The SSD controller attempts to distribute write operations evenly across all blocks to maximize the lifespan of the SSD drive: this process is known as wear balancing. Wear balancing algorithms select new blocks from a free table when data is about to be programmed. A simple approach is to select the block with the lowest number of P / E cycles from the free table to minimize wear differences across blocks.

[0108] Due to the way flash memory operates (e.g., using waste collection and wear leveling), the amount of data erased and rewritten may be greater than the actual data written by the host. Each time data is relocated without being changed by the host system, this relocation increases write amplification and reduces the lifespan of the flash memory. Write amplification can be measured by the ratio of writes committed to flash memory to writes from the host system. FTL can perform various background operations, such as waste collection and wear leveling. In this way, host I / O commands can coexist with background operations, and these two types of flash reads can compete with each other for flash bandwidth. Additional features associated with performing extra programming / erase cycles can affect performance. FTL can attempt to optimize waste collection and wear leveling to improve efficiency and leave more bandwidth for host write and read operations.

[0109] The flash interface 1015 in Figure 10 can perform read and write operations on flash memory. Different flash chips can perform read, write, and erase operations simultaneously and independently. The flash interface can also perform data encoding and error correction suitable for data reliability. The most common error correction codes (ECCs) used by SSD controllers are Bose-Chowdhury-Hokungamme (BCH) and Low-Density Parity Check (LDPC), but other ECCs can also be used. LDPC has stronger error correction capabilities than BCH and can have a longer retention guarantee. However, LDPC can be more complex to implement, has longer encoding and decoding latency, and may require more power. LDPC may be more reliable for data with longer retention periods. For data with shorter retention periods, BCH can provide higher bandwidth and lower cost.

[0110] The flash interface 1015 in Figure 10 can perform direct memory access (DMA) from the flash controller to the flash memory. For programmable flash pages, the flash interface can progressively increase the programmed voltage increments of the NAND flash memory cells. (V), and can stop after the voltage exceeds the desired threshold voltage. A smaller V results in a more accurate target voltage. With a larger programming step voltage, fewer steps are used during the programming process. Therefore, the choice of programming step voltage may involve a trade-off between accuracy and speed.

[0111] All the features described above can affect the performance, reliability, and durability of flash memory, and therefore the entire SSD. Without knowing the data retention period, more retention errors may need to be tolerated. Therefore, more bandwidth, power, and resources are available to meet retention requirements.

[0112] An SSD architecture for executing I / O commands can be used for storage devices such as storage device 120 of Figure 1, such as non-volatile memory (NVMe) with a specified data retention period (DRP) for high-speed writing. The architecture allows the host to specify an estimated data retention period for program data used in a given command. This feature enables efficient data management via FTL, thereby improving the durability of flash memory. The architecture also helps accelerate flash programming and read operations, further improving overall SSD performance.

[0113] The SSD controller 315 can perform data transfer between host system memory and persistent flash memory in response to I / O commands. I / O write commands can specify the destination logical block address (LBA) and the number of blocks to be programmed. The FTL can translate the host LBA to the flash physical block address and perform DMA from the SSD controller to the flash memory array. The FTL can allocate a target flash memory address for each I / O using the following two parameters: 1) DRP; and 2) retention period extension time (RPET).

[0114] The data retention period can be the estimated lifespan of the data as specified by the host. When the retention period expires, the host can read and reprogram the data to extend the period or invalidate the data. The SSD controller can extend the data retention period to the time specified in RPET before invalidating the data.

[0115] DRP based on each command can help allocate data with similar retention periods in nearby blocks within flash memory. The host write command processor 505 in Figure 5 of the FTL can classify free flash pages into one or more queues (or pools) based on data retention periods (e.g., 1 day, 1 week, 1 month, 1 year, more than 1 year, etc.). Pages within a queue or pool can be physically united groups of pages. When a host command arrives, the FTL can check the data retention period in the command and select an available physical page from the corresponding queue or pool. After recording the page address in the logical-to-physical (L2P) table, the FTL can trigger the flash interface controller to program the data to the pre-selected pages. Therefore, blocks of short-retention-period data can be separated from blocks containing long-retention-period data. Since the data within a block can expire at approximately the same time, the block can be reclaimed all at once, minimizing unnecessary data movement during scrap collection. Ideally, write amplification can be reduced to close to its minimum of 1. This fact also reduces background data traffic and preserves more resources and flash channel bandwidth for host read and write operations.

[0116] Frequently overwritten data blocks do not require frequent recycling. For data with short retention periods, scrap collection operations can be avoided. Grouping blocks based on data retention time improves scrap collection efficiency and reduces block P / E cycles. Furthermore, by assigning new blocks (lower P / E cycles) to long-retention-period queues and older blocks (higher P / E cycles) to short-retention-period queues, a further optimal wear balance can be achieved.

[0117] DRP based on each command can also facilitate data programming and increase read speed. Different ECC codes can have different data encoding and decoding latencies. LDPC is stronger in error correction capability than BCH code. However, the LDPC algorithm may be more complex to implement, have longer encoding and decoding latencies, and may consume more power than BCH code. For short retention period data, fewer retention errors may need to be tolerated. Therefore, BCH is strong enough to protect data within the capabilities of short retention period data. Using BCH to encode / decode such data can achieve faster encoding / decoding speeds and lower power consumption. The FTL 330 in Figure 3 can select the ECC mode based on the DRP of each command before triggering flash DMA.

[0118] In addition to using different ECC modes, data programming step voltage can be optimized according to DRP to accelerate the data programming process. Write speed can be improved by using larger programming step voltage values. With a larger programming step voltage, fewer steps may be required during programming. Therefore, a larger programming step voltage can accelerate programming operations, but it can also reduce the tolerance for retention errors. Therefore, applying a larger programming voltage step within short retention periods can help speed up the programming process.

[0119] The FTL 330 in Figure 3 can write data retention period, ECC mode, programmable voltage mode, and logical and physical addresses to the L2P table before programming to flash memory. Table 1 illustrates an example of the information contained in the L2P table. Table 1 [since] [NVMe] [Command Extraction] [By means] [FTL] [filling] Logical address Data retention period Retention period extension time Physical Address (PBA) ECC mode Programmable voltage step mode Retention period refresh time 0000 1D x3 Grain 0, Block 1, Address 0x0001_0000 BCH big x0 0010 1D x3 Grain 0, Block 1, Address 0x0001_0004 BCH big x1 1005 1W x1 Grain 0, Block 5, Address 0x0005_0330 BCH medium x0 1206 1W x1 Grain 0, Block 6, Address 0x0006_0470 BCH medium x0 2030 1M x1 Grain 0, Block 10, Address 0x0010_0200 LDPC Small x0 2049 1M x3 Grain 0, Block 10, Address 0x0010_0570 LDPC Small x1 3112 1Y x0 Grain 0, Block 15, Address 0x0015_0011 LDPC Small x0 4557 1Y x0 Grain 0, Block 15, Address 0x0015_0300 LDPC Small x0 7880 >1Y x0 Grain 0, Block 20, Address 0x0020_9000 LDPC Small x0 8990 >1Y x0 Grain 0, Block 21, Address 0x0021_0375 LDPC Small x0

[0120] The SSD controller 315 in Figure 3 can announce support for per-I / O DRP characteristics via the Identify data structure. The following columns are some examples of information exposed via the Identify data structure: 1) Supported per-I / O DRP; 2) Supported DRP length, such as one day, one week, one month, one year, more than one year, etc.; 3) Supported maximum RPET.

[0121] When the NVMe drive and system software read and identify the data structure, they understand that the connected SSD controller supports per-I / O DRP. The drive can then use the Set Feature / Get Feature commands to configure and enable the per-I / O DRP feature in the SSD controller. Once the per-I / O DRP feature is enabled, the NVMe drive and system software can insert the DRP and maximum RPET into the NVMe write command. The FTL can log the LBA of the data when the DRP expires. The host can then access the log using the NVMe Get Log Page command.

[0122] In another embodiment disclosed herein, the host 105 of FIG1 may specify and set DRP and RPET values ​​instead of per-I / O granularity. Based on this, some examples of storage and network parameters that the host may specify for DRP and RPET values ​​include: LBA range, command ID, namespace ID, stream ID, zone namespace (ZNS) ID, host ID, submission queue ID (SQID), date, time, Transmission Control Protocol / Internet Protocol (TCP / IP), Ethernet Media Access Control (MAC) ID, etc. The host can use the Set Feature / Get Feature commands to set these parameters in the SSD.

[0123] In yet another embodiment disclosed herein, the SSD device 120 of FIG3 may itself specify and set DRP and RPET values ​​instead of per-I / O granularity. Some examples of storage and network parameters that an SSD can use to specify DRP and RPET values ​​include: LBA range, command ID, namespace ID, stream ID, ZNS ID, host ID, SQID, date, time, TCP / IP, Ethernet MAC ID, etc. Such device-specified parameter values ​​can be read by the host using the Identify and / or Set Feature / Get Feature commands.

[0124] The embodiments disclosed herein offer technical advantages over prior art. By using a data retention period, the storage device can better determine where to program data when written by an application to minimize (or potentially eliminate) the programmed data during scrap collection. The storage device can also use information about the retention period to determine how to program data—for example, by selecting appropriate error correction codes and / or programming step voltages. The storage device can also automatically invalidate data when the retention period expires, rather than retaining details indefinitely (and potentially having to unnecessarily program the data to a new location). The storage device can log such data invalidation in case the host requests to know the reason for data invalidation without instruction from the application. Additionally, by using extensions, the storage device can automatically update data whose retention period has expired (instead of invalidating the data).

[0125] The following discussion is intended to provide a brief, general description of one or more suitable machines in which certain aspects of this disclosure may be implemented. One or more machines may be controlled at least in part by input from familiar input devices such as keyboards and mice, and by guidance received from another machine, interaction with a virtual reality (VR) environment, biometric feedback, or other input signals. As used herein, the term "machine" is intended to broadly encompass a single machine, a virtual machine, or a system of communication-coupled machines, virtual machines, or co-operating devices. Exemplary machines include computing devices such as personal computers, workstations, servers, portable computers, handheld devices, telephones, tablets, etc.; and transportation devices such as private or public transportation, such as cars, trains, taxis, etc.

[0126] One or more machines may contain embedded controllers, such as programmable or non-programmable logic devices or arrays, application-specific integrated circuits (ASICs), embedded computers, smart cards, and the like. Machines may utilize one or more connections to one or more remote machines, such as via network interfaces, modems, or other communication couplings. Machines may be interconnected by means of physical and / or logical networks, such as intranets, the Internet, local area networks, wide area networks, etc. Those skilled in the art will understand that network communications can utilize various wired and / or wireless short- or long-range carriers and protocols, including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 802.11, Bluetooth®, optical, infrared, cable, laser, etc.

[0127] The embodiments disclosed herein can be described by reference to or in conjunction with associated materials, including functions, programs, data structures, applications, etc., which, when accessed by a machine, enable the machine to perform tasks or define abstract data types or low-level hardware conditions. Associated data may be stored, for example, in volatile and / or non-volatile memory (e.g., RAM, ROM, etc.), or in other storage devices and their associated storage media, including hard drives, floppy disks, optical storage, magnetic tapes, flash memory, memory sticks, digital video disks, bio-memory disks, etc. Associated data may be transmitted via a transmission environment, including physical and / or logical networks, in the form of packets, serial data, parallel data, or transmitted signals, and may be used in compressed or encrypted formats. Associated data can be used in distributed environments and stored locally and / or remotely for machine access.

[0128] Embodiments of this disclosure may include tangible, non-transitory, machine-readable media comprising instructions executable by one or more processors, including instructions for performing elements of this disclosure as described herein.

[0129] The various operations of the methods described above can be performed by any suitable component capable of performing the operations, such as various hardware and / or software components, circuits and / or modules. The software may include an ordered list of executable instructions for implementing logical functions, and may be embodied in any processor-readable medium used by or in connection with an instruction execution system, device or apparatus (such as a single-core or multi-core processor or a system containing a processor).

[0130] Blocks or steps of methods or algorithms combined with the embodiments disclosed herein, as well as the described functions, may be embodied directly in hardware, in a software module executed by a processor, or a combination of both. If implemented in software, the functions may be stored as one or more instructions or program code on or transmitted via a tangible non-transitory computer-readable medium. The software module may reside in random access memory (RAM), flash memory, read-only memory (ROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in this art.

[0131] The principles of this disclosure have been described and illustrated with reference to the illustrated embodiments. It will be appreciated that the illustrated embodiments may be modified in configuration and detail without departing from such principles, and may be combined in any desired manner. Furthermore, while the foregoing discussion focuses on particular embodiments, other configurations are covered. Specifically, although expressions such as "according to an embodiment of this disclosure" or similar terms are used herein, such phrases generally mean reference to the general possibilities of the embodiments and are not intended to limit this disclosure to the particular embodiment configuration. As used herein, these terms may refer to the same or different embodiments combined in other embodiments.

[0132] The foregoing illustrative embodiments should not be construed as limiting the scope of the disclosure. Although a few embodiments have been described, it will be readily apparent to those skilled in the art that many modifications are possible with respect to those embodiments without substantially departing from the novel teachings and advantages of this disclosure. Therefore, all such modifications are intended to be included within the scope of this disclosure as defined in the claims.

[0133] The embodiments disclosed herein can be extended to, but are not limited to, the following statements: Statement 1 Embodiments disclosed herein include a storage device, comprising: The host interface is used to receive write requests from the host. The write request contains the data and the logical address of the data. The first storage unit is used for data; Retention period determiner, used to determine the retention period of data; A translation layer is used to select physical addresses in the first memory to store data, at least in part based on the retention period; A second memory is used to map logical addresses to physical addresses and a logical-to-physical mapping table with a retention period; and The controller is used to program data into physical addresses in the first memory. Statement 2. Embodiments of this disclosure include the storage device according to Statement 1, wherein: Storage devices include solid-state drives (SSDs); The first storage device includes flash memory; and The translation layer contains the Flash Translation Layer (FTL). Statement 3. Embodiments of this disclosure include the storage device according to Statement 2, wherein: Flash memory contains blocks; FTL is configured to select physical addresses in blocks of flash memory to store data, at least in part based on the retention period; The logical-to-entity mapping table maps logical addresses to entity addresses in blocks and specifies the retention period; and The controller includes a flash interface to program data into physical addresses in blocks of flash memory. Statement 4. Embodiments of this disclosure include the storage device according to Statement 2, wherein: FTL includes buffers for storing data and secondary data; and The FTL is configured to instruct the flash interface to program data and second data into the physical address of the block in flash memory, based at least in part on the buffer storing enough data to fill the block. Statement 5. Embodiments of this disclosure include a storage device according to Statement 2, wherein a block contains second data, and the second data contains a retention period. Statement 6. Embodiments of this disclosure include the storage device according to Statement 1, wherein the translation layer includes a second storage. Statement 7. Embodiments of this disclosure include the storage device according to Statement 1, wherein a write request includes a retention period. Statement 8. Embodiments of this disclosure include the storage device according to Statement 1, wherein a retention period determiner is configured to determine the retention period at least in part based on the attributes of a write request. Statement 9. Embodiments of this disclosure include the storage device according to Statement 1, wherein the attributes of a write request are at least one of the following: logical block address (LBA) range, command identifier, namespace identifier, stream identifier, region namespace identifier, identifier of the commit queue, date, time, protocol, media access control identifier, network parameters, or storage device parameters. Statement 10. Embodiments of this disclosure include a storage device according to Statement 1, wherein a retention period determiner is configured to access the storage device with a preset retention period as the retention period. Statement 11. Embodiments of this disclosure include the storage device according to Statement 1, wherein the retention period is one of a minimum retention period and a second retention period. Statement 12. Embodiments of this disclosure include a storage device according to Statement 1, wherein the translation layer includes an error correction code (ECC) selector that selects a first ECC mode from at least a first ECC mode and a second ECC mode based at least in part on a retention period. Statement 13. Embodiments of this disclosure include the storage device according to Statement 12, wherein an ECC selector is configured to select a first ECC mode from a table containing at least a first ECC mode and a second ECC mode, at least in part based on a retention period. Statement 14. Embodiments of this disclosure include a storage device according to Statement 12, wherein a logic-to-entity mapping table further maps logical addresses to a first ECC mode. Statement 15. Embodiments of this disclosure include the storage device according to Statement 12, wherein the controller is configured to encode data at least in part based on a first ECC mode to generate encoded data and program the encoded data into physical addresses in a first memory. Statement 16. Embodiments of this disclosure include the storage device according to Statement 12, wherein the translation layer further includes a programmable step voltage selector that selects the first programmable step voltage from at least a first programmable step voltage and a second programmable step voltage based at least in part on the retention period. Statement 17. Embodiments of this disclosure include the storage device according to Statement 16, wherein a programmed step voltage selector is configured to select a first programmed step voltage from a table containing at least a first programmed step voltage and a second programmed step voltage, at least in part based on a retention period. Statement 18. Embodiments of this disclosure include a storage device according to Statement 16, wherein a logic-to-entity mapping table further maps logical addresses to a first stylized step voltage. Statement 19. Embodiments of this disclosure include a storage device according to Statement 16, wherein a controller is configured to encode data at least in part based on a first ECC mode to generate encoded data, and the encoded data is programmed into a physical address in a first memory at least in part based on a first programmed step voltage. Statement 20. Embodiments of this disclosure include the storage device according to Statement 1, wherein the translation layer further includes a programmable step voltage selector that selects the first programmable step voltage from at least a first programmable step voltage and a second programmable step voltage based at least in part on the retention period. Statement 21. Embodiments of this disclosure include a storage device according to Statement 20, wherein a programmed step voltage selector is configured to select a first programmed step voltage from a table containing at least a first programmed step voltage and a second programmed step voltage, at least in part based on a retention period. Statement 22. Embodiments of this disclosure include a storage device according to Statement 20, wherein a logic-to-entity mapping table further maps logical addresses to a first stylized step voltage. Statement 23. Embodiments of this disclosure include a storage device according to Statement 20, wherein a controller is configured to program data into physical addresses in a first memory at least in part based on a first programming step voltage. Statement 24. Embodiments of this disclosure include the storage device according to Statement 1, wherein the translation layer includes an extended tracker for tracking retention periods that have expired. Statement 25. Embodiments of this disclosure include the storage device according to Statement 24, wherein the translation layer is configured to determine the number of extensions. Statement 26. Embodiments of this disclosure include the storage device as described in Statement 25, wherein a write request further includes an extended number. Statement 27. Embodiments of this disclosure include a storage device according to Statement 25, wherein the translation layer is configured to determine the number of extensions at least in part based on the attributes of write requests. Statement 28. Embodiments of this disclosure include the storage device according to Statement 27, wherein the attributes of a write request are at least one of the following: LBA range, command identifier, namespace identifier, stream identifier, zone namespace identifier, identifier of the commit queue, date, time, protocol, media access control identifier, network parameters, or storage device parameters. Statement 29. The embodiments disclosed herein include the storage device according to Statement 25, wherein the number of extensions is a preset number of extensions for the storage device. Statement 30. Embodiments of this disclosure include the storage device according to Statement 25, wherein the extended tracker is configured to update the retention period at least in part based on the number of extended trackers. Statement 31. Embodiments of this disclosure include the storage device according to Statement 25, wherein the extension tracker is configured to automatically update the retention period at least in part based on the number of extensions. Statement 32. Embodiments of this disclosure include the storage device according to Statement 30, wherein the extended tracker is further configured to update the retention period at least in part based on the number of extended trackers being greater than zero. Statement 33. Embodiments of this disclosure include the storage device according to Statement 30, wherein the extended tracker is further configured to update the retention period at least in part based on the number of extended trackers being greater than zero. Statement 34. Embodiments of this disclosure include the storage device according to Statement 32, wherein the expansion tracker is configured to reduce the number of expansions. Statement 35. Embodiments of this disclosure include the storage device according to Statement 30, wherein the extended tracker is further configured to update the retention period based at least in part on the number of extended trackers exceeding the refresh time. Statement 36. Embodiments of this disclosure include the storage device according to Statement 30, wherein the extension tracker is further configured to automatically update the retention period based at least in part on the number of extensions exceeding the refresh time. Statement 37. Embodiments of this disclosure include the storage device according to Statement 35, wherein the extended tracker is configured to increment the number of refresh times. Statement 38. Embodiments of this disclosure include a storage device according to Statement 35, wherein a logic-to-entity mapping table further maps logical addresses to the number of refresh times. Statement 39. Embodiments of this disclosure include the storage device according to Statement 30, wherein: The translation layer is configured to select a second entity address for data in the first memory, based at least in part on the retention period, to store the data, and updates the logical-to-entity mapping table to map the logical address to the second entity address and the retention period; and The controller is configured to program data into a second physical address in the first memory. Statement 40. Embodiments of this disclosure include a storage device according to statement 39, wherein the controller is further configured to invalidate data at physical addresses in a first storage unit. Statement 41. Embodiments of this disclosure include a storage device according to Statement 25, wherein a logic-to-entity mapping table further maps logical addresses to an extended number. Statement 42. Embodiments of this disclosure include a storage device according to Statement 24, wherein an extended tracker is configured to invalidate data at physical addresses in a first storage unit at least in part based on the expiration of a retention period. Statement 43. Embodiments of this disclosure include a storage device according to Statement 24, wherein an extended tracker is configured to automatically invalidate data at physical addresses in a first storage unit, at least in part based on the expiration of a retention period. Statement 44. Embodiments of this disclosure include a storage device according to Statement 42, wherein the extension tracker is further configured to invalidate data at physical addresses in the first storage unit based at least in part on an extension number of zero. Statement 45. Embodiments of this disclosure include the storage device according to Statement 42, wherein the extension tracker is further configured to automatically invalidate data at physical addresses in the first storage unit, at least in part based on the extension number being zero. Statement 46. Embodiments of this disclosure include a storage device according to Statement 42, wherein the extension tracker is further configured to invalidate data at physical addresses in the first storage based at least in part on the number of extensions equal to the number of refresh times. Statement 47. Embodiments of this disclosure include a storage device according to Statement 42, wherein the extension tracker is further configured to automatically invalidate data at physical addresses in the first storage device, at least in part based on the number of extensions equal to the number of refresh times. Statement 48. Embodiments of this disclosure include a storage device according to Statement 46, wherein a logical-to-physical mapping table further maps logical addresses to an extension number and a refresh time number. Statement 49. Embodiments of this disclosure include the storage device according to Statement 42, wherein the translation layer includes an automatic logger that records logical addresses in a data retention period log at least in part based on data failure. Statement 50. Embodiments of this disclosure include the storage device according to Statement 49, wherein the translation layer is configured to receive a request for a data retention periodic log from the host and transmit the data retention periodic log back to the host. Statement 51. Embodiments of this disclosure include a storage device according to Statement 1, wherein the translation layer includes a waste collection controller that is at least partially based on a retention cycle scheduling waste collection. Statement 52. Embodiments of this disclosure include a storage device according to Statement 1, wherein the translation layer is configured to receive configuration commands from the host. Statement 53. Embodiments of this disclosure include the storage device according to Statement 52, wherein the configuration commands include at least one of an enable retention command, a disable retention command, a set of available retention periods, a preset retention period, or a preset extension number. Statement 54. Embodiments of this disclosure include the storage device according to Statement 1, wherein the translation layer includes at least a first commit queue associated with a retention period and a second commit queue associated with a second retention period. Statement 55. Embodiments of this disclosure include the storage device according to Statement 1, wherein: The host interface is configured to receive read requests from the host, and the read request contains a logical address; The logic-to-entity mapping table further maps logical addresses to the first ECC mode; The translation layer is configured to use a logical-to-entity mapping table to determine the entity address and the first ECC mode, at least in part, based on the logical address, and then transmits the data back to the host; and The controller is configured to read encoded data from an entity address in a first memory and decode the encoded data, at least in part, based on a first ECC mode, to generate data. Statement 56. Embodiments of this disclosure include a method comprising: The storage device receives a write request from the host, which includes the data and its logical address. Determine the retention period for the data; The physical address in the storage device is selected to store data, at least in part, based on the retention period; Update the logical-to-entity mapping table in the storage device to store logical addresses, entity addresses, and retention periods; and The data is programmed into physical addresses in the storage device. Statement 57. Embodiments of this disclosure include the method described in statement 56, and further include transmitting the result of the write request back from the storage device to the host. Statement 58. Embodiments of this disclosure include the method according to statement 56, wherein: Receiving write requests from the host at the storage device includes receiving write requests from the host at the solid-state drive (SSD); Selecting physical addresses in the storage device to store data, at least in part based on the retention period, includes selecting physical addresses in blocks within the SSD to store data, at least in part based on the retention period. Updating the logical-to-physical mapping table in the storage device to store logical addresses, physical addresses, and retention periods includes updating the logical-to-physical mapping table in the SSD to store logical addresses, physical addresses, and retention periods; and The physical address of data programmed into the storage device includes the physical address of the block in the SSD. Statement 59. Embodiments of this disclosure include the method according to statement 58, wherein: Selecting physical addresses in blocks within the SSD to store data, at least in part based on the retention period, includes selecting physical addresses in blocks within the Flash Translation Layer (FTL) of the SSD to store data, at least in part based on the retention period; and Updating the logical-to-entity mapping table in the SSD to store logical addresses, entity addresses, and retention periods includes updating the logical-to-entity mapping table in the FTL of the SSD to store logical addresses, entity addresses, and retention periods. Statement 60. Embodiments of this disclosure include the method according to statement 58, wherein programming data to a physical address in the SSD includes: The programmatic request is sent to the controller, and the second write request contains data and entity address; and The controller programs the data into the physical addresses of blocks in the SSD. Statement 61. Embodiments of this disclosure include the method according to statement 58, wherein programming data to the entity address in a block of the SSD includes: The buffer contains data with a second data component, which is associated with a retention period; and The data is programmed into the physical address of a block in the SSD; and The second data is programmed into the second entity address in the block of the SSD. Statement 62. Embodiments of this disclosure include the method according to statement 58, wherein the block contains second data associated with a retention period. Statement 63. Embodiments of this disclosure include the method according to statement 56, wherein: Write requests also include a retention period; and The retention period is determined to include the retention period for write-request access. Statement 64. Embodiments of this disclosure include the method according to statement 56, wherein determining the retention period includes determining the retention period based at least in part on the attributes of the write request. Statement 65. Embodiments of this disclosure include the method according to statement 64, wherein the attributes of the write request are at least one of the following: logical block address (LBA) range, command identifier, namespace identifier, stream identifier, region namespace identifier, identifier of the commit queue, date, time, protocol, media access control identifier, network parameters, or storage device parameters. Statement 66. Embodiments of this disclosure include the method according to statement 56, wherein the determination of the retention period includes a preset retention period for accessing the storage device. Statement 67. Embodiments of this disclosure include the method according to statement 56, wherein the retention period is at least one of a first data retention period and a second data retention period. Statement 68. Embodiments of this disclosure include the method according to statement 56, wherein: The method further includes selecting a first error correction code (ECC) mode from at least a first ECC mode and a second ECC mode, based at least in part on the retention period; Updating the logical-to-entity mapping table in the storage device to store logical addresses, entity addresses, and retention periods includes updating the logical-to-entity mapping table in the storage device to further store the first ECC mode; and The process of programming data to physical addresses in a storage device includes programming data to physical addresses in a storage device in at least part based on a first ECC mode. Statement 69. Embodiments of this disclosure include the method according to statement 68, wherein programming data to a physical address in the storage device, at least in part based on a first ECC mode, includes: At least in part, encoded data is generated based on data encoded in the first ECC mode; and The encoded data is programmed into a physical address in the storage device. Statement 70. Embodiments of this disclosure include the method according to statement 68, wherein selecting the first ECC mode from at least a first ECC mode and a second ECC mode based at least in part on the retention period includes reading the first ECC mode from a table stored in a storage device based at least in part on the retention period. Statement 71. Embodiments of this disclosure include the method according to statement 68, wherein: The method further includes selecting the first programmed step voltage based at least in part on the retention period from at least the first programmed step voltage and the second programmed step voltage; Updating the logic-to-entity mapping table in the storage device to store logical addresses, entity addresses, and retention periods further includes updating the logic-to-entity mapping table in the storage device to further store the first programmed step voltage; and The data programming to the physical address in the storage device includes programming the data to the physical address in the storage device based at least in part on the first ECC mode and the first programming step voltage. Statement 72. Embodiments of this disclosure include the method according to statement 71, wherein programming data to a physical address in the storage device based at least in part on a first ECC mode and a first programming step voltage includes: At least in part, encoded data is generated based on data encoded in the first ECC mode; and The encoded data is programmed into physical addresses in the storage device, at least in part based on the first programmed step voltage. Statement 73. Embodiments of this disclosure include the method according to statement 71, wherein selecting the first programmed step voltage based at least in part on a retention period from at least a first programmed step voltage and a second programmed step voltage includes reading the first programmed step voltage from a table stored in a storage device based at least in part on the retention period. Statement 74. Embodiments of this disclosure include the method according to statement 56, wherein: The method further includes selecting the first programmed step voltage based at least in part on the retention period from at least the first programmed step voltage and the second programmed step voltage; Updating the logic-to-entity mapping table in the storage device to store logical addresses, entity addresses, and retention periods includes updating the logic-to-entity mapping table in the storage device to further store the first programmed step voltage; and The process of programming data to physical addresses in a storage device includes programming data to physical addresses in a storage device in at least part based on a first programming step voltage. Statement 75. Embodiments of this disclosure include the method according to statement 74, wherein selecting the first programmed step voltage based at least in part on a retention period from at least a first programmed step voltage and a second programmed step voltage includes reading the first programmed step voltage from a table stored in a storage device based at least in part on the retention period. Statement 76. Embodiments of this disclosure include the method according to statement 56, wherein: The method further includes determining the number of extensions used for the data retention period; and Updating the logical-to-entity mapping table in the storage device to store logical addresses, entity addresses, and retention periods includes updating the logical-to-entity mapping table in the storage device to further store extended numbers. Statement 77. Embodiments of this disclosure include the method according to statement 76, wherein: Write requests also include an expansion number; and The number of extensions to determine includes the number of self-write request access extensions. Statement 78. Embodiments of this disclosure include the method according to statement 76, wherein determining the number of extensions includes determining the number of extensions based at least in part on the attributes of the write request. Statement 79. Embodiments of this disclosure include the method according to statement 78, wherein the attributes of the write request are at least one of the following: LBA range, command identifier, namespace identifier, stream identifier, zone namespace identifier, identifier of the commit queue, date, time, protocol, media access control identifier, network parameters, or storage device parameters. Statement 80. Embodiments of this disclosure include the method according to statement 76, wherein determining the number of extensions includes a preset number of extensions for accessing the storage device. Statement 81. Embodiments of this disclosure include the method according to statement 76, wherein updating the logical-to-entity mapping table in the storage device to store logical addresses, entity addresses, and retention periods further includes updating the logical-to-entity mapping table in the storage device to further store the number of refresh times. Statement 82. Embodiments of this disclosure include the method according to statement 76, and further include: The retention period has expired; and The retention period is updated at least in part based on the number of extensions. Statement 83. Embodiments of this disclosure include the method according to statement 76, wherein updating the retention period at least in part based on the extension number includes automatically updating the retention period at least in part based on the extension number. Statement 84. Embodiments of this disclosure include the method according to statement 82, wherein: The method further includes checking for schedule retention periods that have already expired; and Determining that a retention period has expired includes at least in part based on the scheduled time reached. Statement 85. Embodiments of this disclosure include the method described according to Statement 82, and further include a decreasing number of extensions. Statement 86. Embodiments of this disclosure include the method described in statement 82, and further include increasing the number of refresh times. Statement 87. Embodiments of this disclosure include the method according to Statement 82, wherein updating the retention period based at least in part on the extension number comprises: The second physical address in the storage device is selected at least in part based on the retention period for storing data; and The data is programmed into a second physical address in the storage device. Statement 88. Embodiments of this disclosure include the method according to statement 87, wherein programming data to a second physical address in the storage device includes reading data from the physical address in the storage device. Statement 89. Embodiments of this disclosure include the method according to Statement 87, wherein updating the retention period at least in part based on an extended number further includes updating a logical-to-entity mapping table in the storage device to store a logical address, a second entity address, and a retention period. Statement 90. Embodiments of this disclosure include the method described in statement 56, and further include waste collection for storage devices based at least in part on retention cycle scheduling. Statement 91. Embodiments of this disclosure include the method according to statement 56, and further include: The retention period has expired; and At least in part, the data at the physical address on the storage device is invalidated based on the number of extensions. Statement 92. Embodiments of this disclosure include the method according to Statement 56, wherein invalidating data at a physical address on the storage device based at least in part on an extension number includes automatically invalidating data at a physical address on the storage device based at least in part on an extension number. Statement 93. Embodiments of this disclosure include the method described in statement 91, and further include recording logical addresses in a data retention period log at least in part based on data failure. Statement 94. Embodiments of this disclosure include the method according to statement 93, and further include: Receive requests from the host for data retention periodic logs at the storage device; and The data retention period log is transmitted from the storage device back to the host. Statement 95. Embodiments of this disclosure include the method described in statement 56, and further include receiving configuration commands from a host. Statement 96. Embodiments of this disclosure include the method according to statement 95, wherein the configuration command includes at least one of an enable retention command, a disable retention command, a set of available retention periods, a preset retention period, or a preset extension number. Statement 97. Embodiments of this disclosure include the method described in statement 56, further including placing write requests in a first commit queue at least in part based on a retention period, the storage device including the first commit queue and a second commit queue. Statement 98 The embodiments disclosed herein include a method comprising: The storage device receives a read request from the host, which contains the logical address of the data. The entity address of the data is determined at least in part based on the logical address; Error correction code (ECC) patterns are determined at least in part based on logical address data; Encoded data is read from the physical address in the self-storage device; Decoding encoded data to generate data is at least partially based on ECC mode; and Data is transferred from the storage device back to the host computer. Statement 99. Embodiments of this disclosure include the method according to statement 98, wherein: Receiving read requests from the host at the storage device includes receiving read requests from the host at the solid-state drive (SSD); and Transferring data from storage devices back to the host includes transferring data from an SSD back to the host. Statement 100. Embodiments of this disclosure include the method according to statement 98, wherein: The entity address of the data is determined at least partially based on the logical address, which includes the entity address of the data in the logical-to-entity mapping table being determined at least partially based on the logical address; and An ECC schema that determines data based at least in part on logical addresses includes an ECC schema that determines data in a logical-to-entity mapping table based at least in part on logical addresses. Statement 101. Embodiments of this disclosure include the method according to statement 98, wherein: Encoded data read from the physical address of the self-stored device includes: A second read request is sent to the controller, the second read request containing the entity address; and The controller reads encoded data from the physical address in the storage device. Decoding encoded data in at least part based on ECC mode to generate data includes decoding encoded data in at least part based on ECC mode by a controller to generate data; and Data is transferred from the storage device back to the host, including data transferred from the controller. Statement 102 Embodiments of this disclosure include an article comprising a non-transitory storage medium having instructions thereon that, when executed by a machine, cause the following operations: The storage device receives a write request from the host, which includes the data and its logical address. Determine the retention period for the data; The physical address in the storage device is selected to store data, at least in part, based on the retention period; Update the logical-to-entity mapping table in the storage device to store logical addresses, entity addresses, and retention periods; and The data is programmed into physical addresses in the storage device. Statement 103 The embodiments disclosed herein include an article according to Statement 102, wherein a non-transitory storage medium stores additional instructions thereon, which, when executed by a machine, cause the result of a write request to be transmitted back from the storage device to the host. Statement 104. Embodiments of this disclosure include the articles according to Statement 102, wherein: Receiving write requests from the host at the storage device includes receiving write requests from the host at the solid-state drive (SSD); Selecting physical addresses in the storage device to store data, at least in part based on the retention period, includes selecting physical addresses in blocks within the SSD to store data, at least in part based on the retention period. Updating the logical-to-physical mapping table in the storage device to store logical addresses, physical addresses, and retention periods includes updating the logical-to-physical mapping table in the SSD to store logical addresses, physical addresses, and retention periods; and The physical address of data programmed into the storage device includes the physical address of the block in the SSD. Statement 105. Embodiments of this disclosure include the articles described in statement 104, wherein: Selecting physical addresses in blocks within the SSD to store data, at least in part based on the retention period, includes selecting physical addresses in blocks within the Flash Translation Layer (FTL) of the SSD to store data, at least in part based on the retention period; and Updating the logical-to-entity mapping table in the SSD to store logical addresses, entity addresses, and retention periods includes updating the logical-to-entity mapping table in the FTL of the SSD to store logical addresses, entity addresses, and retention periods. Statement 106. Embodiments of this disclosure include the article according to Statement 104, wherein the physical address of data programmed into the SSD includes: The programmatic request is sent to the controller, and the second write request contains data and entity address; and The controller programs the data into the physical addresses of blocks in the SSD. Statement 107. Embodiments of this disclosure include the article according to Statement 104, wherein the entity address in a block of data programmed into the SSD includes: The buffer contains data with a second data component, which is associated with a retention period; and The data is programmed into the physical address of a block in the SSD; and The second data is programmed into the second entity address in the block of the SSD. Statement 108. Embodiments of this disclosure include articles according to Statement 104, wherein blocks contain second data associated with a retention period. Statement 109. Embodiments of this disclosure include the articles according to Statement 102, wherein: Write requests also include a retention period; and The retention period is determined to include the retention period for write-request access. Statement 110. Embodiments of this disclosure include the article described in statement 102, wherein determining the retention period includes determining the retention period based at least in part on the attributes of the write request. Statement 111. Embodiments of this disclosure include the article according to Statement 110, wherein the attributes of the write request are at least one of the following: logical block address (LBA) range, command identifier, namespace identifier, stream identifier, region namespace identifier, identifier of the commit queue, date, time, protocol, media access control identifier, network parameters, or storage device parameters. Statement 112. Embodiments of the present invention include the article according to statement 102, wherein the determination of the retention period includes a preset retention period for accessing the storage device. Statement 113. Embodiments of this disclosure include articles according to statement 102, wherein the retention period is at least one of a first data retention period and a second data retention period. Statement 114. Embodiments of this disclosure include the articles described in statement 102, wherein: The non-transitory storage medium stores additional instructions thereon, which, when executed by a machine, cause the selection of a first error correction code (ECC) mode from at least a first ECC mode and a second ECC mode based at least in part on a retention period; Updating the logical-to-entity mapping table in the storage device to store logical addresses, entity addresses, and retention periods includes updating the logical-to-entity mapping table in the storage device to further store the first ECC mode; and The process of programming data to physical addresses in a storage device includes programming data to physical addresses in a storage device in at least part based on a first ECC mode. Statement 115. Embodiments of this disclosure include the article according to Statement 114, wherein the programming of data to a physical address in the storage device, at least in part based on a first ECC mode, includes: At least in part, encoded data is generated based on data encoded in the first ECC mode; and The encoded data is programmed into a physical address in the storage device. Statement 116. Embodiments of this disclosure include the article according to statement 114, wherein selecting the first ECC mode from at least a first ECC mode and a second ECC mode based at least in part on the retention period includes reading the first ECC mode from a table stored in a storage device based at least in part on the retention period. Statement 117. Embodiments of this disclosure include the articles described in statement 114, wherein: The non-transient storage medium stores additional instructions thereon, which, when executed by a machine, cause the selection of a first programmed step voltage based at least in part on a retention period from at least a first programmed step voltage and a second programmed step voltage; Updating the logic-to-entity mapping table in the storage device to store logical addresses, entity addresses, and retention periods further includes updating the logic-to-entity mapping table in the storage device to further store the first programmed step voltage; and The data programming to the physical address in the storage device includes programming the data to the physical address in the storage device based at least in part on the first ECC mode and the first programming step voltage. Statement 118. Embodiments of this disclosure include the article according to Statement 117, wherein the programming of data to a physical address in the storage device, at least in part based on a first ECC mode and a first programming step voltage, includes: At least in part, encoded data is generated based on data encoded in the first ECC mode; and The encoded data is programmed into physical addresses in the storage device, at least in part based on the first programmed step voltage. Statement 119. Embodiments of this disclosure include the article according to Statement 117, wherein selecting the first programmed step voltage based at least in part on a retention period from at least a first programmed step voltage and a second programmed step voltage includes reading the first programmed step voltage from a table stored in a storage device based at least in part on the retention period. Statement 120. Embodiments of this disclosure include the articles according to Statement 102, wherein: The non-transient storage medium stores additional instructions thereon, which, when executed by a machine, cause the selection of a first programmed step voltage based at least in part on a retention period from at least a first programmed step voltage and a second programmed step voltage; Updating the logic-to-entity mapping table in the storage device to store logical addresses, entity addresses, and retention periods includes updating the logic-to-entity mapping table in the storage device to further store the first programmed step voltage; and The process of programming data to physical addresses in a storage device includes programming data to physical addresses in a storage device in at least part based on a first programming step voltage. Statement 121. Embodiments of this disclosure include the article according to Statement 120, wherein selecting the first programmed step voltage based at least in part on a retention period from at least a first programmed step voltage and a second programmed step voltage includes reading the first programmed step voltage from a table stored in a storage device based at least in part on the retention period. Statement 122. Embodiments of this disclosure include the articles according to statement 102, wherein: The non-transitory storage medium stores additional instructions thereon, which, when executed by a machine, cause the determination of the extension number of the data retention period; and Updating the logical-to-entity mapping table in the storage device to store logical addresses, entity addresses, and retention periods includes updating the logical-to-entity mapping table in the storage device to further store extended numbers. Statement 123. Embodiments of this disclosure include the articles according to Statement 122, wherein: Write requests also include an expansion number; and The number of extensions to determine includes the number of self-write request access extensions. Statement 124. Embodiments of this disclosure include an article according to Statement 122, wherein determining the number of extensions includes determining the number of extensions based at least in part on the attributes of the write request. Statement 125. Embodiments of this disclosure include the article according to Statement 124, wherein the attributes of the write request are at least one of the following: LBA range, command identifier, namespace identifier, stream identifier, zone namespace identifier, identifier of the commit queue, date, time, protocol, media access control identifier, network parameters, or storage device parameters. Statement 126. Embodiments of this disclosure include the article according to statement 122, wherein determining the number of extensions includes a preset number of extensions for accessing the storage device. Statement 127. Embodiments of this disclosure include the article according to Statement 122, wherein updating the logical-to-entity mapping table in the storage device to store logical addresses, entity addresses, and retention periods further includes updating the logical-to-entity mapping table in the storage device to further store the number of refresh times. Statement 128. Embodiments of this disclosure include an article according to Statement 122, wherein a non-transitory storage medium stores additional instructions thereon, which, when executed by a machine, cause the following operations: The retention period has expired; and The retention period is updated at least in part based on the number of extensions. Statement 129. Embodiments of this disclosure include the article according to Statement 122, wherein updating the retention period at least in part based on the extension number includes automatically updating the retention period at least in part based on the extension number. Statement 130. Embodiments of this disclosure include the articles described in statement 128, wherein: The non-transitory storage medium stores additional instructions thereon, which, when executed by a machine, cause a check that the schedule retention period has expired after the scheduled time; and Determining that a retention period has expired includes at least in part based on the scheduled time reached. Statement 131. Embodiments of this disclosure include an article according to Statement 128, wherein a non-transitory storage medium stores additional instructions thereon, which cause a decreasing number of extensions when executed by a machine. Statement 132. Embodiments of this disclosure include an article according to Statement 128, wherein a non-transitory storage medium stores additional instructions thereon, which, when executed by a machine, cause an increase in the refresh time. Statement 133. Embodiments of this disclosure include the article according to Statement 128, wherein updating the retention period based at least in part on an extended number comprises: The second physical address in the storage device is selected at least in part based on the retention period for storing data; and The data is programmed into a second physical address in the storage device. Statement 134. Embodiments of this disclosure include the article according to Statement 133, wherein programming data to a second physical address in the storage device includes reading data from the physical address in the storage device. Statement 135. Embodiments of this disclosure include the article described in statement 133, wherein updating the retention period based at least in part on an extended number further includes updating a logical-to-entity mapping table in the storage device to store logical addresses, second entity addresses, and retention periods. Statement 136 The embodiments disclosed herein include an article according to Statement 102, wherein a non-transient storage medium stores additional instructions thereon, which, when executed by a machine, cause at least in part a retention period scheduling for waste collection of the storage device. Statement 137. Embodiments of this disclosure include an article according to Statement 102, wherein a non-transitory storage medium stores additional instructions thereon, which, when executed by a machine, cause the following operations: The retention period has expired; and At least in part, the data at the physical address on the storage device is invalidated based on the number of extensions. Statement 138. Embodiments of this disclosure include articles according to Statement 102, wherein invalidating data at physical addresses on a storage device based at least in part on an extension number includes automatically invalidating data at physical addresses on a storage device based at least in part on an extension number. Statement 139. Embodiments of this disclosure include an article according to Statement 137, wherein a non-transitory storage medium stores additional instructions thereon, which, when executed by a machine, cause logical addresses to be recorded in a data retention period log at least in part based on data failure. Statement 140. Embodiments of this disclosure include an article according to Statement 139, wherein a non-transitory storage medium stores additional instructions thereon, which, when executed by a machine, cause the following operations: Receive requests from the host for data retention periodic logs at the storage device; and The data retention period log is transmitted from the storage device back to the host. Statement 141. Embodiments of this disclosure include an article according to Statement 102, wherein a non-transitory storage medium stores additional instructions thereon, which, when executed by a machine, cause a configuration command to be received from a host computer. Statement 142. Embodiments of this disclosure include the article according to statement 141, wherein the configuration command includes at least one of an enable retention command, a disable retention command, a set of available retention periods, a preset retention period, or a preset extension number. Statement 143. Embodiments of this disclosure include an article according to Statement 102, wherein a non-transitory storage medium stores additional instructions thereon, which, when executed by a machine, cause write requests to be placed in a first commit queue at least in part based on a retention period, the storage device including a first commit queue and a second commit queue. Statement 144 Embodiments of this disclosure include an article comprising: The storage device receives a read request from the host, which contains the logical address of the data. The entity address of the data is determined at least in part based on the logical address; Error correction code (ECC) patterns are determined at least in part based on logical address data; Encoded data is read from the physical address in the self-storage device; Decoding encoded data to generate data is at least partially based on ECC mode; and Data is transferred from the storage device back to the host computer. Statement 145. Embodiments of this disclosure include the articles described in statement 144, wherein: Receiving read requests from the host at the storage device includes receiving read requests from the host at the solid-state drive (SSD); and Transferring data from storage devices back to the host includes transferring data from an SSD back to the host. Statement 146. Embodiments of this disclosure include the articles described in statement 144, wherein: The entity address of the data is determined at least partially based on the logical address, which includes the entity address of the data in the logical-to-entity mapping table being determined at least partially based on the logical address; and An ECC schema that determines data based at least in part on logical addresses includes an ECC schema that determines data in a logical-to-entity mapping table based at least in part on logical addresses. Statement 147. Embodiments of this disclosure include articles according to Statement 144, wherein: Encoded data read from the physical address of the self-stored device includes: A second read request is sent to the controller, the second read request containing the entity address; and The controller reads encoded data from the physical address in the storage device. Decoding encoded data in at least part based on ECC mode to generate data includes decoding encoded data in at least part based on ECC mode by a controller to generate data; and Data is transferred from the storage device back to the host, including data transferred from the controller.

[0134] Therefore, given the wide variety of variations of the embodiments described herein, this detailed description and accompanying materials are intended to be illustrative only and should not be considered as limiting the scope of this disclosure. The claimed disclosure therefore encompasses all such modifications within the scope and spirit of the following patent claims and their equivalents.

[0135] 100: Electronic devices 105: Machine 110: Processor 115: Memory 120: Storage device 125: Memory controller 130: Device driver 205: Clock 210: Network Connector 215: Busbar 220: User Interface 225:I / O engine 305: Interface 310: Host Interface Layer 315: SSD Controller 320-1, 320-2, 320-3, 320-4: Channels 325-1, 325-2, 325-3, 325-4, 325-5, 325-6, 325-7, 325-8: Flash memory chips 330: Flash Translation Layer 335: Flash Controller 405-1, 405-2: Superblock Blocks 410-1 and 410-2 Pages 415-1, 415-2, and 415-3 505: Host Write Request Handler 510: Host Read Request Handler 515: Write Request 520: Read Request 525-1, 525-2, 525-3: Submit queue 530: Retention Period Determiner 535: Buffer 540: ECC Selector 545: Table 550: Programmable Step Voltage Selector 555: Extended Tracker 560: Automatic Recorder 565: Logical to Entity Mapping Table 570: Waste Collection Controller 575: Storage 605: Data 610: Logical address 615: Retention Period 620: Number of extensions 805: Entity Address 810: ECC Mode 815: Programmed Step Voltage 820: Refresh Time 1005: Flash Command Interface 1010-1, 1010-2: ECC encoder / decoder 1015: Flash Interface 1020-1, 1020-2: Grains 1105: Error 1110: Data Retention Period Log Request 1115: Data Retention Period Log Response 1120: Data Retention Period Log 1205, 1210, 1215, 1220, 1225, 1305, 1310, 1315, 1325, 1335, 1345, 1350, 1405, 1410, 1420, 1505, 1510, 1515, 1520, 1525, 1530, 1605, 1610, 1615, 1705, 1710, 171 5, 1720, 1725, 1730, 1735, 1740, 1745, 1750, 1805, 1810, 1905, 1910, 1915, 1920, 1925, 2005, 2010, 2015, 2020, 2025, 2030, 2105, 2110, 2115, 2125, 2205, 2210: Blocks 1320, 1330, 1340, 1415: Dashed lines

Claims

1. A storage device, comprising: A host interface for receiving write requests from a host, the write request containing data and the logical address of the data; A first storage device is used for the data; A retention period determiner is used to identify a data set associated with the data and the second data, and to determine the retention period and number of expansions of the data set; a translation layer is used to select an entity address in the first memory to store the data, at least in part based on the retention period; A second storage unit is provided to store a logical-to-entity mapping table that stores the logical address associated with the entity address, the retention period, and the number of extensions; And a controller for programming the data into the physical address in the first memory.

2. The storage device as claimed in claim 1, wherein the translation layer includes an error correction code selector that selects the first error correction code mode from at least a first error correction code mode and a second error correction code mode based at least in part on the retention period.

3. The storage device as claimed in claim 2, wherein the logic-to-entity mapping table further maps the logical address to the first error correction code pattern.

4. The storage device as claimed in claim 1, wherein the first memory includes a Not-And (NAND) flash memory, the translation layer includes a programmable step voltage selector that selects the first programmable step voltage from at least a first programmable step voltage and a second programmable step voltage based at least in part on the retention period, and the logic-to-entity mapping table further stores the logical address associated with the first programmable step voltage.

5. The storage device as claimed in claim 1, wherein the translation layer includes an extended tracker that tracks the expiration of the retention period.

6. The storage device as claimed in claim 5, wherein the expansion tracker is configured to automatically update the retention period at least in part based on the number of expansions.

7. The storage device as claimed in claim 5, wherein the extension tracker is configured to invalidate the data at the physical address in the first storage at least in part based on the expiration of the retention period and the number of extensions.

Images