JP5814335B2 - Reduction of writing and estimation and display of remaining life of nonvolatile memory - Google Patents

Description

Field of Invention

  [0001] This embodiment relates to a memory, and more specifically, to a memory having a finite lifetime.

background

  [0002] Memory is one of the most restrictive features regarding the performance of modern enterprise computing systems. One limiting feature of memory is the fact that many types of memory have a limited lifetime. For example, the lifetime of non-volatile memory, such as flash, decreases a small amount each time the memory is erased and rewritten. As time passes, after thousands of erases and rewrites, such flash memory can become increasingly unreliable.

  [0003] Thus, depending on the type of use (eg, light versus intense), the lifetime of the flash memory may vary significantly. This can be a problem in many ways. For example, flash memory manufacturers are often expected to provide a limited warranty over a specific length of time. Such a warranty may be sufficient for light to normal use of flash memory, but may require return and replacement of flash memory for heavy use (eg, enterprise applications).

  [0004] Such a situation can have a significant impact on the benefits of flash memory manufacturers. Specifically, the need to continually replace guaranteed flash memory for heavily used customers can significantly reduce the profits gained from selling flash memory from light use to normal use customers. is there. Accordingly, there is a need to address the above and / or other problems associated with the prior art.

Overview

  [0005] Systems, methods, and computer program products for delaying operations that reduce the lifetime of a memory are provided. In use, at least one characteristic related to the lifetime of the memory is identified. For this reason, at least one operation that shortens the lifetime of the memory is delayed based on this feature.

FIG. 3 is a diagram illustrating a method for delaying an operation that shortens the lifetime of a memory according to one embodiment. FIG. 6 illustrates a technique for delaying operations that reduce the lifetime of a memory according to another embodiment. FIG. 6 illustrates a time interval based technique for delaying operations that reduce memory life, according to another embodiment. FIG. 6 illustrates an integration-based technique for delaying operations that reduce memory lifetime, according to another embodiment. FIG. 6 illustrates a system for delaying an operation to reduce the lifetime of a memory when a desired lifetime duration exceeds an estimated lifetime duration according to another embodiment. FIG. 6 illustrates a method for delaying an operation that reduces the lifetime of a memory when a desired lifetime duration exceeds an estimated lifetime duration according to another embodiment. FIG. 6 illustrates a graphical user interface for measuring memory lifetime, according to another embodiment. FIG. 6 illustrates a method for reducing write operations in memory using difference information according to another embodiment. FIG. 6 illustrates a system for reducing write operations in memory according to another embodiment. FIG. 6 illustrates a method for reading memory using difference information according to one embodiment. FIG. 6 illustrates a method for writing to memory using difference information, according to one embodiment. FIG. 2 illustrates an embodiment using a processor-based system.

Detailed description

  [0018] In accordance with various described embodiments, various operations that reduce the lifetime of a memory can be controlled to extend such lifetime. In this description, such an operation may refer to a write operation, an erase operation, a program operation, and / or any other operation that can reduce the aforementioned lifetime.

  [0019] FIG. 1 illustrates a method 100 for delaying operations that reduce the lifetime of a memory according to one embodiment. As shown, at least one feature associated with the lifetime of the memory is identified. See operation 102.

  [0020] In this description, the lifetime of the memory is meant to include all the durations during which the memory exhibits any desired degree of use. For example, in various embodiments, such lifetimes can include, but are not limited to, desired lifetimes, actual lifetimes, estimated lifetimes, and the like. Furthermore, the degree of suitability depends on all usage, such as the percentage of components that are still operating (eg, blocks, cells, etc.), the reliability of the memory or its components, and / or any other parameters for that matter. May refer to the relevant parameters.

  [0021] Also, in this description, the lifetime-related features identified in operation 102 include, in various embodiments, a period, a rate of operation that reduces the lifetime of the memory, an allowable total number of operations that reduce the lifetime of the memory, Lifetime duration etc. can be included. Further, given the total allowed number of operations described above and the selected or desired lifetime, in one exemplary embodiment, the maximum average rate of operations is directly calculated in units of operations per period. Can do. Of course, such exemplary features are shown for illustration only, as any other feature of lifetime can be specified. This will be clear immediately.

  [0022] To this end, at least one operation that reduces the lifetime of the memory is delayed based on the feature. See operation 104. Accordingly, such a delay can be implemented in any form that is at least a partial function of the memory lifetime feature characterized by operation 102. In this description, the aforementioned delay of operation is considered to include situations where only a portion of the operation is delayed. For example, in situations where an operation includes multiple components, such a delay may be applied to one or more (or all) parts of such an operation.

  [0023] In one embodiment, an operation may be delayed by delaying a command that initiates the operation. For example, execution of such a command can be delayed in response to the identification of a write command or an erase command. Of course, in other embodiments, the operation itself can simply be delayed. With this design, such a delay in one or more operations that would otherwise reduce the lifetime of the memory at least partially reduces the decrease in lifetime.

  [0024] In the following, more exemplary information will be presented regarding various optional architectures and features. These architectures and features may or may not implement the framework described above as desired by the user. For example, the delay can be managed in a variety of different ways using a number of different techniques. Examples of these techniques are described below. It should be noted that the following information is provided for illustrative purposes and should not be construed as limiting in any way. Any of the following features may optionally be incorporated with or without other features described.

  [0025] FIG. 2 illustrates a technique 200 for delaying operations that reduce the lifetime of a memory according to another embodiment. As an option, the present technique 200 may be implemented to perform the method 100 of FIG. Of course, however, technique 200 may be implemented in any desired environment. It should also be noted that the above definitions may apply during this description.

  [0026] As shown, the technique 200 takes into account the total number of operations 202 that result in the memory exhibiting minimal use suitability, as well as the minimum desired lifetime 204 of the memory. From such data points, the maximum average operating rate 206 that achieves the minimum desired lifetime 204 can be calculated.

  [0027] During use, the number of operations that shorten the life can be monitored over time. If at any time the number of operations over time exceeds the maximum average operation rate 206 in the form shown, all extra operations (contributing to exceeding the rate) are calculated by the calculated amount. Can be adaptively delayed for a predetermined amount of time or based on the previous or predicted rate of life-shortening operations. This predetermined time may in one embodiment be a time that results in not exceeding the maximum average operating rate 206.

  [0028] In various embodiments, which operations are subject to delay (as well as the length of the delay itself) can be based on various factors. For example, in one embodiment, the delay may be based on the application that initiates the operation. In such embodiments, operations initiated by applications with lower priority can be subject to delay, and operations initiated by applications with higher priority are not necessarily subject to delay. (When possible).

  [0029] Of course, other embodiments are contemplated where the delay is managed across operations in an application independent manner. For example, the delay may be applied to all of a certain type of operation (for example, an erase operation) without depending on the application that generated the delay. Furthermore, embodiments using a hybrid approach are also conceivable.

  [0030] In addition, embodiments are contemplated that include operations or patterns of operations that cause abnormal shortening of life in the delayed operations. In one embodiment, only these patterns can be delayed. For example, viruses or rough application behavior patterns can be detected, and only the behavior from such patterns can be delayed.

  [0031] FIG. 3 illustrates a time interval based technique 300 for delaying operations that reduce the lifetime of memory, according to another embodiment. As an option, the technique 300 may be implemented to perform the method 100 of FIG. 1 and / or further with the technique 200 of FIG. Of course, however, technique 300 may be implemented in any desired environment. It should also be noted that the above definitions may apply during this description.

  [0032] Similar to the technique of FIG. 2, technique 300 takes into account the total number of operations 302 that result in the memory exhibiting minimal use suitability, as well as the minimum desired lifetime 304 of the memory. From such data points, the maximum average operating rate 306 that achieves the minimum desired lifetime 304 can be calculated. During use, the number of operations that shorten the lifetime can be monitored over time.

  [0033] When a plurality of such operations over time exceed the maximum average operation rate 206 at any given time, all excessive operations are not necessarily unconditionally delayed ( Not (like technique 200 of FIG. 2). Rather, such excessive motion can be conditionally delayed based on the time interval at which the motion is initiated. Such time intervals can include, for example, but are not limited to time, day, month, and the like. In additional embodiments, the time interval can be adaptively and dynamically adjusted to an optimal period. For example, such adaptive dynamic adjustment may be based on a histogram of the frequency of operations that shorten the life in a subinterval of a certain interval.

  [0034] For example, if an excessive number of actions are specified on Monday, Tuesday, Wednesday, Thursday, etc. in the manner shown above, they may be specified on subsequent Fridays, Saturdays, and Sundays. It can be recognized (eg, anticipated) that the number of certain actions is less. Thus, rather than unconditionally delaying such an excessive number of operations, these are dependent on the likelihood that the average operation rate (when done over a week) does not exceed the maximum average operation rate 206, Can be executed immediately. Of course, if you know this is not the case, you can make some delay during the following weeks, and so on. While the above example has been shown with day situations during the week, other more “macro” embodiments are possible that take into account variations in memory usage across weeks, months, etc.

  [0035] In a further additional embodiment, the conditional delay of operation is not necessarily based on intervals, but instead is based on memory usage history and / or even expected usage of memory. be able to. In such an embodiment, historical data is used to predict future use to perform any desired statistical analysis and more accurately identify situations where it does not necessarily delay excessive action. Can be done.

  [0036] FIG. 4 illustrates an integration-based technique 400 that delays operations that reduce memory lifetime, according to another embodiment. As an option, the technique 400 may be implemented to perform the method 100 of FIG. 1 and / or further in the techniques 200 and 300 of FIGS. Of course, however, technique 400 may be implemented in any desired environment. It should also be noted that the above definitions may apply during this description.

  [0037] Similar to previous techniques, the technique 400 takes into account the total number of operations 402 that result in the memory exhibiting minimal use suitability, and the minimum desired lifetime 404 of the memory. From such data points, the maximum average operating rate 406 that achieves the minimum desired lifetime 404 can be calculated. During use, the number of operations that shorten the lifetime can be monitored over time.

  [0038] At any given time, if multiple such operations over time exceed the maximum average operation rate 406, in the illustrated manner (see 408), all excess operations are It is not necessarily delayed in an unconditional manner (as in technique 200 of FIG. 2). Rather, such excessive operation can be conditionally delayed based on an integration function that reflects memory usage. Specifically, the integral of the difference between the overall rate of operation that shortens life over time and the maximum average operation rate 406 can be calculated as it progresses. For this reason, the delay described above need not necessarily be performed when such integration indicates that such operation may exceed the maximum average operation rate 406.

  [0039] FIG. 5 illustrates a system 500 that delays an operation to reduce the lifetime of a memory when a desired lifetime duration exceeds an estimated lifetime duration, according to another embodiment. As an option, the system 500 may be implemented to perform the method 100 of FIG. 1 and / or optionally further incorporate any of the techniques of FIGS. Of course, however, the system 500 may be used in any desired manner.

[0040] As shown, a storage system 503 including a plurality of storage devices 530, 540 is included. At least one storage bus 502 couples at least one controller 511 to at least one computer 501. In various embodiments, the storage bus 502 is a serial advanced technology attachment (SATA) bus, a serial attached.
SCSI (SAS) bus, fiber channel bus, memory bus interface, flash memory bus, NAND flash bus, integrated drive electronics (IDE) bus, advanced technology attachment (ATA) bus, consumer electronics (CE) bus, universal USBs, universal USBs ) Bus, smart card bus, multimedia card (MMC) bus, etc., but are not limited thereto. Accordingly, the controller 511 can be coupled between the system (eg, computer 501) and secondary storage (such as at least one of the storage devices 530, 540). In addition, at least one device 510 is included that extends the lifetime of the memory associated with the storage devices 530, 540.

  [0041] As shown, the apparatus 510 includes a controller 511 coupled to the storage devices 530, 540 via a plurality of corresponding buses 521, 522, respectively. In order to execute a command received from the computer 501 via the storage bus 502, the controller 511 uses the plurality of buses 521 and 522 to control the plurality of storage devices 530 and 540, and to transfer the data with these storage devices. Exchange. Each of the storage devices 530, 540 includes at least one module or block 531, 532, 533, 541, 542, 543 for storing data. In addition, at least some of the commands described above are commands that shorten the lifetime and have an adverse effect on at least one module or block 531, 532, 533, 541, 542, 543. In use, the device 510 serves to extend the life of the storage devices 530, 540 without relying on such a command to shorten the life.

  [0042] To accomplish this, the controller 511 is coupled to the life assessment module 514 via a corresponding bus 512. Apparatus 510 further includes a time module 517 coupled to life assessment module 514 via bus 518 to provide the current time. In use, the life assessment module 514 serves to receive commands communicated from the computer 501 to the controller 511 via the storage bus 502. Further, the life evaluation module 514 calculates the estimated life assuming that the command (s) received via the bus 512 has been executed.

  [0043] Continuing to refer to FIG. The life estimation module 514 is coupled to the throttling module 516 via the bus 515. The lifetime estimation module 514 uses the bus 515 to pass the estimated lifetime for the command currently being executed by the controller 511 to the throttling module 516. The command currently being executed may be identical to the command received by the lifetime estimation module 514 via the bus 512 and received by the controller 511 from the computer 501 via the storage bus 502 in one embodiment. Can be the same command.

  [0044] Current time module 517 is also coupled to throttling module 516 via bus 518. Accordingly, the current time from the current time module 517 can be passed to the throttling module 516 as well. In one embodiment, the current time module 517 can be implemented, for example, as a simple counter that is incremented at regular time intervals.

  [0045] The throttling module 516 is further coupled to the required life module 520 via the bus 519 and is coupled to the controller 511 via the bus 513. In use, the required life module 520 is adapted to store a desired life. With this design, the throttling module 516 can be configured to pass information to the controller 511 via the bus 513 to instruct the controller 511 to delay execution of the current command.

  [0046] In one embodiment, the throttling module 516 of the device 510 allows the impact of the current command execution on the lifetime to be such that the estimated lifetime is greater than or equal to the required lifetime stored in the required lifetime module 520. , Can operate to delay the execution of the current command. The function of the throttling module 516 is, in one embodiment, as simple as providing a delay signal to the controller 511 when the estimated lifetime received via bus 515 is shorter than the required lifetime received via bus 519. can do.

  [0047] In another embodiment, the functions described above on controller 511, life assessment module 514, and throttling module 516 may be applied to a group of commands received in a given time interval. With such a configuration, the system 500 may be able to meet the required lifetime without unnecessarily suppressing short bursts of commands that would shorten the lifetime. By selecting the time interval as, for example, one day, such a technique allows the system 500 to provide higher instantaneous performance for commands that reduce lifetime. This is because, in a certain period of the day (for example, at night), there may be a time interval in which there are commands that reduce the service life with a lower frequency compared to the average frequency of commands that shorten the service life.

  [0048] In one optional embodiment, coherency can be maintained over time. As an example of the coherency method, if the command A that reduces the lifetime is delayed, all commands (whether or not to reduce the lifetime) that depend on the data of A or the value resulting from the execution of the command A are also included. , Be delayed.

  [0049] In another embodiment, the time can be replaced with various approximations of the time, such as the time the disk is powered up. In another embodiment, the computer 501, RAID controller, and / or other device may provide additional information to increase the accuracy of the time being tracked. Thus, the time counter is not counting when one or more of the storage devices 530, 540 are powered on. This may unnecessarily degrade performance as real time is progressing. In such a scenario, the computer 501, software, and / or controller may provide information regarding when the system 500 is turned off to address such issues.

  [0050] In another embodiment, the system 500 may include an intra-storage device redundancy feature to reduce cost and improve performance. In such embodiments, data can be moved between individual storage devices 530, 540 based on any characteristics related to their lifetime (see, eg, operation 102 in FIG. 1). ). For example, there may be a situation where the first portion 530 of the storage device includes a set of data that is overwritten more frequently than the data in the second portion 540 of the storage device. In that case, after a predetermined time, such data can be moved from the first storage device 530 to the second storage device 540, and in the future the first storage device 530 or one or more blocks / modules 531, 532, 533 can be used to store data that is written less frequently or withdraw from further use.

  [0051] To this end, storage deviceware can be appropriately distributed to prevent one storage device from failing too early relative to the other storage devices in the group. Of course, the technique can be applied not only between different storage devices, but also part thereof. For this reason, the lifetime of any memory component can be managed in such a way.

  [0052] In any case, the controller 511 may be configured to reduce writes and / or distribute writes. This feature can extend the life of a suitable storage device 530, 540. One exemplary method for performing such a technique is shown in the description of FIG.

  [0053] FIG. 6 illustrates a method 600 for delaying an operation to reduce the lifetime of a memory when a desired lifetime duration exceeds an estimated lifetime duration according to another embodiment. As an option, the present method 600 may be performed using the system 500 of FIG. 5 and / or further options may incorporate any of the techniques of FIGS. Of course, however, the method 600 can be performed in any desired manner. Nevertheless, the above definitions may apply in this description.

  [0054] Upon initiating operation 601, method 600 is continued by a controller (eg, controller 511 of FIG. 5) and at least one storage device (eg, storage devices 530, 540) by a computer (eg, computer 501). 602 for a command issued to If a command is received by the controller, the method proceeds to decision 603, where the controller determines whether the command accepted in operation 602 is a command that shortens life (eg, an erase operation, a write operation, etc.). Determine. If the decision 603 determines that the currently received command does not reduce life, such a command can simply be processed by the operation 607.

  [0055] On the other hand, if the decision 603 determines that the currently received command is actually one that shortens the lifetime, then the estimated lifetime is calculated as the command received at the operation 602, the previous lifetime, and the current Based on the time (eg, via the time module 517, etc.), the life evaluation module (eg, life estimator module 514, etc.) calculates. See operation 604. In one embodiment, the previous life may represent a previous state of the life estimation module. In another embodiment, the previous lifetime can be obtained by measuring one or more characteristics of at least one storage device.

  [0056] In any case, the lifetime estimated by such a lifetime assessment module is then provided to a throttling module (eg, throttling module 516, etc.). At decision 605, the throttling module determines that throttling is necessary if the estimated life received from the life assessment module is shorter than the required life sent to the throttling module. If throttling is required, the method 600 proceeds at operation 606 by delaying (eg, by suppressing) a command that shortens life. However, if the estimated lifetime is not shorter than the required lifetime, the method 600 proceeds to operation 607 shown above.

  [0057] Specifically, at operation 606, the throttling module can use the controller to suppress execution of a command that shortens life. In one embodiment, such suppression can be implemented by using the controller to delay execution of a command that reduces the lifetime until the lifetime estimated by the lifetime assessment module is greater than or equal to the required lifetime.

  [0058] In another embodiment, the suppression can be determined within a predetermined time period and applied to the command during a subsequent predetermined time period. In such an embodiment, a limit can be placed on how much the lifetime can be shortened within a given time interval. In yet another embodiment, a limit on how much life can be shortened within a time interval can be determined in one or more previous time intervals. In yet another embodiment, the suppression is determined based on an analysis of a plurality of pending actions, and an action that does not reduce life is prior to an action that shortens or relies on such action to reduce the life. It may be possible to perform.

  [0059] This design can provide a data storage system that controls operations that reduce the life to guarantee the required minimum life. Therefore, it is possible to estimate the influence of the operation that shortens the lifetime with respect to the minimum required lifetime, and it is possible to adaptively restrict the frequency of the operation that shortens the lifetime.

  [0060] FIG. 7 illustrates a graphical user interface 700 for measuring memory lifetime, according to another embodiment. As an option, this graphical user interface 700 may be implemented under the functions and architecture of FIGS. Of course, however, the graphical user interface 700 may be implemented in any desired environment. It should also be noted that the above definitions may apply during this description.

  [0061] As shown, various displays can be presented reflecting at least one characteristic associated with the lifetime of the memory. In one embodiment, such features may be those identified in operation 102 of FIG. However, of course, this lifetime related feature may be any desired feature that is at least partially related to the lifetime of the memory. For example, in the system 500 of FIG. 5, this feature may be retrieved by the controller 511 from any of the illustrated modules to be processed and / or simply passed to the computer 501 and the computer 501. Can present relevant displays under the control of a software application program (eg, a plug-in, etc.).

  [0062] For example, the foregoing display may include a gauge 702 that, in one embodiment, indicates the amount of life remaining for one or more memories. In such an embodiment, the gauge 702 can indicate the length of total memory life remaining as a function of the number of operations that reduce the life performed over time. In another embodiment, the above display may show an estimate 705 indicating a lifetime assuming a pause in the restraining operation based on extrapolation of previous usage.

  [0063] In another embodiment, the aforementioned indication may include a warning 704 indicating that a minimum amount of lifetime remains for one or more memories. Such a lifetime can be estimated based on, for example, memory usage history data. This design allows the user to be warned about situations such as when the memory must be replaced during a predetermined time. Of course, other embodiments are contemplated that use any desired display to report various information related to the lifetime of the memory.

  [0064] FIG. 8 illustrates a method 800 that utilizes difference information to reduce write operations in memory, according to another embodiment. As an option, the method 800 may or may not be performed in connection with the functionality and architecture of FIGS. Of course, however, the method 800 may be performed in any desired environment. It should also be noted that the above definitions may apply during this description.

  [0065] As shown, a write operation to be performed on data stored in memory is first identified. See operation 802. In this description, such a write operation may include all operations that result in modification of data stored in memory. Further, such a write operation can be identified in any desired manner by intercepting a write command associated with such an operation, the write operation itself, and the like.

  [0066] As shown in operation 804, the difference between the result of the write operation and the data stored in the memory is then determined. In this description, the aforementioned differences can reflect, at least in part, all differences between the first state of data stored in the memory and the second state resulting from the aforementioned write operation.

  [0067] In another embodiment, the difference between any data stored in memory can be determined. For example, a new modified version of the file may be created and written to a new location in memory to determine the difference in data from different locations in memory. Optionally, the location of the data can be identified based on a hash, Bloom filter, etc. For this reason, in one exemplary embodiment where different instances of the same data are written to different locations in memory, the determined difference may include the location of the data, but not necessarily the data itself. Good.

  [0068] In one embodiment, difference information related to the difference may be stored in a memory (eg, the same memory in which the data is stored, etc.). In another embodiment, the difference information may be stored in separate buffers in a manner that will be detailed later in the description of the different embodiments. Note that the difference information can include all information that describes the difference determined at least in part at operation 804. As will become apparent in the discussion of embodiments described below, the difference information may be stored using an instruction set in one embodiment. As also described below, such instruction sets can be adaptively modified and / or dynamically expanded in various embodiments.

  [0069] To this end, write operations can be reduced utilizing difference information. See operation 806. With this design, such a reduction in write operations can optionally extend the life of the memory.

  [0070] In the following, more exemplary information is presented regarding various optional architectures and features. Note that the above-described framework may or may not be implemented using these architectures and features according to the user's wishes. For example, one exemplary system is shown for implementation of one exemplary method for reducing write information based on difference information. It is strongly noted that the following information is presented for illustrative purposes and should not be construed as limiting in any way. Any of the following features may optionally be incorporated with or without the other features described.

  [0071] FIG. 9 illustrates a system 900 that reduces write operations in memory, according to another embodiment. As an option, the system 900 may be implemented to perform the method 800 of FIG. 8 and / or to optionally incorporate any of the methods or techniques of FIGS. Of course, however, the system 900 may be used in any desired manner. Again, the above definitions may apply during this description.

  [0072] As shown, system 900 includes a computer 901 coupled to a storage device 930 via an input / output (I / O) bus 902 in the manner described below. The I / O bus 902 includes a read path 903 and a write path 904. The storage device 930 includes a plurality of storage blocks 931, 932, and 933. The storage blocks 931, 932, and 933 are written and read by the computer 901.

  [0073] As will become apparent, a predetermined portion 934 of each of the storage blocks 931, 932, 933 can be allocated to store difference information. The difference information reflects all changes made by the computer 901 to the data stored in the remaining portion 935 of the corresponding storage block 931, 932, 933. In various embodiments, the size of the predetermined portion 934 can be set by the user. Furthermore, the difference information stored therein can take any form.

[0074] Table 1 shows one candidate format that represents an example of difference information (a plurality of difference information can be stored in each predetermined portion 934 of storage blocks 931, 932, 933).

  [0075] In this embodiment, the operation code may represent an operation to be performed on the data stored in the remaining portion 935 of the corresponding storage block 931, 932, 933. Examples of such operations include end, replace, move up, move down, move down, delete, insert, and / or more Any other action may be included, but is not limited to these. Optionally, each such operation may have associated code for a compact representation (eg, replace = '001', move up = '010', etc.).

  [0076] Further, the source start address and size refer to the data stored in the remaining portion 935 of the corresponding storage block 931, 932, 933 to be operated on, and indicate its size (respectively) Can do. Further, in situations where the operation requires data replacement / change, etc., the data itself can be stored as a component of the difference information. As yet another option, a compression algorithm can be applied to the difference information for more efficient storage. As another option, in situations where the operation requires data movement, the source location of the data can be specified, not necessarily the data itself, since the data is contained in the original storage block.

  [0077] In another embodiment, new actions can be created adaptively. For example, the repeating sequence of the first action can be replaced by a new second action. Such a new second action may describe a sequence of the first actions. In this way, new actions can be created adaptively and system 900 can optimally adapt itself to new applications.

  [0078] Of course, the data structure in Table 1 is shown for illustrative purposes only and should not be construed as limiting in any way. For example, an instance of difference information can simply be included in the data to be replaced (without complicated commands or the like).

  [0079] Furthermore, an apparatus 910 is provided to reduce write operations in the memory. Such a device 910 includes an integrated memory 920 that includes a plurality of integrated buffers 921, 922, 923. In one embodiment, each size of the integrated buffers 921, 922, 923 may have a predetermined size (eg, 4 Kb). The predetermined size may be a size that correlates to a minimum block portion that can be written to each of the storage blocks 931, 932, and 933 in a single operation. Further, in various embodiments, the integrated buffer 921 may be on-chip storage, external memory, DRAM, SRAM, and the like.

  [0080] As will be readily apparent, the unified memory buffers 921, 922, 923 hold instances of difference information (eg, see Table 1) for the corresponding storage blocks 931, 932, 933, respectively. To do. That is, the first buffer 921 of the plurality of integrated memory buffers holds an instance of the difference information of the first block 931 among the plurality of storage blocks, and the second buffer of the plurality of integrated memory buffers. The buffer 922 holds an instance of the difference information of the second block 932 of the plurality of storage blocks, and the third buffer 923 of the plurality of integrated memory buffers is the third of the plurality of storage blocks. Hold the instance of the difference information in block 933, and so on.

  [0081] Apparatus 910 further includes an update module 912 that is coupled to integrated memory 920 via bus 914. The update module 912 is for writing the difference information stored in the integrated memory buffers 921, 922, and 923 into the corresponding storage blocks 931, 932, and 933. In one embodiment, such writing causes at least one instance of the difference information to be written to one of the unified memory buffers 921, 922, 923 (and thus suitable of storage blocks 931, 932, and 933). Configure a minimum write size to one). To accomplish this write, update module 912 is coupled to storage device 930 via bus 915. As further shown, the output of update module 912 is coupled to I / O bus 902 via read path 903.

  [0082] Further, a difference calculation module 911 is coupled to the update module 912 via the read path bus 903, coupled to the I / O bus 902 via the write path bus 904, and further integrated via the bus 913. Coupled to memory 920. In use, the difference calculation module 911 can read data from the storage device 930 and can also provide difference information from the associated storage blocks 931, 932, and 933 and / or the integrated memory buffers 921, 922, 923. Can be used to reconstruct the current state of such data.

  [0083] The difference calculation module 911 first reconstructs the current state of the data as needed (similar to the read operation above), and such current state and write operation (initiated by the computer 901). ) And the one or more instances of the difference information used to update the associated storage blocks 931, 932, and 933 into the unified memory buffers 921, 922, 923. By porting, it is further possible to write such data to the storage device 930. Further information regarding such read and write operations is provided below in the description of FIGS.

  [0084] In various embodiments, the difference calculation module 911 can use any desired technique to identify the aforementioned differences. For example, various string matching algorithms, data movement estimation techniques, etc. can be utilized, for example. In yet additional embodiments, the difference can be determined in bytes.

  [0085] Further, the difference calculation detects which byte string is inserted, detects which byte string is deleted, detects which byte string is replaced, which Detect whether byte strings are copied, determine whether byte strings are updated by adding values, detect copies of storage blocks and create references to them, detect block splits Any one or more of the following steps may be used: detecting a block combination.

  [0086] FIG. 10 illustrates a method 1000 for reading memory using difference information, according to one embodiment. Optionally, the method 1000 may be performed using the system 900 of FIG. 9, and / or further options may incorporate any of the techniques of FIGS. Of course, however, the method 1000 may be used in any desired manner. Again, the above definitions may apply during this description.

  [0087] As illustrated, the method 1000 reads blocks (eg, blocks 931, 932, 933, etc. of FIG. 9) from a storage (eg, storage device 930, etc.) as requested by a computer (eg, computer 901, etc.). To start at operation 1001. The read storage block data is then sent to an update module (eg, update module 912, etc.). Then, in response to the read operation, the difference information is obtained from an integrated buffer (eg, buffered buffers 921, 922, 923, etc.) corresponding to the storage block (related to the computer request) and / or from the storage block itself. Read. See operation 1002. The appropriate source of difference information may depend on whether the requested information was written from the unified buffer to the corresponding storage block at the time of the read request. Optionally, the difference information can be interspersed between data in the flash. Furthermore, differences regarding specific data may be grouped into one or more groups.

  [0088] Next, at operation 1003, the update module applies the difference reflected in the difference information from operation 1002 to the corresponding block read at operation 1001. For this purpose, the data reconstructed in operation 1003 can be sent to the computer via a read path (eg, read path 903, etc.). See operation 1004.

  [0089] In various embodiments, the data read operation described above may include a mapping from logical storage block numbers to physical storage block numbers. Further, the method 1000 can provide error detection and error correction associated with reading. Such error detection and error correction of read data may further include a reread operation that attempts to recover the data and relocate the recovered data to another storage location. For example, such relocation of recovered data can use logical storage block conversion and / or can be based on error rate information of candidate storage blocks.

  [0090] FIG. 11 illustrates a method 1100 for writing to memory using difference information, according to one embodiment. As an option, the method 1100 may be performed using the system 900 of FIG. 9 and / or further options may incorporate any of the techniques of FIGS. Of course, however, the method 1100 may be used in any desired manner. Furthermore, the above definitions may apply during this description.

  [0091] Similar to the reading method 1000 of FIG. 10, the method 1100 includes a block (eg, of FIG. 9) from a storage (eg, a storage device 930) that is subject to a write request by a computer (eg, the computer 901, etc.). Reading block 931, 932, 933, etc.) may begin at operation 1101. The read storage block data is then sent to an update module (eg, update module 912). Next, at operation 1102, the difference information is read from the unified buffer (eg, coalesced buffers 921, 922, 923, etc.) corresponding to the storage block (associated with the computer request) and / or from the storage block itself. Next, at operation 1103, the update module applies the difference reflected in the difference information from operation 1102 to the corresponding block read at operation 1101 to reconstruct the data to be read or written.

  [0092] To this end, the data reconstructed in operation 1103 is sent to a difference calculation module (eg, difference calculation module 911, etc.) and compared with the state of the data that should result from the execution of the write operation requested by the computer. can do. See operation 1104. For this, the difference between the reconstructed data and the state of the data that should result from performing the write operation is identified. In one embodiment, such a difference may be caused by an application (running on a computer) for updating data. Such updates can include, but are not limited to, replacing a string of bytes, inserting a string of bytes, deleting a string of bytes, copying a string of bytes, and the like.

  [0093] In operation 1105, difference information associated with the difference calculated in operation 1104 may be added to an appropriate unified buffer corresponding to the block in which at least one difference calculated in operation 1104 exists. Such addition can be accomplished by writing to the end of the unified buffer in the unified memory. In one embodiment, such additions may further include unified buffer decompression, data addition, and appropriate unified buffer recompression. Optionally, the unified buffer memory can be reallocated to the unified buffer on demand.

  [0094] In an optional embodiment, the difference information may be stored as an operation that describes a function (eg, writing) performed on the data. For example, the difference information can reflect changes resulting from operations performed within the B-tree, and thus can represent differences for such operations. Such B-trees can optionally be used by databases, mail servers, file systems, and the like.

  [0095] Next, decision 1106 tests the unified buffers to determine if they are full. If no unified buffer is full, the method 1100 proceeds to operation 1110. On the other hand, if at least one unified buffer is full, method 1100 proceeds to operation 1107. In operation 1107, all full unified buffers are added to the difference information. Further, such a full unified buffer is emptied (for reuse, etc.) as shown in operation 1112.

  [0096] Further, it is determined whether the difference information is full (operation 1114). Method 1100 proceeds to operation 1110 if the difference information is determined not to be full. However, in response to determining that the difference information is full, changes from the difference information are applied to the data. Note operation 1116. Further, as shown in operation 1118, the block of data having the applied changes is written and the old data is discarded. Further, as shown in operation 1120, the difference information is emptied. To this end, a data storage system that uses the difference between written data and existing data to reduce writes and distribute writes across memory blocks to improve block-based storage reliability. Can be offered.

  [0097] In various embodiments, the memory described in the previous embodiments is a mechanical storage device (eg, SATA disk drive, SAS disk drive, Fiber Channel disk drive, IDE disk drive, ATA disk drive, CE disk drive). USB disk drives, smart card disk drives, MMC disk drives, etc.) and / or non-mechanical storage devices (eg, semiconductor based ones). Such non-mechanical memory can include, for example, volatile memory or non-volatile memory. In various embodiments, the non-volatile memory device can include flash memory (eg, single bit NOR flash memory per cell, multiple bit NOR flash memory per cell, single bit NAND flash memory per cell) Multi-bit NAND flash memory per cell, multi-level multi-bit NAND flash per cell, large block flash memory, etc.). Although various examples of memory are shown herein, it should be noted that various principles can be applied to any type of memory whose lifetime can be reduced due to various operations performed thereon.

  [0098] FIG. 12 illustrates an example system 1200 that can implement various architectures and / or functions of various previous embodiments. For example, the exemplary system 1200 may be the computer shown in some of the previous embodiments. Also, the various devices shown above may be components of the system 1200.

  [0099] As shown, a system 1200 is provided that includes at least one host processor 1201 connected to a communication bus 1202. The system 1200 also includes a main memory 1204. Control logic (software) and data are stored in main memory 1204, which can take the form of random access memory (RAM).

  [00100] The system 1200 also includes a graphics processor 1206 and a display 1208 or computer monitor. System 1200 can also include secondary storage 1210. Secondary storage 1210 includes, for example, hard disk drives and / or removable storage drives representing floppy disk drives, magnetic tape drives, compact disk drives, and the like. The removable storage drive reads from and / or writes to the removable storage module in a well-known manner.

  [00101] Computer programs or computer control logic algorithms may be stored in main memory 1204 and / or secondary storage 1210. Such a computer program enables system 1200 to perform various functions when executed. Memory 1204, storage 1210, and / or any other storage are possible examples of computer-readable media.

  [00102] In one embodiment, the architecture and / or functionality of the various previous drawings is changed to at least one of the capabilities of the host processor 1201, graphics processor 1206, secondary storage 1210, both host processor 1201 and graphics processor 1206. Integrated circuit (not shown), a chipset (ie, a group of integrated circuits designed and marketed as modules that perform related functions), and / or Furthermore, it can be implemented in any other integrated circuit.

  [00103] In addition, the architecture and / or functionality of the various previous drawings may be used in general purpose computer systems, circuit board systems, dedicated gaming machine systems for entertainment purposes, application specific systems, and / or any other desired system. Can be implemented. For example, system 1200 can take the form of a desktop computer, a laptop computer, and / or any other type of logic. Further, system 1200 can take the form of various other devices including, but not limited to, personal digital assistant (PDA) devices, mobile phone devices, televisions, and the like.

  [00104] Further, although not shown, system 1200 may be configured to communicate with a network [eg, a telecommunication network, a local area network (LAN), a wireless network, a wide area network (WAN) such as the Internet, a peer-to-peer network, a cable network, etc. ] Can be combined.

  [00105] While various embodiments have been described above, it should be understood that these are provided by way of example only and not limitation. Accordingly, the breadth and scope of the preferred embodiments should not be limited by the exemplary embodiments described above, but should be defined only in accordance with the appended claims and their equivalents.

Claims (20)

Reducing the number of write operations in one or more non-volatile memories;
Estimating a remaining lifetime of at least a portion of the non-volatile memory;
Visually displaying the estimated remaining life and characteristics associated with the life on a graphical user interface , wherein the characteristics represent an operation rate indicated in units of the number of operations per period. Including, steps ,
And wherein the estimating step is performed in connection with the reducing step. Step includes determining the difference between the stored result of the write operation as in the non-volatile memory data, The method according to claim 1 to reduce the number of times of the write operation. The step of reducing the number of write operations is performed at least in part by a controller, the controller being capable of receiving commands from a computer via a storage bus and controlling the non-volatile memory, The method of claim 1, wherein data can be exchanged with non-volatile memory.   The method of claim 1, wherein the remaining lifetime estimate is based at least in part on a previous lifetime.   The method of claim 4, further comprising measuring one or more characteristics of at least one storage device to obtain the previous lifetime.   The method according to claim 1, wherein the step of visually displaying is a step of displaying using a gauge.   The method of claim 1, wherein the non-volatile memory includes flash memory. A controller capable of receiving commands from a computer via a storage bus, the controller capable of controlling one or more nonvolatile memories and exchanging data with the nonvolatile memories;
A lifetime estimation module capable of estimating a remaining lifetime of the non-volatile memory based at least in part on command information received from the controller;
A visual display capable of showing in a graphical user interface the estimated remaining remaining life and characteristics associated with the life , wherein the characteristics are indicated in units of the number of times of the movement per period Including visual display ,
The controller is further capable of reducing write operations to the non-volatile memory to increase the estimated remaining lifetime.   9. The system of claim 8, further comprising a difference calculation module capable of identifying a difference between a current state and a state that occurs after a write operation.   The system of claim 8, wherein the lifetime estimation module is capable of estimating the remaining lifetime based at least in part on a previous lifetime.   The system of claim 10, wherein the previous lifetime is obtained by measuring one or more characteristics of at least one storage device.   The system of claim 8, wherein the visual indication includes a gauge.   The system of claim 8, wherein the non-volatile memory includes flash memory.   The system of claim 13, further comprising the flash memory. A computer program implemented on a tangible computer-readable medium included in a computer system, the program being executed,
A function to reduce the number of write operations in one or more nonvolatile memories;
A function of estimating a remaining lifetime of at least a part of the nonvolatile memory;
A function of visually displaying the estimated remaining remaining life and characteristics related to the life on a graphical user interface , wherein the characteristics have an operation rate indicated in units of the number of operations per period; Including, functions ,
A computer program, wherein the remaining life estimation is performed in connection with reducing the number of write operations . The reduction in the number of write operations includes determining the difference between the stored result of the write operation as in the non-volatile memory data, the computer program of claim 15.   The computer program product of claim 15, wherein the remaining lifetime estimate is based at least in part on a previous lifetime.   The computer program product of claim 17, further causing the computer system to perform a function of measuring one or more characteristics of at least one storage device to obtain the previous lifetime.   The computer program according to claim 15, wherein the visually displaying function displays using a gauge.   The computer program according to claim 15, wherein the non-volatile memory includes a flash memory.

Images