KR101114125B1 - Nand Flash File System And Method For Initialization And Crash Recovery Thereof - Google Patents

Abstract

The present invention relates to a NAND flash file system, and more particularly, a flash memory space partitioning technique can be used to recover a flash memory space in a fast time when a normal shutdown operation is not performed due to sudden power loss or system error. It is about NAND flash file system.

Nand Flash Crash Recovery Block

Description

Nand Flash File System And Method For Initialization And Crash Recovery Thereof}

The present invention relates to a NAND flash file system. More particularly, the present invention relates to a flash memory space partitioning technique that can be quickly restored in a crash state caused by failure of a normal shutdown operation due to sudden power loss or system error. The NAND flash file system and its initialization and crash recovery method.

NAND flash memory is widely used as a storage medium for portable electronic devices due to its nonvolatile characteristics, high speed, and small size.

The NAND flash file system is a system for operating the NAND flash as a storage space in a device with NAND flash memory. Such a file system has a different feature from a file system targeting a hard disk drive due to the limitation of NAND flash erasing and overwriting.

One of the important features is the initialization of the file system. In order to use the file system, the information required by the actual file system itself must be loaded from the storage medium, which is called initialization in the flash file system.

In the initialization process, the metadata of the file system is read to construct data for using the file system in the main memory of the system.

However, if the file system is abnormally terminated before, the metadata may be lost or the recorded metadata may be inconsistent with the actual data. This situation is known as the file system's intergrity is broken, and this is called a crash situation.

Therefore, in the initialization process, a crash situation must be able to be determined, and a crash recovery technique for recovering to an integrity state is required.

In general, log-based file systems such as the Journaling Flash File System (JEFS) or Yeet Another Flash File System (YAFFS) use a log-based structure that is stored with all metadata distributed throughout the memory space along with the data. Does not have a special crash recovery technique because reads are performed over the entire flash space to find all metadata. Although this method can terminate initialization normally even in a crash situation without any additional recovery technique, the execution time is very long.

In order to solve the above shortcomings, the technique of "A fast start-up technique for flash memory based computing systems" is published in KS Yim, J Kim, K Koh, published by 2005 ACM Symposium on Applied computing The procedure was proposed in the name of the snapshot technique.

According to the technique proposed in the above paper, the snapshot technique stores the metadata structure of the file system stored in main memory at the end of the file system in a predetermined area of the flash memory, and reads only the corresponding area at the time of initialization. To perform initialization. This technique shows fast initialization speed, but the crash recovery time is not clearly shown in the crash situation. In other words, we proposed a fast fault recovery method to optimize the initialization method in the existing flash file system, but this method is not different from the method used to reduce the number of read commands in the existing YAFFS. You can expect to see it.

 Also proposed in a paper in "The Design of efficient initialization and crash recovery for log-based file systems over flash memory" (author: Wu, CH, TW Kuo, LP Chang published: Procedure of the 2006 ACM Transactions on Storage Conference). The log-based method records all the write / erase operations occurring in the file as a log, and reads the log only at the time of initialization to efficiently reconstruct the metadata of the file system. In this case, the log is generated continuously according to the use of the file system. Therefore, the number of log segment blocks, which are frequently allocated to record the log, is allocated to a few blocks in the first place without reserving a specific block. Use Each log is written page by block within a log segment block, and log segments are frequently assigned to any block. It allocates a log segment directory in the front space of memory and stores log segment allocation and free information.

However, the conventionally disclosed technology has the following problems.

First, the snapshot technique shows very efficient performance when the file system is shut down normally because the metadata stored in the promised location can be directly read and initialized. However, in the event of a crash, JFFS or YAFFS should read almost the entire flash memory area equally. In this case, the performance of the initialization can be expressed in big O (O) complexity notation. The capacity of the flash memory can be summarized as O (n) when the capacity of n is n. It increases in proportion.

Considering the recent rapid increase in the use of flash memory, the rate of development of capacity has also increased significantly. Therefore, it can be seen that the initialization speed of the flash file system may be a big problem in the future of flash memory utilization. .

Second, in the case of log-based technique, the initialization shows similar performance as the snapshot technique, but because of the limitation of log recording by page, the cache is cached until the page size is generated. The information will be lost and you will have to recover from the crash.

At this time, it is expected to take less time to recover from the error than the snapshot because it can use the log information already recorded, but because the metadata does not know in which space the lost data is located, All must be searched. Therefore, this technique can also increase linearly the crash recovery execution time in the form of O (n) depending on the capacity of the flash memory.

As described above, the currently proposed flash file systems have a problem of increasing the initialization execution time of devices using the flash memory because the execution time of the crash recovery increases linearly in proportion to the capacity of the flash memory. This can be a problem when applied to large flash memory.

In order to solve the above problems, an object of the present invention is to perform a write operation only within a limited working area of a flash memory at a specific time, so that a quick recovery is possible regardless of NAND flash capacity when a crash occurs due to abnormal termination. It is to provide a NAND flash file system.

Figure 1a is a system block diagram according to a preferred embodiment of the present invention, Figure 1b is a detailed block diagram of Figure 1a.

Referring to FIG. 1, the NAND flash file system of the present invention divides and allocates a flash memory 10 divided into a plurality of blocks and a work area of the block into a plurality of operating systems, and records and manages information on a currently working area. It characterized by including (20).

The block of the flash memory 10 may include a super block 110 for storing a file system setting value for recording system setting information and a journal block table for recording metadata of a journal block, and a journal information for recording journal information in a work area. Journal block 120, data block 130 on which data and inodes are written, and free block 140, which is not currently being used.

In addition, an error correction code and a version are stored in a spare area of a page in all of the blocks 110 to 140.

In addition, the journal block table (JBT) is composed of one or more pages, each page has an extra area, the number of journal blocks included in the current page, whether or not unmounted normally, the start block number of the current working area, And at least one of a start block number of a work area to be used next.

In addition, the superblock 110 is composed of a plurality of blocks to prevent the loss of the super block data, it characterized in that it comprises a duplicate block for recovery and spare data for recovery in case of loss.

In addition, the journal block 120 is stored when the journals are cached in the main memory and the size of the journals in the cache reaches one page size. Until then, journals stored in the cache are immediately stored.

The superblock 110 is a block for storing and managing metadata of the journal block 120 included in all work areas (one block in the entire work area. Only there exists a journal block 120, a data block 130, and a free block 140 in each working area.

The operating system 20 may include a work area control module 210 for setting and managing a plurality of subdivided work areas, an initialization module 220 for initializing a file system, and a crash when performing the initialization. It is characterized in that it comprises a crash recovery module 230 for recovering the crash.

Here, the work area control module 210 sets a plurality of subdivided work areas, and if a cache of one page is occupied in the cache or there is an inode deleted outside the work area, or the journal block allocated to the current work area. If 120 does not remain and additional allocation fails, the work area is sequentially moved, and when moving to the next work area, the start block number of the next work area is recorded in the page spare area where the journal is recorded.

The workspace control module 210 performs a delete operation on the journal block 120 and the data block 130 by garbage collection when all pages included in the block are recording unnecessary data. After the journal block table information of the superblock 110 is recorded in the next superblock, a delete operation is performed.

In addition, the initialization module 220 extracts a valid superblock through the information stored in the spare area of the first page for each of the superblocks 110, and has a most recent journal block table among the valid superblocks. When the unmounting is performed correctly by extracting a super block, the entire journal is tracked using the most recent journal block table, and the initialization is performed.

That is, when there are a plurality of super blocks 110, a valid super block is extracted according to whether an error correction code (ECC) stored in the extra area of the first page of each block is valid, and a version of the extracted valid super blocks is extracted. According to the information, the superblock with the most recent journal block table is extracted.

The crash recovery module 230 determines that a crash has occurred when the unmount is not performed correctly, reads journal information based on the most recent journal block table, and finds the last recorded journal using version information. The latest work area is identified through the work area information recorded in the spare area of the journal, and the metadata information is recovered while sequentially searching for blocks changed in the work area but not recorded in the journal.

An effect that can be expected through the present invention is an improvement in crash recovery performance of a flash file system.

In particular, by overcoming the limitations of the existing techniques where the time required for crash recovery is proportional to the capacity of the flash memory, and suggesting a method with an execution time that is not proportional to this, the crash recovery time is almost increased even if the capacity of the flash memory is increased in the future. An excellent effect does not occur. This has the effect that the initialization time of the device when using the device equipped with the actual flash memory is not significantly affected by the performance of crash recovery.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

In order to perform crash recovery of the flash file system efficiently, we designed a scheme that uses a working area for a block of flash memory.

A problem of the conventional crash recovery scheme to be solved in the present invention is that the execution time increases linearly with the entire flash space.

To solve this problem, we propose a method to limit the crash recovery time to a very small constant value by using a work area setting method that divides the area of the block used by the file system and records the current work area.

For example, if you are currently working on 10 blocks from 0 to 9, record this information in the promised space, and then record metadata about the space if all the space is used or other set conditions are met. Move your workspace to 19 and update this information.

In this way, by limiting the amount of space that must be explored during crash recovery, fault recovery time can be reduced regardless of flash memory capacity.

The present invention is characterized by the design of a structure that records changes made to the entire flash memory in one working area, the design that does not lose information about the allocation and variation of the working area, and the provision of an efficient crash recovery technique in such a structure. do. These features will be described in more detail in the following design.

1) Classification of blocks

Referring to FIG. 1B, each block in the flash memory 10 is divided into four types, a super block 110, a journal block 120, a data block 130, and a free block 140.

The superblock 110 is composed of two or more blocks from the first block of the flash memory 10 and stores file system setting values and metadata of journal blocks. The file system settings are recorded on the first page of each block, and the information determined when the file system is created, such as the size of the current partition or the first block number, is stored. The file system setting value may be changed according to the setting of the file system. However, in addition to general file system information, the number of blocks belonging to a work area, the size of a superblock, and the like must be included.

The metadata of the journal block is stored in a journal block table (hereinafter referred to as "JBT").

The JBT is a space in which the number of journal blocks 120 is stored and is composed of one or more pages. The extra area of each page includes the number of journal blocks included in the current page, whether or not the normal operation is performed, and the current work area. The start block number, the start block number of the work area to be used next, is recorded. The above information shows the size and unmount of the JBT and whether the current and next work areas are located.

The journal block 120 is a space where a journal is recorded. The journal stores update information such as write / erase and writes page by page in the journal block within the current work area. Journals are cached in main memory and clean up duplicate journals in the cache. At the same time, each journal is maintained as a linked list in chronological order within the metadata structure of the file containing the journal. When the size of the journals in the cache reaches the size of one page, they are written to the actual journal block.

Even if a crash occurs, changes made in the work area can be identified by scanning the work area, but information deleted by an inode in another area cannot be recovered unless that information is recorded. If the deletion is done, the journals that have been stored in the cache are recorded immediately together with the journal of the information so that the deletion information is not lost.

Although the journal is recorded in this way, the loss of information is prevented, but there is a trade-off relationship in which a space left in one page may be used to reduce the efficiency of resource usage. Then, in the spare area of each page where the journal is stored, the number of the work area where the journal is to be recorded is recorded next.

The data block 130 is a block in which data and an inode are written, and all other blocks are regarded as a free block 140 that is not currently used.

Figure 2 shows a journal block in the form of a C language structure according to a preferred embodiment of the present invention.

Referring to FIG. 2, _u16 represents an unsigned integer type 16-bit data type, and _u32 represents a 32-bit data type of the same type.

The size of a journal is 16 bytes in total, and the ID of the inode represented by the journal, the offset in the file where the operation starts, the size of the operation, a flag indicating the type of operation, and the page address are recorded.

The maximum size a journal can represent is 65,535 bytes, which is equivalent to 32 pages in a 2048-byte page. Flag options include file creation, deletion, writing, truncate, padding with zeros, and other options.

When these journals are gathered on one page, they become journal pages. FIG. 2 shows a form including 128 journals assuming a 2048-byte page, and the length of the journal, the version of the page, and other error correction codes (ECC) are recorded in the page spare area.

3 illustrates a page form in a JBT according to a preferred embodiment of the present invention in the form of a structure of a C language.

Referring to FIG. 3, a total of 512 four-byte addresses are recorded in a 2048-byte page, each representing one journal block address. The spare area of the page where the JBT is written contains the number of journal blocks written to the current page, the address of the page where the work area begins at that time, the address of the page where the next work area starts, and an unmount flag indicating whether the file system has been shut down normally. Etc. are recorded.

2) Block Management

Blocks classified as described above are allocated by the operating system 20, and the rules assigned are as follows.

The super block 110 is statically allocated from the first block of the partition when the file system is created, and its size is a multiple of two.

4 is a detailed block diagram of a super block according to a preferred embodiment of the present invention.

4 is a diagram schematically illustrating a layout in which four super blocks 110 are allocated, in which block 0 is a general super block and block 2 is a duplicate block for preventing loss of super block data and restoring loss.

Block 1 and 3 are reserved blocks for block 0 and 2. Due to the characteristics of flash memory, data cannot be written to a page where data is already written, and a delete operation must be performed.

Therefore, it is possible to prevent the delay due to an erase operation in the operation of writing data to the super block 110 by providing a spare block. For example, if all data is written in block 0, the write operation for the super block is performed in block 1. The erase operation is performed on block 0 during the idle time of the file system, and then block 0 becomes a spare block.

When the file system is initialized, the second page of the block can be examined in order from block 0 to determine that the block in which the JBT is found is the super block currently in use. The first page contains file system configuration values (FS-configurations) that record file system configuration information.

The journal block 120 is allocated N consecutive blocks at a time. Blocks can be in any location, and if all journal blocks are exhausted, an additional N blocks are allocated within the current work area to be used as journal blocks.

When the assignment is made, the JBT in the super block 110 is updated. The reason for allocating N at a time is to prevent too many operations in the super block 110, so that the next journal block can be easily found in a crash situation.

The data block 130 is allocated as sequentially as possible within the current work area. If there are not enough blocks in the work area, the journal information up to that point is recorded and moved to the next work area.

5 shows a state in which blocks are allocated according to a preferred embodiment of the present invention. Referring to FIG. 5, the size of the current working area is six blocks, the super block 110 points to the journal blocks 120 through JBT, and the data block 130 is sequentially assigned within each working area. It can be seen that. Although the current work area 3 has not been used, the journal block 120 has been allocated in advance.

Error correction codes (ECCs) and versions are commonly recorded in the extra area of the page in every block. The error correction code (ECC) is information that is commonly used in all flash-based storage systems to correct 1-bit errors occurring in flash memory, and the version is incremented by 1 to know the recorded order between pages. Global information. This tells you which pages are the most recent.

3) management of the working area

The work area is sized when the file system is created and moves sequentially. The size is specified by the number of blocks and is set to be about 32 ~ 64MB. The larger this size is, the longer the crash recovery time is. Therefore, it is necessary to set an appropriate value according to the specification of the flash memory. If you look at the performance of the current flash memory within 32-64MB, the crash recovery performance is expected to be within 1-2 seconds. This value can then change as flash memory performance evolves.

Management of the work area is performed by the work area control module 210 of the operating system 20. Movement of the work area takes place sequentially. For example, if the current work area is 1024 blocks starting from block 128, the next work area starts from block 1152 (= 128 + 1024).

By continuously moving the work area, even if the latest work area information is lost, the execution time for searching the work area can be minimized.

The time to move is when a journal page is written, that is, when a cache is full of a page or an inode is deleted outside of the work area.

If more than 20% of the size of the work area has been used since moving to the current work area, move to the next work area and record the start block number of the next work area in the extra area of the page where the journal to be written is recorded. This allows you to keep track of the journals to identify the most recent work area.

20% is an arbitrary number and can be changed by various variables such as the size of the flash memory and the size of the working area. If you move to the next work area after all the blocks in one work area have been allocated and used, a large amount of data can be recorded only in a certain area depending on the user's usage pattern, which maintains even wear-leveling. This can interfere with the flash characteristics.

Therefore, the work area is changed frequently so that uniform I / O can be performed for the entire flash space. However, changing the workspace too often can also have a negative impact on performance because there is some overhead in updating the JBT with information about changing the workspace.

4) Garbage Collection Technique

The release of the journal block 120 and the data block 130 is performed by garbage collection when all pages included in the block are recording unnecessary data. The data in journal block 120 is not needed if the updated information is stored elsewhere or if the journal information is no longer valid due to deletion of the file, and data block 130 deletes or modifies the data contained therein. If it is.

Garbage collection, which collects and actually deletes the journal block 120 and the data block 130 as described above, is performed when the file system is idle. After a garbage collection target block is found and its information is written to the journal, the block is cleared.

In the case of the super block 110, since the JBT information is always updated, when all the pages in one super block are used, the information must be recorded in the other super block. In this case, to prevent data loss, the first super block is first deleted after the JBT information is recorded in the next super block. This operation keeps only one valid super block within all super blocks.

5) Initialization and Crash Recovery Techniques

Hereinafter, an initialization technique and a crash recovery technique for a flash file system using the work area scheme designed as described above will be described with reference to FIG. 6.

 Initialization of the file system is performed in the initialization module 220 of the operating system 20, the first of which is to find a valid super block and the last stored journal block table (JBT). To do this, we sequentially search for a plurality of super blocks. The first page of each block is file system information, so both the data and spare areas of the page are read and loaded into main memory. Since the second page is JBT, the unmounted flag is checked sequentially by reading the extra area of each page. If an unmount flag is found and there is no data on the next page, it is considered valid JBT. If there is no valid JBT, this is a crash situation. You must perform crash recovery based on the JBT that stores the most recent version value.

① Initialization technique of normal situation

When unmounting is normally performed, the initialization module 220 may track the entire journal using the latest JBT. N journals are allocated consecutively, so if there are journals that have not been used within N, they can be omitted.

Since all the update information of the file system is recorded in the journal, the entire file system metadata information can be constructed by reading the entire journal information. This normal initialization technique can compensate for the lack of valid superblock and normal unmounting technique in log-based schemes.

② Crash Recovery Techniques

If a crash occurs and the unmounting is not normally performed, the crash recovery module 230 of the operating system 20 first reads journal information based on the latest JBT having the highest version recorded. At this point, you can be sure that there are no more journal blocks allocated, so use the version information to find information about the last recorded journal and work area.

Next, find the information that has been changed in the work area but not written in the journal, and recover the metadata information by sequentially searching for blocks not written in the journal. Since the pages within a block are always written sequentially, you can read the extra area of the first page to see if the block is in use and optimize your search. In this way, when all the block information in the work area is known, crash recovery ends.

In addition, if the performance of the technique according to the present invention represented by the execution time model can be expressed as shown in Equation 1 below.

In the model, T _d and T _s respectively represent the time taken to read the data space and the spare area in one page, L is the total number of journals, M _f is the number of files lost due to a crash, M _d is lost The number of data pages, B _fw , is an unused block in one work area.

The most distinctive feature of the analysis is that it has greatly reduced the time to check for empty blocks. Since the size of the work area is almost fixed regardless of the capacity of the flash memory, it can be estimated that B _fw also has a limit without increasing in proportion to the capacity. This is expected to be between 32 and 64MB, depending on the design.

Therefore, compared to the conventional log-based method, the time used to filter out unused blocks is greatly reduced, and the other time is the same, and the lost inode and the size of the data are caches for storing the journal. Proportional to size. However, you can expect better performance because you store journal data more frequently to manage your work area.

While the present invention has been described in connection with what is presently considered to be practical exemplary embodiments, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention.

Figure 1a is a system block diagram according to a preferred embodiment of the present invention, Figure 1b is a detailed block diagram of Figure 1a.

Figure 2 shows a journal block in the form of a C language structure according to a preferred embodiment of the present invention.

3 illustrates a page form in a JBT according to a preferred embodiment of the present invention in the form of a structure of a C language.

4 is a detailed block diagram of a super block according to a preferred embodiment of the present invention.

5 shows a state in which blocks are allocated according to a preferred embodiment of the present invention.

6 schematically illustrates an initialization and crash recovery process according to a preferred embodiment of the present invention.

* Description of the symbols for the main parts of the drawings *

10: flash memory 110: super block

120: journal block 130: data block

140: free block 20: operating system

210: work area control module 220: initialization module

230: Crash Recovery Module

Claims (14)

In the NAND flash file system, A flash memory divided into a plurality of blocks; A work area is defined by a predetermined number of blocks among the blocks, the blocks are divided into a plurality of the work areas, and the work area information is recorded and managed. Using an operating system to search for a work area in use immediately before a crash occurs, and to recover a crash using metadata of the searched work area; The operating system; A work area control module for setting and managing the work area; An initialization module for performing initialization of the NAND flash file system; And a crash recovery module for recovering a crash when a crash occurs during the initialization. The method of claim 1, The plurality of blocks A super block for storing a file system setting value for recording system setting information and a journal block table for recording metadata of the journal block; A journal block for recording journal information in the work area; A data block in which data and an inode are recorded; NAND flash file system comprising a free block that is not currently used. 3. The method of claim 2, In the spare area of the page in all the blocks NAND flash file system, characterized in that the error correction code and version are stored. 3. The method of claim 2, The journal block table (JBT) is It consists of one or more pages, each of which contains at least one of the number of journal blocks contained in the current page, whether or not the unmounted is normally performed, the starting block number of the current working area, and the starting block number of the next working area. NAND flash file system, characterized in that the recording including one. 3. The method of claim 2, The superblock Consists of a plurality of blocks, A duplicated block for preventing the loss of the super block data and recovering the lost when the super block data is lost; NAND flash file system comprising a spare block for extra data. 3. The method of claim 2, The journal block is Journals are cached in main memory and stored when the size of the journals in the cache reaches one page size, but when deleted for an inode outside the work area, the journals stored in the cache up to that time are immediately saved with the journal of that information. NAND flash file system, characterized in that. delete The method according to any one of claims 1 to 6, The work area control module If you set the workspace, if the cache is full of one-page journals, if there are inodes deleted outside of one workspace, or if there are no journal blocks assigned to the current workspace and additional allocation fails, NAND flash file system, characterized in that to move sequentially, the start block number of the next work area is recorded in the spare area of the page on which the journal is recorded when moving to the next work area. The method of claim 8, The work area control module If all the pages included in the block are writing unnecessary data, garbage collection is performed on the journal block and the data block by garbage collection. NAND flash file system characterized by performing a delete operation after writing the journal block table information of the superblock to the next super block. The method according to any one of claims 1 to 6, The initialization module When the valid superblock is extracted from the information stored in the extra area of the first page for each superblock, and the superblock having the most recent journal block table among the valid superblocks is extracted, the unmounting is performed correctly. NAND flash file system, characterized in that for performing the initialization by tracking the entire journal using the latest journal block table. The method according to any one of claims 1 to 6, The crash recovery module If the unmount was not performed correctly, it is determined that a crash has occurred, the journal information is read based on the most recent journal block table, the version information is used to find the last recorded journal, and the spare area of the page on which the journal is written. NAND flash file system, characterized in that to identify the most recent work area through the work area information recorded in the file, and to recover the metadata information while sequentially searching for blocks that have been changed in the work area but not recorded in the journal. A method for initialization and crash recovery of a flash memory file system having a plurality of blocks: Initializing the blocks by setting and managing a work area in units of a predetermined number of blocks; Sequentially searching a plurality of super blocks among the blocks to find a valid super block and a most recently stored journal block table (JBT); Reading an extra area of each page sequentially from journal information corresponding to the journal block table to identify an unmount flag; If the unmount flag indicates a crash, read journal information from the journal block table to build metadata of the flash memory file system, and simultaneously retrieve the most recent work area; next And recovering a crash by using the metadata of the most recent working area and the journal information of the journal block table. The method of claim 12, And wherein the most recent working area is found using version information stored in the spare area. The method according to claim 12 or 13, The method; If there is journal information changed in the work area but not written in the journal block, the method further includes recovering the crash by recovering the metadata while sequentially searching for super blocks and data blocks not recorded in the journal information; Initializing and crash recovery method of the flash memory file system, characterized in that.

Images