JP2009503740A - Indexing file data in reprogrammable non-volatile memory that directly stores data files - Google Patents

Abstract

  The host system data file directly into the large erase block flash memory system, using the unique identifier of each file and the offset of the data in the file, but without using either the intermediate logical address or virtual address space of the memory Write. The memory system controller, not the host, maintains directory information about where the files are in memory in the memory system. Each data file is uniquely identified in a file directory, and this directory information points to entries in the file index table (FIT) of the data groups that make up the file and their physical storage locations in memory.

Description

  The present invention relates to the operation of a reprogrammable non-volatile memory system, such as a semiconductor flash memory, and more particularly to managing an interface between a host device and a memory.

  There are mainly two techniques for addressing data transmitted via external interfaces of host systems, memory systems, and other electronic systems. One of them is to map the address of the data file generated or received by the system to a separate range of contiguous logical address spaces set up for that system. Usually, the address space is wide enough to cover the entire address that the system can handle. As an example, a drive of a magnetic disk storage device communicates with a computer or other host system via such a logical address space. This address space is large enough to address the entire data storage capacity of the disk drive. The second of the two techniques uniquely identifies the data files that are generated or received by the electronic system, and theoretically addresses those data by offset within the file. This form of addressing method is used between a computer or other host system and a removable memory card known as a “smart card”. Usually, a customer uses a smart card to perform customer identification, banking, point-of-sales purchase, ATM access, and the like.

  In early generation commercial flash memory systems, a rectangular array of memory cells was divided into multiple groups of cells. Each storage data amount was a standard disk drive sector, that is, 512 bytes. Typically, each group further includes an additional amount of data, such as 16 bytes, and other possible data related to error correction codes (ECC) and memory cell groups that store user data and / or associated user data. Overhead data can be stored. The memory cells in each such group are the minimum number of memory cells that can be erased simultaneously. That is, the erase unit is the number of memory cells that are efficient for storing one data sector and any overhead data contained therein. Examples of this type of memory system are described in US Pat. Nos. 5,602,987 (Patent Document 1) and 6,426,893 (Patent Document 2). It is a feature of flash memory to erase memory cells before reprogramming with data.

  Flash memory systems are most commonly offered in the form of memory cards or flash drives that are removably connected to various hosts such as personal computers, cameras, etc., but are embedded in such host systems. In some cases. When writing data to memory, the host typically assigns unique logical addresses to sectors, clusters or other data units within the contiguous virtual address space of the memory system. Like a disk operating system (DOS), the host writes data to and reads data from addresses in the logical address space of the memory system. A controller in the memory system converts the logical address received from the host into a physical address in the memory array. In fact, the data is stored here, and then these address translations are always known. The data storage capacity of the memory system is at least as large as the amount of data that can be addressed for all logical address spaces defined for the memory system.

  In next generation flash memory systems, the size of the erase unit has increased to enough memory cell blocks to store a large number of data sectors. Even if the host system to which the memory system is connected performs data programming or reading in a small minimum unit such as a sector, a large number of sectors are stored in one erase unit of the flash memory. When a host updates or replaces a logical data sector, usually some data sectors in the block may not be used. Since all blocks must be erased before overwriting any data stored in the block, the new data is usually placed in another block that was previously erased but still has data storage capacity. Alternatively, update data is stored. This process frees up the original blocks with obsolete data that occupies valuable space inside the memory. However, if valid data remains inside, the block cannot be erased.

  Therefore, in order to make better use of the memory capacity of the memory, these pieces of fragmented data are made into erased blocks so that the blocks from which valid fragmented data is copied can be erased and their full storage capacity can be reused. It is common practice to consolidate or collect useful fragmentary data by copying. It is also desirable to copy the data to group the data sectors within the block in logical address order because this improves the data read speed and the speed at which the read data is sent to the host. If such data copying is performed quite frequently, the operating performance of the memory system is degraded. This is a typical case that affects the operation of the memory system, especially when the storage capacity of the memory is slightly above the amount of data that the host can address through the system's logical address space. In this case, data integration or collection may be required before the host executes the programmed command. As a result, the time for programming increases.

  In order to increase the number of bits of data stored in an arbitrary semiconductor region, the block size has increased with the generation of memory systems. Blocks that store more than 256 data sectors are common. Furthermore, in order to increase the degree of parallel processing when programming and reading data, two or four or more arrays or subarrays with different numbers of blocks are theoretically connected to form a metablock. It is often done to do. Thus, it is a problem to efficiently operate both operation units having a large capacity.

A common host interface for such a memory system is a logical address interface similar to that commonly used with disk drives. A file generated by the host to which the memory is connected is assigned a unique address in the logical address space of the interface. The memory system then typically maps data between the logical address space and the physical blocks or metablocks of the memory. Although the memory system always knows how to map the logical address space to physical memory, the host does not need to know this. The host always knows the address of its data file in the logical address space, but the operation of the memory system does not need to know about this mapping.
US Pat. No. 5,602,987 US Pat. No. 6,426,893 US Patent Application No. 11 / 060,248 US patent application Ser. No. 10 / 915,039 US Pat. No. 5,570,315 US Pat. No. 5,774,397 US Pat. No. 6,046,935 US Pat. No. 6,373,746 US Pat. No. 6,456,528 US Pat. No. 6,522,580 US Pat. No. 6,771,536 US Pat. No. 6,781,877 US Published Patent Application No. 2003/0147278 US Published Patent Application No. 2003/0109093 US Pat. No. 6,763,424 US patent application Ser. No. 10 / 749,831 US patent application Ser. No. 10 / 750,155 US patent application Ser. No. 10 / 917,888 US patent application Ser. No. 10 / 917,867 US patent application Ser. No. 10 / 917,889 US patent application Ser. No. 10 / 917,725 US patent application Ser. No. 11 / 192,220 US patent application Ser. No. 11 / 192,386 US patent application Ser. No. 11 / 191,686 US patent application Ser. No. 10 / 749,189 US patent application Ser. No. 10 / 841,118 US patent application Ser. No. 11 / 016,271 US patent application Ser. No. 10 / 897,049 US Patent Application No. 11 / 022,369 US patent application Ser. No. 11 / 196,869 US patent application Ser. No. 11 / 316,577 US patent application Ser. No. 11 / 382,232 US patent application Ser. No. 11 / 382,224

  Many techniques have been developed to overcome problems that occur reliably in various degrees when efficiently operating such large scale erase blocks in a flash memory system. In contrast, the present invention is based on a fundamental change, that is, a change in the interface for transferring data between the memory and the host system. By using the logical address in the virtual address space, the data file is identified by the file name assigned by the host, and the address in the file is offset, instead of performing data communication between the memory and the host system. To access it. The memory system then knows which host file each sector or other unit of data belongs to. The file unit described here is a data set ordered by a continuous offset address or the like, which is a data set generated and uniquely identified by an application program operating in the host computing system.

  This is not currently used in many of the commercially available memory systems because the host does not currently identify the file, but identifies the data to the memory systems in all files with a common set of logical addresses. It is because it is doing. Instead of using logical addresses, memory system controllers can store data so as to reduce the need for frequent data integration and garbage collection by identifying host data by file objects. Accordingly, the frequency of data copy operations and the amount of copy data are greatly reduced, thereby improving the data programming and reading performance of the memory system. Further, the controller of the memory system holds the directory and index table information of the memory block that stores the host file. This eliminates the need for the host to hold a file allocation table (FAT) currently required for managing the logical address interface.

  Instead, the data of the file is identified by the data group, and the position of the data group of the file in the memory is held in the file index table (FIT). As described more fully in previously incorporated patent applications, particularly US patent application Ser. No. 11 / 060,248, a data group consists of consecutive consecutive offset addresses and consecutive physical It contains data with both memory addresses. As described in previously incorporated patent applications, the valid data group indexes for each file are kept in the FIT at their offset addresses. By using the unique file identifier, an arbitrary file is accessed through the file directory. Next, the access to the FIT entry of the file becomes the physical position of the data group of the file.

  Typically, the host to which the memory system is connected operates with a preset maximum number of files that are open at one time, such as five files. In the event that a new file needs to be opened when the maximum number of files is already open, the host first closes the currently open file. Each time a file changes by writing, updating, or deleting additional data, the data group of the open file changes frequently. Typically, updating a file data group's FIT list requires reading the pages containing the file entries, modifying those entries, and then modifying the modified page to a different location in memory. If there is, typically, the erase page in the same memory block is rewritten. Thus, each time the page changes, the file directory must be able to point to the current page containing the FIT entry for the file.

  It is preferable to update the list of active file data groups without having to rewrite everything in the file directory. The technique of indirectly addressing the data group of an open file allows the file directory to remain pointing to the same location in memory when accessing the FIT entry of the file. Preferably, the logical addressing of the logical pointer contained in the last written page of the FIT entry containing the address of the page containing the file update FIT entry is preferably performed. Each time the FIT entry of the file is updated, the logical pointer changes, but the address of the file directory of the file does not need to change.

  However, such indirect addressing is not efficient when many files are stored in the memory system, as occurs when many small files are stored. This is because, of course, depending on their data storage capacity, directories and FIT pages can contain very many file entries at once. As a result, since the host was closed, files that are not currently active are preferably addressed directly to the index entry by the file directory. The feature of the logical address pointer with indirect addressing is not used.

  Thus, the combination of indirect addressing of FIT entries for files that are likely to change in the near future, such as open files, and direct addressing to closed files is a preferred mode of operation. That is, for open files that are active and data is being written or updated, the file directory should modify the set of active file index entries without having to modify the file directory. And indirectly define the FIT position of the set of index entries identified by the unique identifier of the file. In a specific example, this is accomplished by a file directory that addresses any location in memory that references the actual physical location of the file's index entry. This reference changes each time the index entry is updated and moved, but the file directory need not be updated. At the same time, for a closed file, the file directory directly defines the FIT position of the set of index entries identified by the unique file identifier. Relocating index entries for closed files is much less likely than for open files.

  Further, for use in direct addressing, preferably the index entry of the FIT page is limited to the data group of the file whose pointer to the FIT is contained in the same page of the file directory. Therefore, when updating one or more FIT entries of a file described in the directory page, only one page of the file directory needs to be updated. Otherwise, when updating one or more FIT entries of a file, multiple file directory pages must be updated frequently.

  Other aspects, advantages, features, and details of the invention are included in the following illustrative description, which is described with reference to the accompanying drawings.

  All patents, patent applications, papers, other publications, documents and matters referred to herein are effectively incorporated by reference herein in their entirety. Any discrepancies or inconsistencies in terms between publications, documents or matters that are defined or incorporated by reference and this application will become apparent from the terms used in this application.

Overview of Flash Memory System A typical flash memory system and a typical operation of a host device will be described with reference to FIGS. This is a system that implements various aspects of the invention. The host system 1 in FIG. 1 stores data in the flash memory 2 and retrieves data from the flash memory 2. Although it is possible to embed flash memory in the host, the memory 2 is a card of a more widespread form and can be removed from the host via connection parts 3 and 4 which are mechanical and electrical connectors. It is illustrated as being connected to. Currently, many different flash memory cards are commercially available. For example, compact flash (CF), multimedia card (MMC), secure digital (SD), mini SD, micro SD, memory stick, smart media and transformer. It is sold under the trademark Flash. Although these cards have unique mechanical and / or electrical interfaces due to their standardized specifications, the flash memory contained in each card is very similar. All of these cards are available from SanDisk Corporation, the assignee of the present application. SanDisk Corporation also sells a series of flash drives under the trademark Cruiser. This is a small package handheld memory system with a universal serial bus (USB) plug that connects to the host by connecting to the host's USB outlet. Each of these memory cards and flash drives includes a controller that interfaces with the host and controls the operation of the internal flash memory.

  The number of host systems using such memory cards and flash drives is large and varied. These include personal computers (PCs), laptops and other portable computers, mobile phones, personal digital assistants (PDAs), digital still cameras, digital video cameras and portable audio players. Hosts typically include one or more types of memory cards or built-in outlets for flash drives, although some require an adapter to connect the memory cards. A memory system typically has its own memory controller and driver, but some memory systems only accept control of software executed by a host to which the memory is connected. Of the memory systems provided with a controller, those embedded in a host often have a memory, a controller and a driver configured on one integrated circuit chip.

  The host system 1 of FIG. 1 can be regarded as being composed of a combination of circuits and software, which are two main parts, as long as the memory 2 is connected. These are the application 5 and the driver portion 6 that interfaces with the memory 2. In a personal computer, for example, the application 5 can include a processor that executes document creation, graphics, control, or other popular application software. For cameras, mobile phones or other host systems that primarily perform a set of functions, the application 5 can be operated so that the camera captures and stores images, the mobile phone makes calls, It also includes software that operates to receive.

  The memory system 2 of FIG. 1 includes a flash memory 7 and a circuit 8 that controls the memory 7 by exchanging data through an interface between the host connected to the card and the flash memory. The controller 8 typically converts between the logical address of the data used by the host 1 and the physical address of the memory 7 during data programming and reading.

  With reference to FIG. 2, a circuit of a typical flash memory system used as the nonvolatile memory 2 of FIG. 1 will be described. Typically, the system controller is implemented on one integrated circuit chip 11 connected in parallel with one or more integrated circuit memory chips via a system bus 13. One such memory chip 15 is shown in FIG. The particular bus 13 shown includes a separate set of conductors 17 for sending data, a set 19 for memory addresses, and a set 21 for control and status signals. Alternatively, one set of conductors may perform these three functions in a time division manner. Further, US patent application Ser. No. 10 / 915,039, filed Aug. 9, 2004, published patent application No. 2006/0031593, “ring bus structure and its use in flash memory systems (Ring It is also possible to use a system bus having another configuration such as a ring bus described in “Bus Structure and It's Use in Flash Memory Systems”.

  A typical controller chip 11 has its own internal bus 23 that interfaces with the system bus 13 via an interface circuit 25. Typically, the main functions connected to the bus are: a processor 27 (such as a microprocessor or microcontroller), a read only memory (ROM) 29 containing code that initializes ("boots") the system, a memory A random access memory (RAM) 31 used mainly for buffering transmission data between the host and the host, and an error correction code (ECC) for data exchanged between the memory and the host via the controller And a circuit 33 for calculating and verifying. The controller bus 23 interfaces with the host system via a circuit 35. This is done via the card's external contacts 37 that are part of the connector 4 in the case of the system of FIG. Each other component of the controller 11 connects to and uses the clock 39.

  Along with other components connected to the system bus 13, the memory chip 15 typically includes a memory cell array configured as a number of subarrays or planes. For simplicity of illustration, two such planes 41 and 43 are shown, but four or eight such planes may be used. Alternatively, the memory cell array of the chip 15 may not be divided into planes. However, when divided, each plane usually has column control circuits 45 and 47 that can operate independently of each other. Circuits 45 and 47 receive their respective memory cell array addresses from the address section 19 of the system bus 13, decode these addresses, and address specific one or more individual bit lines 49 and 51. I do. The word line 53 is addressed via the row control circuit 55 in accordance with the address received on the address bus 19. Source voltage control circuits 57 and 59 are also connected to their respective planes, like P well voltage control circuits 61 and 63. If the memory chip 15 has one memory cell array and there are more than two such chips in the system, each array of chips operates in the same way as the planes or sub-arrays in the multiplane chip described above. Will do.

  Data is exchanged with the planes 41 and 43 via data input / output circuits 65 and 67 connected to the data portion 17 of the system bus 13, respectively. Circuits 65 and 67 supply data for programming the memory cells and data to be read from the memory cells of each plane through lines 69 and 71 connected to the planes through column control circuits 45 and 47, respectively.

  The controller 11 controls the operation of the memory chip 15 and performs data programming, data reading, erasing, and various setups. Each memory chip also executes commands from the controller 11 to perform such functions. Includes some control circuits to do. The interface circuit 73 is connected to the control / state portion 21 of the system bus 13. Commands from the controller are supplied to the state machine 75, which then performs certain control of other circuits in order to execute these commands. As shown in FIG. 2, control lines 77-81 connect the state machine 75 to these other circuits. The state information from the state machine 75 is communicated to the interface 73 via the line 83 and transmitted to the controller 11 via the bus unit 21.

  Other architectures such as NOR may be used instead, but the NAND architecture of memory cell arrays 41 and 43 is currently preferred. An example NAND flash memory and their operation as part of a memory system are described in US Pat. Nos. 5,570,315, 5,774,397, 6, 046,935 (patent document 7), 6,373,746 (patent document 8), 6,456,528 (patent document 9), 6,522,580 (patent document 10), Reference may be made to US Pat. No. 6,771,536 (Patent Document 11) and 6,781,877 (Patent Document 12) and US Published Patent Application No. 2003/0147278 (Patent Document 13).

  FIG. 3 is a circuit diagram showing an example NAND array. This is a part of the memory cell array 41 of the memory system of FIG. A number of global bit lines are formed, but only four such lines 91-94 are shown in FIG. 3 for the sake of simplicity. A large number of series-connected memory cell strings 97 to 104 are connected between one of these bit lines and the reference potential. When the memory cell string 99 is used as a representative example, a plurality of charge storage memory cells 107 to 110 are connected in series with selection transistors 111 and 112 at either end of the string. When the selection transistor of one string is conductive, the string is connected between the bit line and the reference potential. Next, programming or reading is performed for each memory cell in the string.

  The word lines 115-118 of FIG. 3 individually extend for each charge storage element in each memory cell of multiple strings of memory cells, and gates 119 and 120 are connected to the select transistor at each end of the string. Control the state. A block 123 of memory cells to be erased at one time is constituted by a memory cell string sharing the common word line and the control gate lines 115 to 120. This cell block includes the minimum number of cells that can be physically erased at one time. Programming is performed once for one row of memory cells along one of the word lines 115-118. Typically, the NAND array rows are programmed in a predetermined order. In this case, we start with the row along the word line 118 closest to the end of the string connected to ground or another common potential. Programming is performed on the row of memory cells along the word line 117 and this is repeated one after another for the entire block 123. Finally, programming is performed on the row along the word line 115.

  The same applies to the second block 125. The memory cell string is connected to the same global bit line as the string of the first block 123, but the set of word lines and control gate lines is different. The row control circuit 55 drives the word line and the control gate gate line with these appropriate operating voltages. If there is more than one plane or sub-array in the system, such as planes 1 and 2 in FIG. 2, one memory architecture uses a common word line that extends between them. Alternatively, there may be more than two planes or subarrays that share a common word line. In other memory architectures, individual planes or sub-array word lines are driven separately.

  The memory system operates to store three or more detectable levels of charge in each charge storage element or region, as described in some of the previously incorporated NAND patents and published patent applications. As a result, two or more bits of data are stored. The charge storage elements of memory cells are usually generally conductive floating gates, or alternatively non-conductive dielectric charge supplemental materials as described in US Published Patent Application No. 2003/0109093. It can also be.

  FIG. 4 is a conceptual diagram showing a configuration of a flash memory cell array 7 (FIG. 1) used as an example. This will be further described below. Four planes of memory cells or subarrays 131-134 may be placed on one integrated memory cell chip, on two chips (two planes on each chip), or on four separate chips. Good. In the following description, the particular arrangement is not important. Of course, there can be other numbers of planes in the system, such as 1, 2, 8, 16 or more. Like the blocks 137, 138, 139 and 140 on the respective planes 131 to 134, the planes are individually divided into rectangular memory cell blocks shown in FIG. Each plane can be divided into tens or hundreds of blocks. As described above, the memory cell block is an erase unit of the minimum number of memory cells that can be physically erased at one time. However, since parallel processing is increasing, block operations are performed in large metablock units. One block from each plane is logically linked together to form a metablock. The four blocks 137 to 140 shown in the figure form one metablock 141. Typically, all cells in the metablock are erased together. As can be seen from the second metablock 143 formed from blocks 145 to 148, the blocks used to form the metablock need not be in the same relative position within each plane. Usually, it is preferable to extend metablocks to all of the planes, but to increase system performance, dynamically form metablocks from one, two, or three blocks of different planes, or all The memory system can be operated by the function. This makes it possible to closely match the size of the metablock with the amount of data that can be stored in one programming operation.

  As shown in FIG. 5, the individual blocks are sequentially divided into pages of memory cells for operation. For example, the memory cells of the blocks 131 to 134 are divided into eight pages P0 to P7. Alternatively, each block may be divided into pages of 16, 32 or more memory cells. A page is a unit for programming and reading data in a block, and includes a minimum amount of data to be programmed at a time. In the NAND architecture of FIG. 3, the page is formed from memory cells along the word lines in the block. However, such pages in two or more blocks may be logically linked to a metapage to improve parallel processing of memory system operations. FIG. 5 shows the metapage 151. This is composed of one physical page in each of the four blocks 131-134. For example, the metapage 151 includes the page P2 in each of the four blocks, but the pages of the metapage are not necessarily in the same relative position in each block.

  It is preferable to program and read the maximum amount of data in parallel on all four planes, but for higher system performance, either one, two or three pages in separate blocks on different planes or The memory system can also be operated to form all metapages. This allows programming and read operations to be adaptively matched with the amount of data that can be conveniently processed in parallel, reducing the possibility of remaining metapages that are not subject to data programming. .

  As shown in FIG. 5, the metapage constituting the physical pages of the plurality of planes includes memory cells along the rows of the word lines of the plurality of planes. Rather than programming all of the cells in a single word line row at the same time, more generally, the programming is done alternately in two or more alternating groups. Each group stores one page of data (in one block) or one metapage (across multiple blocks). By programming the memory cells alternately once at a time, it is not necessary to arrange one unit of peripheral circuit including the data register and the sense amplifier for each bit line, but rather in a time-sharing manner between adjacent bit lines. Process. This saves the amount of substrate space required for the peripheral circuitry and allows memory cells to be integrated at high density along the row. Alternatively, it is preferable to program each cell along a row simultaneously to maximize the parallelism possible with any memory system.

  Referring to FIG. 3, by placing two rows of select transistors (not shown) along at least one end of the NAND string, rather than placing one row as shown. Most conveniently, data programming is performed simultaneously for every other memory cell along the row. Then, in response to one control signal, one row of select transistors is connected to each other bit line for every other string in the block, and in response to another control signal, the other The select transistors in one row are connected to the respective bit lines so that every other string is sandwiched. Thus, two pages of data are written to each row of memory cells.

  Typically, the data amount of each logical page is one or more data sectors that are integers, and conventionally each sector contains 512 bytes of data. FIG. 6 shows two sectors 153 and 155 of a logical data page of data of one page or one metapage. Each sector typically includes a stored portion of 512 bytes of user or system data 157, and separate overhead data for either the portion 157 data, or the physical page, or the block storing it. It is included as a number of bytes 159. Typically, the number of bytes of overhead data is 16 bytes, for a total of 528 bytes for each sector 153 and 155. The overhead portion 159 includes the ECC calculated from the data portion 157 during programming, its logical address, the actual number of times the block was erased and reprogrammed, one or more control flags, the operating voltage level, etc. In addition, the ECC calculated from the overhead data 159 may be included. Alternatively, overhead data 159 or a portion thereof may be stored on a different page in another block.

  As memory parallel processing increases, the data storage capacity of metablocks increases and the size of data pages and metapages increases as a result. The data page includes three or more data sectors. There are two sectors per data page and two data pages per metapage, and there are four sectors per metapage. Therefore, each metapage stores 2,048 bytes of data. This is a high degree of parallel processing, and the degree becomes even higher as the number of memory cells in a row increases. For this reason, the width of the flash memory is increased in order to increase the data amount of one page and one metapage.

  The previously identified, physically small, reprogrammable non-volatile memory cards and flash drives are commercially available with 512 megabyte (MB), 1 gigabyte (GB), 2 GB and 4 GB data storage capacities, making the capacity even larger ing. FIG. 7 shows the most common interface between a host and such a mass memory system. The host processes data files generated or used by application software or firmware programs executed by the host. An example is a data file for document processing, and another example is a drawing file of computer aided design (CAD) software, which is often found in general computer hosts such as PCs and laptop computers. A document in the pdf format is also such a file. The still digital video camera generates a data file for each image stored in the memory card. The cellular phone uses data from a file on an internal memory card such as a telephone directory. The PDA stores and uses several different files such as an address file and a calendar file. In any such application, the memory card contains software that runs the host.

  A typical logical interface between the host system and the memory system is shown in FIG. The continuous logical address space 161 is large enough to constitute an address of all data stored in the memory system. Typically, the host address space is divided in units of data clusters. Each cluster may be designed such that any host system includes multiple data sectors, typically between 4 and 64 sectors. A standard sector contains 512 bytes of data.

  In the example of FIG. 7, three files 1, 2, and 3 are generated. Each file is generated as an ordered data set by an application program running on the host system and identified by a unique name or other criteria. The host assigns a fully available logical address space for file 1 that has not yet been assigned to another file. The file 1 shown in the figure is assigned to a continuous range of available logical addresses. Address ranges are generally assigned for a specific purpose, such as a specific range of software that operates the host, so these addresses are not used when the host assigns logical addresses to data However, the data cannot be stored.

  If the host later generates file 2, the host similarly allocates two different ranges of consecutive addresses in the logical address space 161, as shown in FIG. There is no need to assign files to consecutive logical addresses, but addresses may be fragmented between address ranges already assigned to other files. Next, for this example, it can be seen from the fact that another file 3 further generated by the host is assigned to other parts of the host address space not previously assigned to files 1, 2 and other data.

  By holding a file allocation table (FAT), the host keeps track of the memory logical address space. This holds the logical addresses assigned by the host to various host files after performing the conversion 160. The host frequently updates the FAT table when a new file is stored, another file is deleted, or a file is changed. The FAT table is typically stored in the host memory along with a copy stored in non-volatile memory that is updated from time to time. For copying, typically, the non-volatile memory is accessed through a logical address space like other data files. When deleting a host file, the host then deallocates the logical address previously assigned to the deleted file and updates the FAT table to indicate that it can be used with other data files.

  The host is irrelevant as to the physical location where the memory system controller selects and stores the file. A typical host knows only about its logical address space and logical addresses assigned to its various files. On the other hand, the memory system knows only through the typical host / card interface about a portion of the logical address space that wrote the data, but the logical address assigned to a particular host file, or host file. I don't know about the number. The controller of the memory system converts the logical address provided by the host for data storage or retrieval into a unique physical address in the flash memory cell array in which the host data is stored. Block 163 represents a work table for these logical-to-physical address translations, which is maintained by the memory system controller.

  The memory system controller is programmed to store data files in the blocks and metablocks of the memory array 165 in a manner that maintains system performance at a high level. In this figure, four planes or subarrays are used. Preferably, data programming and reading are performed with the maximum degree of parallelism that the system can execute across all metablocks comprised of blocks in each plane. Normally, at least one metablock 167 is allocated as a reserved block for storing operation firmware and data used by the memory controller. Another metablock 169, or multiple metablocks, may be assigned to store software running the host, host FAT table, etc. Most physical storage space is left for storing data files. However, the memory controller does not know how the host has allocated the received data between the various file objects. Typically, all that the memory controller knows by interacting with the host is that the corresponding physical address that the controller's logical-to-physical address table 163 holds the data that the host wrote to a particular logical address. It is to remember.

  In a typical memory system, the storage capacity of an extra block is provided in excess of the amount of data required to be stored in the address space 161. One or more of these extra blocks may be provided as redundant blocks to replace other blocks that fail during the lifetime of the memory. Logical grouping of blocks included in individual metablocks is usually performed for various reasons, such as replacing a defective block and a redundant block originally assigned to a metablock. Typically, one or more additional blocks such as metablock 171 are kept in the erase block pool. When the host writes data to the memory system, the controller translates the logical address assigned by the host to a physical address in the metablock of the erase block pool. Next, other metablocks that are not used to store data in the logical address space 161 are erased and designated as erase pool blocks that are used during the next data write operation. In a preferred form, the logical address space is divided into logical groups each containing the same amount of data as the storage capacity of the physical memory metablock, allowing one-to-one mapping of logical groups to metablocks.

  When the originally stored data is no longer used, the data stored at a specific host logical address is frequently overwritten with new data. Correspondingly, the memory system controller has written new data to the erase block and then modified the logical-to-physical address table for those logical addresses to store the data for those logical addresses. Identify new physical blocks. The block containing the original data at those logical addresses is then erased and made available for storing new data. If the storage capacity of a previously erased block from the erase block pool at the start of writing is not sufficient, it is necessary to frequently perform such erase before the current data write operation is completed. This will adversely affect system data programming speed. Typically, the memory controller learns that the host no longer uses data at any logical address only when the host writes new data to their same logical address. Therefore, many blocks of the memory store such invalid data for a certain period.

  In order to efficiently use the area of the integrated circuit memory chip, the size of the block and the metablock is increased. For this reason, a significant portion of the individual data write will store a smaller amount of data than the metablock storage capacity, often less than the block storage capacity. Typically, the memory system controller directs new data to the erase pool metablock, which prevents writing to a portion of the metablock. If the new data is an update of data stored in another metablock, preferably the remaining valid metapage data from other metablocks with logical addresses adjacent to those new data metapages Are copied to a new metablock in the order of logical addresses. Old metablocks may be kept on other valid data metapages. This will invalidate the data on a particular metapage in an individual metablock over time, replacing this data with new data at the same logical address written to a different metablock. .

  In order to maintain sufficient physical memory space for data storage across the entire logical address space 161, such data is periodically compressed or consolidated (garbage collection is performed). It is also desirable to keep the data sectors in the metablock in the same order as their logical addresses so that they can be as practical as possible. This is because it makes reading of continuous logical address data more efficient. Thus, data compression and garbage collection are typically performed for this additional purpose. Several aspects of memory management and use of metablocks upon receipt of partial block data updates are described in US Pat. No. 6,763,424 (Patent Document 15).

  Typically, data compression ignores metapages with invalid data in the process and reads all valid data metapages from the metablock and writes them to the new metablock. It is also preferable to arrange metapages with valid data in a physical address order that matches the logical address order of the stored data. The number of metapages that occupy the new metablock is less than the number that occupied the old metablock. This is because the metapage containing invalid data has not been copied to the new metablock. The old block is then erased and made available for storing new data. Next, the capacity of the added metapage obtained by the integration can be used for storing other data.

  During garbage collection, valid data metapages with contiguous or nearly contiguous logical addresses are collected from two or more metablocks and rewritten to another metablock. Usually there is one for the erase block pool. If all valid data metapages are copied from the original two or more metablocks, they are erased and used later.

  In particular, if data integration or garbage collection needs to be performed before commands from the host can be executed, data integration and garbage collection can be time consuming and affect the performance of the memory system. Typically, such operations are scheduled by the memory system controller and run in the background as much as possible, but these operations must be performed, so the controller must host until such operations are complete. Will have to send a busy signal. One example where host command execution can be delayed is that there is not enough previously erased metablocks in the erase block pool to store all the data that the host wants to write to memory, and data consolidation or garbage collection is required. Examples include clearing valid data in one or more metablocks first and then erasing. Therefore, it is noted that memory control is managed to minimize such confusion. Many such technologies are described in US patent application Ser. No. 10 / 749,831, filed Dec. 30, 2003, published patent application No. 2005/0144358, “Nonvolatile with large erase block”. Management of Non-Volatile Memory Systems Having Large Erase Blocks ”(Patent Document 16), US patent application Ser. No. 10 / 750,155 filed Dec. 30, 2003,“ Using Block Management System Non-Volatile Memory and Method with Block Management System "(Patent Document 17), US patent application Ser. No. 10 / 917,888, filed Aug. 13, 2004, published patent now published No. 2005/0141313 “Non-Volatile Memory and Method wit Using Memory Plane Array” h Memory Planes Alignment) "(Patent Document 18), U.S. Patent Application No. 10 / 917,867 (Patent Document 19) filed Aug. 13, 2004, which is currently published application No. 2005/0141312. US patent application Ser. No. 10 / 917,889, filed Aug. 13, 2004, published patent application No. 2005/0166087, “Non-volatile memory and method using phase program fault handling (Non- Volatile Memory and Method with Phased Program Failure Handling ”(Patent Document 20), US patent application Ser. No. 10 / 917,725, filed Aug. 13, 2004, published patent application No. 2005/0144365. “Non-Volatile Memory and Method with Control Data Management” (Patent Document 21), US patent application Ser. No. 11 / 192,220, filed Jul. 27, 005 “Non-Volatile Memory and Method with Multi-Stream Update Tracking” (Patent Document 22) No. 11 / 192,386, filed Jul. 27, 2005, Non-Volatile Memory and Method with Improved, with improved indexing for scratchpads and update blocks. Indexing for Scratch Pads and Update Blocks) "(Patent Document 23), US Patent Application No. 11 / 191,686, filed July 27, 2005" Non-Volatile Memory and Method Using Multi-Stream Update " and Method with Multi-Stream Updating) ”(Patent Document 24).

  One challenge to efficiently control the operation of a memory array with a large erase block is to match the number of data sectors being stored during any write operation with the capacity and boundaries of the memory block. And adjust. One approach is to use less than the maximum number of metablocks to store new data from the host if you need to store less data than fills all metablocks. Is to configure. The use of adaptive metablocks is described in US patent application Ser. No. 10 / 749,189, filed Dec. 30, 2003, published patent application No. 2005/0144357, “Adaptive Metablocks”. (Patent Document 25). For fitting the boundaries between the data blocks and the physical boundaries between the metablocks, see US patent application Ser. No. 10 / 841,118 filed May 7, 2004 of the currently published published patent application No. 2005/0144363. Patent Document 26), U.S. Patent Application No. 11 / 016,271 filed December 16, 2004, and published patent application No. 2005/0144367 currently published, “Data Run Programming” ( Patent Document 27).

  The memory controller also uses data from the FAT table. This is what the host stores in the non-volatile memory, and makes the operation of the memory system more efficient. One such use is to learn when data identified by the host is no longer used and the logical addresses are deallocated. Knowing this, the memory controller usually schedules the block containing such invalid data to be erased before the host learns by writing new data to be written to those logical addresses. Is possible. This is described in US patent application Ser. No. 10 / 897,049 filed Jul. 21, 2004, published patent application No. 2006/0020744, which is currently published, “Method of Retaining Data on Nonvolatile Memory Systems. And “Method and Apparatus for Maintaining Data on Non-Volatile Memory Systems” (Patent Document 28). Other techniques allow a host to write new data to memory in order to infer whether any write operation is performed on a single file, i.e., whether there are boundaries between multiple files. Includes performing pattern monitoring. US Patent Application No. 11 / 022,369 filed December 23, 2004, published patent application No. 2006/0020745, “FAT Analysis for Optimized Sequential Cluster Management”. (Sequential Cluster Management) "(Patent Document 29) describes the use of this type of technology.

  In order to efficiently operate the memory system, it is desirable for the controller to know as much as possible about the logical addresses assigned by the host to the data of individual files. Second, if the file boundaries are not known, the controller can store the data file in one metablock or metablock group rather than being distributed among multiple metablocks. As a result, the number and complexity of data integration and garbage collection operations are reduced. As a result, the performance of the memory system is improved. However, as described above, if the host / memory interface includes the logical address space 161 (FIG. 7), it is difficult for the memory controller to know much about the host data file structure.

  Referring to FIG. 8, the exemplary logical address host / memory interface already shown in FIG. 7 is shown in another manner. The host assigns a data file generated by the host to a logical address. Next, the memory system recognizes these logical addresses and performs mapping to the physical addresses of the memory cell blocks that actually store data.

Different types of interfaces between the file-based memory interface and the operating host and the memory system storing large amounts of data eliminate the need for logical address space. Instead, the host logically addresses each file with a unique file ID (or other unique reference) and an offset address of a data unit (such as bytes) within the file. This file address is passed directly to the controller of the memory system and stored in its own table where each host file's data is physically stored. This new interface can be implemented in the same memory system described above in connection with FIGS. The main difference from the above is the communication method performed by the memory system with the host system.

  This file-based interface to be compared with the logical address interface of FIG. 7 is shown in FIG. The identification names of the files 1, 2 and 3 and the data offset in the file of FIG. 9 are directly passed to the memory controller. Next, the memory controller function 173 converts the logical address information into a metablock physical address and a memory 165 metapage. The file directory always keeps track of the host file to which each stored sector, page or other unit file data belongs.

  A file-based interface to be compared with the logical address interface of FIG. 8 is also shown in FIG. The logical address space and host held in the FAT table of FIG. 8 are not shown in FIG. Rather, the data file generated by the host is identified to the memory system by the file number and the data offset in the file. Next, the controller of the memory system directly maps the file to the physical block of the memory cell array, and holds the file directory and index table information of the memory block storing the host file. The host does not need to maintain a file allocation table (FAT) currently required for managing the logical address interface.

  FIG. 11 is a block diagram outlining the main functions of the direct data file system executed by the firmware of the memory system executed by the processor and other circuits of the controller. This is an overall framework that assumes specific memory operations described below. A file-based interface 601 layer exchanges commands and data between the memory system and an external host system or a host application executing on the same memory card or flash drive. The host application performs three main functions of the memory system: writing a file, deleting a file, and reading a file. Data is stored in the flash memory array 603.

  Based on the file that identified the data, a file-to-block mapping function 605 organizes the storage of the data in the flash memory. For each file, limit the number of flash blocks that contain file data along with other file data. This minimizes the amount of irrelevant file data that must be reclaimed to free up unused data space generated when files are deleted or modified, resulting in performance In addition, the durability of the memory is improved. A physical memory cell block of the memory 603 is a basic unit of data management.

  A data buffering and programming function 607 temporarily stores file data from a location in the file interface or flash memory in the buffer memory, transfers the data to the flash memory, and updates the active block or temporary swap block of the file. Either controls the programming. Preferably, the start point of each file data group is directly aligned with the start point of the metapage in the flash memory. The structure of the logical metapage is already defined in the offset address space for each data group.

  A function 609 in FIG. 11 accesses the memory 603 and controls reading of data stored therein. By deleting the file data that is performed when the host instructs, the function 611 is updated with the file indexing information held by the function 613 and the record of the block of the function 615.

  The file data indexing 613 indexes individual files stored in the memory 603 based on the unique file identifier and the offset address of the data in the file. The data of each file is stored as a data set group having continuous logical offset addresses. The file directory identifies the position of the file index table (FIT) of the data group entry set for each individual file. The block record function 615 holds an ID of a block that has been erased, a block in which file data has been partially programmed, or a block that includes file data together with data that is no longer used.

  The main purpose of the garbage collection and data integration functions described above is to free up unused memory space for storing additional data. In garbage collection, valid data in a source block is copied from a block that also contains obsolete data to one or more destination blocks that have at least some space that has been erased. This consolidates valid data into a smaller number of blocks, so once the original source block is erased, the capacity occupied by the unused data is released. Data integration combines valid data from one partially filled block with valid data from another partially filled block, including erased but unused space . Most commonly, a partially filled block results from writing to a new file that is partially partially filled and closed with the last erased block. Once the data is merged, the source block containing the newly copied data, which becomes the duplicate data, is then erased and made available for storing new data.

  Both garbage collection and data integration operations are treated together here as block release. Function 617 releases the block by controlling the copying of valid file data from one physical block with an unprogrammed metapage or one that contains obsolete data to another block. This erases the original block, frees up unused space in the block, and makes this space available for storing new file data. The function 619 controls the number and period of block release operations to be adaptive based on the releasable capacity and the number of erase blocks. Blocks are released at a speed that is optimal for the speed at which new file data is written, in a manner that maintains good overall memory system performance.

  In the functional diagram of FIG. 11, the conversion layer 621 and the interface layer 623 are positioned above the file interface 601 and interface with the flash memory back-end system to control its operation. In this example, the interface layer 623 has a function of communicating data outside the memory system with a host or other device by one of three different protocols. The file interface 625 is the center of the description here, and identifies individual file data based on a unique file identifier and a logical offset address in the file. The object interface 627 is mainly used for exchanging data files between electronic devices, and the size of the file is usually known. Existing protocols for interface 627 include Microsoft Corporation's Media Transfer Protocol (MTP) and Picture Transfer Protocol (PTP). In this example, a backward compatible logic (LBA) interface 629 is also included. Data is sent via the interface 629 according to the protocol currently used by the flash memory card, similar to that of the magnetic disk drive system, and the host addresses the data to the logical address space of the defined memory system. Specify.

  The conversion layer 621 includes protocol adapters 631, 633 and 635. The functions of these adapters convert each of the interface protocols 625, 627, and 629 into a common protocol with the file interface 601. The conversion layer converts commands, data formats, etc. between different protocols. The LBA protocol adapter 635 further divides the logical address space of the memory system into static files. The file interface 601 then treats these files as separate files that communicate via interfaces 625 and 627 in the same manner. Details of the functions of the LBA protocol adapter 635 can be found in A. See US patent application Ser. No. 11 / 196,869 filed Aug. 3, 2005 by S. A. Gorobets. Information about the conversion layer 621 and the interface layer 623 can be further obtained from US patent application Ser. No. 11 / 316,577 filed Dec. 21, 2005 by inventor Alan Sinclair.

  When programming a new data file and loading it into memory, the data is written into the erased memory cell block. Starting from the first physical location within the block, the writing proceeds sequentially through the location of the block. Regardless of the offset order of the data in the file, the data is programmed in the order received from the host. Continue programming until all file data is written to memory. If the amount of data in the file exceeds the capacity of one memory block, programming continues to the second erase block when the first block is full. In the same manner as the first block, the second memory block is programmed sequentially from the first location until all the data in the file is stored or until the second block is full. The remaining data in the file may be programmed for the third block or the additional additional block. A plurality of blocks or metablocks storing data of one file need not be physically or logically contiguous. For simplicity, unless otherwise specified, the term “block” as used herein refers to an erase block unit or a plurality of blocks, depending on whether the metablock is used in a particular system. Is something to say about either.

  The state diagram of FIG. 12 shows the overall function of the memory operation shown in FIG. Considering an individual memory block, it can be in one of three states. These include erase block 641 and block 643 where valid file data is stored with no releasable capacity, erased pages that are not programmed and / or stored but no longer used (invalid And block 645 containing valid file data having a releasable capacity from the data. Function 647 writes data to the erased memory block, resulting in a category 643 or 645 block based on whether the resulting programmed block has releasable capacity. As indicated by function 649, when erasing a file, the block 643 containing the file data is converted to a block 645 having a releasable capacity. By releasing the unused storage capacity of the block 645, the function 651 returns these blocks to the state of the erase block 641 where new data is written.

  Referring to FIG. 13A, data file writing to the memory system is shown. In this example, the data file 181 is larger than the storage capacity of one block or metablock 183 of the memory system. This extends between the vertical solid lines. Accordingly, the portion 184 of the data file 181 is written to the second block 185. Although these memory cell blocks are shown physically contiguous, they need not necessarily be contiguous. Data from the file 181 is written as reception streaming from the host until all the file data is written to the memory. In the example of FIG. 13A, the data 181 is initial file data.

  A preferred way for the memory system to manage stored data and keep track of the state is to use variable-size data groups. That is, the file data is stored as a plurality of groups of data connected in a predefined order that forms a complete file. Preferably, however, by using a file index table (FIT), the controller of the memory system maintains the order of the data groups in the file. While writing as a data stream from the host, if there is a discontinuity in the logical offset address of the file data or the physical space for storing the data, a new data group always starts. An example of such a physical discontinuity is when the file data is full in one block and writing to another block begins. This is illustrated in FIG. 13A. The first data group becomes full in the first block 183 and the remaining portion 184 of the file as the second data group is stored in the second block 185. The first data group is indicated by (F0, D0). F0 is a logical offset when the data file starts, and D0 is a physical location inside the memory where the file starts. The second data group is indicated by (F1, D1). F1 is the logical file offset of the data stored when the second block 185 begins, and D1 is the physical location where the data is stored.

  The amount of data transferred through the host-memory interface may be described by a large number of bytes of data, a large number of data sectors, or other granularity. When communicating with a large memory system via the current logical address interface, the host often defines the file data with byte granularity, but then groups the bytes into 512-byte sectors. Or grouping into clusters for many sectors. This is usually done to simplify the operation of the memory system. Although the file-based host-memory interface described herein may use other units of data, the byte granularity of the original host file is generally preferred. That is, preferably, data offset, length, and the like are expressed not in sectors, clusters, etc., in bytes, but in the smallest reasonable unit of data. As a result, the capacity of the flash memory storage device according to the technique described here can be used more efficiently.

  Next, the new file written in the memory in the manner shown in FIG. 13A is represented by FIT in this order as an index entry (F0, D0), (F1, D1) sequence of the data group. That is, whenever the host system wants to access a particular file, the host sends the file ID or other identifier to the memory system, and then accesses the FIT to identify the data groups that make up the file. Identify. For convenience of operation of the memory system, these individual entries may also be included in the length <length> of the individual data group. When used, the memory controller calculates and stores the length of the data group.

  Preferably, as long as the host holds the file of FIG. 13A in an open state, the physical write pointer P is also held so that a position for further receiving data from the host and writing to the file can be defined. . Regardless of the logical position of the new data in the file, the new data in the file is written at the end of the file in the physical memory. The memory system allows a plurality of files, such as four or five files, to remain open at one time, and holds a write pointer P for each. Different file write pointers point to locations in different memory blocks. If the memory system has a limit on the number of open files that already exist, and the host system wants to open a new file, it closes one of the open files first and then opens the new file. open.

  FIG. 13B shows that the host adds data to the end of the file that was written before FIG. 13A but is still an open file. This indicates that the host system is adding data 187 to the end of the file. This is the end of the data of the file, and the second block 185 is being written. Since the additional data becomes a part of the data group (F1, D1), it further includes data. This is because there is no logical or physical address discontinuity between the existing data group 184 and the additional data 189. Therefore, the full file is still represented as a sequence of FIT index entries (F0, D0) and (F1, D1). The address of the pointer P is also changed to the end address of the stored additional data.

  FIG. 13C shows an example of the insertion of the data block 191 into the file written before FIG. 13A. The host has inserted the data 191 into the file, but the memory system is adding the inserted data to the end position 193 of the previously written file data. Although the host may close the file and later in the background, there is no need to rewrite the data in the logical order while inserting data into the open file. . This is because when one new group (F1, D3) is formed, all the inserted data is stored in the second memory block 185. However, by performing this insertion, it becomes the previous data group (F0, D0) of FIG. 13A, and is divided into two groups, a group before insertion (F0, D0) and a group after insertion (F2, D1). Divided. This is because a new data group must be formed whenever there is a logical discontinuity of data as occurs at the insertion start point F1 and the insertion end point F2. The group (F3, D2) is a result of the physical address D2 that is the start point of the second block 185. Even if stored in the same memory block, groups (F1, D3) and (F3, D2) are held separately. That is, the stored data offset is discontinuous. Next, the original file of insertion is represented in the memory system FIT in the order of data group index entries (F0, D0), (F1, D3), (F2, D1), (F3, D2). Note that it can be seen from the examples of FIGS. 13A, 13B, and 13C that all of the data in the memory can be used to write new files or new data for existing files.

  Instead of inserting data into the existing file shown in FIG. 13C, whenever data is inserted, the host may rewrite the file in the memory as a separate file. The memory system may then treat this separate file as a new file. The host then deletes the old file and the memory system can respond to the release of the space storing the old file whose data is no longer used.

  FIG. 13D shows another example of updating a portion of the data originally written in the manner shown in FIG. 13A. The data file portion 195 is an updated portion. Rather than updating and rewriting all the files in the memory system, an updated portion 197 of the file is added to the previously written data. The previously written data portion 199 is no longer used. After updating, the files are represented in the memory system FIT in the order of data group index entries (F0, D0), (F1, D3), (F2, D1), (F3, D2). One data group (F0, D0) in FIG. 13A is divided again into the portions shown in FIG. 13D. The group before the update part, the update part, and the group after the update part. Although it is desirable to free space 199 occupied by data that is no longer used, it is preferably done later, not as part of writing file data to memory. Typically, by performing such a release, the number of data groups of data of a specific file stored is reduced.

  To further illustrate the use of variable length data groups, several write operations involving a series of identical files are shown in order in FIGS. 14A-14E. First, as shown in FIG. 14A, the original file data W1 is written into two blocks of the memory system. Next, a file is defined by two data groups, a first group starting from the start of the physical memory block and a second group that must start after the boundary of the physical memory block. Next, the file in FIG. 14A is described by the following series of index entries (F0, D0) and (F1, D1) for the data group.

  In FIG. 14B, the host updates the file data written in FIG. 14A. The updated file data U1 is written immediately after the group (F1, D1) before the previous version of the update data is no longer used. The previous group (F0, D0) in FIG. 14A is shortened to become the group (F0, D0) after the change in FIG. 14B, and the previous group (F1, D1) is shortened to become the group (F4, D2). Become. Since the data overlap at the boundary of the memory block, the update data is written into the two groups (F2, D3) and (F3, D4). Some of the data is stored in a third memory block. The file is now described by the following series of index entries (F0, D0), (F2, D3), (F3, D4), (F4, D2) for the data group.

  FIG. 14C shows a further modification of the file of FIG. 14B in which the host inserts new file data I1. Since the inserted data overlaps the boundary of the memory block, the new groups (F5, D6) and (F6, D7) in FIG. 14C are stored in the next memory of the previous group (F4, D2) in FIG. 14B. The new data I1 is written. A fourth memory block is used. By inserting new data I1, the previous group (F0, D0) in FIG. 14B is divided into the shortened groups (F0, D0) and (F7, D5) in FIG. 14C. The following index entry sequences (F0, D0), (F5, D6), (F6, D7), (F7, D5), (F8, D3), (F9, D4), (F10, D2) describes the file.

  FIG. 14D shows another modification of the data file of FIG. 14C in which new data W2 is added to the end of the file. As a new group (F11, D8) in FIG. 14D, new data W2 is written immediately after the previous group (F10, D2) in FIG. 14C. The following index entry sequences (F0, D0), (F5, D6), (F6, D7), (F7, D5), (F8, D3), (F9, D4), (F10, A file is described by D2) and (F11, D8).

  FIG. 14E shows a second update to the open file that writes the updated file data U2 to the file of FIG. 14D. The update data U2 of FIG. 14E is written immediately after the previous group (F11, D8) of FIG. 14D where the previous version of the data is no longer used. The previous group (F9, D4) in FIG. 14D is shortened to become the changed group (F9, D4) in FIG. 14E, and the previous group (F10, D2) is not completely used. F11, D8) are shortened to form a new group (F14, D9). Update data is written into the new groups (F12, D10) and (F13, D11) in FIG. 14E that overlap the block boundaries. Thus, it is necessary to store the file in the fifth block. The following index entry sequences (F0, D0), (F5, D6), (F6, D7), (F7, D5), (F8, D3), (F9, D4), (F12, The file is described by D10), (F13, D11), and (F14, D9).

  Preferably, the offset of the data in each file is continuously maintained in the correct logical order after the file is created or modified as described above. Therefore, as part of the operation of inserting data into the file, for example, the offset of the inserted data performed by the host is continuous from the offset immediately before the insertion, and the data already in the file after insertion is inserted. Increment by the amount of data. Most commonly, updating an existing file results in data in any address range of the existing file that has been replaced with a similar amount of update data, so it is usually necessary to replace the data offset in the other file There is no.

  Note that all of the data allocation and indexing functions described above in connection with FIG. 13 are performed by the controller of the memory system. With the appropriate command, the host simply needs to communicate to send the file ID and the offset of the data in the file to the memory system. The rest is done by the memory system.

  The advantage of writing file data from the host directly into the flash memory in the manner described above is that the granularity or decomposition of the data stored in this way can be retained in the same way as the host data. When the host application writes file data with 1-byte granularity, for example, the data is also written into the flash memory with 1-byte granularity. Next, the data amount and position in the individual data group are measured by the number of bytes. That is, the same offset unit of data that can be addressed separately within the host application file can still be addressed separately within that file when stored in the flash memory. Next, any boundaries between data groups of the same file in the block are specified in the index table for the nearest byte or other host offset unit. Similarly, the boundaries between data groups of different files within a block are defined in host offset units.

  The term “sector” is used herein for a large block of memory and represents a unit of stored data associated with an ECC. A sector is also a minimum unit of data transfer to and from the flash memory. A “page” is used to represent a unit of memory cells in a block and is the smallest unit of programming. “Metapage” is used to represent a page that performs complete parallel processing of metablocks. A metapage is the largest unit of programming.

  From FIG. 14B and FIG. 14E, it can be seen that the update command results in a physical space that needs to store a file larger than the data amount in the file. This is because the data replaced by the update is still stored in the memory. Therefore, it is highly desirable to consolidate file data into a smaller physical storage space (garbage collection) by deleting invalid data that is no longer used. Therefore, other data can further use the storage space.

  It can also be seen that by inserting the data in FIG. 14C in addition to updating the file data in FIGS. 14B and 14E, the file data is stored out of order. That is, almost always logically positioned anywhere in the file, but when updating and inserting, updates and insertions are added to the end of the file stored in memory. This is an example in FIGS. 14B, 14C and 14E. Therefore, it is desirable to re-arrange the file data stored in the memory so that it matches the order of the offsets in the file. By continuously reading the pages and blocks, the file data is in the order of their offsets, so that the read speed of the stored data is improved. This maximizes the possible defragmentation of the file. However, in some cases, reorganizing file data to make reading more efficient, such as file data integration that frees one or more memory blocks and uses other data for storage, Less important to system performance. Therefore, reorganizing the data in the file is not usually done alone, as it does not provide the valuable benefits of adding factory management costs, but with little or no factory management costs. As part of the garbage collection operation.

  The file of FIG. 14E includes a data group (gray portion) that is no longer used and is stored in memory due to the two generated data updates U1 and U2. As a result, as can be seen from FIG. 14E, the amount of memory capacity used to store the file is considerably larger than the size of the file. Therefore, it is appropriate to perform garbage collection. FIG. 15 shows the result of garbage collection of the data file of FIG. 14E. Prior to garbage collection, the file occupies approximately 5 blocks of storage (FIG. 14E), but the same file after garbage collection is stored slightly beyond 3 memory cell blocks ( FIG. 15). As part of the garbage collection operation, data is copied from the block. First, writing to another erase block is performed, and then the original block is erased. When garbage collecting all files, the data is copied to a new block in the same physical order as the order of data logical offsets in the file. For example, after garbage collection (FIG. 15), updates U1 and U2 and insert I1 are stored in the same order as in the host file.

  Typically, file-based garbage collection will also create new and different data groups within the consolidated file. In the case of FIG. 15, a file is described by the following new index entry sequences (F0, D12), (F1, D13), (F2, D14), and (F3, D15) for the new data group. This is a much smaller number of data groups than those present in the file state shown in FIG. 14E. There is one data group for each memory cell block to which the file data is copied. As part of the garbage collection operation, the file index table (FIT) is updated to reflect the new data groups that make up the file.

  Note that copying from the data distribution of FIG. 14E to the data distribution of FIG. 15 requires a significant amount of data to be copied. Effective data is read from each block in FIG. 14E, and then written into the four erase blocks in FIG. This greatly simplifies the data group of the file to be used in the future, but it takes a considerably long time to copy the data. Therefore, garbage collection of file-based data is not performed. Instead, even when data is directly stored in a memory as a file, it is performed on a block basis. Garbage collection is performed on the block with the smallest amount of data, and then copied to another block to release unused capacity of the block. This was previously incorporated by reference in US patent application Ser. No. 11 / 382,232, “Reclaiming Data Storage Capacity in Flash Memories,” filed May 8, 2006 (patented). Reference 32).

  Therefore, in the state shown in FIG. 14E, the blocks holding the file data are not released to a plurality of blocks storing the same file data, but individually to the blocks. For example, if the effective data amount of the second block 002 in FIG. 14E is the smallest among the blocks of the memory system that are considered to perform the release operation at any time, then, as shown in FIG. The one data group is copied to another erase block 010. The new block includes one data group (F8, D16) and the remaining erased capacity of the block in which new data is written. The erased capacity is released from the block storing data in FIG. 14E. Next, the files (F0, D0), (F5, D6), (F6, D7), (F7, D5), (F8, D16), (F9, D4), (F12, D10), (F13, D11) ), (F14, D9), the file is described for the data group by the following index entry sequence. Based on the block release processing, the other blocks shown in FIG. 14E are not changed until the criteria for the release operation are individually satisfied.

Indexing File Data FIG. 17 shows the index entry sequence in the file index table (FIT) for a file at several different times 0, 2, 4, X and Y. These are the previously described sequences associated with FIGS. 14A, 14C, 14E, 15 and 16 respectively. Preferably, the FIT data is written by the memory controller without assistance from the host system, and the current state is maintained. When writing data to the memory system, the host system supplies the path name, file name, and offset of the data in the file, but the host is responsible for defining the data group or where to store it in the memory cell array. Not performed. In the entry of FIG. 17, numbers starting from 1 are assigned to the memory cell blocks of FIGS. 14A to 14E. Therefore, in the file in the state shown in FIG. 14C, for example, the third data group (F6, D7) is annotated in FIG. 17 to be stored in the block 004. The fourth block from the left, which is D7 bytes from the initial address of the block. Preferably, each entry in the table also includes the length of each data group.

  When the file change shown in FIG. 17 results in a modification to the data group of the file, or less frequently, the memory controller rewrites the index entry sequence for one file. The controller stores such changes in its memory and can make many writes to the flash memory at one time. There is only one set of valid indexes per file at any given time. This is a set of five indexes shown in FIG. 17 that define files at different times. The indices at times X and Y indicate the results of two different types of release operations. As described above, one is file-based and the other is block-based. When you need to program additional data to a file, read data from a file, or garbage collect data from a file or block that stores that data, the memory system controller sets the current index of the file. Is used. It may be used for other operations. Therefore, FIT is easy to use when storing individual file index entries in the order of their file offsets (Fx), but otherwise the controller must read the entries in a logical order. Can do. The most common reason for the memory controller to read an index entry for a particular file is during execution of a host command.

First Embodiment Performing Specific File Indexing Referring to FIG. 18, a unique file ID 201, which is a numerical value in a continuous set, of a file stored in a memory system operating directly with a data file interface Identify. The directory 203 includes one entry for each valid file stored in the memory device. Preferably, directory 203 is a flat hierarchy and does not support subdirectories. This allows the memory direct data file system to be independent of the operating system used by the host. File metadata (also known as file “attribute” information) for hierarchical directories that follow specific host operating system protocols, supported directly by the firmware layer outside the data file system and still supporting a flat directory structure Use with.

  In summary, the file data is stored as a data set group. Each of the file offset address space and the physical address space covers the entire continuous address executed at one time. Data groups within a set of files need not have a specific physical address relationship to each other. A data group is a set of file data having consecutive offset addresses of a file, and programming is performed with consecutive physical addresses of one memory block. Typically, the file is programmed as a number of data groups. The length of the data group can be between 1 byte and 1 block. A file index table (FIT) 205 records the positions of valid data groups of the file to be identified in the order of offset addresses. A set of FIT entries of a file is known as an FIT record, and is specified by an entry in the directory 203.

  The FIT 205 has two components, an active file index block 207 and one or more inactive file index table blocks 209. The FIT record of the active file in the direct data file device is arranged in the active file index block 207. As described below, the directory 203 performs indirect addressing for this block, so that it is possible to modify the FIT record of the active file without having to update the entry of the directory 203 of those files. Become. For the inactive file, the file directory 203 directly addresses the FIT record to the inactive file index block 209. In any case, the position of the data group 211 that constitutes the file that is individually designated by the unique file ID 201 is designated by the FIT record. For reference, each data group may be programmed with a header that includes the file ID of the partial file. As indicated by reference numeral 213 in FIG. 18, the FIT record of the file may be modified so that it becomes necessary after releasing the block storing the file data.

  FIG. 19 shows a slightly expanded version of FIG. 18 in which common components are identified by the same reference numerals. A plurality of inactive file index blocks 209 are shown. The inactive FIT program block 209a has an erased memory page in which a new FIT record of a newly written data file is written. Once this block is full, it is designated as an inactive file FIT block 209b and a new erase block is designated as an inactive FIT program block. Typically, the file directory 203 points to the FIT records of all FIT blocks 207, 209a and 209b for each file ID held in the system.

  Whether an active file index block 207 or one of the inactive file index blocks 209 stores a FIT record for a particular file depends on whether the file is likely to be modified in the near future To do. If it is high, it is considered to be an active file holding the FIT record in block 207, and if not high, it is considered to be an inactive file holding the FIT record in one of blocks 209. It is done. If the memory system is operating with a host system that sends “open file” and “closed file” commands, the memory is active for all open files and inactive for all closed files. Is considered. Typically, a host using these commands maintains a number of open files that do not exceed a predetermined number, such as five. Thus, the data that the host wrote to the open file has its FIT record stored in block 207 and the FIT record of the closed file stored in one of blocks 209. .

  However, some hosts do not send open file commands and closed file commands to the memory system. In this case, by monitoring the writing of data to the file on the host, it is determined whether or not the memory system is likely to modify the file in the near future. Somewhere between the beginning and end of a storage block, if the host has finished writing a new data group, the most likely possibility is that the host will write to that file for at least a short time. This means that the data has been written. However, if the new data group ends with the end of the storage block, it is likely that the host has more data to write to the file. In this case, the memory system is most likely to define that the data group ends with the end of the storage block, and does not indicate that the host has completed writing the file data.

  The file directory 203 of the direct data file interface system includes one entry for each file ID supported by the system. A directory is organized as a set of consecutive entries corresponding to consecutive file ID values supported by the device. As shown in FIG. 20, an entry with a specified file ID can be directly accessed as a specific entry number in a specific logical page. There is no need to perform a directory search to find an entry for a specified file ID.

  The directory entry designates the position of the FIT record including the indexing information of the file data, together with the number of FIT entries constituting the FIT record. This is shown in FIG. 20 for fields 217 and 219, respectively. If the contents of field 217 point to a record of an inactive file, it contains the physical address of one of the blocks 209 storing the file's FIT record. However, if the file is active, field 217 contains a logical address that points to an intermediate location that remains the same as the update or change of the file's FIT entry, described below.

  The directory is composed of logical pages of P pages, and each page is composed of E directory entries. Therefore, the directory has a capacity of a P * E file. Directories are stored in one or more dedicated blocks. When there are D directory blocks, each includes a P / D logical page and has a capacity of a P / D * E file. The directory block is designated as DIR0 to DIR (D-1) based on the range of the logical page included. The number of directory blocks is determined from the maximum number of files that existed simultaneously on the device. If the existing block does not include the assigned file ID entry, the directory block is added. However, the directory may be compressed if the number of supported files is reduced.

  An example of a physical structure used for a directory block for updating a logical page will be described with reference to FIG. Each entry (between adjacent vertical dotted lines) contains a FIT record specification for a file ID or a null value indicating that no file with that file ID exists. If the number of data groups containing file data exceeds the maximum allowed number of FIT entries in the FIT record, a continuation file ID is assigned to the file so that the continuation FIT record can be used. The continuation file ID is specified in the directory entry of the main file ID assigned to the file. A directory is located in one or more dedicated blocks. The physical location of the directory block is defined in the directory block list in the control log of the control block.

FIG. 21 shows an explanatory diagram of the directory entry 225 including the following four fields.
1) FIT logical block # (227): This field identifies the FIT logical block number where the FIT record of the target file ID is located. The corresponding physical block address is defined by one of the FIT block pointers in the directory block. An example physical pointer 229 is shown in FIG. Field 227 points to one of the FIT block pointers. A FIT logical block N is reserved for the active file index block. A value of 0 in the FIT logical block number means that no file exists on the device.
2) FIT logical page # (231): This field identifies the logical page number in the active file index block 207 or inactive FIT block 209 (FIG. 19) where the FIT record of the target file ID is located. . The position of the FIT record stored in the active file index block 207 (FIG. 19) is the indirect address of the page where the record is located. In the case of the inactive FIT program block 209a or the inactive FIT block 209b, it is the direct physical address of the page.
3) FIT page entry # (233): This field identifies consecutive entry numbers in the page where the FIT record of the target file ID starts.
4) FIT entry # (235): If the first bit in this field is zero, this field specifies the number of FIT entries in the FIT record of the target file ID. When the first bit in this field is 1, the number of FIT entries of the target file ID exceeds the maximum number of FIT entries permitted in the FIT record. In this case, the field specifies the continuation file ID used for the file. In the continuation file ID directory entry, this field specifies the total number of FIT entries in both the target ID and continuation file ID FIT records.

The FIT block pointer of FIG. 21, which is an example of the pointer 229, specifies each FIT logical block existing in the apparatus. These are only valid for the last programmed page in the directory block. There is a FIT block pointer for each FIT logical block # present in the device. The following three fields are present in the FIT block pointer.
1) FIT block address (237): This field specifies the physical block address currently assigned to the FIT logical block # in the field 227 of the directory entry 225.
2) Valid FIT record # (239): This field specifies the number of valid files present in the FIT logical block.
3) FIT entry # (241) no longer used: This field specifies the number of FIT entries no longer in use present in the FIT logical block.

  The directory logical page pointer 243 (FIG. 21) functions as a logical to physical page mapping of the directory block. One pointer exists for each logical page in the block and specifies the current physical page address of the logical page. Directory page pointer entries are only valid for the most recently programmed physical page in the directory block.

  Update the directory in units of logical pages. Any number of entries in the logical page may be updated in one programming operation. The page may be read to update one or more entries and reprogrammed with the next available erase page in the directory block. The directory page pointer and FIT block pointer are reprogrammed simultaneously to specify the current values of all fields.

  When programming is performed on the last page of the directory block, the block is compressed and rewritten into an erase block. This becomes a new directory block. Before erasing a directory block that is no longer in use, compression is performed by copying all valid pages to the erase block as defined by the directory page pointer.

  The file index table (FIT) pointed to by the file directory includes a FIT entry string. Each FIT entry identifies the file offset address and the physical location of the data group in the flash memory. Preferably, the FIT contains entries for all valid data groups of files stored on the device. Data groups that are no longer used need not be indexed by the FIT. A set of FIT entries of data groups in the file is held in the file as consecutive entries in the order of offset addresses. A set of entries is known as a FIT record. The FIT is held in a set of FIT blocks along with the active file index block. The number of FIT blocks varies depending on the number of data groups in the device. During the operation of the device, a new FIT block is created and the FIT block is deleted.

  An example of the logical structure of FIT is shown in FIG. The FIT record 247 of a specific file is detected from the FIT block address 237 of the directory entry of the file and the FIT logical page # 231 (FIG. 21). Each FIT record contains a set of consecutive FIT entries for a data group in the file. Preferably, the set entries are consecutive in the order of file offset addresses.

Preferably, each FIT record of the file includes a FIT header 249 (FIG. 22) as the first entry of the FIT record. The fixed length of the FIT header is equal to an integer FIT entry. The three fields of the FIT header are as follows:
1) File ID: The file ID in the directory is identified by the file ID.
2) Program block: When the updated version of the FIT record is written to the FIT, the current physical position of the program block of the file is recorded in the FIT header. When the host reopens the file, it is used to detect the program block of the file. It may be used to check the correspondence between the FIT record and the program block of the file selected for program block integration.
3) Program pointer: When writing an updated version of the FIT record in the FIT, the current value of the program pointer in the program block of the file is recorded in the FIT header. When the host reopens the file or selects a program block for program block integration, this is used to define the location for programming data within the program block of the file.

Typically, a file's FIT record also has a number of entries that specify the physical location of the data groups that make up the file. One FIT entry 251 for an example file is shown in FIG. 22 along with others. Each FIT entry has the following four fields:
1) Offset address: The offset address is the byte representation offset within the file associated with the first byte of the data group.
2) Length: This defines the file data length in the data group in bytes. The length of the complete data group is longer than this value by the length of the data group header.
3) Pointer: This is a pointer indicating the position in the flash block where the data group begins. The pointer has two subfields: (1) a block address that defines the physical block that contains the data group, and (2) a byte address that defines the byte offset within the block where the data group begins. This address includes a data group header.
4) EOF flag: The EOF flag is one bit for identifying the data group at the end of the data file.

  FIG. 23 shows the physical format of the active file index block 207 (FIGS. 18 and 19). In the index block dedicated to the active file, the FIT record of the active file is updated. By storing only one FIT record of one or more entries for each page of the block and performing indirect addressing of the logical FIT record, it becomes possible to easily update the FIT record in the active file index block. . When the logical FIT record is updated, the entire available erase page is rewritten, and the logical page to physical page is mapped by setting the FIT page pointer of the page that has been programmed recently. . There is one logical FIT record for each file that is simultaneously active in the system.

  As described above, when the corresponding FIT logical block # 227 in the directory entry relates to the active file index block, the FIT logical page # 231 (FIG. 21) in the file directory entry of the file specifies the logical FIT record. . The logical FIT record is updated and rewritten in the active file index block without the need to update the file directory entry of the file. FIT logical page # 231 is an indirect address of the FIT record. As a part of the page including the updated FIT record, one of the sets of FIT logical page pointers 255 is updated and rewritten with respect to the physical page. , Mapping.

  A set of FIT page pointers 255 (FIG. 23) in a page programmed immediately after the active file index block 207 specifies a physical page on which a valid version of the logical FIT record is located. A null value of the FIT page pointer means that the FIT logical page # in the active file index block is not allocated. There is one FIT page pointer field for each active file that exists simultaneously on the device.

  When programming the last page of an active file index block, compressing the block and rewriting it into an erase block results in a new active file index block. Before erasing an active file program block that is no longer used, compression is performed by copying all valid pages to the erase block as defined by the FIT page pointer.

  When the active file becomes inactive by closing or the FIT record is copied to an inactive FIT program block described below, the data of the FIT record in the active FIT block is not used.

  The inactive FIT block becomes a storage area for FIT records of all data files stored in the memory system in addition to the currently active file. One FIT program block is a means for programming the FIT record in the FIT block. Referring to FIG. 24, details of the inactive file FIT program block 209a (FIG. 19) are shown. When programming is performed on all pages in the inactive FIT program block, this becomes the inactive FIT block 209b, and the erase block is assigned as a new inactive FIT program block.

  As shown in FIG. 24, addressing of each FIT record in the inactive FIT program block is performed directly from the directory. The FIT logical page # 231 (FIG. 21) in the directory entry directly points to the physical page in the inactive FIT program block, and the FIT page entry # 233 in the directory entry identifies the start point of the FIT record. Multiple FIT records may be stored on one page in the inactive FIT program block.

  Preferably, as shown in FIG. 20, all FIT records in the page of the inactive FIT program block of FIG. 24 must have a directory entry in the same logical page of the directory. This makes it possible to update the directory entries of all the FIT records in the inactive FIT program block page by one program operation in the directory block.

  If the file becomes active by opening, its FIT record is generated in the active file index block, or the file is deleted, all the FIT records in the inactive FIT program block are not used.

  When programming is performed on the last page of the inactive FIT program block of FIG. 24, an inactive FIT block 209b (FIG. 19) is generated.

  FIG. 25 shows an example of the operation of the FIT record. One such operation 261 writes data to the active file. When data is being written to the active file, an algorithm for programming the file data occasionally requests an FIT update. Programming the update FIT record of the file being written to the active file index block 207. As shown in FIG. 23 described above, since the indirect addressing method is used for the logical FIT record in the active file index block, it is not necessary to update the directory entry of the file.

  When an existing inactive data file or a new data file is opened or activated, as shown as function 263 in FIG. 25, the pointer is written in the FIT page pointer field in the block (see FIG. 23). The logical FIT record is assigned to the active file index block 207. If the file is an existing file, its FIT record is also moved from the active file index block 207 to its existing location in the FIT block 209b or FIT program block 209a. The FIT page pointer field and the FIT record may be written in one page programming operation in the active file index block 207. To update a directory entry for an open file or an active file, only one page in the directory needs to be updated.

  A state 265 in FIG. 25 shows a state where the data file is closed. When the file is closed and the active file becomes inactive, the FIT record is moved from the active file index block 207 to the FIT program block 209a. If the FIT program block 209a is programmed with a page containing this FIT record, preferably as many FIT records associated with the same directory page are moved from the FIT block to the same page of the FIT program block 209a. . This provides a garbage collection mechanism for FIT blocks containing FIT entries that are no longer used. Based on the number of unused FIT entries already included, it is necessary to select a source FIT block for moving such FIT records. The highest priority is given to the FIT block having the highest number of FIT entries that are no longer used. Preferably, FIT records are not moved from a smaller number of FIT blocks than a predefined number of unused FIT entries.

  The number of unused FIT entries in the FIT block is defined in the FIT block pointer field in the directory page where programming was performed last. It is necessary to program the directory page to update the entry of the moved FIT record and update the parameters in the FIT block pointer and directory page pointer fields. It is necessary to program the active file index block page and insert a null entry into the FIT page pointer of the logical FIT record moved from the block.

  Garbage collection operation 267 (FIG. 25) may relate to either garbage collection of FIT blocks or garbage collection of data files or data blocks. First, garbage collection of one of the FIT blocks 209b will be described. The erase operation of the FIT block needs to be performed occasionally in order to recover the capacity occupied by the FIT entry that is no longer used. Prior to erasing the FIT block, all valid FIT records are moved from the FIT block 209b to the FIT program block 209a. Performing the process described above for deactivating a file does not move all valid FIT records. Therefore, it is desirable to move from the FIT block that performs the FIT garbage collection process and erases all valid FIT records.

  Preferably, the FIT block with the highest number of FIT entries that are no longer used must be designated as the FIT garbage collection block and then FIT garbage collection operations must be performed on this block until all valid FIT records are moved. is there. Next, another FIT block is designated as the FIT garbage collection block. Select a page of the FIT garbage collection block to go to the FIT program block and, if available, fill the page with other FIT records from the FIT garbage collection block associated with the same directory page. If there is still space on the page to be programmed, it may be further filled with FIT records from other FIT blocks. Based on the entries in the associated directory page, it is necessary to make a selection of other FIT records that move with the selected page.

  Preferably, programming is performed on the directory page to update the entry of the moved FIT record and update the parameters in the FIT block pointer and directory page pointer fields. Preferably, the FIT garbage collection operation is scheduled and performed at the same time as the data garbage collection operation. Each time the data garbage collection page program operation is performed N times, the FIT garbage collection page program operation is performed once.

  Here, the garbage collection 267 of the data file or data block will be described. Data garbage collection operations require the FIT record of a closed or inactive file to be updated. This is done by incorporating the necessary updates and moving the FIT record from the FIT block to the FIT program block. Preferably, the page in which the FIT program block is programmed is filled with other FIT records associated with the same directory page.

Second Embodiment Performing Specific File Indexing Data is written to the direct data file memory system in the file object identified by the file ID, and the file address is specified in the file object by the logical offset address. Do. Data is stored as a data set group. Each group has a contiguous logical offset address and a contiguous physical location. File indexing associates file IDs and logical offset addresses with data group locations.

  The directory directly defines the position of the file object index entry in the file index table (FIT). Typically, direct indexing is used, but the indirect indexing method is also used, so that index entries for a file can be frequently modified without modifying the file directories that need to be done as a result. File indexing also supports storing separate file attribute information from file data.

  A file in the DFS device is a data object having one logical ID. A file is identified by a numerical file ID, and data in the file is identified by an offset address.

  In response to the command from the host, the DFS apparatus assigns a file ID value and generates a file object. The DFS system performs file indexing to track the physical location of the data within each file object and the physical location of the attributes of each file object.

  The file indexing hierarchy is shown in FIG. A directory entry for a file includes three main fields: a unique file ID and two pointers that point to other addresses in memory. The pointer 1 points to the FIT record of the file having the file ID in the FIT, and the pointer 2 points to the file attribute record (ATR) of the file. Preferably, the directory, FIT, ATR are stored in separate sets of blocks in the flash memory.

  The directory contains one entry for each file object that exists in the device. Entries are stored in ranges where the file ID values do not overlap each other and the ranges are assigned to different pages. Based on the file ID value, the entries within the range are ordered. By reading one page in the page and performing a binary search, the directory entry of the target file ID can be detected.

  In order to minimize the occupied space, the file index table (FIT) is directly addressed to each directory by entry. It consists of a collection of records that describe file objects organized into pages. The record of one page in the FIT is updated by a read / modify / write operation that moves the page to a position where the same or another FIT block is not programmed. All records of a page in the FIT are related to the same page entry in the directory, so updating the FIT page results in the need to modify only one page of a directory page. .

  A separate temporary file index table (TFIT) block can be used to store FIT records that will be modified in the near future. The record of the file object is stored in a logical page in TFIT, and indirect addressing is performed by a directory entry. It is possible to modify the record in the TFIT without having to update the directory.

  A file attribute record (ATR) is stored for the file object identified by the file ID. The contents of the attribute record are predefined by the host system and are not interpreted by the memory system. In general, whenever the host is deemed important or useful to operate with the memory system, the host can store the attributes of the file object in the ATR. The file attribute indexing method is the same as when using the file index table.

  An example set of file indexing structures used in a direct data file memory system is shown in FIG. The file directory DIR includes a collection of entries describing file objects identified by file IDs. There is an entry in the DIR, one for each file object that exists in the memory system. The DIR is included in one or more dedicated DIR blocks.

  Each DIR block contains a fixed number of logical pages. Each update is performed by rewriting the next available physical page. Assign a page containing a valid DIR entry to a logical page number. The number of logical pages in the DIR block is specified to be 25% of the number of physical pages in one block.

  After writing the last page of the DIR block, the block is compressed by writing all valid pages in the erase block and erasing the original DIR block.

  The DIR page includes a set of DIR entries in order of file ID values. A valid DIR entry occupies a contiguous set of entry positions within a DIR page, but does not need to completely fill the page. There are no more unused entries in the set, and the file ID values do not have to be contiguous. The range of file ID values in a DIR page does not overlap with the range of file ID values in other DIR pages.

  If it is necessary to insert a new file entry, the DIR page with the file ID range containing the file ID value of the new block is identified from the information in the DIR index. A new entry is inserted at an appropriate position within the file ID range, and the DIR page is rewritten. When the entry needs to be moved, the DIR page is compressed without any entry and rewritten.

  When adding further to a full DIR page, assign a free logical page as a new DIR page, split the file ID range of the full DIR page into two approximately equal non-overlapping ranges, and two available Write to the correct DIR page.

  If the total number of valid entries in two DIR pages with adjacent file ID ranges is less than 70% of the number of entry positions in the DIR page, the two DIR page ranges are merged to Write to one of them. Then, other unused pages become free logical pages.

The DIR entry of the DIR block of FIG. 27 includes three fields.
1) File ID
2) Pointer indicating the FIT record (the FIT page logical identifier and byte offset of the FIT record are defined by the pointer. In the specific example, the FIT page logical identifier is an individual up to 16 pages referenced by an entry in the same DIR page. Is identified by a FIT index field in the DIR page containing the entry, and is converted to a physical block address and page number by a byte offset in the identified FIT page. Identify the location of the FIT record, or the pointer may indicate TFIT, a pending bit in the pointer to indicate that the FIT record is in TFIT and that the pointer defines a logical page in TFIT Set.)
3) Pointer indicating the file attribute record (the pointer defines the ATR page logical identifier and byte offset of the ATR record. In the specific example, the ATR page logical identifier refers to the individual up to 16 pages referenced by the entry in the DIR page. One of the ATR pages is converted to the physical block address and page number by the FIT index field in the DIR page containing the entry, and the ATR in the identified ATR page by the byte offset. (Identify the position of the record.)

  There is a separate valid FIT index field for each valid DIR page. By using this, the logical identifier of the FIT page is converted into a physical block address and a page number where the FIT page is located. One entry is included for each logical identifier used in the entry of the page indicating the FIT record.

  A valid DIR index field is present only on the most recently written DIR page. Information in the fields of all previously written DIR pages is no longer used. Its purpose is to support the order of DIR entries and the mapping of logical pages to physical pages.

The DIR index contains one entry for each possible logical page ordered based on the logical page number. Each entry has three fields.
1. 1. Logical page allocation status flag File ID associated with the first entry in the page (this allows caching by setting the range of file ID values in each DIR page)
3. Pointer indicating a physical page in the DIR that performs logical page mapping

  The FIT in FIG. 27 includes a collection of records. Each includes file data indexing information of the file object identified by the control data and the file ID. There is one entry for each FIT or TFIT of a file object that exists in the device. FIT records for most file objects are stored in the FIT, and the TFIT contains only FIT records for file objects that are likely to be modified in the near future.

  When the address of the FIT record in the FIT is directly specified by the DIR entry and the FIT page is corrected, it is necessary to correct the DIR page.

  The FIT is included in one or more dedicated FIT blocks. The FIT block includes only one page on which the FIT record is written and not programmed. All the FIT record information is programmed at the position of the page in the block where the next programming is not performed, and is identified by the FIT write pointer. When programming for the last page in the block, move the FIT write pointer to the first page of the erase block. The FIT block may contain pages that are no longer used from the rewritten FIT page and obsolete FIT records in the valid FIT page that are obtained from the removed DIR entry. Capacity that is no longer used may be released from the FIT block.

  The FIT page includes a set of FIT records referred to by a DIR entry as entries in the DIR page in the same order in the same DIR page. The DIR page may refer to a plurality of FIT pages. Therefore, if the FIT page is corrected, as a result, it is necessary to correct only one DIR page. The FIT page may be modified by reading the page and then performing an update or adding one or more FIT records. The compressed FIT record is removed by compressing the page, and then the page is programmed at the position identified by the FIT write pointer.

The FIT page header stores a reference to the DIR page associated with the FIT page and the length of the FIT record information in the FIT page. The FIT page header may also store a record of the number of pages that are no longer used in each FIT block when the FIT page is written. Typically, this information is valid only in the most recently written FIT page header.
The FIT record of the FIT block in FIG. 27 includes the following fields.
1) File ID
2) File status (as described in previously incorporated US patent application Ser. No. 11 / 382,224), which is a number from 0 to 9, each status being a file data Specifies the location-defined combination of physical block types that are allowed to contain, typically because one or more data groups in the file changed when the file state changed In addition, it is necessary to update the FIT record.)
3) Address of the active block of the file 4) Number of data groups in the file 5) One field for each data group in the file including: a) Logical offset of byte representation in the file b) Length of byte representation C) Pointer indicating physical position

  By using the TFIT block of FIG. 27, it is possible to store a temporary FIT record, that is, a FIT record having a high probability of performing correction in the near future. As described in the first embodiment, for example, this makes it possible to incorporate an open file into a system that uses open file commands and closed file commands. The DIR entry allows the TFIT entry to be modified without having to indirectly address the FIT record in the TFIT and update the DIR.

  The TFIT is contained in one dedicated TFIT block that contains a fixed number of logical pages. Next, each logical page is updated by rewriting the usable physical page. Assign a logical page number to the page that contains a valid TFIT entry. The number of logical pages in the TFIT block is designated to be 25% of the number of physical pages in the block.

  After the last page of the TFIT block is written, all valid pages are written to the erase block, and the original TFIT block is erased to compress the block. FIT records do not exist in both FIT and TFIT at the same time.

The TFIT page contains only one FIT record. The FIT record in TFIT may be exactly the same as described above for the FIT block. A valid TFIT index field exists only in the most recently written TFIT page. The information in the fields of all previously written TFIT pages is not used. Its purpose is to map logical pages to physical pages. The TFIT index contains one entry for each possible logical page ordered based on the logical page number. Each entry has two fields.
1. 1. Logical page allocation status flag Pointer indicating the physical page in TFIT that performs logical page mapping

  The ATTR block in FIG. 27 is a collection of records, and each includes attributes of a file object identified by a file ID. The contents of the attribute record are already defined by the host system and are not interpreted by the memory system. There is one entry in the ATR for each file object for which the host writes attributes. The DIR entry directly addresses the ATR record in the ATTR block, and the DIR page is corrected when the ATR page is corrected.

  The ATR is contained in one or more dedicated ATTR blocks. Only one ATR block contains a non-programmed page where an ATR record is written. The ATTR block may include a page that is no longer used that is obtained from the rewritten ATR page and an ATR record that is no longer used in a valid ATR page obtained from the deleted file.

  A page ATTR block contains a set of ATR records that are referenced by DIR entries in the same DIR page in the same order as the entries in the DIR page. The DIR page may refer to a plurality of ATR pages. Therefore, when the ATR page is corrected, as a result, it is necessary to correct only one DIR page.

The header of the ATR page stores a reference to the DIR page associated with the ATR page and the length of the ATR record information in the ATR page. The ATR page header may also contain a record of the number of unused pages present in each ATTR block when the ATR page is written. Typically, this information is valid only for the header of the most recently written ATR page. The ATR record includes the following fields:
1) File ID
2) Length of ATR record 3) Contents of ATR record (The contents of the attribute record are not interpreted by the DFS system because the host system has already been defined.)

  As described above, a data group is a set of file data having consecutive logical offset addresses in a file, and programming is performed with continuous physical addresses in one block. Files are frequently programmed as multiple data groups. The data group may be any length between 1 byte and 1 block. Preferably, each data group is programmed with a header and includes file IDs of some files.

  The FIT record is included in one or more FIT blocks, and is directly addressed by a DIR entry. Only one FIT block contains erase pages that can be used to program new or updated FIT records. In all other FIT blocks, all pages are programmed, but the block may contain pages that are completely obsolete or partially obsolete.

  By designating one FIT block as the next block to be released, this capacity occupied by the FIT record that is no longer used is released, and before the released block is erased, the FIT write pointer is now specified from this released block. Continuous page copy to the current page.

  When the release processing before the FIT block is completed and the block is erased, the release block is selected. The FIT block having the largest number of pages that are no longer used is selected as a release block. This value is recorded for each FIT block in the FIT page header of the most recently written FIT page. There is no need to select and free the FIT block containing the FIT write pointer. The selected FIT block remains as a release block until the release process is completed and the block is erased.

  The process of releasing a FIT block containing a page that is no longer used is a small number containing a valid FIT record in the page specified by the FIT write pointer from this block in individual bursts at scheduled intervals. It is necessary to make a copy of the page. The number of pages in one burst must be the number of pages included in the metapage. As a metapage programming operation, it is necessary to program the page indicated by the FIT write pointer.

  Through the number of page positions contained in the four metapages, the progress of the FIT write pointer needs to schedule burst copy operations for pages in the release block at defined intervals. When scheduling a burst copy operation, the write pointer points to the first page in the physical metapage.

  The same release process may be performed separately on the ATTR block.

Variations of Embodiments In each of the two specific file indexing embodiments described above, the page of data from the host, the FIT entry, and the directory entry are all in separate groups of one or more blocks. I remember it. As a first modification of this configuration, a page including a directory entry and a page including a FIT record may exist together in the same block. As shown in FIG. 20, the plurality of logical pages in the block include directory entries. A directory entry for a specific file ID has a known logical address in the block. As shown in FIG. 21, each logical page also includes a set of logical page pointers. These serve as a logical to physical page mapping of directory pages within the block. There is one pointer for each logical page in the block, which specifies the current physical page address of the logical page. A FIT page containing a FIT record may exist in a block. The FIT page is not assigned to a logical page, but is directly addressed at a physical page position by a directory entry. When updating one or more FIT records in a FIT page, identify the location of the FIT page from the associated directory entry, read the page, modify the associated record, and use it next in the block Write the updated page to a page where no programming is possible. To update the directory entry and address directly to this new FIT page location, modify one directory logical page and program to the physical page location following the location occupied by the updated FIT page. . The logical page pointer of this directory page is also updated and programmed by the same operation. The logical page pointer of all logical pages in the block is only valid in the directory page that was last written in the block, which is always the last page written in the block.

  Alternatively, the FIT page may include a set of logical page pointers, or the FIT page may be the last written page in the block.

  In yet another variation of the configuration described in the two specific file indexing embodiments, it includes a page containing directory entries, a page containing FIT records, and data from the host. A page may exist together in the same block. When writing data from the host, programming is performed on a plurality of consecutive physical pages in a block in the form of a data group. The location of this data group is identified by the field of the associated FIT record in the updated FIT page. This programs the physical page immediately following the end of the data group. The directory page is also programmed immediately after the FIT page, and the pointers indicating all the FIT records in the updated FIT page are updated as described above.

  By ensuring that the data group does not exceed the third last page in the block, it is possible to program the FIT page and directory page immediately after this.

Summary While various aspects of the invention have been described with reference to illustrative embodiments, it will be understood that the invention is entitled to protection within the full scope of the appended claims.

1 schematically illustrates a non-volatile memory system connected to a host as currently implemented. FIG. 2 is a block diagram of an example flash memory system used as the nonvolatile memory of FIG. 1. FIG. 3 is a typical circuit diagram of a memory cell array used in the system of FIG. 3 shows a physical memory configuration of an example of the system of FIG. It is the elements on larger scale of the physical memory of FIG. FIG. 6 is another partial enlarged view of the physical memory of FIGS. 4 and 5. 1 illustrates a typical prior art logical address interface between a host and a reprogrammable memory system. FIG. 8 illustrates a typical prior art logical address interface between a host and a reprogrammable memory system that differs in manner from that shown in FIG. Fig. 3 shows a direct file storage interface between a host and a reprogrammable memory system according to the invention. FIG. 10 illustrates a direct file storage interface between a host and a reprogrammable memory system according to the present invention in a manner different from that shown in FIG. FIG. 2 is a functional block diagram of a memory system that cooperates with a direct data file storage interface. Indicates the operation cycle of the direct data file memory. An example of writing file data directly to memory is shown. Another example of directly writing file data to memory will be described. Another example of directly writing file data to memory will be described. Another example of directly writing file data to memory will be described. A sequence for directly writing one data file to a memory is shown. A sequence for directly writing one data file to a memory is shown. A sequence for directly writing one data file to a memory is shown. A sequence for directly writing one data file to a memory is shown. A sequence for directly writing one data file to a memory is shown. FIG. 14E shows the result of releasing the block of FIG. 14E. FIG. Indicates release of a block containing one data group and data that is no longer used. 14A, 14C, 14E, 15 and 16 show FIT entries of the data groups. FIG. 4 illustrates the principle of file indexing using different FIT structures for active and inactive files of the first embodiment for specific file indexing. FIG. The explanation of FIG. 18 is expanded. FIG. 20 shows an example of the logical structure of the file directory of FIGS. 18 and 19. FIG. FIG. 20 shows the physical structure of a memory block containing the file directory of FIGS. 18 and 19. FIG. The logical structure of FIT of FIG. 18 and FIG. 19 is shown. The physical structure of the block containing the FIT entry (TFIT) of the active file is shown. The physical structure of the block containing the FIT entry of the inactive file is shown. The operation | movement performed to the FIT record in the file indexing of an example of FIG. 19 is shown. FIG. 6 illustrates a file indexing hierarchy according to a second embodiment for performing specific file indexing. FIG. FIG. 27 shows an exemplary data structure of a memory block, FIT, and table dedicated to a file directory having file attributes in the embodiment of FIG.

Claims (34)

A method of operating a non-volatile memory system having storage cells grouped into memory cell blocks that are erased prior to reprogramming with file data received from outside the memory system,
Storing data of a file having a unique file identifier in the memory block;
Holding a record of the position of the physical block of the data of the individual file for the individual file;
Maintaining the classification of the individual files as either classification (1) likely to make a near future correction or classification (2) not likely to make a near future correction;
A directory of links to the record of the file, which is an indirect link to the record of the file classified as (1) and a direct link to the record of the file classified as (2) by a unique file identifier. Holding step;
Accessing a selected one of the records via the directory by using a unique file identifier;
Including methods. The method of claim 1, wherein
The host system connected to the memory system holds the file in the classification (1) that specifies that the individual file is opened, and the host system connected to the memory system specifies that the individual file is closed. How to keep files in category (2). The method of claim 1, wherein
A method in which the memory system retains the file classification in response to writing file data into at least one of the memory blocks from a host connected to the memory system. The method of claim 1, wherein
The indirect link of the file includes an entry in the directory at the address of the first location in the memory that does not change as the second location containing the record of the file change, A method wherein the location includes an address of the second location with a change and the direct link of the file includes an entry in the directory of the address of the second location. The method of claim 1, wherein
(1) keep records of files classified as (1) in separate pages in the memory block without records of other files, and (2) record multiple records of files classified as separate in the memory block. How to keep on page. The method of claim 1, wherein
(2) group together a large number of records in the file into the first page of the memory block, and link a large number of links to those number of records to a second of the memory blocks comprising the directory. How to group together on a page. The method of claim 6 wherein:
A method of limiting the number of records of a file classified as (2) stored in the first page to a file whose link is stored in the second page. A method of operating a non-volatile memory system having storage cells grouped into memory cell blocks that are erased prior to reprogramming with data of a file identified by a unique file identifier, comprising:
Storing individual file data as one or more data groups;
Holding a record of the data group comprising each of the data of the file;
Maintaining a directory of links to the records that are direct links to inactive files and indirect links to active files by the unique file identifier;
Including methods. The method of claim 8, wherein
A method where active files are likely to make those modifications in the near future and inactive files are not likely to make those modifications in the near future. The method of claim 8, wherein
A method in which an active file includes a file that is designated as open by a host connected to the memory system, and an inactive file includes a file that is designated as closed by the host. The method of claim 8, wherein
The method wherein the memory system identifies that the individual file is active or inactive by monitoring at least one pattern of storage of the file in the memory block. The method of claim 8, wherein
The method wherein the one or more data groups include data at successive logical file offset addresses and successive physical addresses within a memory cell block. The method of claim 8, wherein
A method of maintaining a record of an active file on a separate page in the memory block without records of other files and a plurality of records of an inactive file on a separate page in the memory block. The method of claim 8, wherein
Multiple records of inactive files are grouped together on the first page of the memory block, and multiple links to those number of records are grouped together on the second page of the memory block that makes up the directory. how to. A method of operating a non-volatile memory system having storage cells grouped into memory cell blocks that are data identified by a unique file identifier and offset address within the file and that are erased before reprogramming the page of the block. There,
Storing data of individual files as one or more data groups that individually specify data in successive logical file offset addresses and successive physical addresses in a memory cell block;
Maintaining a set of entries in a table of the data groups of the individual files;
A file that links the file to an entry in the table of data of the file that is a direct link to the data of the closed file and an indirect link to the data of the open file, with a unique identifier of the file Maintaining a directory;
Including methods. The method of claim 15, wherein
Keep a table of open files on a separate page in the memory block that does not contain tables of other files, and keep multiple records of closed files on a separate page in the memory block Method. The method of claim 15, wherein
Group together a number of records in a closed file into a first page of the memory block, and link a number of links to those number of records together into a second page of the memory block that constitutes the directory. How to group. A method of operating a non-volatile memory system having storage cells grouped into memory cell blocks that are erased prior to reprogramming the data in a page of the block, comprising:
Storing data of files having individually unique file identifiers in the first plurality of pages;
Holding a record of the physical page position of the data of the file stored in the first plurality of pages at least in a second page;
At least a third page holds at least a pointer indicating the position of the record in the second page, and the pointer in the second page is stored in the third page. Limiting to that of the file;
Including methods. The method of claim 18, wherein:
A method wherein at least a pointer indicating a position of a record in the second page is associated with a unique identifier of the file to which the record is related. The method of claim 18, wherein:
The first plurality of pages is located in a first group of one or more blocks, the at least second page is located in a second group of one or more blocks, and the at least third The method, wherein the page is located in a third group of one or more blocks. The method of claim 18, wherein:
The first plurality of pages are located in a first group of one or more blocks, and the at least second page and the at least third page are shared by a second group of one or more blocks The method that is located in the block. The method of claim 18, wherein:
The method wherein the first plurality of pages, the at least second page, and the at least third page are located together in a shared block of a group of one or more blocks. A method of operating a non-volatile memory system having storage cells grouped into memory cell blocks that are erased prior to reprogramming the data in a page of the block, comprising:
Holding a record of the position of the physical page in which data is stored in at least a first page;
At least a second page holds a pointer to at least the position of the record in the first page, and the pointer stored in the second page points to the record in the first page Step to restrict to things,
Including methods. A method of operating a non-volatile memory system having storage cells grouped into memory cell blocks that are erased prior to reprogramming the data of a file in a page of the block, comprising:
Storing data of a file having a unique file identifier in the memory block;
Holding a record of the position of the physical block of the data of the individual file for the individual file;
Maintaining in the directory a directory of links to the record of the file, which is a link to one or more locations in memory containing the physical address of the record, with a unique file identifier;
Accessing a selected one of the records via the directory by using a unique file identifier, and maintaining a record of an individual file on a separate page without a record of another file;
Including methods. A non-volatile memory memory system having storage cells grouped into memory cell blocks that are erased together prior to data reprogramming,
Data of files having unique file identifiers received from outside the memory system are stored in the memory block by the file identifiers;
Keep a record of the physical block position of the data for the individual file;
Holding the classification of the individual files as either classification (1) likely to make a near future correction or classification (2) not likely to make a near future correction;
A directory of links to the record of the file, which is an indirect link to the record of the file classified as (1) and a direct link to the record of the file classified as (2) by a unique file identifier. Memory system to hold. 26. The memory system of claim 25.
Furthermore, the host system connected to the memory system holds the file in the classification (1) that specifies that the individual file is opened, and the host system connected to the memory system closes the individual file. A memory system that holds files in the category (2) that is designated as being. 26. The memory system of claim 25.
Further, the indirect link of the file includes an entry in the directory at the address of the first location in the memory that does not change as the second location containing the record of the file change, A memory system wherein a location of 1 includes the address of the second location with a change, and the direct link of the file includes an entry in the directory of the address of the second location. 26. The memory system of claim 25.
Furthermore, the records of the file classified as (1) are held in individual pages in the memory block having no records of other files, and the records of the file classified as (2) are stored in the memory block. A memory system that keeps individual pages. 26. The memory system of claim 25.
Further, a large number of records of the file classified as (2) are grouped together in a first page of the memory block, and a large number of links to the number of records are grouped into the first number of the memory blocks constituting the directory. A memory system that groups two pages together. 30. The memory system of claim 29.
Further, a memory system for limiting the number of records of the file classified as (2) stored in the first page to the file stored in the second page. A non-volatile memory memory system having storage cells grouped into memory cell blocks that are erased together before reprogramming a block of data to a page,
Data of files individually having unique file identifiers stored in the first plurality of pages;
A record of the physical page position holding data of the uniquely identified file in at least a second page;
A pointer indicating the position of the record in the at least second page is held in at least the third page, and the pointer in the second page is stored in the third page. A pointer that is restricted to that of the file, and
A memory system comprising: 32. The memory system of claim 31, wherein
Further, the first plurality of pages is located in a first group of one or more blocks, the at least second page is located in a second group of one or more blocks, and the at least first A memory system in which three pages are located in a third group of one or more blocks. 32. The memory system of claim 31, wherein
The first plurality of pages are located in a first group of one or more blocks, and the at least second page and the at least third page are shared by a second group of one or more blocks A memory system located in a block. 32. The memory system of claim 31, wherein
The memory system, wherein the first plurality of pages, the at least second page, and the at least third page are located together in a shared block of a group of one or more blocks.

Images