WO2008087634A1 - Procédé et système pour faciliter le réveil rapide d'un système de mémoire flash - Google Patents

Procédé et système pour faciliter le réveil rapide d'un système de mémoire flash Download PDF

Info

Publication number
WO2008087634A1
WO2008087634A1 PCT/IL2008/000062 IL2008000062W WO2008087634A1 WO 2008087634 A1 WO2008087634 A1 WO 2008087634A1 IL 2008000062 W IL2008000062 W IL 2008000062W WO 2008087634 A1 WO2008087634 A1 WO 2008087634A1
Authority
WO
WIPO (PCT)
Prior art keywords
memory
data structure
information data
future information
nonvolatile memory
Prior art date
Application number
PCT/IL2008/000062
Other languages
English (en)
Inventor
Menahem Lasser
Avraham Meir
Original Assignee
Sandisk Il Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/808,451 external-priority patent/US7769945B2/en
Application filed by Sandisk Il Ltd. filed Critical Sandisk Il Ltd.
Priority to DE112008000180T priority Critical patent/DE112008000180T5/de
Priority to JP2009546065A priority patent/JP5351046B2/ja
Priority to KR1020097015437A priority patent/KR101288408B1/ko
Publication of WO2008087634A1 publication Critical patent/WO2008087634A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
    • G06F12/0246—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11C—STATIC STORES
    • G11C16/00—Erasable programmable read-only memories
    • G11C16/02—Erasable programmable read-only memories electrically programmable
    • G11C16/06—Auxiliary circuits, e.g. for writing into memory
    • G11C16/10—Programming or data input circuits
    • G11C16/102—External programming circuits, e.g. EPROM programmers; In-circuit programming or reprogramming; EPROM emulators
    • G11C16/105—Circuits or methods for updating contents of nonvolatile memory, especially with 'security' features to ensure reliable replacement, i.e. preventing that old data is lost before new data is reliably written
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/72—Details relating to flash memory management
    • G06F2212/7201—Logical to physical mapping or translation of blocks or pages

Definitions

  • the present invention relates to methods and systems for maintaining data structures that are useful for facilitating a wake-up of a flash memory system.
  • a flash physical unit might contain the number of the virtual unit mapped to it.
  • During program runtime we may frequently need to translate a virtual unit number into its physical counterpart. If we have to rely only on flash-stored control data, we may need to scan the units until we find the unit with the specified virtual unit number, a very long process by the standards of a simple media access.
  • by scanning the flash device once on system wake-up and constructing a table mapping each virtual unit number into a corresponding physical unit number we are able to later do such mappings very efficiently.
  • the problem is that scanning the flash data storage device on system wake-up might take a long time, especially for high capacity devices. This is especially annoying for systems and devices in which a user expects immediate turn-on (i.e.
  • this problem is solved by storing translation tables in the flash memory and adding some means for the software to invalidate the translation tables in a way that is detectable whenever reading them.
  • Possible implementations include adding a checksum value that makes the sum of all entries equal some fixed known value, or adding a validity flag to the stored tables. Additionally, one should ask the application software to call a specific function in the translation layer before shutting the system down.
  • the flash memory device is able to initiate fast wake-ups when the system undergoes an orderly shut down, and reverts to regular wake-ups when the system undergoes an un-orderly shut down.
  • a second example where the solution may not be adequate is where the operating system of the appliance hosting the flash memory system does not provide the software application with a service for orderly device dismounting or shutting down. While complex operating systems like Linux do provide such service, there are many simpler and smaller operating systems that are designed for starting up the storage system upon power-on and never shut the operating system down. In such cases the methods of Lasser '488 will result in every power-up of the system doing a regular wake-up of the flash management system, gaining nothing from those methods.
  • a third example where the solution may not be adequate is where there is a strict limit on the length of the time interval between powering the system up and having the system ready for operation.
  • Lasser '056 discloses another solution to the problem of a fast wake-up of flash management systems.
  • the aforementioned application of Lasser '056 is incorporated by reference for all purposes as if fully set forth herein.
  • Lasser '056 discloses a technique whereby one or more flash management tables are updated and saved in flash memory after some but not after all events of the flash memory system.
  • waking up if it turns out that a given flash management table stored in the flash memory contains out-of-date information, it is still possible to use the stored table(s) to facilitate system wake-up, and there is no requirement to invalidate the out-of-date table.
  • the out-of-date flash management table saved in flash memory before shut down and/or power loss may, when waking up, be used to re-construct the "proper" table (i.e. reflecting a current state of the system) This is carried out by concurrently maintaining in flash memory an events log.
  • Lasser '056 requires maintaining an events log in the flash memory. While in some flash management systems this is not a real drawback because an events log is already maintained for other reasons, there are many flash management systems in which an events log is not otherwise required, making the use of the methods of Lasser '056 costly in write performance. There is thus a widely recognized need for, and it would be highly advantageous to have, a method and system that can provide a method for fast wake-up of a flash memory system, without compromising the integrity of the flash data structures and without sacrificing performance.
  • block is defined as the smallest unit of the flash memory that can be erased in a single operation.
  • page is defined as the smallest unit of flash memory that can be written (also called “programmed” for historical reasons) in a single operation. Typically, a block contains many pages.
  • flash management system and “flash file system” are synonyms and are used interchangeably.
  • Each of these terms refers to a software module that manages the storage of data in a flash memory device, regardless whether the interface exported by the module is file- oriented (with commands like “open file” or “write file”) or block-oriented (with commands like “read block” or “write block”), and regardless whether the software module runs on a controller dedicated solely for flash management or on the same host computer on which the applications using the storage system are running.
  • a "flash management table” is any table containing data used by a flash management system for supporting the operation of the flash management system algorithms, where the data in the table at any specific point in time represents some aspect of the state of the flash memory system at that specific time.
  • the flash management table is a table containing a bit per each block of the flash memory, with the bit indicating whether or not the corresponding block is free to be used
  • the contents of the table at a first point of time are a first pattern of bits that represents the aspect of the state of the system regarding which of the blocks are free and which are not free at that time.
  • the pattern of bits in that table could be the same, or may be different than in the first point, implying a different mix of free and non-free blocks caused by some free blocks becoming non-free and some non-free blocks becoming free.
  • an “event” is any write request, erase request, or housekeeping request, to the flash memory from an entity that controls the flash memory.
  • the entity could be a flash memory controller as illustrated below in Figure 1, a general purpose CPU as illustrated below in Figure 5, or a flash memory controller and a general purpose CPU acting cooperatively, as illustrated below in Figure 6.
  • a "selected event” is an event selected by the flash memory system designer to generate one or more updates to one or more memory management tables.
  • the present invention includes a method, for achieving the above need, that stores in flash memory information related to future events of the flash memory system. For example, when storing into flash memory the current value of a virtual-to- physical address translation table, the system also stores with the table a list of the next few physical blocks that are to be used in the future when events in the system will require allocation of new free physical blocks. At a later time an event in the system (such as a write request) may cause the allocation of a new physical block that is to replace another physical block as the corresponding block of some virtual block, resulting in a change in the state of the address mapping flash management table.
  • an event in the system such as a write request
  • the flash management system will allocate as the newly assigned block the block that is at the head of the stored list. After completing the handling of the write request the stored copy of the table is no longer up-to-date, as the mapping of the virtual block effected by the write operation is out-of-sync with the true state of the system.
  • the stored copy of the management table is first loaded.
  • the table correctly reflects the state of the system, as it is possible that a few events prior to the system's shut-down caused several incompatibilities between the stored table and the correct table.
  • the "future information" stored in the flash memory and associated with the stored table provides enough information for correcting the stored table and reconstructing the correct up-to-date version of the table.
  • the method of the current invention requires only a few flash memory accesses as only blocks in the "future list" are examined, and typically only some of the blocks are actually examined according to the above logic. Therefore, the present method for generating an up-to-date version of a flash management table from an out-dated version of the table is much faster than a full reconstruction of the table by a full scan of all flash memory blocks.
  • the present invention can be looked at as an analog of the method of Lasser '056. Both methods reconstruct an up-to-date version of a management table from a stored copy of the table with the help of additional flash-stored information. But while in Lasser '056 the additional data are an events log, in the present invention the additional data are a list related to "future events". In Lasser '056 the additional information is stored at a time that is later than the time of storing the table into flash memory, while in the present invention the additional information is, typically, stored at the same time the table is stored into flash memory.
  • a method of maintaining data structures of a memory system in accordance with events of the system including the steps of (a) storing, in a nonvolatile memory of the memory system, at least a portion of at least one management table whose contents indicate a state of the memory system at a first point in time; (b) storing in the nonvolatile memory a future information data structure including a plurality of records related to events of the memory system expected to occur subsequent to the storing of the information data structure; and (c) at a second point in time subsequent to the first point in time, handling an event in accordance with the future information data structure.
  • the nonvolatile memory is a flash memory.
  • the storing of the at least a portion of the at least one management table includes updating the at least a portion of the at least one management table in the nonvolatile memory.
  • the storing of the at least a portion of at the at least one management table, whose contents indicate the state of the memory system at the first point in time also includes storing the at least a portion of the at least one management table in a volatile memory of the memory system.
  • the updating is effected every N>1 times that one of the at least a portion of the at least one management table is changed in the volatile memory.
  • Other ways of doing the updating include in response to selected events, updating periodically, and updating according to availability of resources of the memory system.
  • the future information data structure includes a list of blocks of the nonvolatile memory that are free at the first point in time.
  • a method of waking up a memory system including the steps of: (a) reading, from a nonvolatile memory of the memory system, at least a portion of at least one management table describing a state of the memory system at a point in time prior to the waking up; (b) reading, from the nonvolatile memory, a future information data structure including a plurality of records related to events expected to occur subsequent to a storing of the future information data structure; and (c) updating the at least portion of the at least one nonvolatile management table in accordance with at least one record of the future information data structure.
  • the nonvolatile memory is a flash memory.
  • the updating changes the at least a portion of the at least one management table to describe a current state of the memory system.
  • the updating is conditional. For example, if the exit was orderly, the update need not be done.
  • the method further includes the step of comparing the a plurality of records to the nonvolatile memory to determine whether the state of the memory system has changed since the point in time, the updating then being conditional on the state of the memory system having changed since the point in time.
  • a memory module including (a) a first nonvolatile memory; and (b) a controller of the nonvolatile memory that is operative to manage the first nonvolatile memory by steps including (i) storing in the first nonvolatile memory at least a portion of at least one management table whose contents indicate a state of the memory system at a first point in time, (ii) storing in the first nonvolatile memory a future information data structure including a plurality of records related to events of the memory system expected to occur subsequent to the storing of the future information data structure, and (iii) at a second point in time subsequent the storing of the future information data structure, handling the event in accordance with the future information data structure.
  • the module further includes a second nonvolatile memory; and the controller is operative to effect the steps by executing code stored in the second nonvolatile memory.
  • a memory system including: (a) a memory module including a nonvolatile memory; and (b) a host, of the memory module, that participates in managing the nonvolatile memory by steps including: (i) storing in the first nonvolatile memory at least a portion of at least one management table whose contents indicate a state of the memory system at a first point in time, (ii) storing in the first nonvolatile memory a future information data structure including a plurality of records related to events of the memory system expected to occur subsequent to the storing of said information data structure, and (iii) at a second point in time subsequent to the storing of the future information data structure, handling an event in accordance with the future information data structure.
  • the steps are effected only by the host.
  • the memory module also includes a controller that cooperates with the host to effect the steps.
  • a memory module including: (a) a first nonvolatile memory; and (b) a controller of the nonvolatile memory that is operative to wake up the memory module by steps including (i) reading, from the first nonvolatile memory, at least a portion of at least one management table describing a state of the memory module at a point in time prior to the waking up (ii) reading, from the nonvolatile memory, a future information data structure including a plurality of records related to events expected to occur subsequent to the point in time; and (iii) updating the at least a portion of the at least one flash management table in accordance with at least one record of the future information data structure.
  • the memory module further includes: a second nonvolatile memory; and the controller is operative to effect the steps by executing code stored in the second nonvolatile memory.
  • a memory system including: (a) a memory module including a nonvolatile memory; and (b) a host, of the memory module, that participates in managing the nonvolatile memory by steps including: (i) reading, from the nonvolatile memory, at least a portion of at least one management table describing a state of the memory system at a point in time prior to the waking up;
  • the steps are effected only by the host.
  • the memory module also includes a controller that cooperates with the host to effect the steps.
  • a computer-readable storage medium having computer-readable code embodied therein for maintaining data structures of a memory system in accordance with events of the system, the computer-readable code including: (a) program code for storing, in a nonvolatile memory of the memory system, at least a portion of at least one management table whose contents indicate a state of the memory system at a first point in time; (b) program code for storing in the nonvolatile memory a future information data structure including a plurality of records related to events of the memory system expected to occur subsequent to the storing of the future information data structure; and (c) program code for: at a second point in time subsequent to the storing of the future information data structure, handling the event in accordance with the future information data structure.
  • a computer-readable storage medium having computer-readable code embodied therein for waking up a memory system
  • the computer-readable code including: (a) program code for reading, from a nonvolatile memory of the memory system, at least a portion of at least one management table describing a state of the memory system at a point in time prior to the waking up; (b) program code for reading, from the nonvolatile memory, a future information data structure including a plurality of records related to events expected to occur subsequent to a storing of the future information data structure; and (c) program code for updating the at least a portion of the at least one management table in accordance with at least one record of the future information data structure.
  • FIG. 1 is a block diagram of an exemplary flash memory system in accordance with some embodiments of the present invention.
  • Figures 2A-2B provide an illustration of an exemplary translation table in accordance with some embodiments of the present invention
  • Figure 3 is a flow-chart of the maintaining in flash memory of a flash management table and a future information data structure in accordance with an embodiment of the present invention
  • Figure 4 is a flow chart of an exemplary routine for waking up.
  • Figures 5 and 6 are block diagrams of more exemplary flash memory systems in accordance with some embodiments of the present invention. DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • the presently disclosed methods, systems and computer-readable codes for maintaining data structures are useful for facilitating a "fast-wakeup" of the flash memory system, for example, in environments in which frequent power failures are encountered. Nevertheless, this should not be construed as a limitation of the present invention, and is merely disclosed as one non-limiting application of the presently disclosed techniques for maintaining flash memory system data structures.
  • presently disclosed techniques are used to provide a fast wake-up of a flash management system, even under conditions in which unexpected power failures frequently occur, without sacrificing data integrity.
  • FIG. 1 is a block diagram of a non-limiting exemplary flash memory system 100 in accordance with some embodiments of the present invention.
  • Exemplary system 100 includes a memory module 120 for storing data, and a host device 110 (examples of host device 110; a microcomputer, a smart card terminal, digital camera, cellular phone, PDA or any other device) that communicates with the memory module 120 via a host interface 180.
  • host device 110 examples of host device 110; a microcomputer, a smart card terminal, digital camera, cellular phone, PDA or any other device
  • Memory module 120 includes a flash memory 130 that may be of any type, as well as a controller 140 that accesses flash memory 130 in accordance with read and/or write requests received through host interface 180.
  • controller 140 includes a CPU 150, a ROM 160 (where the code executed by CPU 150 is stored), and a RAM 170 that is used by the CPU 150 for supporting the execution of the code by controller 140.
  • This block diagram of the non-limiting example Figure 1 is representative of typical nonvolatile storage modules, such as SecureDigital flash memory cards or portable USB flash drives.
  • FIG. 5 is a block diagram of another non-limiting exemplary flash memory system 220 in accordance of some embodiments of the present invention.
  • Exemplary flash memory system 220 includes a general purpose CPU 250, a RAM 260, the flash memory 280, a bus interface 290 to flash memory 280, a boot ROM 270, a storage medium device 300, and a bus 240 that interconnect the various other components with each other.
  • system 220 powers up, the system bootstraps from ROM 270, then computer code and data are loaded from storage medium 300 into RAM 260. Also loaded from storage medium 300 is emulation code that controls flash memory 280.
  • Bus interface 290 accesses flash memory 280 according to read and/or write requests received from CPU 250.
  • Storage medium 300 is an example of a computer-readable storage medium bearing computer code for implementing the methods of the present invention.
  • storage medium 300 is a hard disk or a flash memory device.
  • Other examples of such computer-readable storage media include CDs, DVDs, diskettes etc.
  • this exemplary flash memory system 220 has no flash memory controller (that controls the flash memory system). Instead, the CPU 250 loads controller emulation code from mass storage 300 to RAM 260 and then CPU 250 executes the code from RAM 260 emulating the controller 140 in Figure 1. Savings of flash management tables and their recovery and reconstruction upon power up and other flash management functions are all performed by emulation code executed by CPU 250.
  • FIG. 6 in the drawings, is a block diagram of another non-limiting exemplary flash memory system 320 in accordance of some embodiments of the present invention.
  • Exemplary system 320 includes a general purpose CPU 350, a RAM 360, a flash memory module 330, a flash memory controller 310, flash memory 380, a bus interface 390 to the flash memory module 330, a boot ROM 370, a storage medium 400, and a bus 340 that interconnect the various other components with each other.
  • system 320 powers up, the system bootstraps from ROM 370, then computer code and data are loaded from storage medium 400 into RAM 360. Also loaded from storage medium 400 is emulation code that controls flash memory module 330.
  • Bus interface 390 accesses flash memory 380 according to read and/or write requests received from CPU 350.
  • storage medium 400 is an example of a computer-readable storage medium bearing computer code for implementing the methods of the present invention.
  • this exemplary flash memory system 320 also has, in flash memory module 330, a flash memory controller 310 that cooperates with CPU 350 to control flash memory system 380.
  • CPU 350 loads controller emulation code from storage medium 400 to RAM 360 and then CPU 350 executes the code from RAM 360 emulating some of the controller 140 functions in Figure 1. Saving of flash management tables and their recovery and reconstruction upon power up and other flash management functions are performed jointly by controller 310 and CPU 350.
  • flash memory system 100 typically stores one or more flash management tables in a volatile memory, for example, in RAM 170 of memory module 120, in RAM of host device 110, or in some other appropriate location.
  • a flash management table is a translation table that provides an address translation from a virtual block number to a physical block number. This is a mapping that exists in many flash management systems, as for example in the system of US Patent 5,937,425. It is noted that the same concepts and methods are also applicable to many other types of flash management tables, for example, to an allocated blocks table that represents which blocks are currently allocated and are not free to be used and which blocks are not allocated, to a table that represents a mapping from a virtual block number into a group of one or more physical block numbers, etc.
  • the data stored in the flash memory may change, and various ancillary data related to the flash memory may also change.
  • the "state" of the flash memory system changes over time as different events (for example, write requests, housekeeping operations, etc) of the flash management system occur.
  • each flash management table represents one or more aspects of a total "state" of the flash management system.
  • any given flash management table or set of tables does not necessarily represent the full state of the system, just one or more aspects of the system, hi the example of a free blocks table mentioned above, the knowledge of which blocks are free and which blocks are not free is certainly not enough for defining the complete state of the system.
  • a non-free block may contain just a single used page, or some or all of the pages of a non-free block may be written with valid data. This is not reflected by the free blocks table but by either other flash management tables or by some other means, but still that table does represent an aspect of the system state and therefore falls within the definition of a flash management table.
  • a flash management table moves among a sequence of states, each state representing, at a given time, one or more aspects of the flash memory system at the time.
  • the aspect of the state of the system that is modeled by the table switches among discrete states with clear-cut transition points that correspond to events of the flash memory system.
  • the table is indexed by virtual block number and lists the physical block number that currently contains the data of the corresponding virtual block. In practical implementations there often is no need to allocate space for storing the virtual block
  • Now virtual block number 2 corresponds in the table to physical block number 777 and no longer to physical block 172.
  • the table has switched from a first state to a second state. Any change in the contents of a flash management table is defined as a state change of that table. It should be emphasized that it is not the case that every write operation occurring in the flash management system causes a change of state in all the flash management system's flash management tables.
  • Figure 3 is a flow chart of an exemplary routine
  • 'maintaining in flash memory' includes storing in flash memory.
  • maintaining in flash memory includes maintaining the table and/or relevant data for
  • the system is idle, and the system waits 206 for a next event.
  • the system waits 206 for a next event.
  • one or more tables typically are updated 214 in volatile memory in accordance with
  • this future information data structure contains a
  • each record including data affecting one future event of the
  • structure stored in flash memory includes information related to all events that have
  • One exemplary implementation of the future information data structure is an
  • a future information data structure may be stored in any location in flash memory, and not necessarily physically adjacent to the flash management table the future information data structure is associated with.
  • the flash management table(s) is/are saved 230 into flash memory for some but not for all events of the flash memory system (i.e. only for events for which a "save table” condition has been met 226 - this condition is discussed below).
  • an updated future information data structure is also saved 234.
  • the flash management table(s) saved in the flash memory is/are said to be "synchronized to a latest state" or "latest event" of the flash memory system.
  • the process in which the flash management table(s) is/are stored in flash memory after various events (but not necessarily after all events) is defined herein as “maintaining the table in flash memory.”
  • another version of the flash management table(s) (typically, each subsequent version indicative of a later state of the flash memory system) is thus stored in flash memory.
  • the "maintaining the table in flash memory” does not require that for any given moment the table most recently saved in the flash memory is synchronized with the current state of the flash memory system.
  • Inspection of Figure 3 indicates that there usually are periods of time during which the most recently stored flash memory table(s) are indicative of an earlier state of the flash memory system (i.e. a state of the system before more recent events occur in the flash memory system).
  • future information data structure may later be retrieved from the flash memory, for example, after power up of the flash system.
  • the saved flash management table(s) reflect(s) the most recent state (i.e. the aspect of the state represented in the table) of the system.
  • the flash management table of Figures 2A and 2B provides a mapping from virtual block numbers to corresponding physical block numbers. During system operation the state of the table changes whenever the flash management software allocates a free physical block to a given virtual block, at the same time freeing the previous physical block corresponding to that virtual block.
  • the future information data structure associated with that table is an ordered list of currently free blocks.
  • the list defines the exact order according to which free blocks will be allocated in the future. In other words, the next time the flash management software allocates a free block it is guaranteed that the flash management software will select the block at the head of the list. The second time the flash management software allocates a free block, it is guaranteed that the flash management software will select the block in the second entry in the list, and so on.
  • each physical block contains within itself the number of the virtual block that that physical block is currently assigned to. This fact allows the flash management software to reconstruct the present state of the table from the saved (and not up-to-date) version of the table and from the table's associated future information list, as is explained below in the discussion of the system's wake-up process.
  • any policy for determining what constitutes an event for which the updated table is saved into flash memory - i.e. the "save condition" of step 226 - is within the scope of the present invention.
  • the scope of the present invention includes a number of policies for determining when to save (an) updated flash management table(s) to flash memory in accordance with particular embodiments of the present invention.
  • N can be as small as 2 when the saving overhead is low, or N can be as high as 100 or even more, for example, when the saving overhead is high.
  • a counter variable is initialized to be zero. After each event, this counter variable is incremented. If the counter variable exceeds the pre-determined value N, one or
  • the "save table" condition is determined in accordance with the change of state triggered by a most recent event. For that purpose state changes are classified as either 'minor' changes or 'major' changes. Changes in the table state that are minor do not cause an immediate (i.e. before processing 210 the next event) saving of the table (i.e. the "NO" branch after step 226), while changes that are major do cause an immediate saving.
  • a non-limiting example for a classification of changes to minor and major in the case of a free blocks flash management table is that a change that changes a free block into a non-free block is considered minor, while a change that changes a non-free block into a free block is considered major.
  • the table(s) is/are saved periodically, whenever a predetermined time interval expires. There is typically a tradeoff between how often the table(s) is/are updated, and the amount of system resources expended in saving the flash management table(s) to flash memory. On the other hand, saving the management table(s) more often means that, on average, a table retrieved from flash memory during wake-up is more likely to be more updated, thereby providing for a faster wake-up. It is noted that any time interval is within the scope of the present invention. In exemplary non-limiting embodiments, the time interval is between a tenth of a second and 5 or more minutes.
  • the frequency of updating a table is determined in accordance with an availability of system resources, hi one example, when controller 140 handles many read/write/erase requests, or during a period of time when there are many housekeeping operations, the flash management table(s) is/are saved to flash memory less often, in order to conserve system resources.
  • the flash management table(s) is/are saved to flash memory less often, in order to conserve system resources.
  • Other embodiments for policies of when to save a flash management table to flash memory are also possible.
  • the accompanying future information data structure preferably should contain enough information to support the handling of all future events until the next saving will occur. It is advisable to provide a safety margin and prepare for more events than are expected to take place until the next saving.
  • the invention is not dependent on this to be the case and correctly handles all events even if eventually it turns out that all stored future information was already used and an additional event is received. In such a case we just do an immediate synchronization of the table to the flash, as if a "Save Condition" has been met. For simplicity, this case of running out of future information is not shown in Figure 3.
  • updated flash management table(s) i.e. (a) flash table(s) updated in accordance with most recent events of the flash memory system
  • flash management table(s) is/are saved to flash memory.
  • these flash management table(s) are then retrieved from flash memory.
  • embodiments provided by the present invention obviate the need to invalidate out of date tables as done in Lasser US 6,510,488.
  • Figure 4 is a flow chart of an exemplary wake-up routine in accordance with some embodiments of the present invention.
  • Figure 4 presents an exemplary wake-up routine in the context of the previous example of the table of Figures 2 A and 2B with the future information data structure being an ordered list of free blocks that are next in line for allocation.
  • the flash management system retrieves 414 the saved copy of a flash management table.
  • the flash management system retrieves 418 the associated future information list that was saved at a time that the flash management table was saved to the flash memory.
  • the flash management system gets 422 the first physical block number in the list, and also sets a pointer 426 to point to the first entry of the list.
  • the first block in the list should still be free. If, however, one or more state changes of the flash management table(s) occurred after the last saving of the table and before system shut down, then the first block in the list should now be in use.
  • the power-up flash management software can determine whether a physical block is currently in use or not. This can be determined independently of any flash management table by reviewing the contents of one or more control fields contained within the block. In some flash management systems it suffices to look for the "corresponding virtual block number" control field - if a valid virtual block number is specified there then the block is in use, and if the field does not contain a valid virtual block number then the block is not in use. In other flash management systems the determination of whether a physical block is currently free or not requires the review of more than a single control field, but in all cases such determination is relatively straight-forward and fast to do.
  • the flash management software can determine whether there is a discrepancy between the retrieved table and the "true" table that would reflect the system's present state.
  • the block's current corresponding virtual block number This allows us to update the table in RAM 438 to reflect the current correspondence between the virtual and physical block numbers.
  • the physical block indicated by the retrieved table to correspond to that virtual block (which is now known to have been replaced by the first block in the list) is no longer pointed to by the table as that physical block is not in use at the current time.
  • the pointer into the list is advanced 442 and the same process is repeated for the next physical block in the list. As long as the inspected block is found to be in use, the table in RAM is updated to reflect the event of allocating that block.
  • step 446 of saving the table to the flash memory is not really necessary in case it is found that no block from the future list was allocated, as in such case the stored table is already up-to-date. For simplicity this is not shown in Figure 4.
  • One benefit provided by certain embodiments of the present invention is that the reading of the saved copy of a flash management table plus the updating of the table for the events not yet reflected in the saved copy of the table typically takes much shorter time than the re-creation of the table from scratch by scanning the many blocks of the storage system. If the system was shut down after saving the table before additional state changes occurred (for example if there is an orderly exit, or if we are "lucky" enough to shut down before any new events had occurred), then the wake-up time, in some embodiments, is fast, the same as in the method of Lasser '488 when an orderly shutdown takes place.
  • the wake-up time of the system may not be as bad as occurs in the method of Lasser '488 when there was no orderly shutdown. In many situations, only a few events have to be detected and their effects on the tables' state re-created. The exact time this takes typically depends on the number of entries that have to be handled from the future information data structure. This in turn may depend on the frequency with which the table is saved to non-volatile memory. The higher the frequency the fewer entries that are to be handled on average and the faster the wake-up on average. On the other hand, the higher the saving frequency the longer the time spent in
  • the present invention is similar in performance to the methods of Lasser '056. But this is so only when the overhead spent for writing the events log of Lasser '056 does not add extra overhead, as for example when the log is kept anyway for other reasons. When this is not the case, the use of the methods of the present invention provides better overall performance than Lasser '056 because the costly maintain of the log is no longer needed.
  • each flash management table is saved using the table's own saving policy, not necessarily at the same points in time.
  • each flash management table is reconstructed using the methods presented above, using the specific future information data of each flash management table. It is also possible that two or more tables share a common future information data structure, used for guiding the handling of incoming events with respect to those multiple tables.
  • the presently disclosed techniques may be implemented using any combination of hardware, firmware and software.
  • the saving of flash management tables and their recovery and reconstruction upon power up are all performed by controller 140, or
  • each of the verbs, "comprise” “include” and “have”, and conjugates thereof, are used to indicate that the object or objects of the verb are not necessarily a complete listing of members, components, elements or parts of the subject or subjects of the verb.
  • an element means one element or more than one element.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Techniques For Improving Reliability Of Storages (AREA)

Abstract

La présente invention concerne des procédés et des systèmes pour maintenir des structures de données en conformité avec les événements d'un système de mémoire non volatile. Au moins une partie de tables de gestion et une structure de données d'information future sont stockées dans une mémoire non volatile. La structure de données d'information future contient des fiches d'événements susceptibles de se produire suite au stockage de la structure de données d'information future. Lorsque les événements de mémoire flash se produisent, ces événements sont gérés selon la structure de données d'information future. Lors du réveil du système de mémoire, la/les table(s) de gestion est/sont récupérée(s) et les fiches de la structure de données d'information future sont comparées avec l'état de la/des table(s). La/les table(s) est/sont mise(s) à jour selon la structure de données d'information future.
PCT/IL2008/000062 2007-01-18 2008-01-16 Procédé et système pour faciliter le réveil rapide d'un système de mémoire flash WO2008087634A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE112008000180T DE112008000180T5 (de) 2007-01-18 2008-01-16 Verfahren und System für die Umsetzung eines Fast-Wakeup eines Flashspeichersystems
JP2009546065A JP5351046B2 (ja) 2007-01-18 2008-01-16 フラッシュメモリシステムの高速起動を容易にする方法およびシステム
KR1020097015437A KR101288408B1 (ko) 2007-01-18 2008-01-16 플래시 메모리 시스템의 고속 웨이크-업을 용이하게 하는 방법과 시스템

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US88541207P 2007-01-18 2007-01-18
US60/885,412 2007-01-18
US11/808,451 US7769945B2 (en) 2007-01-18 2007-06-11 Method and system for facilitating fast wake-up of a flash memory system
US11/808,452 US7721040B2 (en) 2007-01-18 2007-06-11 Method and system for facilitating fast wake-up of a flash memory system
US11/808,452 2007-06-11
US11/808,451 2007-06-11

Publications (1)

Publication Number Publication Date
WO2008087634A1 true WO2008087634A1 (fr) 2008-07-24

Family

ID=39243733

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IL2008/000062 WO2008087634A1 (fr) 2007-01-18 2008-01-16 Procédé et système pour faciliter le réveil rapide d'un système de mémoire flash

Country Status (1)

Country Link
WO (1) WO2008087634A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011180773A (ja) * 2010-02-26 2011-09-15 Toshiba Corp メモリシステム
JP2013506903A (ja) * 2009-10-01 2013-02-28 マイクロン テクノロジー， インク． 電源遮断管理
US9612954B2 (en) 2008-12-31 2017-04-04 Micron Technology, Inc. Recovery for non-volatile memory after power loss
US11307766B2 (en) 2020-03-25 2022-04-19 Silicon Motion, Inc. Apparatus and method and computer program product for programming flash administration tables

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5924113A (en) * 1995-07-31 1999-07-13 Lexar Media, Inc. Direct logical block addressing flash memory mass storage architecture
EP0973097A1 (fr) * 1997-12-05 2000-01-19 Tokyo Electron Limited Memoire et procede d'acces
WO2007072367A2 (fr) * 2005-12-21 2007-06-28 Nxp B.V. Memoire avec des emplacements effaçables par blocs
WO2007072313A2 (fr) * 2005-12-22 2007-06-28 Nxp B.V. Memoire a emplacements de blocs effaçables et chaine liee de pointeurs pour localiser des blocs avec informations de pointeur
WO2007072317A2 (fr) * 2005-12-21 2007-06-28 Nxp B.V. Memoire remanente a emplacements effaçables par blocs
WO2007096844A2 (fr) * 2006-02-27 2007-08-30 Nxp B.V. Mémoire avec emplacements effaçables par bloc

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5924113A (en) * 1995-07-31 1999-07-13 Lexar Media, Inc. Direct logical block addressing flash memory mass storage architecture
EP0973097A1 (fr) * 1997-12-05 2000-01-19 Tokyo Electron Limited Memoire et procede d'acces
WO2007072367A2 (fr) * 2005-12-21 2007-06-28 Nxp B.V. Memoire avec des emplacements effaçables par blocs
WO2007072317A2 (fr) * 2005-12-21 2007-06-28 Nxp B.V. Memoire remanente a emplacements effaçables par blocs
WO2007072313A2 (fr) * 2005-12-22 2007-06-28 Nxp B.V. Memoire a emplacements de blocs effaçables et chaine liee de pointeurs pour localiser des blocs avec informations de pointeur
WO2007096844A2 (fr) * 2006-02-27 2007-08-30 Nxp B.V. Mémoire avec emplacements effaçables par bloc

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9612954B2 (en) 2008-12-31 2017-04-04 Micron Technology, Inc. Recovery for non-volatile memory after power loss
US10552311B2 (en) 2008-12-31 2020-02-04 Micron Technology, Inc. Recovery for non-volatile memory after power loss
JP2013506903A (ja) * 2009-10-01 2013-02-28 マイクロン テクノロジー， インク． 電源遮断管理
TWI459399B (zh) * 2009-10-01 2014-11-01 Micron Technology Inc 電力中斷管理
US8990476B2 (en) 2009-10-01 2015-03-24 Micron Technology, Inc. Power interrupt management
US9874918B2 (en) 2009-10-01 2018-01-23 Micron Technology, Inc. Power interrupt management
US10564690B2 (en) 2009-10-01 2020-02-18 Micron Technology, Inc. Power interrupt management
JP2011180773A (ja) * 2010-02-26 2011-09-15 Toshiba Corp メモリシステム
US8583856B2 (en) 2010-02-26 2013-11-12 Kabushiki Kaisha Toshiba Memory system
US11307766B2 (en) 2020-03-25 2022-04-19 Silicon Motion, Inc. Apparatus and method and computer program product for programming flash administration tables

Similar Documents

Publication Publication Date Title
US7769945B2 (en) Method and system for facilitating fast wake-up of a flash memory system
USRE46446E1 (en) Method and system for facilitating fast wake-up of a flash memory system
US9910602B2 (en) Device and memory system for storing and recovering page table data upon power loss
US7711923B2 (en) Persistent flash memory mapping table
US8312204B2 (en) System and method for wear leveling in a data storage device
EP2329360B1 (fr) Gestion de données et de métadonnées de mémoire cache
US6938116B2 (en) Flash memory management method
US7562202B2 (en) Systems, methods, computer readable medium and apparatus for memory management using NVRAM
US20070094445A1 (en) Method to enable fast disk caching and efficient operations on solid state disks
US20100070747A1 (en) Managing cache data and metadata
US20030005219A1 (en) Partitioning cache metadata state
WO2007005859A1 (fr) Technique permettant d'ecrire en memoire non volatile
WO2007056106A2 (fr) Récupération après panne d’une mémoire non volatile
KR101392062B1 (ko) 고속 컴퓨터 시스템 파워 온 및 파워 오프 방법
WO2008087634A1 (fr) Procédé et système pour faciliter le réveil rapide d'un système de mémoire flash
EP2264602A1 (fr) Dispositif mémoire pour gérer la récupération d'une mémoire non volatile
CN109002265B (zh) 一种数据处理的方法以及相关装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08702643

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2009546065

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 1120080001804

Country of ref document: DE

WWE Wipo information: entry into national phase

Ref document number: 1020097015437

Country of ref document: KR

RET De translation (de og part 6b)

Ref document number: 112008000180

Country of ref document: DE

Date of ref document: 20091203

Kind code of ref document: P

122 Ep: pct application non-entry in european phase

Ref document number: 08702643

Country of ref document: EP

Kind code of ref document: A1

REG Reference to national code

Ref country code: DE

Ref legal event code: 8607