KR20120131579A - Flash file system - Google Patents

Abstract

PURPOSE: A flash file system is provided to reduce the usability of a main memory and time for mounting by storing a part of management structure configuration in a flash memory. CONSTITUTION: A master block(100) stores a file system version, a format option, and a bad block list and indicates a mount log block(200). The mount log block stores an object header block list(300), a preliminary block list, a first checkpoint block, and unmount success information. The preliminary block list maintains a list of the preliminary blocks which store file data and an object header block list. [Reference numerals] (100) Master block; (200) Mount log block; (300) Object header block list; (400) Preliminary block list; (A1, A2) Check point; (B1~B5) Empty; (C1~C12) File data; (D1,D2) Object; (E1~E5) Tnode; (FF) DRAM; (GG) Flash memory; (HH) Object head block; (II) Preliminary block; (JJ) Data, tnode or free block

Description

Flash file system {FLASH FILE SYSTEM}

The present invention minimizes the scanning that occurs when the flash file system is mounted on the system, thereby reducing the time required for mounting, reducing the amount of main memory used, and efficiently managing invalid pages generated while operating the file system. The present invention relates to a file system for NAND Flash memory including garbage collection that improves input / output speed.

With the rise of mobile devices such as smartphones and tablet PCs, a large amount of flash memory is generally used. However, the existing flash file system needs to scan a larger amount of data at boot time as the size of the flash memory increases, which causes a significant decrease in the boot speed and the increase in the main memory usage, thus causing a decrease in system performance. do. In addition, garbage collection to retrieve invalid pages is not efficient, causing unnecessary flash memory operation and consequently slowing the input / output speed of the file.

At present, it is necessary to devise a file system that solves the above-mentioned problems because it is obvious that the flash file system will become a serious bottleneck in view of the development direction of portable devices and the technology trend of large-capacity flash memory.

1 illustrates a NAND flash memory. In NAND flash memory, reading and writing is possible only in units of pages. Deletion can be performed only in units of blocks. Since it cannot be overwritten, it must be written in units of pages after erasing in units of blocks. There is a limit on the number of deletions.

The prior art (also referred to as YAFFS) (see FIG. 2) is a file system optimized for NAND flash memory and stores metadata for each page together in an OOB area (see FIG. 1) of the NAND flash. It is designed to cope with sudden power loss without journaling. It is a log structured file system that copes with the wear of flash memory, and its simple structure shows higher input / output performance than other flash file systems.

Because the metadata is scattered, to use the file system, you must scan the entire flash memory at initial mount and build the management structure in main memory. Garbage collection operates to recover invalid pages generated during use, and selects a block that has a certain amount of invalid pages in one block so that many invalid pages can be recovered at a low cost.

The prior art requires a full scan of the flash memory to reconstruct the object and index tree on DRAM, thus using a file system and a long mount time due to the full scan. The problem is that the main memory required for this purpose is large, and that even though higher input / output performance can be achieved, inefficient garbage collection causes performance degradation.

As the size of flash memory increases, the mount time also increases, which is a serious problem in light of the exponential growth of flash memory. The amount of main memory required increases proportionally with mount time, which affects the performance of applications and other subsystems, resulting in overall system degradation. In addition, as the usage of flash memory approaches 100%, the available free blocks decrease, which causes frequent garbage collection. The conventional garbage collection algorithm causes unnecessary flash memory operation, resulting in a decrease in input / output performance.

In order to solve the above problems of the present invention, it is possible to minimize the information required for configuring the management structure and to store some of the information in the flash memory to shorten the mount time, reduce the usage of the main memory, and reduce the usage pattern of each logical block. It aims to provide a flash file system that tracks and estimates future usage patterns and reflects them in the garbage collection policy to increase efficiency and improve I / O performance.

In order to achieve the above object, a flash file system according to an embodiment of the present invention,

It is used to store the information contained in the superblock, which stores the file system type and the starting point for searching the metadata. It stores one or more of the file system versions, format options, and bad block list that are not easily updated. A master block pointing to,

The object header block list, the spare block list, the first checkpoint block, and whether the unmount succeeded are used to store information contained in a superblock that stores a type of file system and a starting point for searching metadata. A mount log block that stores one or more of

An object header block list which holds a list of object header blocks separately storing only object headers which are metadata stored in flash memory, and

A spare block list, which maintains a list of spare blocks used to store file data until information about an index tree for quick reference of file contents is reflected in flash memory,

When the file system is mounted, an object is constructed by the object header block list, and a lazy loading method of storing an index tree in flash memory and reading it into main memory when necessary is used.

Flash file system according to another embodiment of the present invention,

In the case of small data, the page where the object header is stored is saved as a list by utilizing the empty space except the object header, and when the file size increases, the empty slot of the root node is used instead of updating the leaf node directly. The extended data is stored in the form of a differential B + tree using a method of temporarily storing updated data, and then stored using additionally allocated pages.

Flash file system according to another embodiment of the present invention,

The master block and the mount log block are characterized in that the same information is repeatedly stored in two blocks.

Flash file system according to another embodiment of the present invention,

The object header block list may be allocated with N (N> 1) object header blocks.

Flash file system according to another embodiment of the present invention,

When garbage collection is performed, a block containing valid pages having a low or high read intensiveness is selected as a big team, a valid page in the block selected as a big team is copied to the free block, and the block selected as the big team is selected. It is characterized in that the deletion.

Flash file system according to another embodiment of the present invention,

When selecting a Victim block, a block usage table is used, and the block usage table is arranged according to the reading frequency of valid pages in the block.

Flash file system according to another embodiment of the present invention,

When selecting a Victim block, a GC value is stored which stores the number of times a valid page is transferred by garbage collection, and has the smallest number within a block, and the valid page read frequency in the block usage table is determined by the block. GC value and the number of valid pages in the block, and characterized in that the high GC value blocks are selected as a big team during garbage collection.

The present invention has been made to solve the problems of the prior art by minimizing the information required for the configuration of the management structure and re-store a portion in the flash memory to shorten the mount time, reduce the use of the main memory and use of each logical block By tracking patterns, you can estimate future usage patterns and incorporate them into your garbage collection policies to increase efficiency and improve I / O performance.

1 illustrates a NAND flash memory.
2 is a view showing a flash memory system according to the prior art.
Fig. 3A is a schematic configuration diagram of a flash file system according to the present invention, and Fig. 3B is a diagram showing a flash memory in the flash file system according to the present invention.
4 is a diagram showing that four object header blocks are allocated to an object header block list in the flash file system according to the present invention.
5 is a view showing the structure of the B + tree according to the prior art.
FIG. 6 is a diagram illustrating an update operation in a flash memory according to a change of data in a differential B + tree according to the present invention.
7 is a diagram for describing a garbage collection operation.
8 is a block usage table used for garbage collection in the flash file system according to the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, preferred embodiments of the present invention will be described with reference to the drawings.

In order to store files, the file system stores the data including metadata and contents representing attributes of each file. Metadata includes file name, access rights, directory hierarchy information, and index information about the data so that the contents of the file can be accessed from the metadata.

Metadata stored in flash memory is called an object header, and what is read in main memory is called an object. Thus, an object can be seen as a starting point for accessing a file. An object maintains index information to refer to the contents of a file. It constructs a tree for quick reference to maintain an index, which is called an index tree.

[Object header block list]

The prior art scans the entire flash memory at mount time to construct an object and an index tree, but the present invention collects and stores only object headers separately in an object header block and maintains a list of these blocks so that the object header block is not scanned for data. Objects can be constructed by only scanning. As shown in Figs. 3A and 3B, in the flash file system according to the present invention, the list for this object header block is called an object header block list 300. The block indicated by the arrow in the object header block list 300 is an object header block. At this time, the contents of the list should be changed whenever a file is created or deleted and an object header block is added or deleted. Since this causes additional write operations, add multiple object header blocks at once to reduce the overhead. For example, a flash memory with 64 pages per block requires an object header of one page per file, so an object header block is added and the list is updated each time 64 files are created. However, if four blocks are added at a time, the contents of the list may be updated every time 256 files are generated (see FIG. 4).

[Index tree]

Since objects are constructed from object headers without scanning for data at mount time, index trees cannot be constructed by scanning as in the prior art. Instead, it uses lazy loading, which stores the index tree in flash memory and loads it into main memory when needed. This can eliminate scans of data and reduce the main memory usage by loading the index tree into main memory only as needed.

As the size of the file grows, the amount of data that constitutes the index tree also increases, and the small size data is stored in a list using the empty space other than the object header on the page where the object header is stored. After that, if the file size gradually increases, it expands to the form of B + tree and stores it using additionally allocated pages. At this time, the B + tree was modified according to the characteristics of the flash memory, and this is called a differential B + tree. The difference B + tree is described again below.

[Differential B + Tree]

The existing B + tree (see FIG. 5) stores data in leaf node slots and intermediate inner nodes connect from the root node to the leaf node. However, since flash memory cannot be overwritten, each time a data is added or deleted, the leaf node must be updated and written to another page. Therefore, the page storing the leaf node is changed and the upper inner nodes must also be serially updated as shown in FIG. 5 to update the changed information.

That is, as shown in FIG. 5, the tree path is changed only in the reverse order from the leaf node to the object header in the form of a wandering tree. Therefore, a write operation on a page is required by the height of the tree.

This causes many additional write operations to the flash memory. To solve this problem, the differential B + tree used in the present invention uses a method of temporarily storing updated data using empty slots of the root node instead of directly updating leaf nodes. do.

FIG. 6 is a diagram illustrating an additional write operation to the flash memory in the differential B + tree in the order of FIGS. 6 (A)-> 6 (B)-> FIG. 6 (C)-> FIG. 6 (D). As shown in Figs. 6A to 6D, the changed data block addressing information 301 is accumulated and recorded in the remaining area of the root node of the B + tree (see Fig. 6 (B)) and written to the root node. If there is not enough space left, create a child node (see Figure 6 (C)) to add the corresponding change 302. The block addressing information 301 recorded in the root node and the information 302 recorded in the child node are recorded in a new leaf node, and a node pointer pointing to the leaf node newly recorded in the root node is made (see Fig. 6 (D)). ]. Also, increasing the node pointer at the root increases the tree depth.

In this case, when using the differential B + tree, the sequential write operation does not need to change the contents of the previously recorded leaf node. Only one write occurs to the root node, and an empty space in the object header is used to store the root node. This reduces the load by having the root node updated with the object header when it is saved.

[Spare block list]

When the information for constructing the index tree is stored in the flash memory as described above, if a sudden power loss occurs, the file system may be inconsistent and the file data may be lost or the file system may malfunction. For example, if a file data is written but a power loss occurs before the update of the index tree accompanying it is reflected in the flash memory, there is no way to access the written data. In addition, if a power loss occurs when only part of the index tree information is reflected in the flash memory, the index tree may be inconsistent and may cause a file system malfunction.

To solve this problem, the blocks used to store file data are managed in the spare block list 400 until the index tree information is reflected in the flash memory, and the index tree is recovered from this list at the next mount even if a sudden power loss occurs. Do it. When the index tree is reflected in the flash memory, related blocks are deleted from the spare block list 400 and the list management scheme is the same as that of the object header block list 300.

[Master block and mount log block]

Storing the file system type and starting point to find metadata is called a superblock. In the present invention, the master block 100 and the mount log block 200 are used to store the information contained in the superblock. Superblocks are the first data referenced when a file system is mounted, so they are usually stored in a physically fixed location. Superblocks, on the other hand, are frequently updated in nature. Therefore, applying this method to flash memory will cause wear to the block and shorten its lifespan.

In order to solve such a problem, the master block 100 stores file system versions, format options, bad block lists, etc., which are relatively infrequently updated, and the master block 100 points to the mount log block 200. In this case, the frequently updated information such as the object header block list 300, the spare block list 400, the first checkpoint block, and whether the unmount is successful is stored. Then, the master block 100, which should be in a fixed position, may not wear out well so that the wear may be reduced, while the mount log block 200 may use any block of the device. Can be.

The master block 100 and the mount log block 200 repeatedly store the same information in two blocks in order to prepare for power loss or bit-flip error that may occur during the update.

Garbage Collection

Flash memory cannot be overwritten and an erase operation is required to rewrite a page once it has been written. However, erasing is done in blocks rather than pages. So instead of overwriting it, you store the updated data in a blank page and make the existing page invalid. As a result, if the flash memory continues to be used, the empty blocks disappear, and a process of collecting the invalid pages and recreating the empty blocks through the erase operation is necessary. This is called garbage collection.

7 is a diagram for describing a garbage collection operation. FIG. 7 (A) shows that valid pages in a block selected as a big team are copied to a free block (free page), and FIG. 7 (B) shows that valid pages in a big team block are copied to a free block and then in a big block. Fig. 7 (C) is a view showing that all pages are made invalid pages, and Fig. 7 (C) shows that the Victim blocks composed of only invalid pages are deleted to form free blocks composed only of free pages.

As such, garbage collection can be divided into two stages. The first is to select a VicTim block to be an empty block by the erase operation, and the second is to preserve data by transferring valid pages that may exist within the VicTim block. In the prior art, a block having less than a certain amount of valid pages is selected among the blocks being used to select the Victim block. This is to reduce the cost (garbage collection overhead) required to transfer the valid pages [where the cost is the cost of making the big team block a free block after the big team block has been selected, to make the free page a free block. After moving it to another place, it is deleted. This concept includes copying the valid page to a free block, deleting the Victim block, and time and power consumption. Such a policy has weaknesses in locality access patterns, such as failing to reflect the read and write patterns of pages, causing repeated migration of once migrated pages, and block generation of some invalid pages for a long time. It is known.

In the present invention, the number of times a valid page is transferred by garbage collection (GC count) is stored, and the smallest number of times in a block is referred to as a GC value. The GC value obtained in this way means that a block contains data that is not updated frequently, while a smaller value means that a block contains data that is frequently updated. When garbage collection is based on this GC value, if a policy with a high GC value block is selected as a big team, or a block with a low GC value as a big team, then pages that are updated frequently or infrequently occur frequently. Can be gathered in blocks. This can solve the problem of garbage collection scattered in each block, which increases the cost of garbage collection.

Blocks with high GC values are selected as big teams if they are garbage collections that are performed periodically in the background, or garbage collections are made during appending rather than updating of file data. In this case, garbage collection is performed while the file data is being updated. The reason for taking such a policy is that, in the case of the addition, it can be assumed that the data written in this way will be data that is not updated frequently.

[Block Usage Table]

When selecting a VicTeam block, you need to consider the GC value of the blocks and which blocks contain how many valid pages. This is because when a block having many valid pages is selected as a big team block, it is expensive to transfer the valid pages.

The present invention uses a block usage table (see FIG. 8) to quickly find a block with few or valid pages in garbage collection. The number of entries in this table is the number of pages per block plus one and each entry points to a list of blocks with the same number of valid pages. For example, a flash memory with 64 pages per block has 65 entries, each entry pointing to a list of blocks with 0 to 64 valid pages each. When a page of a block is used to increase the number of valid pages or a page is deleted to become an invalid page, the block is moved to the appropriate entry in the block usage table to maintain the attributes of the table. In addition, the list of entries is sorted according to GC value to effectively select Victim blocks for garbage collection. In other words, select blocks with low usage to reduce copy overhead, and take blocks from the head or tail of the list to select the largest or smallest GC value as the big team. do.

Although the preferred embodiments of the flash file system according to the present invention have been described in detail above with reference to the drawings, the present invention is not limited to the above embodiments and various modifications by those skilled in the art without departing from the spirit and scope of the present invention described in the claims. Modifications and changes are possible.

Claims (7)

It is used to store the information contained in the superblock, which stores the file system type and the starting point for searching the metadata. It stores one or more of the file system versions, format options, and bad block list that are not easily updated. A master block pointing to,
The object header block list, the spare block list, the first checkpoint block, and whether the unmount succeeded are used to store information contained in a superblock that stores a type of file system and a starting point for searching metadata. A mount log block that stores one or more of
An object header block list holding a list of object header blocks that separately store only object headers, which are metadata stored in flash memory, and
A spare block list, which maintains a list of spare blocks used to store file data until information about an index tree for quick reference of file contents is reflected in flash memory,
When the file system is mounted, an object is constructed by the object header block list, and a lazy loading method of storing an index tree in flash memory and reading it into main memory when necessary is used. The method of claim 1,
In the case of small data, the page where the object header is stored is saved as a list by utilizing the empty space except the object header, and when the file size increases, the empty slot of the root node is used instead of updating the leaf node directly. Flash file system, characterized in that by using the additionally allocated pages to expand in the form of a differential B + tree using a method of temporarily storing the updated data. The method of claim 1,
And the master block and the mount log block each store the same information in two blocks. The method of claim 1,
And N (N> 1) object header blocks are allocated to the object header block list. The method according to any one of claims 1 to 4,
When garbage collection is performed, a block including valid pages having a low or high reading frequency is selected as a big team, a valid page in the block selected as a big team is copied to the free block, and the block selected as the big team is deleted. Flash file system. The method of claim 5, wherein
And a block usage table, wherein the block usage table is arranged in accordance with the frequency of reading valid pages in the block. The method according to claim 6,
When selecting a Victim block, a GC value is stored which stores the number of times a valid page is transferred by garbage collection, and has the smallest number within a block, and the frequency of reading valid pages in the block usage table is A flash file system including a GC value of blocks and a valid number of pages in a block, and selecting blocks having a high GC value as a big team during garbage collection.

Images