Firmware-based solid state drive block failure prediction and avoidance scheme

Abstract

A solid state drive (SSD) is disclosed. The SSD can include flash memory for data, the flash memory organized into a plurality of blocks. A controller can manage reading data from and writing data to the flash memory. A metadata store can store device-based log data to protect against errors in the SSD. Identification firmware can identify blocks in response to the device-based log data. In some embodiments of the inventive concept, verification firmware can determine whether a suspect block is predicted to fail in response to both precise block-based data and the device-based log data.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application Serial No. 62 / 926,420, filed October 25, 2019, which is incorporated herein by reference for all purposes. Technical Field

[0003] The present invention relates generally to storage devices, and more specifically to providing fine-grained block failure prediction. Background Technology

[0004] Field failures of NAND flash solid-state drives (SSDs) can cause server shutdowns, thereby impairing the performance and availability of data center applications. To prevent such unexpected failures, systems using SSDs typically employ a simple threshold-based model, avoiding such failures by replacing the drive before they occur. This protection mechanism can lead to a high false alarm rate or an inability to predict / avoid all SSD failures. Furthermore, in the event of a physical error, the SSD cannot recover from the error, thus preventing device failure.

[0005] Fine-grained block fault prediction is still needed. Summary of the Invention Attached Figure Description

[0006] Figure 1 A system comprising a solid-state drive (SSD) capable of performing fine-grained block fault prediction, according to an embodiment of the present invention, is shown.

[0007] Figure 2 It shows Figure 1 Details of the machine.

[0008] Figure 3 It shows Figure 1 Details of the SSD.

[0009] Figure 4 It shows that it can be made by Figure 1 The SSD uses block-based data as an example.

[0010] Figure 5 It shows that it can be made by Figure 1 The SSD uses device-based log data.

[0011] Figure 6 It shows Figure 3 The identification firmware and verification firmware are used to determine whether a specific block is expected to fail.

[0012] Figures 7A-7B A flowchart illustrating an example process for determining whether a block is expected to fail, according to an embodiment of the present invention. Detailed Implementation

[0013] Reference will now be made in detail to embodiments of the inventive concept, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth to enable a thorough understanding of the inventive concept. However, it should be understood that those skilled in the art can practice the inventive concept without these specific details. In other instances, well-known methods, processes, components, circuits, and networks have not been described in detail to avoid unnecessarily obscuring aspects of the embodiments.

[0014] It will be understood that although the terms first, second, etc., may be used herein to describe various elements, these 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 the inventive concept, a first module may be referred to as a second module, and similarly, a second module may be referred to as a first module.

[0015] The terminology used in the description of the inventive concept herein is for the purpose of describing particular embodiments only and is not intended to limit the inventive concept. As used in the description of the inventive concept and the appended claims, the singular forms “a,” “an,” and “the” are also intended to include the plural forms, unless the context clearly indicates otherwise. It should 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 also be understood that when the terms “comprising” and / or “including” are used in this specification, they specify the presence of the stated feature, integer, step, operation, element, and / or component, but do 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 accompanying drawings are not necessarily drawn to scale.

[0016] A firmware-based solid-state drive (SSD) fault protection mechanism is proposed for early detection and error isolation. This fault mechanism can prevent drive failure or at least prevent premature drive replacement.

[0017] An SSD consists of multiple flash memory chips, each containing numerous blocks. A block can contain any number of pages. A page is typically several kilobytes in size and is usually the smallest unit used for reading and writing data to an SSD. The SSD controller (firmware) may include all the logic required to servicing read and write requests, running wear leveling algorithms, and performing error recovery processes.

[0018] Each SSD page can include Error Correction Code (ECC) metadata, which the SSD controller can use to recover and repair a limited number of bit errors (typically 1-2 bit errors). However, if the number of bit errors due to hardware failure exceeds a certain threshold, the SSD controller may be unable to correct the errors and will therefore provide corrupted data to the host. Repeated failures of this type may necessitate replacing the entire device, incurring high costs for the device manufacturer and negatively impacting application performance and availability due to subsequent server shutdowns.

[0019] On the other hand, when data is written to a flash page (programming operation), if an error occurs, the page is marked as "failed" and is no longer used. Once some pages in a block fail, the entire block is evicted. SSDs typically retain some spare blocks to replace such withdrawn blocks. If the number of available spare blocks on an SSD is insufficient (for example, more than 90% of spare blocks are in use), the device may need to be replaced.

[0020] In some cases, most blocks in a drive may function correctly (normal blocks), with only a small fraction being faulty (bad blocks). If read operations target bad blocks and fail frequently (reading corrupted data or failing due to hardware malfunction), it may be necessary to replace the entire drive to prevent future failures and avoid data loss. However, if fine-grained block errors / failures can be predicted early and subsequently avoided / recovered, bad blocks can be evicted / reclaimed. This prevents the SSD from storing data on those blocks, thus avoiding further failures and data corruption / loss.

[0021] Predicting fine-grained (block-level) errors / failures in SSDs (with thousands of blocks) is not straightforward and requires (i) storing a large amount of historical (time-series) data corresponding to each block, and (ii) processing / analyzing very large datasets to predict and avoid failures. Regarding the amount of historical data required, the amount of data to be stored grows with the amount of failure history information, regardless of whether such metadata is stored in the DRAM space on the SSD or in the flash memory itself. Storing this information can result in high storage costs and may even sacrifice a significant portion of the drive's capacity. Since storage devices contain only a limited amount of DRAM and are highly sensitive to the price per GB, the data storage requirements are not negligible, and sacrificing a large portion of the device's storage capacity to store such failure time-series data is neither a simple nor an efficient approach.

[0022] Regarding the processing required for prediction, SSDs typically have limited processing power, which is primarily used for their internal operations (such as flash translation layers, wear leveling, and scheduling). Processing large amounts of data within an SSD to predict block-level failures / errors is not a straightforward and feasible task.

[0023] To address the aforementioned challenges in block-level failure prediction, embodiments of the present invention utilize the temporal and spatial locality of physical errors within each block and / or each page within a block. Temporal locality refers to the frequent occurrence of errors within the same physical page and / or block; spatial locality refers to the occurrence of errors in adjacent physical components (e.g., pages or blocks). By leveraging the locality of error occurrence, only a very limited amount of data (rather than the device's error history) associated with a few past errors can be used to predict block failures. The intuition behind this idea is that a page / block that has generated erroneous data is highly likely to generate errors in the future. Similarly, when a page in a block fails, adjacent pages in the same block are likely to fail because they are all within the same physical component.

[0024] Predicting block-level failures

[0025] As mentioned above, predicting block-level failures is not easy due to its capacity and processing requirements. A simple approach is to use fine-grained historical log data corresponding to thousands of blocks for accurate prediction; however, the size of this dataset grows over time and may reduce the storage capacity of user data. Instead, embodiments of the present invention employ a two-step identification and verification mechanism to locate suspicious blocks, and then use a learning-based model to verify the future failure of the blocks.

[0026] First, by leveraging the locality of error in physical errors to identify suspicious drives, only the most recent error information needs to be stored. For example, during the entire operation of the drive, only the last k entries of the error history (i.e., the k most recent events) are retained, instead of the entire error history. Errors earlier than the last k entries may be discarded. Although only information about the most recent errors is stored, this limited information can still help identify suspicious blocks due to the location of the errors. For example, if 10 out of the past 100 errors were caused by specific pages within an identified block, this fact suggests that errors are likely to occur in the same page or its adjacent pages within the same block in the future. Therefore, given information about the past k errors, suspicious blocks can be identified using potentially orders of magnitude less data than the entire error history of the device.

[0027] In the second step, although suspicious blocks are likely to produce errors in the near future, simply labeling them as defective and discarding them can be inefficient. This threshold-based identification mechanism may fail to accurately capture fault information and could generate numerous false alarms, leading to the discarding of normally functioning blocks and wasting drive capacity. To prevent such inaccurate and threshold-based predictions, a predictive model (already trained) can be used to more accurately predict block failures after suspicious blocks are identified.

[0028] Get block-level parameters

[0029] Running a previously trained prediction model requires time-series information associated with the suspected block to verify its failure. Tracking such fine-grained information can lead to high capacity demands, potentially far exceeding the storage device's capacity. Instead, regarding the definition and interpretation of each parameter, embodiments of the inventive concept extract and obtain some block-based log data (directly or with some modifications) from available driver-based log data. Specifically, to construct a parameter set for the suspected block, i.e., setting S = {param1, param2, ...} and inputting it into the prediction module, the log data can be divided into two categories:

[0030] (i) Precise block-based log data: S_Block_Precise = {p1, p2, ...} and

[0031] (ii) Approximate block-based log data: S_Block_Approx = {a1, a2, ...}.

[0032] Then, to derive the set S, S = S_Block_Precise ∪ S_Block_Approx, this is equivalent to S = S_Block_Precise + S_Block_Approx, since the two sets are disjoint. For parameters directly related to error / failure information (e.g., the number of read errors, write errors, and erase errors), precise information for each block can be stored. The required block-based data volume is negligible (only a few megabytes of area even for a 1TB SSD) and can be managed by an SSD that already contains several gigabytes of DRAM space. Moreover, such data does not involve time-series information and is simply a counter for each parameter of each block.

[0033] To extract time-series log data, this information can be derived from the global driver-level error information maintained for the past k errors. Since the suspect block is selected based on the past k error events, its latest error information is already present in the global driver-level error data. The data for the driver-related k most recent errors may contain cumulative error information for a block, which can be obtained by adding the block's error counter to the new error data. Note that the counter for each block only contains cumulative error information. The global error information contains complete data about the k most recent errors, which may include errors generated by the suspect block.

[0034] Approximate parameters for a block can be extracted from driver-level error information (i.e., S_Block_Approx). The intuition behind this idea is that certain log information about a suspicious block can be approximated from driver-level parameters because they refer to the state of the drive / block, not error messages. In other words, these parameters can be averaged across all blocks and thus represent a single block. For example, some parameters (such as "read count" and "write count") are based on the total number of reads and writes to the drive and are indicators of drive lifetime; averaging across all blocks can approximate the corresponding parameters for the suspicious block.

[0035] By combining historical driver information with counter-based block-level log data, a parameter set for suspicious blocks can be generated and fed into the prediction module. Then, in the event of a fault alarm for a suspicious block, the block may be prematurely removed to avoid further errors associated with it and subsequent driver replacement. Therefore, instead of maintaining time-series data for each potentially growing block, only a lightweight counter needs to be maintained for each block. Furthermore, for time-series driver information, only the most recent k error events can be maintained, which only occupies a few gigabytes of data. This optimization addresses the dataset size and computational / processing requirements for performing fine-grained block-level fault prediction. The proposed enhancement requires less data than the original block-level time-series log data, and subsequent processing of such a small amount of data can be very fast, enabling real-time execution.

[0036] Required metadata and data structures

[0037] As mentioned earlier, only lightweight error information / counters need to be maintained for each block. Assuming the SSD contains n blocks, only n entries are needed. On the other hand, for drive-level information, we only retain information about the past k error events. For each of the k error events, information such as the physical location of the error (page, block), the time the error occurred (timestamp), the error counter for that block at that time, and the SMART log data on the SSD can be stored.

[0038] As mentioned above, the embodiments of this invention require very low overhead. Assuming an SSD with a storage capacity of 1TB, 256 pages per block, and a page size of 4KB:

[0039] Page count = 1TB / 4KB = 256,000,000

[0040] Number of blocks = 256,000,000 / 256 = 1,000,000

[0041] If each block has three error attributes (a counter for the number of read errors, write errors, and erase errors, each possibly a 4-byte integer), then the total storage space required for block-level error data will be...

[0042] For driver-level information, assuming k = 100 (i.e., information about the most recent 100 error events is stored), each error event requires 1KB of storage space. Therefore, the total capacity required for driver-level metadata is 100KB. Consequently, the total memory overhead will be 12.1MB, which is negligible for an SSD containing several GB of DRAM.

[0043] Please note that SSD error log data is typically firmware and device model specific. For illustrative purposes, some parameters that may be stored in the log data include critical warnings, available space, data units read, data units written, power cycles, boot time, unsafe shutdown, media errors, warning temperature time, and critical combination temperature time. Embodiments of this invention may also store other parameters.

[0044] Execution process

[0045] In the event of an error occurring in block I, the error counter in the block-level metadata can be read and updated. The driver-level metadata can then be updated to reflect the new error event information. The information stored in the driver-level metadata can include parameters discussed above, such as the location of the error (page ID / block ID), timestamp, etc.

[0046] Identify suspicious blocks

[0047] To identify suspicious blocks, the drive-level metadata table can be periodically scanned to see if blocks have produced duplicate errors (by checking the block ID field in this table). This scan can be performed at fixed time intervals (e.g., every minute) or after a certain number of errors have been recorded (e.g., after each error, after every five errors, etc.). If multiple past errors occur in the same block, the block can be added to a suspicious block pool: the SSD may then temporarily avoid using it for data storage (but it can still be read because it may contain valid data). More specifically, a block is marked as "suspicious" if the number of events corresponding to a specific block in the most recent k errors exceeds a threshold.

[0048] There are two different methods for setting a threshold:

[0049] (1) Define a static threshold α. A block is marked as suspicious when the number of error events corresponding to a specific block exceeds α% of the most recent k errors. The threshold parameter α can be adjusted based on protection / reliability level requirements. For example, setting α = 10 means that if more than 10% of the most recent k error events involve a specific block ID, the block is marked as suspicious. Alternatively, α can be a fixed number instead of a percentage: that is, setting α = 10 means that if 10 or more of the most recent k error events involve a specific block ID, the block is marked as suspicious.

[0050] (2) Define an average-based threshold. Such a threshold can be obtained by averaging the total number of errors across all blocks in the drive (in the device log). Suspicious block identification decisions can be made based on this threshold (directly or implicitly): if a particular block experiences more errors than its share of errors in the most recent k error events, the block can be marked as suspicious. For example, suppose a device with a total of 256,000 blocks experiences a total of 100 errors. The ratio of errors to blocks is 100 / 256,000 = 1 / 2,560. If a block encounters more than this number of errors, the block may be marked as suspicious.

[0051] Note that even a single error can cause a block to be marked as suspicious before the number of errors is roughly proportional to the number of blocks. To prevent every error from triggering a block to be marked as suspicious, the average-based threshold can be scaled up (or down) by any desired factor. Thus, for example, the average-based threshold can be multiplied by a number (e.g., 10,000) to produce a threshold that is actually greater than one. This scaling value can also be varied over time or in response to the number of errors to prevent the average-based threshold from becoming too large.

[0052] predict

[0053] Once a suspicious block is identified, a parameter set (set S) corresponding to the suspicious block can be generated and input into the fault prediction module. As mentioned above, part of S can be based on block-level error information, and part of S can be derived from driver-level log information, which can be extracted from driver-level metadata stored for the past k errors (reflecting the average of all blocks, to estimate with block-level data). This data can then be processed using any algorithm to determine whether the block was actually predicted to fail. Example algorithms that can be used include logistic regression or random forest algorithms. If the prediction indicates that the block is likely to fail in the future, the block can be evicted by first copying its valid data to other blocks and then removing the suspicious block from the list of available blocks. To minimize the processing power required by the prediction module, the prediction module does not need to be executed for all blocks, nor does it need to be continuously executed. Instead, the prediction module can be triggered only for suspicious blocks and only when the block is identified as suspicious.

[0054] As mentioned above, a prediction module can be selected that uses some time-series data to predict any desired event. An example of a prediction module could be a machine learning-based fault prediction model (examples of which include random forests, logistic regression, outlier detection, anomaly detection, etc.) that has been primarily trained and whose predictive information (e.g., optimized weights) is embedded in the driver firmware. Therefore, upon receiving information about past errors, the model can predict the failure probability of a specific block by performing lightweight computations.

[0055] Figure 1 A system comprising a solid-state drive (SSD) capable of performing fine-grained block fault prediction, according to an embodiment of the present invention, is shown. Figure 1 The machine may include a processor 105, memory 110, and a solid-state drive (115). The processor 105 may be any type of processor: for example, an Intel Xeon, Celeron, Itanium or Atom processor, an AMD Opteron processor, an ARM processor, etc. Figure 1 A single processor 105 is shown. The machine 120 may include any number of processors, each of which may be a single-core or multi-core processor and may be mixed in any desired combination.

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

[0057] Processor 105 and memory 110 can also support various operating systems on which applications can run. These applications can issue requests to read data from or write data to memory 110 or SSD 115. SSD 115 can be used, for example, to store initial parameters (or a range of initial parameter values, and the type of behavior represented by that range) used to initialize a simulation. SSD 115 can be accessed using device driver 130. Although Figure 1 SSD 115 is shown, but embodiments of the inventive concept may include other storage device formats that may benefit from fine-grained block failure prediction: any references to “SSD” below should be understood to include such other embodiments of the inventive concept.

[0058] Figure 2 It shows Figure 1 Details of the machine. Figure 2 Typically, machine 120 includes one or more processors 105, which may include a memory controller 125 and a clock 205, which can be used to coordinate the operation of the machine's components. As an example, processor 105 may also be coupled to memory 110, which may include random access memory (RAM), read-only memory (ROM), or other state-saving media. Processor 105 may also be coupled to storage device 115 and network connector 210, which may be, for example, an Ethernet connector or a wireless connector. Processor 105 may also be connected to bus 215, where, among other components, user interface 220 and input / output interface ports that can be managed using input / output engine 225 may be connected.

[0059] Figure 3 It shows Figure 1 Details of the SSD. Figure 3 In this context, the SSD 115 may include host interface logic 305, which can connect the SSD 115 to a host computer (e.g., Figure 1 An interface is provided between the machine 120 and the SSD 115. The SSD 115 may also include an SSD controller 310, various channels 315-1, 315-2, 315-3, and 315-4, along which various flash memory chips 320-1, 320-2, 320-3, 320-4, 320-3, 320-6, 320-7, and 320-8 can be arranged. Although Figure 3 Four channels and eight flash memory chips are shown, but those skilled in the art will recognize that any number of channels, including any number of flash memory chips, can exist.

[0060] Within each flash memory chip, this space can be organized into blocks, which can be further subdivided into pages. For example, flash memory chips 320-7 are shown as comprising blocks 1 to n (identified as blocks 325 and 330), each block may contain pages numbered 1 to m. Although multiple pages may be assigned the same number (e.g., page 1) across multiple blocks, a combination of the page identifier (ID) and the block ID can uniquely identify a specific page in flash memory chip 320-7. (Alternatively, a combination of the page ID, block ID, and flash memory chip ID can uniquely identify a page in SSD 115.)

[0061] The difference between blocks and pages lies in how SSDs handle read, write, and erase operations. A page is typically the smallest unit of data that can be read or written on an SSD. Page sizes can vary as needed: for example, a page might be 4KB of data. If less than a full page's worth of content is to be written, the extra space is considered "unused."

[0062] However, while pages can be written to and read from, SSDs typically do not allow data to be overwritten: that is, existing data may not be "replaced" with new data. Instead, when data needs to be updated, the new data is written to a new page on the SSD, and the original page becomes invalid (marked as erasable). Therefore, SSD pages typically have one of three states: idle (ready to be written), valid (contains valid data), and invalid (no longer contains valid data, but is not available until erased) (the exact names of these states may vary).

[0063] However, although pages can be written to and read from individually, a block is the basic unit of data that can be erased. That is, pages are not erased individually: all pages in a block are erased simultaneously. For example, if a block contains 256 pages, all 256 pages in the block will be erased simultaneously. This arrangement can lead to some SSD management issues: if the block selected for erasure still contains some valid data, it may be necessary to copy the valid data to free pages elsewhere on the SSD before erasing the block. (In some embodiments of the present invention, the unit of erasure may differ from a block: for example, it could be a superblock: a collection of multiple blocks.)

[0064] The SSD controller 310 may include a flash translation layer 335, a metadata storage 340, identification firmware 345, and verification firmware 350. The flash translation layer 335 can process logical block addresses (e.g., data stored in flash memory chips 320-1 to 320-8) that are stored in the flash memory chips 320-1 to 320-8. Figure 1 The processor 105 (used by the SSD 115) performs the translation between physical block addresses and the SSD's physical block address. Metadata memory 340 can store metadata information used by the SSD 115 in performing fine-grained block failure prediction. Identification firmware 345 can be used to identify blocks suspected of potential failure using the metadata information stored in metadata memory 340; verification firmware 350 can then again use the metadata information stored in metadata memory 340 to determine whether the suspected block actually might be failing. A processor that can be part of the SSD 115 can be used. Figure 3 (Not shown in the text) to perform firmware identification 345 and firmware verification 350: for example, using the inherent processing power of the SSD controller 310.

[0065] Figure 4 It shows that it can be made by Figure 1 The SSD 115 uses block-based data as an example. Figure 4 In this context, the block-based data 405 may include data for each block, which can be stored in... Figure 3 The metadata storage is located in 340. For example... Figure 4 The data shown is for blocks 1 to n, although it may include data for any number of blocks (up to...). Figure 1 The data used for each block in the SSD 115). Each block's data can include counters 410-1, 410-2, and 410-3, which can store the number of read errors, write errors, and erase errors that have occurred for the corresponding block. Note that, due to... Figure 1 The SSD 115 is manufactured as follows: (Refer to the following) Figure 5Compared to other data discussed, block-based data 405 can also be called precise block-based data, so counters 410-1, 410-2 and 410-3 can be cumulative.

[0066] Each of counters 410-1, 410-2, and 410-3 may require 4 bytes per counter. Since each of counters 410-1, 410-2, and 410-3 includes three counters (each for the number of read errors, write errors, and erase errors), a total of 12 bytes are available to store each of counters 410-1, 410-2, and 410-3. Multiplying 12 bytes by... Figure 1 The number of blocks on the SSD 115 can be used to calculate the overhead imposed by the block-based data 405.

[0067] For example, consider an SSD offering a total storage capacity of 1TB, where each block contains 256 pages, and each page contains 4KB of data. It would take 268,435,456 pages to store 1TB of data in 4KB pages. With 256 pages per block, this means the SSD would contain a total of 1,048,576 blocks. Assuming each block has three counters and 12 bytes of data, the data based on the blocks would require approximately 12MB of storage, just over one-thousandth of the total storage offered by the SSD.

[0068] Note that counters 410-1, 410-2, and 410-3 indicate the number of errors that have occurred in each block. These errors may be clustered on one or several pages within the block, or they may be scattered across several pages within the block. In this way, the block-based data 405 provides some spatial location for determining the errors, as a page with one error is more likely to have other errors, as are other nearby pages (compared to pages in other blocks).

[0069] Figure 5 It shows that it can be made by Figure 1 The SSD 115 uses device-based log data. Figure 5 The image shows device-based log data 505. Device-based log data 505 may include information about... Figure 1 Data on specific errors that have occurred on the SSD 115, based on device log data 505, can be stored Figure 3 The metadata is stored in the metadata store 340. However, instead of storing data for... Figure 1 The SSD 115 contains all the error data that has ever occurred, but the device-based log data 505 can store information about the errors that occurred on it. Figure 1The data contains the k most recent errors that occurred on the SSD 115. Any older errors can be discarded. Therefore, errors 1 to k may not be... Figure 1 The first k errors that occurred on the SSD 115, which could be the k most recent errors (earlier errors had previously been discarded). k can be any expected value: larger values ​​provide more information and can be used to determine whether a particular block is predicted to fail, but at the cost of needing to store more data (thus increasing overhead).

[0070] Various types of data can be stored for each error currently being tracked. For example, as shown in errors 510-1, 510-2, and 510-3, the page and block IDs, the time the error occurred, and the error counter for that block (i.e., the block where the error occurred) can be stored together. Figure 4 The precise value of block-based data 405), the timestamp when the error occurred, and other log data (such as that shown in SMART log data 515). Based on device log data 505 Figure 5 The data shown represents one embodiment of the inventive concept; other embodiments may include... Figure 5 Show more, less, or other data, without limit.

[0071] and Figure 4 In contrast to the precise block-based data 405, device-based log data 505 can be used to derive approximate block-based data. This is because device-based log data 505 is only available in... Figure 1 The SSD115 stores information about the most recent k errors, so the device-based log data 505 (and the approximate block-based data derived therefrom) provides the ability to determine some time position of the errors, thus allowing the identification of blocks that have experienced more recent errors than other blocks.

[0072] Because only the data for the k most recent errors is stored, the overhead required to store the device-based log data 505 can be calculated by knowing the size of the data stored for each error and then multiplying it by the number of errors for which that data was stored. For example, if the data for the 100 most recent errors is stored, and each error requires 1KB of storage, then the total storage required to store the device-based log data is 100KB. Again, relative to Figure 1 The SSD 115 size, such as Figure 1 As shown, the storage overhead is only Figure 1 It is a fraction of one percent of the overall size of the SSD 115 (approximately one hundred thousandth of the size of a 1TB SSD).

[0073] The value of k can be preset. Then, in Figure 1The value of k can remain constant throughout the lifespan of the SSD 115. Optionally, k can be configurable and can vary over time according to user preferences. For example, as... Figure 1 As the SSD 115 ages, you may want more error messages.

[0074] Figure 6 It shows Figure 3 The identification firmware 345 and verification firmware 350 operate to determine whether a specific block is expected to fail. Figure 6 In this context, the firmware 345 can receive device-based log data 505 (which may include SMART log data 515, in...) Figure 6 (Not shown in detail). Then, the identification firmware 345 can identify the block in which each error has occurred is stored. If the number of errors in a particular block exceeds a certain threshold in the most recent k errors, it may be suspected that the block in question is about to fail. Therefore, the identification firmware 345 can generate approximate block-based data 605 from the device-based log data 505.

[0075] Any desired threshold can be used to determine whether a particular block is suspected of being about to fail. For example, a predetermined, user-specified threshold can be set whereby a block is likely to fail soon if the number of errors occurring in it exceeds a threshold among the last k errors. This threshold can be a number (e.g., 10 errors out of the last k errors) or a percentage (e.g., 10% of the last k errors). This threshold can also be adjusted based on the actual number of errors that occur. For example, if the threshold is set as a percentage of the total number of errors, the block encountering the first error will be automatically suspected, as 100% of the errors will be associated with that block. To avoid this outcome, until... Figure 1 The identification firmware 345 can only run after the number of errors that have occurred in the SSD 115 exceeds other values: this will prevent the identification firmware 345 from identifying blocks suspected of premature failure.

[0076] Another threshold that can be used is to calculate the average number of errors per block across the entire SSD. That is, the total number of errors that have occurred (since the SSD was manufactured) can be calculated and divided by the total number of blocks in the SSD. Any block that experiences too many errors relative to this average is likely to be suspected of failing soon. Alternatively, a percentage of this average can be used. Again, this average (or its usage) can be adjustable. For example, any block experiencing a single error will have a higher number of errors than the average number of errors until the number of errors experienced by the SSD approaches the number of blocks in the SSD, and will be automatically considered suspicious by the identification firmware 345. The identification firmware 345 may not begin to consider whether a block will soon fail until the number of errors exceeds a certain predetermined value. Alternatively, the identification firmware 345 can calculate the relative percentage (relative to k) of errors occurring in a particular block and compare that value to the average number of errors per block across the entire SSD: if the block has experienced a higher percentage of the most recent k errors exceeding the average, the identification firmware 345 may suspect that the block will fail soon.

[0077] In other embodiments of the inventive concept, the identification firmware 345 may suspect a block is about to fail not because it has recently experienced a larger share of errors, but based on the total error count. For example, suppose k is chosen to be 100 (i.e., based on the device's log data, only 100 recent errors are stored). If every 50th error occurs in a particular block, based on having a higher percentage of errors in the recent k errors, it might not be more appropriate to consider that block as suspicious than to consider it as such. However, from the device's history, one in every 50 errors in that block could mean that the block has experienced more errors total than any other block. Therefore, the identification firmware 345 can check... Figure 4 The precise block-based data 405 is used to find blocks that are suspected of failing soon. Blocks with a total error count exceeding a certain threshold can also be identified as suspicious blocks, even if the block does not exceed the threshold based on approximate block-based data 605.

[0078] In some embodiments of the present invention, the identification firmware 345 can check... Figure 4 The precise block-based data 405, without considering device-based log data 505: In this embodiment of the inventive concept, the identification firmware 345 can check Figure 1 The total error count for each block in the SSD 115. In other embodiments of the inventive concept, the identification firmware 345 can check... Figure 4 The precise block-based data 405 is only for blocks that have experienced one (or more) of the most recent k errors: In such embodiments of the present invention, the identification firmware 345 can... Figure 4 The precise block-based data 405 is considered in conjunction with the device-based log data 505.

[0079] Regardless of the specific method used, the identification firmware 345 can simply determine whether a particular block is considered suspicious by comparing two values. This process simplifies the identification of suspicious blocks.

[0080] The identification firmware 345 can operate according to any desired schedule. The identification firmware 345 can operate at regular time intervals: for example, every minute, every 10 minutes, or every day (or at increasingly larger intervals). Alternatively, the identification firmware 345 can operate after a certain number of errors have occurred: for example, after each error or after every fifth error (other numbers of errors are also possible).

[0081] Note that although the identification firmware 345 is described as using device-based log data 505 when determining whether a block is suspicious, embodiments of the inventive concept may also use device-based log data 505 instead of or in addition to it. Figure 4 Precise block-based data 405. For example, firmware identification 345 can be based on... Figure 4 A block is simply identified as a suspicious block if the sum of the counters 410-1 exceeds a predetermined threshold number.

[0082] Once firmware 345 has identified a block suspected of being prone to failure, firmware 350 can be invoked for verification. Firmware 350 can use... Figure 4 The precise block-based data 405, specifically, using a block counter 410-1 applicable to blocks suspected of soon failing, and approximate block-based data 605, is used to determine whether the blocks identified as suspicious by the identification firmware 345 are actually predicted to fail soon. The verification firmware 350 can use any desired method to make this determination. For example, the verification firmware 350 can implement a machine learning-based failure prediction model, such as random forest, logistic regression, outlier detection, anomaly detection, etc., which can be trained and whose prediction information (e.g., optimized weights) is already embedded in the verification firmware 350. The verification firmware 350 can then produce a result 610 indicating whether the blocks suspected of impending failure by the identification firmware 345 are actually predicted to fail soon.

[0083] although Figure 6 The identification firmware 345 is shown as generating approximate block-based data 605 from device-based log data 505; however, embodiments of the inventive concept may have other components to generate approximate block-based data 605. For example, the verification firmware 350 may take device-based log data 505 and generate approximate block-based data 605 itself.

[0084] Note that the identification firmware 345 and the verification firmware 350 have different functions. The identification firmware 345 only identifies blocks suspected of being about to fail. The identification firmware 345 can be used alone (that is, each block suspected of being about to fail can simply be assumed to be about to fail). However, this approach would cause many blocks to exit operation, even though these blocks might still function normally for a long time. The identification firmware 345 can be thought of as similar to a police officer arresting a suspect for a crime: the fact that a suspect is arrested does not automatically mean that the suspect is guilty.

[0085] On the other hand, the verification firmware 350 can be viewed as similar to a criminal trial, returning a guilty or not guilty verdict. The verification firmware 350 makes the final judgment on whether a particular block should actually be removed from use. Taking additional steps to verify that a block is actually ready to be removed can prevent blocks from being removed prematurely.

[0086] It's also worth noting what kind of computation is actually needed to both identify a block as suspicious and verify whether it's preparing to exit. A block can be identified as suspicious by simply comparing the number of errors that have occurred within it (relative to a threshold). This computation is typically very fast and easy to perform, and doesn't require complex prior operations to analyze the block to see if it's expected to fail soon and therefore be ready to exit.

[0087] Verifying firmware 350 may involve more computation than identifying firmware 345. However, verifying firmware 350 can only be executed after a block has been identified as suspicious. This condition prevents verifying firmware 350 from being repeatedly executed for many blocks, as mentioned above, which could exceed [the required computational power]. Figure 1 The available computing resources of the SSD 115 are limited. It is better to invoke the verification firmware 350 only as needed for individual suspicious blocks, rather than using a large amount of computation to constantly check each block to determine if any blocks should be removed. Therefore, the use of both the identification firmware 345 and the verification firmware 350 achieves the goal of providing fine-grained block failure prediction without imposing the computational requirements for implementing fine-grained block failure prediction.

[0088] Figures 7A-7B A flowchart illustrating an example process for determining whether a block is expected to fail, according to an embodiment of the present invention, is shown. Figure 7A In the middle, at position 705, Figure 1 The SSD 115 can be tracked in Figure 3 Errors that have already occurred in blocks 330 and 330. In box 710, Figure 1 The SSD 115 can Figure 3 Metadata storage 340 Figure 5 Device-based log data 505. In box 715, regarding the earliest error, Figure 1The SSD 115 can be discarded. Figure 5 Driver-based log data 505. If referring to the earliest error, it does not exist. Figure 5 For driver-based log data 505, box 715 can be omitted, as shown by dashed line 720. In box 715, Figure 1 The SSD 115 can Figure 3 Metadata storage 340 Figure 4 The precise block-based data 405.

[0089] At position 730. Figure 1 The SSD 115 can be derived from Figure 6 The approximate block-based data 605. See the above reference. Figure 6 The subject of discussion Figure 6 The approximate block-based data 605 can be derived from... Figure 3 Identification firmware 345 Figure 3 Verification firmware 350 or Figure 1 Another component of the SSD 115 (e.g., via) Figure 3 The SSD controller 310 is derived from this.

[0090] In box 735, Figure 3 Firmware 345 can identify blocks suspected of being about to fail. (See above for reference.) Figure 6 The discussed firmware 345 can be used to identify firmware 345. Figure 6 Approximate block-based data 605 Figure 5 Blocks are identified based on device log data (505 error) or other data. At box 740, Figure 3 The verification firmware 350 can verify whether a suspicious block was actually predicted to be faulty. (See above reference.) Figure 6 The subject of discussion Figure 5 The verified firmware 350 can be used Figure 6 Approximate block-based data 605 Figure 4 Precise block-based data 405 Figure 5 This determination can be made based on device log data 505 or other data, and can be performed using any desired algorithm (such as a machine learning-based fault prediction model), which can use random forest algorithm, log regression algorithm, outlier detection algorithm, anomaly detection algorithm or any other desired algorithm.

[0091] At frame 745. Figure 3 The verification firmware 350 can determine whether the suspicious block is actually predicted to fail soon. If so, then at box 750, Figure 3The verification firmware 350 may evict suspicious blocks. Evicting a suspicious block may include copying any valid data currently stored in that block to other blocks (and updating any tables that identify where that data is stored) and marking the block to make it... Figure 1 The SSD 115 will not write any new data to that block. For example, Figure 3 The verification firmware 350 can mark each block as containing invalid data, but somehow prevents any garbage collection logic from selecting that block for garbage collection.

[0092] On this point, regardless Figure 3 To verify whether firmware 350 has eliminated a suspicious block, control will return to any of the following points: Control can return to box 705 to trace... Figure 3 A new error has occurred in the SSD 115, as shown by dashed line 755. Alternatively, control can be returned to box 730 to scan. Figure 3 The SSD 115 detects new blocks suspected of impending failure, as shown by dashed line 760. The former method can be used in systems that scan for suspicious blocks after a predetermined number of errors have occurred. The latter method can be used in systems that scan for suspicious blocks after a predetermined time interval. Control can also be terminated completely.

[0093] exist Figures 7A-7B The flowchart illustrates some embodiments of the inventive concept. However, those skilled in the art will recognize that other embodiments of the inventive concept are possible by changing the order of the boxes, by omitting boxes, or by including links not shown in the figures. All such variations of the flowchart, whether explicitly described or not, are considered embodiments of the inventive concept.

[0094] The embodiments of this invention offer technical advantages over the prior art. First, the embodiments of this invention allow for fine-grained block fault prediction, which is not possible with conventional systems. Second, by distinguishing between the identification of suspicious blocks and verifying that the suspicious blocks are actually predicted to be faulty, the embodiments of this invention avoid the possibility of high false positive identification of blocks predicted to be faulty. Third, the embodiments of this invention enable the verification of whether a suspicious block is predicted to be faulty without requiring the large amount of computational resources associated with such predictions in conventional systems. Fourth, the embodiments of this invention allow verification of whether a specific block is predicted to be faulty without having to determine whether other blocks are also predicted to be faulty, thereby minimizing the computational resources used.

[0095] The following discussion is intended to provide a general description of one or more suitable machines in which certain aspects of the inventive concept can be implemented. One or more machines can be controlled at least in part by input from conventional input devices (e.g., keyboard, mouse, etc.) and by instructions 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 devices operating together. 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 vehicles (e.g., cars, trains, taxis, etc.).

[0096] One or more machines may include embedded controllers, such as programmable or non-programmable logic devices or arrays, application-specific integrated circuits (ASICs), embedded computers, smart cards, etc. One or more machines may utilize one or more connections to one or more remote machines, such as via network interfaces, modems, or other communication coupling. Machines may be interconnected via 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-range or long-range carriers and protocols, including radio frequency (RF), satellite, microwave, and IEEE 802.11. Optics, infrared, cables, lasers, etc.

[0097] Embodiments of the present invention can be described with reference to or in conjunction with relevant data including functions, procedures, data structures, and application programs. When this relevant data is accessed by a machine, it causes the machine to perform tasks or define abstract data types or low-level hardware contexts. The relevant data can be stored, for example, in volatile and / or non-volatile memory, such as RAM, ROM, etc., or other storage devices and their associated storage media, including hard disks, floppy disks, optical disk storage, magnetic tape, flash memory, memory sticks, digital video disks, bio-storage, etc. The relevant data can be transmitted through a transmission environment (including physical and / or logical networks) in the form of data packets, serial data, parallel data, propagated signals, etc., and can be used in compressed or encrypted formats. The relevant data can be used in a distributed environment and can be stored locally and / or remotely for machine access.

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

[0099] The various operations described above can be performed by any suitable means 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 embedded in any processor-readable medium for use by or in conjunction with an instruction execution system, apparatus, or device (e.g., a single-core or multi-core processor or a system containing a processor).

[0100] The blocks or steps of the methods, algorithms, and functions described in conjunction with the embodiments disclosed herein can be directly embedded in hardware, in a software module executed by a processor, or in a combination of both. If implemented in software, the functionality can be stored as one or more instructions or code on or transmitted on a tangible, non-transitory computer-readable medium. A software module can reside in random access memory (RAM), flash memory, read-only memory (ROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art.

[0101] The principles of the inventive concept have been described and illustrated with reference to the illustrated embodiments. It will be appreciated that the illustrated embodiments may be modified in arrangement and detail without departing from these principles and may be combined in any desired manner. Furthermore, although the foregoing discussion focuses on specific embodiments, other configurations are contemplated. In particular, even when expressions such as "according to embodiments of the inventive concept" are used herein, these phrases are intended to generally refer to the possibilities of the embodiments and are not intended to limit the inventive concept to specific embodiment constructions. As used herein, these terms may refer to the same or different embodiments that can be combined into other embodiments.

[0102] The foregoing illustrative embodiments should not be construed as limiting the inventive concept. Although some embodiments have been described, those skilled in the art will readily recognize that many modifications can be made 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 the inventive concept as defined in the claims.

[0103] The embodiments of the present invention can be extended without limitation to the following statements:

[0104] Statement 1. Embodiments of the present invention include a solid-state drive (SSD), comprising:

[0105] Flash memory is used for data; the flash memory is organized into multiple blocks.

[0106] The controller is used to manage reading data from and writing data to the flash memory;

[0107] Metadata storage for storing device-based log data regarding errors in the SSD; and

[0108] Identification firmware, which can be executed on the processor, is used to identify suspicious blocks among multiple blocks in response to device-based log data.

[0109] Statement 2. An embodiment of the inventive concept includes an SSD according to Statement 1, wherein a metadata storage store device-based log data for only the most recent set of errors in the SSD.

[0110] Statement 3. An embodiment of the inventive concept includes an SSD according to Statement 2, wherein when a new error occurs, the oldest entry in the device's log data is discarded.

[0111] Statement 4. Embodiments of the inventive concept include the SSD according to Statement 2, wherein:

[0112] The metadata storage is further operable to store precise block-based data about errors in the SSD; and

[0113] The SSD also includes verification firmware that can be executed on the processor, which can be used to determine whether a suspected block failure is predicted in response to accurate block-based data and device-based log data.

[0114] Statement 5. An embodiment of the inventive concept includes an SSD according to Statement 4, wherein verification firmware is performed only for suspicious blocks.

[0115] Statement 6. An embodiment of the inventive concept includes an SSD according to Statement 4, wherein, for any of the plurality of blocks other than the suspicious block, verification firmware is not executed.

[0116] Statement 7. Embodiments of the inventive concept include an SSD according to Statement 4, wherein the verification firmware is operable to eliminate suspicious blocks in response to precise block-based data and device-based log data.

[0117] Statement 8. An embodiment of the inventive concept includes an SSD according to Statement 4, wherein the precise block-based data includes a counter for the number of errors for each of the plurality of blocks.

[0118] Statement 9. An embodiment of the inventive concept includes an SSD according to Statement 8, wherein a counter for the number of errors for each of a plurality of blocks includes a read error counter, a write error counter, and an erase error counter for each of the plurality of blocks.

[0119] Statement 10. An embodiment of the inventive concept includes an SSD according to Statement 8, wherein precise block-based data includes a counter of the number of errors in each of a plurality of blocks since the manufacture of the SSD.

[0120] Statement 11. Embodiments of the inventive concept include an SSD according to Statement 4, wherein the verification firmware applies one of random forest, logistic regression, outlier detection analysis, and anomaly detection analysis to precise block-based data and device-based log data.

[0121] Statement 12. Embodiments of the inventive concept include an SSD according to Statement 4, wherein the identification firmware is operable to identify suspicious blocks among a plurality of blocks in response to both device-based log data and precise block-based data.

[0122] Statement 13. Embodiments of the inventive concept include an SSD according to Statement 2, wherein the identification firmware is operable to derive approximate block-based data from device-based log data.

[0123] Statement 14. An embodiment of the inventive concept includes an SSD according to Statement 13, wherein the identification firmware is operable to determine approximate block-based data from device-based log data as average block-based data.

[0124] Statement 15. Embodiments of the inventive concept include an SSD according to Statement 2, wherein the SSD is operable to periodically execute identification firmware.

[0125] Statement 16. An embodiment of the inventive concept includes an SSD according to Statement 15, wherein the SSD is operable to execute identification firmware at regular time intervals.

[0126] Statement 17. An embodiment of the inventive concept includes an SSD according to Statement 15, wherein, after a conventional number of errors have occurred, the SSD is operable to execute identification firmware.

[0127] Statement 18. Embodiments of the present invention include a solid-state drive (SSD), comprising:

[0128] Flash memory is used for data; the flash memory is organized into multiple blocks.

[0129] The controller is used to manage reading data from and writing data to the flash memory;

[0130] Metadata store, which stores precise block-based data for errors in SSDs; and

[0131] Identification firmware, which can be executed on the processor, is used to identify suspicious blocks among multiple blocks in response to precise block-based data.

[0132] Statement 19. Embodiments of the inventive concept include an SSD according to Statement 18, wherein the identification firmware is operable to identify suspicious blocks in response to a precise total error count of suspicious blocks in the block-based data.

[0133] Statement 20. An embodiment of the inventive concept includes an SSD according to Statement 18, wherein precise block-based data includes a counter for the number of errors for each of the plurality of blocks.

[0134] Statement 21. An embodiment of the inventive concept includes an SSD according to Statement 20, wherein a counter for the number of errors for each of a plurality of blocks includes a read error counter, a write error counter, and an erase error counter for each of the plurality of blocks.

[0135] Statement 22. An embodiment of the inventive concept includes an SSD according to Statement 21, wherein the identification firmware is operable to calculate a total error count from read error counters, write error counters, and erase error counters for suspicious blocks, and compares the total error count with a threshold.

[0136] Statement 23. An embodiment of the inventive concept includes an SSD according to Statement 18, wherein the SSD is operable to periodically execute identification firmware.

[0137] Statement 24. Embodiments of the present invention include an SSD according to Statement 23, wherein the SSD is operable to execute identification firmware at regular time intervals.

[0138] Statement 25. Embodiments of the inventive concept include an SSD according to Statement 23, wherein the SSD is operable to execute identification firmware after a conventional number of errors have occurred.

[0139] Statement 26. An embodiment of the present invention includes a method comprising:

[0140] Tracking errors in a solid-state drive (SSD) that consists of multiple blocks;

[0141] Stores device-based log data about errors in the SSD; and

[0142] Based on device-based log data, identify suspicious blocks among multiple blocks.

[0143] Statement 27. Embodiments of the inventive concept include the method according to Statement 26, wherein storing device-based log data about errors in the SSD includes storing only the device-based log data of the most recent set of errors in the SSD.

[0144] Statement 28. Embodiments of the inventive concept include the method according to Statement 27, wherein storing device-based log data about errors in the SSD further includes: discarding the oldest entry in the device-based log data when a new error occurs in the SSD.

[0145] Statement 29. Embodiments of the inventive concept include the method according to Statement 27, and further include:

[0146] Stores precise, block-based data about errors in the SSD; and

[0147] Once a suspicious block is identified, it is determined whether a failure of the suspicious block is predicted, based on both accurate block-based data and device-based log data.

[0148] Statement 30. Embodiments of the inventive concept include the method according to Statement 29, wherein determining whether to predict a suspected block failure in response to both precise block-based data and device-based log data includes determining whether to predict a suspected block failure only for the suspected block in response to both precise block-based data and device-based log data.

[0149] Statement 31. Embodiments of the inventive concept include the method according to Statement 29, wherein determining whether a suspected block failure is predicted in response to both precise block-based data and device-based log data includes: noting whether any other block failure is predicted.

[0150] Statement 32. Embodiments of the present invention include the method according to Statement 29, further comprising eliminating suspicious blocks based at least in part on precise block-based data and device-based log data.

[0151] Statement 33. Embodiments of the inventive concept include the method according to Statement 29, wherein storing precise block-based data about errors in an SSD includes storing a counter for the number of errors for each of a plurality of blocks.

[0152] Statement 34. Embodiments of the present invention include the method according to Statement 33, wherein storing a counter for the number of errors for each of a plurality of blocks includes storing a read error counter, a write error counter, and an erase error counter for each of the plurality of blocks.

[0153] Statement 35. Embodiments of the inventive concept include the method according to Statement 33, wherein storing a counter for the number of errors for each of the plurality of blocks includes storing a counter for the number of errors for each of the plurality of blocks since the SSD was manufactured.

[0154] Statement 36. Embodiments of the inventive concept include the method according to Statement 29, wherein determining whether a suspected block failure is predicted in response to both precise block-based data and device-based log data includes applying one of random forest, logistic regression, outlier detection analysis, and anomaly detection analysis to both the precise block-based data and the device-based log data.

[0155] Statement 37. Embodiments of the inventive concept include the method according to Statement 29, wherein determining whether to predict a suspected block failure in response to both precise block-based data and device-based log data includes determining whether to predict a suspected block failure in response to spatial locality information of the suspected block.

[0156] Statement 38. Embodiments of the inventive concept include the method according to Statement 27, wherein identifying a suspicious block among a plurality of blocks in response to device-based log data includes deriving approximate block-based data from the device-based log data.

[0157] Statement 39. Embodiments of the inventive concept include the method according to Statement 38, wherein deriving approximate block-based data from device-based log data includes determining average block-based data from the device-based log data.

[0158] Statement 40. Embodiments of the present invention include the method according to Statement 27, further comprising: periodically identifying new suspicious blocks among a plurality of blocks in response to device-based log data.

[0159] Statement 41. Embodiments of the inventive concept include the method according to Statement 40, wherein periodically identifying new suspicious blocks among a plurality of blocks in response to log data of the device includes checking the suspicious blocks among the plurality of blocks at regular time intervals.

[0160] Statement 42. Embodiments of the inventive concept include the method according to Statement 40, wherein periodically identifying new suspicious blocks among a plurality of blocks in response to log data of the device includes checking the suspicious blocks among the plurality of blocks after a regular number of errors have occurred.

[0161] Statement 43. An embodiment of the present invention includes a method comprising:

[0162] Tracking errors in a solid-state drive (SSD) that consists of multiple blocks;

[0163] Stores precise, block-based data about errors in the SSD; and

[0164] Responding to precise block-based data, identify suspicious blocks among multiple blocks.

[0165] Statement 44. Embodiments of the inventive concept include the method according to Statement 43, wherein identifying suspicious blocks among a plurality of blocks in response to precise block-based data comprises:

[0166] Calculate the total error count of suspicious blocks from precise block-based data; and

[0167] Compare the total error count with the threshold error count.

[0168] Statement 45. Embodiments of the inventive concept include the method according to Statement 44, wherein calculating the total error count of suspicious blocks from precise block-based data comprises:

[0169] Determine the read error counters, write error counters, and erase error counters of suspicious blocks from precise block base data; and

[0170] The read error counter, write error counter, and erase error counter are totaled to calculate the total error count of the suspicious block.

[0171] Statement 46. Embodiments of the inventive concept include the method according to Statement 43, which further includes periodically identifying new suspicious blocks among a plurality of blocks in response to device-based log data.

[0172] Statement 47. Embodiments of the inventive concept include the method according to Statement 46, wherein periodically identifying new suspicious blocks among a plurality of blocks in response to log data of the device includes checking the suspicious blocks among the plurality of blocks at regular time intervals.

[0173] Statement 48. Embodiments of the inventive concept include the method according to Statement 46, wherein periodically identifying new suspicious blocks among a plurality of blocks in response to log data of the device includes checking the suspicious blocks among the plurality of blocks after a regular number of errors have occurred.

[0174] Statement 49. Embodiments of the present invention include a product comprising a non-transitory storage medium storing instructions that, when executed by a machine, cause:

[0175] Tracking errors in a solid-state drive (SSD) that consists of multiple blocks;

[0176] Stores device-based log data about errors in the SSD; and

[0177] Based on device-based log data, identify suspicious blocks among multiple blocks.

[0178] Statement 50. Embodiments of the inventive concept include the product according to Statement 49, wherein storing device-based log data about errors in the SSD includes storing only the device-based log data of the most recent set of errors in the SSD.

[0179] Statement 51. Embodiments of the present invention include the product according to Statement 50, wherein storing device-based log data about errors in the SSD further includes: discarding the oldest entry in the device-based log data when a new error occurs in the SSD.

[0180] Statement 52. Embodiments of the inventive concept include the product according to Statement 50, wherein a non-transitory storage medium stores additional instructions thereon, which, when executed by a machine, cause:

[0181] Stores precise, block-based data about errors in the SSD; and

[0182] Once a suspicious block is identified, it is determined whether a failure of the suspicious block is predicted, based on both accurate block-based data and device-based log data.

[0183] Statement 53. Embodiments of the inventive concept include the product according to Statement 52, wherein determining whether to predict a suspected block failure in response to both precise block-based data and device-based log data includes determining whether to predict a suspected block failure only for suspected blocks in response to both precise block-based data and device-based log data.

[0184] Statement 54. Embodiments of the inventive concept include the product according to Statement 52, wherein determining whether a suspected block failure is predicted in response to both precise block-based data and device-based log data includes: noting whether any other block failure is predicted.

[0185] Statement 55. Embodiments of the inventive concept include the product according to Statement 52, wherein a non-transitory storage medium stores additional instructions thereon that, when executed by a machine, cause the elimination of suspicious blocks based at least in part on precise block-based data and device-based log data.

[0186] Statement 56. Embodiments of the inventive concept include the product according to Statement 52, wherein storing precise block-based data about errors in an SSD includes storing a counter for the number of errors for each of a plurality of blocks.

[0187] Statement 57. Embodiments of the inventive concept include the product according to Statement 56, wherein the counter storing the number of errors for each of the plurality of blocks includes storing a read error counter, a write error counter, and an erase error counter for each of the plurality of blocks.

[0188] Statement 58. Embodiments of the inventive concept include the product according to Statement 56, wherein storing a counter for the number of errors for each of the plurality of blocks includes storing a counter for the number of errors for each of the plurality of blocks since the SSD was manufactured.

[0189] Statement 59. Embodiments of the inventive concept include the product according to Statement 52, wherein determining whether a suspected block failure is predicted in response to both precise block-based data and device-based log data includes applying one of random forest, logistic regression, outlier detection analysis, and anomaly detection analysis to both the precise block-based data and the device-based log data.

[0190] Statement 60. Embodiments of the inventive concept include the product according to Statement 52, wherein determining whether to predict a suspected block failure in response to both precise block-based data and device-based log data includes determining whether to predict a suspected block failure in response to spatial locality information of the suspected block.

[0191] Statement 61. Embodiments of the inventive concept include the product according to Statement 50, wherein identifying a suspicious block among a plurality of blocks in response to device-based log data includes deriving approximate block-based data from the device-based log data.

[0192] Statement 62. Embodiments of the inventive concept include the product according to Statement 61, wherein deriving approximate block-based data from device-based log data includes determining average block-based data from device-based log data.

[0193] Statement 63. Embodiments of the inventive concept include the product according to Statement 50, wherein a non-transitory storage medium stores additional instructions thereon, which, when executed by a machine, cause new suspicious blocks among a plurality of blocks to be periodically identified in response to device-based log data.

[0194] Statement 64. Embodiments of the inventive concept include the product according to Statement 63, wherein periodically identifying new suspicious blocks among a plurality of blocks in response to log data of the device includes checking suspicious blocks among the plurality of blocks at regular time intervals.

[0195] Statement 65. Embodiments of the inventive concept include the product according to Statement 63, wherein periodically identifying new suspicious blocks among a plurality of blocks in response to log data of the device includes checking suspicious blocks among the plurality of blocks after a regular number of errors have occurred.

[0196] Statement 66. Embodiments of the present invention include a product comprising a non-transitory storage medium having instructions stored thereon that, when executed by a machine, cause:

[0197] Tracking errors in a solid-state drive (SSD) that consists of multiple blocks;

[0198] Stores precise, block-based data about errors in the SSD; and

[0199] Responding to precise block-based data, identify suspicious blocks among multiple blocks.

[0200] Statement 67. Embodiments of the inventive concept include the product according to Statement 66, wherein identifying suspicious blocks among a plurality of blocks in response to precise block-based data includes:

[0201] Calculate the total error count of suspicious blocks from precise block-based data; and

[0202] Compare the total error count with the threshold error count.

[0203] Statement 68. Embodiments of the inventive concept include the product according to Statement 67, wherein calculating the total error count of suspicious blocks from precise block-based data includes:

[0204] Determine the read error counters, write error counters, and erase error counters of suspicious blocks from precise block base data; and

[0205] The read error counter, write error counter, and erase error counter are totaled to calculate the total error count of the suspicious block.

[0206] Statement 69. Embodiments of the inventive concept include the product according to Statement 66, wherein the non-transitory storage medium stores additional instructions thereon that, when executed by a machine, cause new suspicious blocks among a plurality of blocks to be periodically identified in response to device log data.

[0207] Statement 70. Embodiments of the inventive concept include the product according to Statement 69, wherein periodically identifying new suspicious blocks among a plurality of blocks in response to log data of the device includes checking suspicious blocks among the plurality of blocks at regular time intervals.

[0208] Statement 71. Embodiments of the inventive concept include the product according to Statement 69, wherein periodically identifying new suspicious blocks among a plurality of blocks in response to log data of the device includes checking suspicious blocks among the plurality of blocks after a regular number of errors have occurred.

[0209] Therefore, given the various arrangements of the embodiments described herein, this detailed description and the appended materials are intended to be illustrative only and should not be considered as limiting the scope of the inventive concept. Thus, the claimed inventive concept encompasses all such modifications falling within the scope and spirit of the appended claims and their equivalents.

Claims

1. A solid state drive (SSD), comprising: a flash memory for storing data, the flash memory comprising a plurality of blocks; a controller for managing reading data from and writing data to the flash memory; the controller comprising a translation layer to map logical addresses used by a processor on the flash memory to physical addresses, and a metadata store storing first data and second data, the first data comprising device-based log data for error events in the SSD, the second data comprising block-based data regarding counters of a number of errors for each of the plurality of blocks; wherein the controller is configured to execute first instructions based at least in part on the first data to identify a suspect block of the plurality of blocks and execute second instructions based at least in part on both the second data and the first data to verify whether the suspect block is predicted to fail; and wherein the error events are related to abnormal activity performed by the controller on the flash memory.

2. The SSD of claim 1, wherein, the metadata store stores device-based log data only for a most recent set of errors in the SSD; and the SSD further comprises an identification firmware executing on the processor, the identification firmware operable to identify a suspect block of the plurality of blocks in response to the device-based log data.

3. The SSD of claim 2, wherein: the metadata store is further operable to store precise block-based data regarding errors in the SSD; and the SSD further comprises a verification firmware executing on the processor, the verification firmware operable to determine whether a suspect block is predicted to fail in response to the precise block-based data and the device-based log data.

4. The SSD of claim 3, wherein, the verification firmware is executed only on the suspect block.

5. The SSD of claim 3, wherein, the verification firmware is operable to retire the suspect block in response to the precise block-based data and the device-based log data.

6. The SSD of claim 3, wherein, the verification firmware implements one of a random forest, a logistic regression, an outlier detection analysis, and an anomaly detection analysis on the precise block-based data and the device-based log data.

7. The SSD of claim 2, wherein, the identification firmware is operable to derive approximate block-based data from the device-based log data.

8. The SSD of claim 2, wherein, the SSD is operable to periodically execute the identification firmware.

9. A method for failure prediction, comprising: tracking errors in a solid state drive (SSD), the SSD comprising a plurality of blocks; storing first data and second data in the SSD, the first data comprising device-based log data for error events in the SSD, the second data comprising block-based data regarding counters of a number of errors for each of the plurality of blocks; and executing first instructions based at least in part on the first data to identify a suspect block of the plurality of blocks and executing second instructions based at least in part on both the second data and the first data to verify whether the suspect block is predicted to fail; wherein the error events are related to abnormal activity in the SSD.

10. The method of claim 9, wherein, storing device-based log data regarding errors in the SSD includes storing only device-based log data for a most recent set of errors in the SSD.

11. The method of claim 10, further comprising: storing precise block-based data regarding errors in the SSD; and determining whether the suspect block is predicted to fail in response to both the precise block-based data and the device-based log data once the suspect block is identified.

12. The method of claim 11, wherein, determining whether the suspect block is predicted to fail in response to both the precise block-based data and the device-based log data includes determining whether the suspect block is predicted to fail in response to both the precise block-based data and the device-based log data only for the suspect block.

13. The method of claim 11, further comprising: retiring the suspect block based at least in part on the precise block-based data and the device-based log data.

14. The method of claim 11, wherein, determining whether the suspect block is predicted to fail in response to both the precise block-based data and the device-based log data includes implementing one of a random forest, a logistic regression, an outlier detection analysis, and an anomaly detection analysis on the precise block-based data and the device-based log data.

15. The method of claim 10, wherein, identifying suspect blocks in the plurality of blocks in response to the device-based log data includes deriving approximate block-based data from the device-based log data.

16. The method of claim 10, further comprising: periodically identifying new suspect blocks in the plurality of blocks in response to the device-based log data.

17. A program product comprising a non-transitory storage medium having stored thereon instructions that, when executed by a machine, cause: tracking errors in a solid state drive (SSD), the SSD comprising a plurality of blocks; storing first data and second data in the SSD, the first data comprising device-based log data for error events in the SSD, the second data comprising block-based data of counters of numbers of errors for each block in the plurality of blocks; and executing first instructions based at least in part on the first data to identify suspect blocks in the plurality of blocks and second instructions based at least in part on both the second data and the first data to validate whether the suspect blocks are predicted to fail; wherein the error events are related to abnormal activity in the SSD.

18. The program product of claim 17, wherein, storing device-based log data regarding errors in the SSD includes storing only device-based log data for a most recent set of errors in the SSD.

19. The program product of claim 18, wherein, the non-transitory storage medium has further instructions stored thereon that, when executed by the machine, cause: storing precise block-based data regarding errors in the SSD; and determining whether the suspect block is predicted to fail in response to both the precise block-based data and the device-based log data once the suspect block is identified.

20. The program product of claim 19, determining whether a suspect block is predicted to fail in response to both the precise block-based data and the device-based log data includes: determining whether the suspect block is predicted to fail in response to both the precise block-based data and the device-based log data only for the suspect block.

Images