Background data refresh using system timestamps from storage

Abstract

Techniques for performing background refreshes of a storage device using timestamps from a host are described. In one example, the method involves receiving a timestamp from the host, storing the timestamp in a storage device, and determining a retention time for data stored in one or more blocks of the storage device based on the timestamp relative to a second timestamp indicating a time when the data was written to the one or more blocks. In response to determining that the retention time exceeds a threshold, the storage device moves the data to one or more other blocks of the storage device, which may include interleaving activity from the host with the refresh writes.

Description

Technical Field

[0001] The present description relates generally to storage devices such as solid-state drives, and more particularly to techniques for background data refresh using system timestamps of the storage devices. Background Art

[0002] There is a trend across mobile, client, and enterprise systems to use solid-state drives (SSDs) for data storage. Solid-state drives, such as NAND SSDs, include non-volatile storage devices. Non-volatile storage devices are storage devices whose state remains fixed even when power to the device is interrupted. However, even non-volatile storage devices have limited data retention capabilities, and data stored in the non-volatile storage devices may require refreshing. Failure to refresh data may result in the loss of data stored on the non-volatile storage devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The following description includes a discussion of the accompanying drawings that are provided as examples of implementations of embodiments of the present invention. The accompanying drawings should be understood as examples and not as limitations. As used herein, references to one or more "embodiments" or "examples" are to be understood as describing specific features, structures, and / or characteristics included in at least one implementation of the present invention. Therefore, phrases such as "in one embodiment" or "in an example" that appear herein describe various embodiments and implementations of the present invention and do not necessarily all refer to the same embodiment. However, they are not necessarily mutually exclusive.

[0004] Figure 1 A block diagram is shown of a system with an SSD in which background data refresh can be implemented according to one example.

[0005] Figure 2 is a block diagram illustrating an example of the transfer of system clock information from a host to an SSD.

[0006] Figure 3A An example of a super block of an SSD is shown.

[0007] Figure 3B is a table showing examples of information that an SSD may store to enable accurate data refresh.

[0008] Figure 4A An example of an identification controller data structure is shown that can be used to identify which features are supported by a given memory device, including whether the memory device can accept system clock information.

[0009] Figure 4B is a table showing an example of how system clock information may be sent from a host to a storage device via a set feature command.

[0010] Figure 5 is a flow chart illustrating an example of a method for performing a background refresh using a system timestamp.

[0011] Figure 6 is a flow chart illustrating an example of a method performed by a storage device to perform a background refresh using a system timestamp.

[0012] Figure 7 is a flow chart illustrating an example of a method performed by a host to provide a system timestamp to enable background refresh.

[0013] Figure 8 is an example of pseudocode for setting the background refresh rate.

[0014] Figure 9 is a block diagram of an example of a computing device with an SSD in which background data refresh can be implemented, according to one example.

[0015] Figure 10 is a block diagram of an example of a mobile device with an SSD in which background data refresh can be implemented according to one example.

[0016] Certain details and implementations are then described, including a description of the accompanying figures, which may depict some or all of the embodiments described below, as well as a discussion of other potential embodiments or implementations of the inventive concepts presented herein. DETAILED DESCRIPTION

[0017] This article describes techniques for background data refresh on non-volatile storage devices, such as solid-state drives (SSDs). Background data refresh involves refreshing "cold data" stored on the storage device to prevent retention-related errors or failures. Cold data is infrequently accessed data stored on the storage device. Cold data may be stored on the storage device and not accessed for a period of time that approaches or exceeds the maximum retention capacity of the storage device. Refreshing the data involves writing the data to another location (or rewriting the data to the same location), which can prevent data loss.

[0018] Enterprise solid-state drives (SSDs), such as those used in servers, implement refresh technologies that rely on an internal time clock. Enterprise SSDs are typically always powered on and maintain a time clock that shows when data is written to the SSD blocks. However, SSDs used in mobile and other consumer devices are not constantly powered on and often enter a low-power state to reduce power consumption and preserve battery life. When powered off or in the lowest power mode, most components of the storage device are powered down, including those used to maintain the time clock. Therefore, existing technologies for refreshing data stored in SSDs are ineffective for mobile and other consumer SSDs.

[0019] Background data refresh techniques that use the system clock, rather than relying on an internal clock, enable refreshing cold data stored on a storage device, even when the storage device is powered off or in a low-power state. In one example, the storage device maintains timestamp information for each Super Block (or each block, page, or other granularity) storing data, indicating the time the data was written to the Super Block. When the storage device is powered off or enters a low-power state, the storage device saves the timestamp information to non-volatile media (NVM). After the storage device is powered on or exits a low-power state, the storage device loads the timestamp information from the non-volatile storage device and also receives a timestamp indicating the current time from the host. Compared to existing techniques, the storage device can use the current timestamp received from the host to accurately determine the retention time of data in each Super Block storing data, even if the device has been powered off or in a low-power state for a period of time. If the retention time exceeds a threshold, the storage device can refresh the data. In one example, the storage device refreshes the data by placing those Super Blocks in a queue and interleaving writes from the queue with host traffic. Therefore, using the refresh technique derived from the host's system clock enables accurate determination of retention time and reduces data loss in mobile and other consumer devices.

[0020] Figure 1 A block diagram of a system having an SSD in which background data refresh can be implemented is shown according to one example. The system 100 includes a solid state drive (SSD) 102 coupled to a host 110 .

[0021] Host 110 represents a host hardware platform connected to SSD 102. Host 110 includes a CPU (central processing unit) 120 or other processor that serves as a host processor. CPU 120 represents any host processor that generates a request to access data stored on SSD 102 or to read data or write data to storage device 122. Such processors may include single or multi-core processors, a main processor for a computing device, a graphics processor, a peripheral processor, or a supplemental or auxiliary processor, or a combination. Host 110 includes a chipset 114, which represents a hardware component that can control or manage the flow of data between CPU 120 and other components of system 100, including SSD 102. For example, chipset 114 may include interconnect circuitry and logic to enable access to SSD 102. In one example, chipset 114 includes a storage controller, which is a host-side controller separate from controller 130 within SSD 102. Although Figure 1A chipset in the host is shown, which includes logic for controlling access to the SSD. In other examples, the host 110 may not include a chipset, or if it does include a chipset, the storage controller may be independent of the chipset. In one example, the chipset, storage controller, or both are integrated with the CPU 120. The host 110 also includes a clock generator 132 to generate a system clock. In one example, the clock generator 132 includes circuits such as a resonant circuit and an amplifier to generate timing signals for synchronizing the operation of the platform 100.

[0022] The host also includes firmware and software that executes on the hardware, such as an operating system 112, a file system 124, a basic input / output system (BIOS) 118, drivers 116, and other firmware and software. When the system is powered on, the BIOS 118 is generally responsible for initializing the hardware and loading the operating system 112. The operating system 112 is generally responsible for managing, coordinating, and scheduling activities on the system 100, as well as sharing system resources. The file system 124 interacts with the software, firmware, or both to access the SSD 102. For example, the host 110 may include an SSD driver, via which the operating system 112 and file system 124 can access the SSD. An example of an SSD driver is an Intel® Rapid Storage Technology (RST) driver. Although system 100 is illustrated as a computer system having a host operating system and an SSD for storing data, system 100 may alternatively include storage devices connected to an SPI bus or SPI (Serial Peripheral Interface) storage devices, key-value solutions based on LSM (Logarithmic Structure Merging), solutions based on three-dimensional crosspoint memory, or other storage systems.

[0023] SSD 102 represents a solid-state drive and includes a non-volatile storage device 122 (which may also be referred to as non-volatile media (NVM)) for storing data. SSD 102 may be a flash-based drive that connects to a processor using PCI Express (PCIe), Serial Advanced Technology Attachment (ATA), Parallel ATA, and / or Universal Serial Bus (USB) interfaces. Storage device 122 may include one or more of the following: NAND, NOR flash, phase-change memory (PCM), phase-change memory with switches (PCMS), resistive memory, or other non-volatile storage media. Data may be stored in single-level cell (SLC), triple-level cell (TLC), quad-level cell (QLC), and / or multi-level cell (MLC) formats. TLC, QLC, and / or MLC cells or blocks are typically used to store user data. SLC cells or blocks (which typically have faster access speeds at the expense of reduced storage density) typically do not store user data and are generally not accessible to the host. An SSD may use SLC cells or blocks to store "system data" related to the operation of the SSD.

[0024] In addition to the non-volatile storage device 122, the SSD 102 may also include DRAM 108 (or other volatile memory). The DRAM 108 includes volatile memory that can store data while the solid-state drive 102 is powered (e.g., operating). The DRAM 108 may include, for example, LPDDR3 (Low Power Double Data Rate version 3 (originally released by JEDEC (Joint Electron Device Engineering Council)), JESD209-3B, JEDEC August 2013), LPDDR4 (Low Power Double Data Rate (LPDDR)) version 4, JESD209-4, originally released by JEDEC in August 2014, or other types of DRAM. The DRAM may conform to a standard promulgated by the Joint Electron Devices Engineering Council (JEDEC), such as JESD79F for DDR Double Data Rate (DDR) SDRAM, JESD79-2F for DDR2 SDRAM, JESD79-3F for DDR3 SDRAM, or JESD79-4A for DDR4 SDRAM (these standards are available at www.jedec.org). Other volatile memories may be used. Some SSDs do not include DRAM (e.g., "DRAMless" SSDs). In one such example, the SSD may include SSD controller memory (not shown), which is typically SRAM. DRAM 108 may be used to store data related to the operation of SSD 102, such as a logical-to-physical indirection table or other such information.

[0025] SSD 102 also includes a controller 130 to control access to storage device 122. In one example, controller 130 includes an interface to storage device 122 and an interface to host 110. Controller 130 includes hardware logic to control writing to and reading from storage device 122. Controller 130 can be an application-specific integrated circuit controller (ASIC) device connected to an interface such as Serial ATA or an integrated drive electronics controller. In another example, controller 130 includes a processor or other processing circuitry (not shown). In one example, controller 130 can be included in a system-on-chip (SoC) on a single integrated circuit chip.

[0026] SSD 102 also includes firmware 104. Firmware 104 may perform various functions, such as translation, garbage collection, wear leveling, and other functions for the operation and optimization of SSD 102. In one example, firmware 104 may include a flash translation layer (FTL), which includes logic that provides indirection to identify the physical address space of a logical address, such as a logical block address (LBA) of a request received from file system 124.

[0027] In the illustrated example, firmware 104 includes refresh logic 140 to perform background refreshes to ensure that data stored in storage device 122 is not lost or corrupted. Existing techniques for refreshing data in SSDs typically rely on the SSD's "power-on time" or a clock internal to the SSD (such as the ASIC time clock of controller 130) to determine which data to refresh. Such existing techniques are ineffective for determining when to refresh data in some systems (e.g., mobile devices), where the SSD is frequently powered off or placed in a low-power state. For example, the SSD "power-on time" is a count stored on the SSD (e.g., in a register on the SSD, or in another location on the SSD, such as a block on the SSD that is not accessible to the host) that indicates how long the SSD has been in a powered-on state. Refresh techniques that rely on the SSD "power-on time" do not account for the time that data remains in storage device 122, even if the device is powered off or in a low-power state. Consequently, such techniques can result in infrequent data refreshes and data loss. Similarly, refresh techniques that rely on a time clock located on SSD 102 may also be less accurate because the circuitry including the clock is powered off when SSD 102 is powered off or in a lowest power state.

[0028] However, unlike the prior art, SSD firmware 104 can accurately track the retention time of data stored in SSD storage device 122 by maintaining information about the time when data was written to each superblock and based on the current timestamp from the host. By accurately tracking the retention time, SSD firmware 104 can more accurately determine when data needs to be refreshed to avoid data loss. For example, Figure 2 is a block diagram illustrating an example of the transfer of system clock information from a host to an SSD. Figure 2 An SSD driver 202 is shown coupled to an SSD 204. The SSD driver may be coupled to Figure 1 The SSD drive 128 of the host 110 shown in FIG. 1 is the same as or similar to the SSD drive 128 of the host 110, and the SSD 204 can be the same as Figure 1The SSD 102 is identical or similar to the SSD 102 of the host. Blocks 206, 208, and 210 represent operations in a method for transmitting a timestamp from a host to an SSD. In the illustrated example, operations 206, 208, and 210 occur after power-on or after exiting a low-power state. The low-power state may be a "sleep state." In one example, the low-power state is a state in which most components of the SSD 204 (including the SSD controller, DRAM, NVM, and other discrete components on the board) are powered off (e.g., PS4 in the Non-Volatile Memory Express (NVMe) protocol and L1 or L1.2 in the PCI Express (PCIe) protocol). The NVMe protocol may refer to the protocol described in NVMe Specification Version 1.3, released on May 1, 2017, or another version of the NVMe specification. The PCIe protocol may refer to the protocol described in PCI Express® Base Specification Version 3.0, released on November 10, 2010, or another version of the PCI Express® Base Specification.

[0029] After SSD 204 is powered on or after SSD 204 exits a low-power state, at block 206, SSD 204 notifies SSD driver 202 that the SSD is initialized and ready to accept host commands. In one example, at the time of (e.g., immediately after) the first I / O command (at operation 208), SSD driver 202 sends system clock information (e.g., in the form of a timestamp) to SSD 204 at operation 210. In another example, SSD driver 202 may send the system clock information to the SSD before the first I / O command. In one example, the command (via which the system clock information is sent) is triggered by the storage driver upon completion of the PCIe / NVMe protocol handshake for device (SSD) readiness. Once SSD 204 receives the system clock information from the host, it can use the system clock information from the host to accurately determine retention time and refresh data that is at risk of being lost or corrupted due to exceeding a threshold. For example, the SSD may store a timestamp indicating when data was written to a given superblock. The SSD may also determine and store a retention time for the Super Block based on a timestamp indicating the time at which data was written to the given Super Block relative to a current timestamp from the host. In one example, the SSD may store the timestamp information and the retention time in volatile memory of the SSD while the SSD is operating (e.g., while the DRAM of the SSD is powered on and operating).

[0030] As briefly mentioned above, the SSD can track such information at a superblock granularity (eg, for each superblock that has been written to). A superblock (also called a stripe) is a block that spans all die across all planes. Figure 3AAn example of a four-plane (4NAND die SSD) superblock is shown. Figure 3A In the example shown in , the SSD has four different dies (e.g., Dies 0, 1, 2, and 3), each die has four planes (e.g., 0, 1, 2, and 3), and each plane has blocks (e.g., Blocks 0-n). Thus, in the example shown, Super Block 0 includes Block 0 in each plane of each die. Accordingly, in one example, the SSD can track the timestamp and retention time of each Super Block (e.g., Super Blocks 0-n). Figure 3B is a table showing information that an SSD can store to enable accurate data refresh. Figure 3B The information shown in the table (e.g., timestamp and retention time) can be stored in a volatile memory when the SSD is operating, and stored in a non-volatile storage device when the SSD is powered off or in a low power mode (e.g., a low power mode in which DRAM is not operating). For example, referring to Figure 1 , DRAM 108 of SSD 102 can store timestamp and retention time information while the SSD is operating. In a DRAMless SSD, the timestamp and retention time information can be stored in another location, such as in SSD controller memory. Then, before entering low power mode or losing power, SSD 102 can store the timestamp and retention time information to SSD storage 122. In one such example, SSD 102 stores the timestamp and retention time information to an SLC block (e.g., a reserved or "system" SLC block (which is generally not directly accessible by the host)) of SSD storage 122. Again referring to Figure 3B ,Note that although timestamps and retention times are in seconds, other time granularities (e.g., minutes, hours, days, or other time units) can be used. Similarly, although Figure 3B The table in shows an example of storing the timestamp of each super block, but other granularities can be used. For example, the SSD can store the timestamp information of each block, or only store the timestamp information of the blocks or super blocks that have been written, or other granularity of timestamp information.

[0031] In the example shown, each entry of the table includes a write timestamp indicating the time at which the superblock was written. The SSD also stores a current timestamp based on the time clock on the host. Figure 2 In the described example, the host sends the current timestamp to the SSD in response to receiving notification from the SSD that the SSD is initialized and ready to accept commands (e.g., after powering up or exiting from a low power mode). Note that although Figure 3BThe table shows the current timestamp multiple times (for each Super Block). The SSD may store the current timestamp only once (rather than for each Super Block). In one example, the SSD also stores the data retention time for each Super Block. In one example, the data retention time is calculated by subtracting the write timestamp from the current timestamp.

[0032] Referring again to the current timestamp, in one example, a protocol for communicating the current timestamp from the host to the SSD is established. By having a protocol that both the SSD firmware and the SSD driver conform to, the SSD driver can provide a timestamp that is consistent with the timestamp expected by the SSD, and the SSD can correctly interpret the timestamp received from the host. Figure 4A and 4B An example of some features of the protocol for communicating timestamps from a host to an SSD is shown.

[0033] Figure 4A An example of an identify controller data structure is shown that can be used to identify which features are supported by a given storage device, including whether the storage device can accept system clock information. Data structure 400A can be used in protocols such as Non-Volatile Memory Express (NVMe) or other storage protocols. NVMe defines an identify command that a host sends to a storage device to identify which capabilities and settings are applicable to a storage controller (e.g., Figure 1 SSD controller 130). In response to receiving the identify command, the storage device will return a data structure (e.g., identify controller data structure 400A) that includes information about one or more features. In data structure 400A, a byte range is reserved for vendor-specific features. In the example shown, bytes 4095:3072 are reserved for vendor-specific features, including a byte used to identify whether the storage device supports the feature of receiving system clock information. By setting bit 0 of byte 3072 to logic 1, the storage device indicates support for the feature, and by setting the bit to logic 0, the storage device indicates non-support of the feature. The opposite convention can also be used (e.g., logic 0 can indicate support for the feature). Although the bytes are shown as mandatory (as indicated by the 'M' in the 'O / M' column), in other examples, the bytes may be optional.

[0034] If the storage device does support a feature for accepting system clock information (e.g., as indicated by byte 3072 in data structure 400A), the host can pass the system clock information to the storage device at some predetermined time (e.g., after power-up or after exiting a low-power state). For example, the host can pass the system clock information via a vendor-unique set feature command.

[0035] Figure 4B4 is a table illustrating an example of how system clock information can be sent from a host to a storage device via a set feature command. For example, Table 400B illustrates the feature identifier for the NVMe set feature command. Before the host sends the set feature command to the storage device, the host (e.g., via a storage driver such as SSD drive 128) sets the feature identifier C0h to reflect the current time as indicated by the system clock. The current timestamp can be defined as the number of seconds (or milliseconds (ms), minutes, hours, or other time granularity) that have elapsed since a predetermined date and time. Other timestamp formats are possible, as long as the format is defined by the protocol and followed by both the host and the storage device. In the example shown, the system clock information feature is in a vendor-specific feature (e.g., the vendor-specific feature identifier includes bytes C0h-FFh in the example shown). However, other feature identifiers or other commands may be used. The host then sends a command including the feature identifier to the storage device. The storage device may store the current timestamp for use in determining data retention time, as described above and in more detail below.

[0036] Figure 5-7 is a flow chart illustrating an example of a method for performing a background refresh using a system timestamp. Figure 5 is a flowchart from a system perspective, including operations performed by both the host and the storage device. Figure 6 This is a flowchart from the perspective of the storage device. Figure 7 As mentioned above, existing techniques for refreshing data in non-volatile media may be ineffective for storage devices that are frequently powered off or put into a low-power state. Figure 5-7 In the method, the timestamp from the host is used to more accurately determine the data retention time and thus can enable improved data refresh.

[0037] refer to Figure 5 At operation 502, method 500 begins by powering on the SSD. Alternatively, method 500 may begin by the SSD exiting a low power state (eg, waking up or entering a higher power state). The SSD may be Figure 1 Then, at operation 504, the SSD firmware loads the timestamp table from the non-volatile storage device to the DRAM. For example, referring to Figure 1, the SSD firmware 104 may load the timestamp table from the SSD storage device 122 to the DRAM 108. In one example where the SSD does not include DRAM, the SSD firmware may load the timestamp table from the SSD storage device 122 to the SSD controller memory. Loading the timestamp table may include loading the write timestamps of one or more superblocks (or other granularity) from the SSD storage device 122. Then, at operation 506, the host-side SSD driver sends the current timestamp on the first host I / O command. For example, the SSD driver 128 may send the timestamp via a vendor-unique set feature command, such as Figure 4B In one such example, the SSD driver sends the timestamp immediately after the first host I / O command (e.g., after the first write, read, or other I / O command) via a vendor-unique set features command. In one example, the host sends the timestamp information immediately after the first I / O command (e.g., without intervening commands between the first I / O command and the vendor-unique set features command) to enable deterministic behavior. In another example, the SSD driver may send the timestamp before the first I / O command, or if the timestamp is sent after the first write command, there may be one or more intervening commands between the first I / O and the vendor-unique set features command. Commands other than the vendor-unique set features command may be used.

[0038] Then, at operation 508, the SSD firmware updates the timestamp table with the retention time of each Super Block in the table. For example, the SSD firmware 104 can calculate the data retention time of each Super Block by subtracting the write timestamp from the current timestamp. In one example, the SSD firmware stores the calculated data retention time for each Super Block.

[0039] After determining the retention time of one or more Super Blocks, the SSD firmware may then check to see if the retention time exceeds a threshold at operation 510. The threshold may be a predetermined number depending on the characteristics of the SSD. The threshold may be static (e.g., the same threshold is used throughout the life of the SSD) or dynamic (e.g., the threshold may be updated as the SSD is used over time). If the retention time has exceeded the threshold ("yes" branch at 510), the SSD firmware may move the Super Block to a Background Data Refresh (BDR) queue at operation 512 and set a flag (e.g., a BDR flag) for the Super Block to indicate that the data should be moved. The queue may be implemented in firmware, hardware, or a combination thereof. In one example, moving the Super Block to the BDR queue may involve setting a BDR flag for the Super Block. The flag may comprise one or more bits, and setting the flag to indicate that data in a given Super Block is to be moved may involve setting the flag to a logic 1, a logic 0, or another value to indicate that data in the Super Block should be moved. In another example, moving the Super Block to the BDR queue may also or alternatively involve storing information identifying the Super Block in a queue data structure. If the BDR flag is set (e.g., to a value indicating that data is to be moved) (514 "yes" branch), then at 516 the SSD firmware interleaves host activity with the BDR write to move valid data from the Super Block in the BDR queue to the new Super Block. One or more operations may be performed by a garbage collection routine, which is typically a part of the SSD firmware (e.g., Figure 1 For example, the interleaving of host activity with BDR writes and the execution of BDR writes may be performed by a garbage collection routine.

[0040] If the retention time of a given Super Block does not exceed the threshold (510 "No" branch), the Super Block is not placed in the queue, the BDR flag is not set (514 "No" branch), and the SSD continues to process ongoing host activities at operation 518. Therefore, in one example, at each power cycle, the SSD firmware scans the data retention time of each Super Block. If the retention time exceeds the retention time threshold, the Super Block is placed in the BDR queue to be picked up by the garbage collection routine to move the data, and the BDR flag is set by the firmware. The firmware checks the BDR flag, and if set, the firmware triggers the garbage collection routine, and the blocks in the BDR queue can be prioritized for garbage collection. When the SSD is about to enter a low power state or is about to lose power, the SSD firmware stores timestamp information to the SSD storage device 122 so that the information can be retrieved when the SSD wakes up or powers up.

[0041] Figure 6 Also according to an example, a flow chart of a method for performing a background refresh using a timestamp from a host. Figure 6The method 600 is executed by a storage device (eg, by SSD firmware (eg, Figure 1 At operation 602, the method 600 executes the firmware 104 of the host computer (e.g., Figure 1 The SSD firmware may then store the timestamp in a storage device at operation 604. For example, the firmware may store the timestamp in DRAM of the SSD (e.g., Figure 1 DRAM 108 of SSD 102). After receiving the timestamp from the host, at operation 606, the firmware determines the retention time of the data stored in one or more blocks of the storage device based on the timestamp relative to the write timestamp. The write timestamp indicates the time when the data was written to one or more blocks (e.g., blocks, super blocks, or other granularity of storage space). The firmware may also store the retention time of the one or more blocks in the DRAM. If the retention time exceeds a threshold, then at operation 608, the firmware moves the data to one or more other blocks of the storage device. For example, the firmware (e.g., Figure 1 The refresh logic 140) can interleave refresh writes with host activity to refresh data in the background of the host activity.

[0042] Figure 7 is a flow chart of a method for transmitting a current timestamp to a storage device based on a system clock according to one example. Figure 7 The method 700 may be performed by a host (e.g., Figure 1 In operation 702, the method 700 is performed by the host from a storage device (eg, Figure 1 The host then sends the current timestamp information to the storage device via a unique set feature command based on the host's system clock. For example, the host may send the current timestamp information to the storage device via a unique set feature command based on the host's system clock. Figure 4B The timestamp is sent using the command specified in

[0045] . However, other commands may also be used to provide a timestamp to the storage device. The storage device stores a current timestamp and may determine a retention time for data stored in a block of the storage device based on the current timestamp.

[0043] therefore, Figure 5-7The method of FIGURE 1 illustrates a method for communicating a current timestamp from a host to a storage device, determining a retention time for data stored on the storage device using the current timestamp, and performing a background refresh based on the retention time. As briefly mentioned above, refreshing data can be done in the background in the sense that refresh activity can be interleaved with host activity. However, the amount of writes that need to be performed due to refreshes as well as host activity can vary significantly. Therefore, in one example, the storage device (e.g., SSD firmware) can dynamically determine a ratio of refresh writes to host activity. For example, the ratio of interleaved refresh writes and host activity can be based on one or more of: the retention time of blocks in the queue, the number of commands from the host, the number of blocks to be refreshed, and the available space for performing the refresh (e.g., the number of empty blocks).

[0044] Figure 8 The following is an example of pseudocode 800 for setting the background refresh rate. In pseudocode 800, the rate of background writes used for refresh varies based on the following variables: the percentage of valid cells moved from the source block and the percentage of empty blocks available at the destination. The percentage of valid cells moved from the source block is given by: valid cells in the block divided by the total cells in the block (where the total cells include both valid and invalid blocks). The percentage of empty blocks is given by: the current number of empty blocks divided by the total number of allocated empty blocks. If the percentage of valid cells is less than 25% or if the percentage of empty blocks is greater than 75% (at line 802), this indicates that there is less data to write or more space available for writing, so the host activity to background write activity ratio can be set to a relatively high ratio, such as 4:1 (at lines 804-810). If the percentage of valid cells is less than 50% or the percentage of empty blocks is greater than 50% (at line 812), the firmware can set the host activity to background write activity ratio to 2:1 (at lines 814-818). If the percentage of valid cells is less than 75% or if the percentage of empty blocks is greater than 25% (at line 820), the ratio of host activity to background write activity can be set to 1:2 (at lines 822-826). Otherwise (at line 828), the ratio of host activity to background write activity can be set to 1:4 (at lines 830-834). These ratios are examples, and other ratios can be used to perform background flushes to achieve performance goals and prevent data corruption. For example, a ratio higher than 4:1 can be used (e.g., 8:1, 16:1, 32:1, or higher), or a ratio lower than 1:4 can be used (e.g., 1:8, 1:16, 1:32, or lower).

[0045] Figure 99 is a block diagram of an example of a computing system including a non-volatile storage device implementing background data refresh techniques. System 900 represents a computing device according to any example herein and can be a laptop, desktop, tablet, server, gaming or entertainment control system, smartphone, or other electronic device.

[0046] System 900 includes a processor 910 that provides processing, operation management, and execution of instructions for system 900. Processor 910 may include any type of microprocessor, central processing unit (CPU), graphics processing unit (GPU), processing core, or other processing hardware that provides processing for system 900, or a combination of processors. Processor 910 controls the overall operation of system 900 and may be or include one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), etc., or a combination of such devices.

[0047] In one example, system 900 includes an interface 912 coupled to processor 910, which may represent a higher-speed or high-throughput interface for system components requiring higher-bandwidth connections, such as memory subsystem 920 or graphics interface component 940. Interface 912 represents interface circuitry, which may be a separate component or integrated on the processor die. Interface 912 may be integrated as circuitry on the processor die or as a component on a system-on-chip. Where present, graphics interface 940 interfaces with a graphics component for providing a visual display to a user of system 900. Graphics interface 940 may be a separate component or integrated on the processor die or system-on-chip. In one example, graphics interface 940 may drive a high-definition (HD) display that provides output to the user. In one example, the display may include a touchscreen display.

[0048] Memory subsystem 920 represents the main memory of system 900 and provides storage for code to be executed by processor 910 or data values ​​to be used in executing routines. Memory subsystem 920 may include one or more memory devices 930, such as read-only memory (ROM), flash memory, one or more random access memories (RAM) such as DRAM, or other memory devices, or a combination of such devices. Memory 930 stores and hosts (among other things) an operating system (OS) 932 to provide a software platform for executing instructions in system 900. Additionally, applications 934 may execute on the software platform of OS 932 from memory 930. Applications 934 represent programs with their own operating logic for performing one or more functions. Processes 936 represent agents or routines that provide auxiliary functionality to OS 932, one or more applications 934, or a combination. In one example, memory subsystem 920 includes a memory controller 922, which is a memory controller for generating and issuing commands to memory 930. It will be understood that memory controller 922 may be a physical part of processor 910 or a physical part of interface 912. For example, memory controller 922 may be an integrated memory controller (integrated onto circuitry with processor 910 ), such as onto a processor die or system-on-chip.

[0049] Although not specifically shown, it will be understood that the system 900 may include one or more buses or bus systems between devices, such as a memory bus, a graphics bus, an interface bus, and the like. A bus or other signal line can couple components together communicatively or electrically, or both communicatively and electrically. A bus can include physical communication lines, point-to-point connections, bridges, adapters, controllers, or other circuits or combinations thereof. A bus can include one or more of, for example, a system bus, a peripheral component interconnect (PCI) bus, PCI Express (PCIe), HyperTransport or an Industry Standard Architecture (ISA) bus, a small computer system interface (SCSI) bus, a universal serial bus (USB), or an Institute of Electrical and Electronics Engineers (IEEE) standard 994 bus.

[0050] In one example, system 900 includes an interface 914, which can be coupled to interface 912. Interface 914 can be a lower speed interface than interface 912. In one example, interface 914 represents interface circuitry, which can include both discrete components and integrated circuits. In one example, multiple user interface components or peripheral components, or both, are coupled to interface 914. Network interface 950 provides system 900 with the ability to communicate with remote devices (e.g., servers or other computing devices) via one or more networks. Network interface 950 can include an Ethernet adapter, a wireless interconnect component, a cellular network interconnect component, a USB (Universal Serial Bus), or an interface based on other wired or wireless standards or proprietary interfaces.

[0051] In one example, the system 900 includes one or more input / output (I / O) interfaces 960. The I / O interfaces 960 may include one or more interface components (e.g., audio, alphanumeric, tactile / touch, or other interfaces) through which a user interacts with the system 900. The peripheral interfaces 970 may include any hardware interfaces not specifically mentioned above. A peripheral generally refers to a device that is connected to the system 900 in a dependent manner. A dependent connection is a connection between the system 900 and a software platform or a hardware platform, or both, on which operations are executed (and with which the user interacts). The system 900 also includes a power source 902 that provides power to the components of the system 900. More specifically, the power source 902 is typically connected to one or more power supplies 904 in the system 902 to provide power to the components of the system 900.

[0052] In one example, system 900 includes a storage subsystem 980 for storing data in a non-volatile manner. In one example, in certain system implementations, at least some components of storage 980 may overlap with components of memory subsystem 920. Storage subsystem 980 includes one or more storage devices 981, which include non-volatile storage devices 984. Non-volatile storage devices 984 can be any conventional medium for storing large amounts of data in a non-volatile manner, such as one or more magnetic, solid-state, or optical disks, or a combination thereof. Storage devices 984 maintain code or instructions and data 986 in a persistent state (i.e., the values ​​are retained despite power interruption to system 900). Storage devices 984 can generally be considered "memory," although memory 930 is generally execution or operational memory for providing instructions to processor 910. While storage devices 984 are non-volatile, memory 930 may include volatile memory (i.e., the value or state of the data is indeterminate if power is interrupted to system 900). In one example, the storage subsystem 980 includes a host-side controller 982 that interfaces with the storage device 981 and a storage device-side controller 985 that interfaces with the host. In one example, the controller 982 is a physical part of the interface 914 or the processor 910, or may include circuits or logic in both the processor 910 and the interface 914. The storage device 981 also includes firmware 983, which can perform various functions, such as those described above with respect to Figure 1 In one example, the storage device 981 may be connected to the firmware 104. Figure 1 The same or similar to the SSD 102. In one such example, the storage device 981 uses a timestamp from the host to perform an improved background refresh technique, as described herein.

[0053] Figure 10 1 is a block diagram of an example of a mobile device including a non-volatile storage device that implements background data refresh technology. Device 1000 represents a mobile computing device, such as a computing tablet, a mobile phone or smartphone, a wireless-enabled e-reader, or other mobile device. It will be understood that certain components are generally shown, and not all components of such a device are shown in device 1000.

[0054] Device 1000 includes a processor 1010, which performs the primary processing operations of device 1000. Processor 1010 may comprise one or more physical devices, such as a microprocessor, an application processor, a microcontroller, a programmable logic device, or other processing components. Processing operations performed by processor 1010 include the execution of an operating platform or operating system (on which applications and device functions execute). Processing operations include operations related to I / O (input / output) with a human user or with other devices, operations related to power management, operations related to connecting device 1000 to another device, or a combination thereof. Processing operations may also include operations related to audio I / O, display I / O, or other interfacing, or a combination thereof. Processor 1010 can execute data stored in memory. Processor 1010 can also write or edit data stored in memory.

[0055] In one example, system 1000 includes one or more sensors 1012. Sensor 1012 represents an interface to an external sensor, an embedded sensor, or a combination thereof. Sensor 1012 enables system 1000 to monitor or detect one or more conditions of an environment or device in which system 1000 is implemented. In one example, one or more sensors 1012 are coupled to processor 1010 via front-end circuitry integrated with processor 1010. In one example, one or more sensors 1012 are coupled to processor 1010 via another component of system 1000.

[0056] In one example, device 1000 includes an audio subsystem 1020, which represents the hardware (e.g., audio hardware and audio circuitry) and software (e.g., drivers, codecs) components associated with providing audio functionality to the computing device. Audio functionality may include speaker or headset output, as well as microphone input. Devices for such functionality may be integrated into device 1000 or connected to device 1000. In one example, a user interacts with device 1000 by providing audio commands that are received and processed by processor 1010.

[0057] Display subsystem 1030 represents the hardware components (e.g., a display device) and software components (e.g., a driver) that provide a visual display for presentation to a user. In one example, the display includes a touch component or touchscreen element for user interaction with the computing device. Display subsystem 1030 includes a display interface 1032, which includes a specific screen or hardware device for providing a display to the user. In one example, display interface 1032 includes logic separate from processor 1010 (e.g., a graphics processor) to perform at least some processing related to the display. In one example, display subsystem 1030 includes a touchscreen device that provides both output and input to the user.

[0058] I / O controller 1040 represents hardware devices and software components related to interaction with a user. I / O controller 1040 is operable to manage hardware that is part of audio subsystem 1020 or display subsystem 1030, or both. In addition, I / O controller 1040 illustrates connection points for additional devices connected to device 1000, through which a user may interact with the system. For example, devices that may be attached to device 1000 may include a microphone device, a speaker or stereo system, a video system or other display device, a keyboard or keypad device, or other I / O devices for use with specific applications (such as a card reader or other device).

[0059] In one example, the apparatus 1000 includes a power management 1050 that manages battery power usage, battery charging, and features related to power saving operations. The power management 1050 manages power from a power source 1052 that provides power to the components of the system 1000.

[0060] Memory subsystem 1060 includes one or more memory devices 1062 for storing information in device 1000. Memory subsystem 1060 may include non-volatile (the state does not change if power to the memory device is interrupted) or volatile (the state is indeterminate if power to the memory device is interrupted) memory devices, or a combination. Memory 1060 may store application data, user data, music, photos, documents, or other data, as well as system data (whether long-term or temporary) related to the execution of applications and functions of system 1000. In one example, memory subsystem 1060 includes a memory controller 1064 (which can also be considered part of the control of system 1000 and potentially part of processor 1010). Memory controller 1064 includes a scheduler to generate and issue commands to control access to memory devices 1062.

[0061] Connectivity 1070 includes hardware devices (e.g., wireless or wired connectors and communication hardware, or a combination of wired and wireless hardware) and software components (e.g., drivers, protocol stacks) that enable device 1000 to communicate with external devices. External devices can be standalone devices such as other computing devices, wireless access points or base stations, and peripherals such as headsets, printers, or other devices. In one example, system 1000 exchanges data with external devices for storage in memory or for display on a display device. The exchanged data can include data to be stored in memory, or data already stored in memory, to read, write, or edit data.

[0062] Connectivity 1070 may include multiple different types of connectivity. In general, device 1000 is shown with cellular connectivity 1072 and wireless connectivity 1074. Cellular connectivity 1072 generally refers to cellular network connectivity provided by a wireless carrier, such as provided via GSM (Global System for Mobile Communications) or a variant or derivative, CDMA (Code Division Multiple Access) or a variant or derivative, TDM (Time Division Multiplexing) or a variant or derivative, LTE (Long Term Evolution - also known as "4G"), or other cellular service standards. Wireless connectivity 1074 refers to non-cellular wireless connectivity and may include personal area networks (such as Bluetooth), local area networks (such as WiFi), wide area networks (such as WiMax), or other wireless communications or combinations thereof. Wireless communication refers to the transmission of data over a non-solid medium using modulated electromagnetic radiation. Wired communication occurs over a solid communication medium.

[0063] Peripheral connections 1080 include hardware interfaces and connectors, as well as software components (e.g., drivers, protocol stacks) for peripheral connections. It will be understood that device 1000 may be a peripheral device ("to" 1082) to other computing devices, as well as have peripheral devices ("from" 1084) connected to it. Device 1000 typically has a "docking" connector to connect to other computing devices, such as for purposes such as managing (e.g., downloading, uploading, changing, synchronizing) content on device 1000. Additionally, the docking connector may allow device 1000 to connect to certain peripherals that allow device 1000 to control content output, such as to an audio-visual system or other system.

[0064] In addition to proprietary docking connectors or other proprietary connection hardware, the device 1000 can make peripheral connections via common or standards-based connectors 1080. Common types may include a Universal Serial Bus (USB) connector (which may include any number of different hardware interfaces), DisplayPort including Mini DisplayPort (MDP), High-Definition Multimedia Interface (HDMI), FireWire, or other types.

[0065] The apparatus 1000 also includes a solid state drive (SSD) 1011, which provides non-volatile storage for the apparatus 1000. The SSD 1011 can be used with Figure 1 The same or similar SSD 102. In one such example, SSD 1011 uses timestamps from the host to perform an improved background refresh technique, such as described herein.

[0066] Next are examples of methods, devices, and systems for implementing background refresh techniques. In one example, a method involves receiving a timestamp from a host; storing the timestamp in a storage device; determining a retention time for data stored in one or more blocks of the storage device based on the timestamp relative to a second timestamp indicating a time when the data was written to the one or more blocks of the storage device; and moving the data to one or more other blocks of the storage device in response to determining that the retention time exceeds a threshold. In one example, receiving the timestamp from the host is responsive to powering on the storage device or the storage device exiting a low-power state. In one example, receiving the timestamp from the host is also responsive to a first write command after powering on the storage device or after exiting the low-power state. In one example, the method further involves: for each of a plurality of super blocks, storing a timestamp indicating a time when data was written to a given super block and a retention time of the data written to the given super block; in response to powering on the storage device or the storage device exiting a low power state, scanning the data retention times of the plurality of super blocks; and in response to determining that the retention time of one or more of the plurality of super blocks exceeds a threshold, moving the data from the one or more of the plurality of super blocks to one or more other super blocks.

[0067] In one example, the method involves: in response to entering a low-power state or powering off the storage device, storing the timestamp and retention time of each of the plurality of Super Blocks in a non-volatile memory; and in response to exiting the lower power state or powering on the storage device, loading the timestamp and retention time of each of the plurality of Super Blocks from the non-volatile memory. In one example, storing the timestamp and retention time of each of the plurality of Super Blocks involves storing the timestamp and retention time of each of the plurality of Super Blocks in one or more single-level cell (SLC) Super Blocks of the storage device. In one example, moving the data involves placing the one or more blocks in a queue to indicate that the retention time of the data stored in the one or more blocks has exceeded a threshold; and interleaving accesses from the host with writes from the queue. In one example, placing the one or more blocks in the queue involves setting a flag to identify the one or more blocks and indicate that the retention time of the data stored in the one or more blocks has exceeded the threshold. In one example, the method includes adjusting a ratio of interleaving the accesses from the host with the writes from the queue; wherein the interleaving ratio is based on one or more of: a retention time of blocks in the queue, a number of commands from the host, a number of blocks to be flushed, and available space for performing flushes. In one example, receiving the timestamp includes receiving the timestamp from the host via a supplier-unique command.

[0068] In one example, a solid-state storage device (SSD) includes: a solid-state storage device to store data; and logic to: receive a timestamp from a host, store the timestamp in the solid-state storage device, determine a retention time of the data stored in one or more blocks of the solid-state storage device based on the timestamp relative to a second timestamp indicating a time when the data was written to the one or more blocks, and move the data to one or more other blocks of the storage device in response to a determination that the retention time exceeds a threshold. In one example, the receipt of the timestamp from the host is responsive to powering on the SSD or exiting a low-power state. In one example, the receipt of the timestamp from the host is also responsive to a first write command after powering on the SSD or exiting the SSD. In one example, the logic further stores, for each of a plurality of Super Blocks, a timestamp indicating a time when data was written to the given Super Block and the retention time of the data written to the given Super Block.

[0069] In one example, the logic is further configured to: scan data retention times of the plurality of Super Blocks in response to powering on the storage device or the storage device exiting a low-power state; and in response to determining that the retention time of one or more of the plurality of Super Blocks exceeds a threshold, move the data from the one or more of the plurality of Super Blocks to one or more other Super Blocks. In one example, the SSD further comprises: volatile memory; wherein in response to entering a low-power state or powering off the SSD, the logic is configured to store the timestamp and retention time of each of the plurality of Super Blocks in the non-volatile storage device; and wherein in response to exiting the lower power state or powering on the SSD, the logic is configured to load the timestamp and retention time of each of the plurality of Super Blocks from the non-volatile storage device to the volatile memory. In one example, in response to entering the low-power state or powering off the SSD, the logic is configured to store the timestamp and retention time of each of the plurality of Super Blocks in one or more single-level cell (SLC) Super Blocks of the storage device. In one example, the logic to move the data is to: place the one or more blocks in a queue to indicate that the retention time of the data stored in the one or more blocks has exceeded the threshold; and interleave accesses from the host with writes from the queue. In one example, the logic to place the one or more blocks in the queue is to: set a flag to identify the one or more blocks and indicate that the retention time of the data stored in the one or more blocks has exceeded the threshold. In one example, the logic is to: adjust a ratio of interleaving the accesses from the host with the writes from the queue; wherein the ratio of interleaving is based on one or more of: the retention time of blocks in the queue, the number of commands from the host, the number of blocks to be refreshed, and the available space for performing the refresh. In one example, the logic is to receive the timestamp from the host via a supplier unique command. In one example, the logic comprises firmware for the SSD.

[0070] In one example, a system includes a processor and a non-volatile storage device coupled to the processor, the non-volatile storage device including features described herein. In one example, a solid-state storage device (SSD) includes: a non-volatile storage device to store data; and components to: receive a timestamp from a host, store the timestamp in the non-volatile storage device, determine a retention time of the data stored in one or more blocks of the non-volatile storage device based on the timestamp relative to a second timestamp indicating a time when the data was written to the one or more blocks, and, in response to a determination that the retention time exceeds a threshold, move the data to one or more other blocks of the non-volatile storage device.

[0071] In one example, the receiving of the timestamp from the host is in response to powering on the SSD or the SSD exiting a low power state. In one example, the receiving of the timestamp from the host is also in response to a first input / output (I / O) command after powering on the SSD or after exiting the low power state. In one example, the SSD includes components to: for each of a plurality of Super Blocks, store a timestamp indicating a time when data was written to the given Super Block and the retention time of the data written to the given Super Block. In one example, the SSD includes components to: in response to powering on the SSD or the SSD device exiting a low power state, scan the data retention times of the plurality of Super Blocks; and in response to determining that the retention time of one or more of the plurality of Super Blocks exceeds a threshold, move the data from the one or more of the plurality of Super Blocks to one or more other Super Blocks. In one example, the SSD further includes: volatile memory; and means for storing the timestamp and retention time of each of the plurality of Super Blocks in the non-volatile storage device in response to entering a low-power state or powering off the SSD, and loading the timestamp and retention time of each of the plurality of Super Blocks from the non-volatile storage device to the volatile memory in response to exiting the lower power state or powering on the storage device. In one example, the SSD further includes means for storing the timestamp and retention time of each of the plurality of Super Blocks in one or more single-level cell (SLC) Super Blocks of the SSD in response to entering a low-power state or powering off the SSD. In one example, the means for moving the data includes: placing the one or more blocks in a queue to indicate that the retention time of the data stored in the one or more blocks has exceeded a threshold; and interleaving accesses from the host with writes from the queue. In one example, the means for placing the one or more blocks in the queue includes: setting a flag to identify the one or more blocks and to indicate that the retention time of the data stored in the one or more blocks has exceeded the threshold. In one example, the SSD includes components to adjust a ratio of interleaving the accesses from the host with the writes from the queue; wherein the interleaving ratio is based on one or more of: a retention time of blocks in the queue, a number of commands from the host, a number of blocks to be refreshed, and available space for performing refreshes. In one example, the SSD includes components to receive the timestamp from the host via a vendor-unique command. In one example, an article of manufacture includes a computer-readable storage medium having content stored thereon that, when accessed, causes the execution of operations to perform a method for performing a background refresh as described herein.

[0072] The flowcharts shown herein provide examples of various sequences of process actions. A flowchart may indicate operations to be performed by a software or firmware routine as well as physical operations. In one example, a flowchart may illustrate states of a finite state machine (FSM), which may be implemented in hardware and / or software, or a combination thereof. Although shown in a specific sequence or order, the order of the actions may be modified unless otherwise specified. Therefore, the illustrated embodiments should be understood as examples only, and the processes may be performed in a different order, and some actions may be performed in parallel. In addition, one or more actions may be omitted in various examples; therefore, not all actions are required in every embodiment. Other process flows are possible.

[0073] To the extent various operations or functions are described herein, they may be described or defined as software code, instructions, configuration, data, or a combination thereof. The content may be directly executable ("object" or "executable" form), source code, or differential code ("delta" or "patch" code). The software content of the embodiments described herein may be provided via an article of manufacture (having the content stored thereon) or via a method of operating a communication interface to send data via the communication interface. Machine-readable storage media can enable a machine to perform the described functions or operations and include any mechanism for storing information in a form accessible by a machine (e.g., a computing device, electronic system, etc.), such as recordable or non-recordable media (e.g., read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, etc.). A communication interface includes any mechanism that interfaces with any hardwired, wireless, optical, or other medium to communicate with another device (e.g., a memory bus interface, a processor bus interface, an Internet connection, a disk controller, etc.). The communication interface can be configured by providing configuration parameters or sending signals, or both, to prepare the communication interface to provide data signals describing the software content. The communication interface can be accessed via one or more commands or signals sent to the communication interface.

[0074] The various components described herein may be means for performing the described operations or functions. Each component described herein may include software, hardware, or a combination thereof. A component may be implemented as a software module, a hardware module, dedicated hardware (e.g., dedicated hardware, an application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.), an embedded controller, a hardwired circuit, etc.

[0075] In addition to what is described herein, various modifications may be made to the disclosed embodiments and implementations of the present invention without departing from their scope. Therefore, the description and examples herein should be interpreted in an illustrative, rather than a restrictive, sense. The scope of the present invention should be measured solely with reference to the claims that follow.

[0076] This application also discloses a set of technical solutions, as follows:

[0077] 1. A method comprising:

[0078] Receive timestamp from host;

[0079] storing the timestamp in a storage device;

[0080] determining a retention time for data stored in one or more blocks of the storage device based on the timestamp relative to a second timestamp indicating a time when the data was written to the one or more blocks; and

[0081] In response to determining that the retention time exceeds a threshold, the data is moved to one or more other blocks of the storage device.

[0082] 2. The method of claim 1 , wherein receiving the timestamp from the host is in response to powering on the storage device or the storage device exiting a low-power state.

[0083] 3. The method of claim 2, wherein receiving the timestamp from the host is further in response to a first input / output (I / O) command after the storage device is powered on or after exiting the low-power state.

[0084] 4. The method according to technical solution 1 further includes:

[0085] For each of a plurality of Super Blocks, a timestamp is stored indicating a time when data was written to a given Super Block and the retention time of the data written to the given Super Block.

[0086] 5. The method according to technical solution 4 further includes:

[0087] In response to powering on the storage device or the storage device exiting a low power state, scanning data retention times of the plurality of super blocks; and

[0088] In response to determining that the retention time of one or more of the plurality of Super Blocks exceeds a threshold, the data is moved from the one or more of the plurality of Super Blocks to one or more other Super Blocks.

[0089] 6. The method according to technical solution 4 further includes:

[0090] responsive to entering a low power state or removing power from the storage device, storing the timestamp and retention time for each of the plurality of super blocks in a non-volatile storage device of the storage device; and

[0091] In response to exiting the lower power state or powering on the storage device, the timestamp and retention time for each of the plurality of super blocks are loaded from the non-volatile storage device to a volatile memory of the storage device.

[0092] 7. The method of claim 6, wherein storing the timestamp and retention time of each of the plurality of super blocks in the non-volatile storage device comprises:

[0093] The timestamp and retention time of each of the plurality of Super Blocks are stored in one or more Single Level Cell (SLC) Super Blocks of the storage device.

[0094] 8. The method of claim 1, wherein moving the data comprises:

[0095] placing the one or more blocks in a queue to indicate that a retention time of data stored in the one or more blocks exceeds the threshold; and

[0096] Accesses from the host are interleaved with writes from the queue.

[0097] 9. The method of claim 8, wherein placing the one or more blocks in the queue comprises setting a flag to identify the one or more blocks and to indicate that the retention time of the data stored in the one or more blocks has exceeded the threshold.

[0098] 10. The method according to technical solution 9 further includes:

[0099] adjusting a ratio of interleaving the accesses from the host with the writes from the queue;

[0100] The ratio of interleaving is based on one or more of: a retention time of blocks in the queue, a number of commands from the host, a number of blocks to be flushed, and available space for performing flushes.

[0101] 11. The method of claim 1, wherein receiving the timestamp comprises:

[0102] The timestamp is received from the host via a vendor unique command.

[0103] 12. A solid-state storage device (SSD), comprising:

[0104] non-volatile storage devices to store data; and

[0105] The logic is:

[0106] Receive timestamp from host;

[0107] storing the timestamp in the non-volatile storage device;

[0108] determining a retention time for data stored in one or more blocks of the non-volatile storage device based on the timestamp relative to a second timestamp indicating a time when the data was written to the one or more blocks; and

[0109] Responsive to a determination that the retention time exceeds a threshold, the data is moved to one or more other blocks of the non-volatile storage device.

[0110] 13. The SSD of solution 12, wherein the receipt of the timestamp from the host is in response to powering on the SSD or the SSD exiting a low power state.

[0111] 14. The SSD of claim 12, wherein the receiving of the timestamp from the host is further in response to a first input / output (I / O) command after the SSD is powered on or after the SSD exits a low power state.

[0112] 15. The SSD of claim 12, wherein the logic further comprises:

[0113] For each of a plurality of Super Blocks, a timestamp is stored indicating a time when data was written to the given Super Block and the retention time of the data written to the given Super Block.

[0114] 16. The SSD of claim 15, wherein the logic further comprises:

[0115] In response to powering on the SSD or the SSD exiting a low power state, scanning data retention times of the plurality of super blocks; and

[0116] In response to determining that the retention time of one or more of the plurality of Super Blocks exceeds a threshold, the data is moved from the one or more of the plurality of Super Blocks to one or more other Super Blocks.

[0117] 17. The SSD according to technical solution 15, further comprising:

[0118] Volatile memory;

[0119] wherein in response to entering a low power state or removing power from the SSD, the logic is to store the timestamp and retention time for each of the plurality of super blocks in the non-volatile memory; and

[0120] Wherein in response to exiting the lower power state or powering on the SSD, the logic is to load the timestamp and retention time of each of the plurality of super blocks from the non-volatile storage device to the volatile memory.

[0121] 18. An SSD as described in technical solution 12, wherein the logic includes firmware for the SSD.

[0122] 19. An article of manufacture comprising a computer-readable storage medium having content stored thereon that, when accessed, causes said execution of operations to perform a method comprising:

[0123] Receive timestamp from host;

[0124] storing the timestamp in a storage device;

[0125] determining a retention time for data stored in one or more blocks of the storage device based on the timestamp relative to a second timestamp indicating a time when the data was written to the one or more blocks; and

[0126] In response to determining that the retention time exceeds a threshold, the data is moved to one or more other blocks of the storage device.

[0127] 20. The article of manufacture of claim 19, wherein receiving the timestamp from the host is in response to powering on the storage device or the storage device exiting a low-power state.

Claims

1. A method for performing background refresh using a system timestamp, comprising: After powering on the storage device or after exiting a low power state of the storage device, receiving a first input / output (I / O) command from a host; receiving a first timestamp from a host in response to the first I / O command; storing the first timestamp in a storage device; determining a retention time of data stored in one or more blocks of the storage device based on the first timestamp relative to a second timestamp indicating a time when the data was written to the one or more blocks; as well as In response to determining that the retention time exceeds a threshold, the data is moved to one or more other blocks of the storage device.

2. The method of claim 1, further comprising: For each of a plurality of Super Blocks, the second timestamp indicating the time at which data was written to the given Super Block and the retention time of the data written to the given Super Block are stored.

3. The method of claim 2, further comprising: In response to powering on the storage device or the storage device exiting the low power state, scanning data retention times of the plurality of super blocks; as well as In response to determining that the retention time of one or more of the plurality of Super Blocks exceeds a threshold, the data is moved from the one or more of the plurality of Super Blocks to one or more other Super Blocks.

4. The method of claim 2, further comprising: responsive to entering the low power state or removing power from the storage device, storing the second timestamp and the retention time for each of the plurality of super blocks in a non-volatile storage device of the storage device; as well as In response to exiting the low power state or powering on the storage device, the second timestamp and the retention time for each of the plurality of super blocks are loaded from the non-volatile storage device to a volatile memory of the storage device.

5. The method according to claim 4, wherein: Storing the second timestamp and the retention time of each of the plurality of super blocks in the non-volatile storage device comprises: The second timestamp and the retention time of each of the plurality of super blocks are stored in one or more single-level cell (SLC) super blocks of the storage device.

6. The method of claim 1, wherein: Moving the data includes: placing the one or more blocks in a queue to indicate that a retention time of data stored in the one or more blocks exceeds the threshold; and Accesses from the host are interleaved with writes from the queue.

7. The method according to claim 6, wherein: Placing the one or more blocks in the queue includes setting a flag to identify the one or more blocks and to indicate that a retention time of data stored in the one or more blocks has exceeded the threshold.

8. The method of claim 7, further comprising: adjusting a ratio of interleaving the accesses from the host with the writes from the queue; The ratio of interleaving is based on one or more of: a retention time of blocks in the queue, a number of commands from the host, a number of blocks to be flushed, and available space for performing flushes.

9. The method of claim 1, wherein: The first I / O command comprises a vendor-unique command, and receiving the first timestamp comprises: The first timestamp is received from the host via the vendor unique command.

10. A solid-state storage device (SSD), comprising: Non-volatile storage devices for storing data; as well as Logic, to: After the SSD is powered on or after the SSD exits a low power state, receiving a first input / output (I / O) command from a host; receiving a first timestamp from a host in response to the first I / O command; storing the first timestamp in the non-volatile storage device; determining a retention time of data stored in one or more blocks of the non-volatile storage device based on the first timestamp relative to a second timestamp indicating a time when the data was written to the one or more blocks; as well as Responsive to a determination that the retention time exceeds a threshold, the data is moved to one or more other blocks of the non-volatile storage device.

11. The SSD according to claim 10, wherein: The logic also: For each of a plurality of Super Blocks, the second timestamp indicating the time at which data was written to the given Super Block and the retention time of the data written to the given Super Block are stored.

12. The SSD of claim 11, wherein: The logic also: In response to powering on the SSD or the SSD exiting the low power state, scanning data retention times of the plurality of super blocks; as well as In response to determining that the retention time of one or more of the plurality of Super Blocks exceeds a threshold, the data is moved from the one or more of the plurality of Super Blocks to one or more other Super Blocks.

13. The SSD of claim 11, further comprising: Volatile memory; wherein, in response to entering the low power state or removing power from the SSD, the logic is to store the second timestamp and the retention time for each of the plurality of super blocks in the non-volatile storage device; and Wherein, in response to exiting the low power state or powering on the SSD, the logic is to load the second timestamp and the retention time of each of the plurality of super blocks from the non-volatile storage device to the volatile memory.

14. The SSD of claim 13, wherein: In response to entering the low power state or removing power from the SSD, the logic is to store the second timestamp and the retention time for each of the plurality of Super Blocks in one or more Single Level Cell (SLC) Super Blocks of the storage device.

15. The SSD of claim 11, wherein: The logic to move this data would be to: placing the one or more blocks in a queue to indicate that a retention time of data stored in the one or more blocks has exceeded the threshold; as well as Accesses from the host are interleaved with writes from the queue.

16. The SSD of claim 15, wherein: The logic to place the one or more blocks in the queue is to: A flag is set to identify the one or more blocks and to indicate that a retention time of data stored in the one or more blocks has exceeded the threshold.

17. The SSD of claim 15, wherein: The logic is to: adjusting a ratio of interleaving the accesses from the host with the writes from the queue; The ratio of interleaving is based on one or more of: a retention time of blocks in the queue, a number of commands from the host, a number of blocks to be flushed, and available space for performing flushes.

18. The SSD of claim 10, wherein: The logic is to receive the first timestamp from the host via a vendor unique command.

19. The SSD of claim 10, wherein: The logic includes firmware for the SSD.

20. A solid-state storage device (SSD), comprising: Non-volatile storage devices for storing data; as well as Components, to: After powering on the SSD or after exiting a low power state of the SSD, receiving a first input / output (I / O) command from the host; receiving a first timestamp from a host in response to the first I / O command; storing the first timestamp in the non-volatile storage device; determining a retention time of data stored in one or more blocks of the non-volatile storage device based on the first timestamp relative to a second timestamp indicating a time when the data was written to the one or more blocks; as well as Responsive to a determination that the retention time exceeds a threshold, the data is moved to one or more other blocks of the non-volatile storage device.

21. The SSD of claim 20, wherein the component further comprises: For each of a plurality of Super Blocks, the second timestamp indicating the time at which data was written to the given Super Block and the retention time of the data written to the given Super Block are stored.

22. The SSD of claim 21, wherein the component further comprises: In response to powering on the storage device or the storage device exiting the low power state, scanning the data retention times of the plurality of super blocks; and In response to determining that the retention time of one or more of the plurality of Super Blocks exceeds a threshold, the data is moved from the one or more of the plurality of Super Blocks to one or more other Super Blocks.

23. The SSD of claim 21, wherein the component further comprises: In response to entering the low power state or removing power from the storage device, storing the second timestamp and the retention time for each of the plurality of super blocks in a non-volatile storage device of the storage device; and In response to exiting the low power state or powering on the storage device, the second timestamp and the retention time for each of the plurality of super blocks are loaded from the non-volatile storage device to a volatile memory of the storage device.

24. The SSD of claim 23, wherein: The component for storing the second timestamp and the retention time of each of the plurality of super blocks in the non-volatile storage device is to: The second timestamp and the retention time of each of the plurality of super blocks are stored in one or more single-level cell (SLC) super blocks of the storage device.

25. The SSD of claim 20, wherein: To move the data, you need to: placing the one or more blocks in a queue to indicate that a retention time of data stored in the one or more blocks exceeds the threshold; as well as Accesses from the host are interleaved with writes from the queue.

26. The SSD of claim 25, wherein: The component that is to place the one or more blocks in the queue is to set a flag to identify the one or more blocks and to indicate that the retention time of data stored in the one or more blocks has exceeded the threshold.

27. The SSD of claim 26, wherein the component further comprises: adjusting a ratio of interleaving the accesses from the host with the writes from the queue; in, The ratio of interleaving is based on one or more of: a retention time of blocks in the queue, a number of commands from the host, a number of blocks to be flushed, and available space for performing flushes.

28. The SSD of claim 20, wherein: The first I / O command comprises a vendor-unique command, and the component to receive the timestamp is to: The first timestamp is received from the host via the vendor unique command.

29. A computer readable medium having stored thereon instructions which, when executed, cause a computing device to perform the method according to any one of claims 1 to 9.

30. A computer program product having instructions stored thereon, which when executed cause a computing device to perform the method according to any one of claims 1 to 9.

Images