Because flash memory can be written to by individual locations, but can only be erased in much larger blocks (e.g., 256 KB blocks), updating a file may require that the file be modified by copying the block containing the file (or at least the block containing the portion of the file that is being modified) from flash memory to volatile memory, modifying the copy in volatile memory, and writing the modified copy to a new spare block of flash memory that was previously empty. Spare blocks are typically maintained in flash memory for just this use. Once the contents of an old block have been copied, modified, and placed into the spare block, the old block may be erased to become a new spare block, to be used in a future file update. Typically, each flash volume may have its own spare block, dedicated for the use of that volume. If the number of volumes in the flash memory is relatively large, and the number of updates is relatively small (or is concentrated in a small number of those volumes), a great deal of flash memory space may be unused and unavailable in the form of spare blocks that are seldom needed.
Some embodiments of the invention may be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:
In the following description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.
References to “one embodiment”, “an embodiment”, “example embodiment”, “various embodiments”, etc., indicate that the embodiment(s) of the invention so described may include particular features, structures, or characteristics, but not every embodiment necessarily includes the particular features, structures, or characteristics. Further, some embodiments may have some, all, or none of the features described for other embodiments.
In the following description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. Rather, in particular embodiments, “connected” may be used to indicate that two or more elements are in direct physical or electrical contact with each other. “Coupled” may mean that two or more elements co-operate or interact with each other, but they may or may not be in direct physical or electrical contact.
The term “processor” may refer to any device or portion of a device that processes electronic data from registers and/or memory to transform that electronic data into other electronic data that may be stored in registers and/or memory. A “computing platform” may comprise one or more processors.
As used herein, unless otherwise specified the use of the ordinal adjectives “first”, “second”, “third”, etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.
Various embodiments of the invention may be implemented in one or a combination of hardware, firmware, and software. The invention may also be implemented as instructions contained on a machine-readable medium, which may be read and executed by a computing platform to perform the operations described herein. A machine-readable medium may include any mechanism for storing, transmitting, or receiving information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), the interfaces and/or antennas that transmit and/or receive those signals; and others.
Various embodiments of the invention may share a spare block among multiple volumes, in a non-volatile memory that has block erase characteristics, such as but not limited to flash memory. Block erase characteristics refer to those types of memory whose write characteristics are such that individual bits may not be reset to a defined ‘erased’ state such as all ‘0’s (or all ‘1’s, depending on the convention being used) unless all the bits in a block of memory are reset to that state together. In some types of memory, such as but not limited to flash memory, these blocks may commonly be referred to as ‘erase blocks’.
Within the context of this document, a ‘block’ refers to an ‘erase block’, although the term ‘block’ might be defined elsewhere in other ways for other purposes. Although most of the examples herein refer to one spare block, in some embodiments more than one spare block may each be shared among the same multiple volumes. Within the context of this document, a ‘volume’ may be described as an organizational entity comprised of multiple blocks. However, other terms may be used outside this document to describe such an organizational entity, and the term volume may be used outside this document in other ways. Such differences in terminology should not be read as an artificial limitation on the scope of the appended claims.
The spare block may be used by any of the volumes for a block update process. If more than one volume requests use of the spare block, various priority schemes may be used to resolve which volume will obtain use of the spare block, such as but not limited to: 1) the first request gets to use the spare block, 2) volumes are assigned a priority for this purpose and the higher-ranking volumes wins, 3) update requests are assigned a priority for this purpose and the higher-ranking request wins, 4) etc.
Once a spare block has been identified, at 220 the contents of a block containing data that is to be changed (called the first block here for ease of identification) may be copied to an intermediate storage area in which the data may be modified without the block erase constraints. Such an intermediate storage area may be any feasible type of storage, such as but not limited to static random access memory (SRAM), dynamic random access memory (DRAM), etc. Such an intermediate storage may be located in any feasible location.
At 230 the data may be modified as needed in intermediate storage, and then the modified data may be written from intermediate storage to the previously-identified spare block at 240. Although in this example all the modification takes place while the data is in intermediate storage, in other embodiments the data may be modified as it is being transferred from the first block to intermediate storage, while it is in intermediate storage, while it is being transferred from intermediate storage to the spared block, or any combination of these. In addition to the modified data, the proper identification information may also be written into the spare block, identifying such things the volume, block number, type of block, etc. Once these operations have been performed, the block previously identified as a spare block may no longer be a spare block, and may no longer be identified as such.
At 250 the first block may be erased, and at 260 the new spare block may be identified. In some embodiments the recently-erased first block may be identified as the new spare block, a technique that may potentially allow all but one block in the non-volatile memory to be available for data at all times. In other embodiments another, previously erased, block may be identified as the new spare block, a technique that may allow the new spare block to be available for use without waiting for the first block to be erased, but which may require at least two blocks to be unavailable for data at any given time.
In some embodiments, operations 220-250 may be controlled partly or entirely by instructions executed by a processor, such as but not limited to those instructions in a software driver.
The update process may create memory blocks in a particular volume that are in different locations than before (e.g., in the location of the previous spare block), and may create new spare blocks that are in different locations than before (e.g., in a location that was previously part of a volume). In the process described above, where a spare block may be used by any of several different volumes, a spare block may eventually reside in any location that was previously occupied by any block of any of those volumes. Similarly, the individual blocks of a volume may eventually reside in any of the locations previously occupied by any of the other volumes. When the volumes collectively occupy multiple devices, both the volumes and the spare block may eventually be randomly arranged throughout the various devices.
The foregoing description is intended to be illustrative and not limiting. Variations will occur to those of skill in the art. Those variations are intended to be included in the various embodiments of the invention, which are limited only by the spirit and scope of the following claims.