KR102033323B1 - Method for storing metadata of log-structured file system for flash memory - Google Patents

Abstract

The present invention relates to a method for storing data in a Log-structured File System (LFS), and includes a checkpoint record when recording a checkpoint without separately storing segment summary information (SS) and segment usage information (SU). The present invention relates to a method of improving the write performance of a flash memory by reducing the number of metadata that must be written to a flash page by writing the data in a recorded file.

Description

Method for storing metadata of log-structured file system for flash memory}

The present invention relates to a data storage method of a log-structured file system (LFS), and more particularly, to improve the write performance of a flash memory by reducing the number of metadata to be written to a flash page. It is about a method.

Flash memory is widely used as a storage device in various embedded systems because of its low cost, low power consumption and small size.

In particular, the NAND flash memory, which is one of the widely used types of flash memory, is composed of several erase unit blocks, and each erase unit block is composed of several pages. In addition, in the case of a large block NAND flash memory, which has recently increased in use, one page is 2KB in size and 64 pages are collected to form one erase unit block.

Flash memory can perform three operations: Read, Write, and Erase. Read / write is made up of pages, and writing is called a program. To reprogram a page once programmed, the entire erase unit block to which the page belongs must be erased, which takes much longer than read / write. In addition, each deletion unit block has a limit on the number of times that can be deleted, and when the number of deletions reaches the limit, the corresponding deletion unit block cannot be used. Delete unit blocks that are no longer usable correspond to bad blocks. Therefore, wear-leveling to ensure that each erase unit block is used evenly can ensure sufficient lifespan of the flash memory.

As described above, there is a problem in that a flash memory requires a long processing time to rewrite the data once recorded, and a block of the flash memory becomes more worn as it is used and becomes unusable when the limit is reached. Accordingly, a method of solving the above problem by processing a data by performing a specific operation in a file system corresponding to a higher layer of a flash memory has been proposed.

The typical file system used for flash memory is the Log-structured File System. Log Structure The file system stores data in a way that sees the storage space as a single log and records both the metadata and data of the file system in a log.

These log structure file systems include the Sprite LFS, which implements the Log Structure File System (LFS) in the Sprite operating system, and the F2FS (Flash-Friendly), which is adapted to use the Sprite LFS structure for FTL (Flash Translation Layer) based flash storage. File System) and the New Implementation of a Log-structured File System (NILFS2), which provides snapshot capabilities.

Korea Patent Publication 10-2012-0072228

An embodiment of the present invention is to provide a method that can increase the write performance of the file system by reducing the number of writes required to make the file system a consistent state.

The metadata storage method of the file system according to an embodiment of the present invention comprises the steps of: allocating a block to store information to be recorded, generating a segment summary information (SS) record for the allocated block, and recording the temporary list; Generating a segment usage information (SU) record for the segment in which the blocks in which the segment summary information record is generated are recorded in the temporary list, the segment summary information record and the segment usage information recorded in the temporary list; And including at least one of the records in a checkpoint record and recording the checkpoint record at an assigned location.

According to another aspect of the present invention, there is provided a method of storing metadata in a file system, the method comprising: allocating a block to store information to be recorded, a segment summary information (SS) record for the allocated block, and the segment summary information record. Generating a segment usage information (SU) record for the segment in which the blocks are located; and including at least one of the segment summary information record and the segment usage information record in a checkpoint record and recording it in a pre-assigned position It may include.

The embodiment of the present invention can increase the write performance of the file system by reducing the number of writes necessary to bring the file system to a consistent state.

1 is a view showing the structure of a storage space according to an embodiment of the present invention.
FIG. 2A is a diagram illustrating a structure of block-by-block segment summary information (SS) entries according to an embodiment of the present invention. FIG.
FIG. 2B is a diagram illustrating the SS entries of FIG. 1A configured in a table form. FIG.
3A is a diagram illustrating a structure of a segment usage information (SU) entry according to an embodiment of the present invention.
FIG. 3B is a diagram showing the SU entries of FIG. 3A configured in a table form. FIG.
4A illustrates the structure of a checkpoint record in accordance with one embodiment of the present invention.
4B and 4C are diagrams illustrating structures of an SS record and an SU record included in the SS / SU record list of the checkpoint record, respectively.
5 is a flowchart for explaining a process in which a file system writes a checkpoint record.
6 and 7 illustrate a method of recording a checkpoint record using a plurality of checkpoint segments.
FIG. 8 is a flowchart illustrating a process of reflecting SS records and SU records included in a checkpoint record to be deleted in segment summary information and segment usage information when the old version of the checkpoint record is deleted.
9 illustrates a structure of a metadata file in a NILFS2 file system as an embodiment of the present invention.
FIG. 10 illustrates a structure of a storage space in a NILFS2 file system as an embodiment of the present invention. FIG.
11 illustrates a metadata synchronization process according to an embodiment of the present invention.
12 illustrates a structure of a storage space in an F2FS file system as another embodiment of the present invention.
13 is a diagram illustrating a metadata synchronization process according to another embodiment of the present invention.

Hereinafter, with reference to the accompanying drawings will be described in detail a preferred embodiment of the present invention. Prior to this, terms or words used in the present specification and claims should not be construed as being limited to the common or dictionary meanings, and the inventors should properly explain the concept of terms in order to best explain their own invention. Based on the principle that can be defined, it should be interpreted as meaning and concept corresponding to the technical idea of the present invention. Therefore, the embodiments described in the specification and the drawings shown in the drawings are only the most preferred embodiments of the present invention and do not represent all of the technical idea of the present invention, various modifications that can be replaced at the time of the present application It should be understood that there may be equivalents and variations.

1 is a view showing the structure of a storage space according to an embodiment of the present invention.

The file system according to an embodiment of the present invention stores data and metadata corresponding to the data in a storage space. In this case, the metadata includes inode information and checkpoint information, and includes segment summary information (SS) and segment usage information (SU) for garbage collection.

Storage space is divided into segments, and each segment is divided into blocks. In this case, the size of the segment / block is preferably matched to the size of an erase block / page of the flash memory. For example, a large block NAND flash memory having a page size of 2 KB and an erase block size of 128 KB may have a block size of 2 KB and a segment size of 128 KB.

Inode information in metadata is information for accessing an inode representing a file, and any of inode information used in a conventional file system may be used. For example, the inode information in this embodiment may use any of an inode map of a Sprite LFS, a NAT of F2FS, or an IFILE of NILFS2.

FIG. 2A is a diagram illustrating a structure of segment summary information (SS) entries for each block according to an embodiment of the present invention, and FIG. 2B is a diagram illustrating SS entries of FIG. 2A configured in a table (SS table) form.

Segment summary information (SS) includes a block-specific SS entry, one for each block in the segment. The SS entry for each block includes an inode number and a file block number. At this time, the file block number is information indicating which part of the file the block constitutes, for example, the number of blocks within the file. That is, the file block number does not mean the number of each block constituting the segment. Segment summary information (SS) is a group of these SS entries for each block to form a table as shown in Figure 2b. At this time, the index indicating the order in the table corresponds to the block number. Therefore, the SS entry in this embodiment does not include the block number separately.

FIG. 3A is a diagram illustrating a structure of a segment usage information (SU) entry according to an embodiment of the present invention, and FIG. 3B is a diagram illustrating the SU entries of FIG. 3A configured in a table (SU table) form.

The segment usage information SU includes one SU entry that exists for each segment. The SU entry contains information about the number of valid blocks in the segment and the last time recorded in the segment. At this time, the effective number of blocks in the segment literally represents the number of valid blocks in the segment. For example, if a file is changed and the old block becomes invalid, the value of this field (the number of valid blocks in the segment) of the segment including the block is decreased. Segment usage information is a collection of these SU entries to form a table as in FIG. 3B. At this time, the index indicating the order in the table corresponds to the segment number. Therefore, the SU entry in this embodiment does not include the segment number separately.

4A is a diagram illustrating a structure of a checkpoint record according to an embodiment of the present invention, and FIGS. 4B and 4C are diagrams illustrating structures of an SS record and a SU record included in an SS / SU record list of a checkpoint record, respectively. to be.

The record unit of a checkpoint is a checkpoint record, and one checkpoint record occupies one block as storage space for storing it. Each checkpoint record includes checkpoint information and a list of SS / SU records.

The checkpoint information includes checkpoint write time or version information (e.g., version number) to distinguish which record is up to date. The version number is a counter that increments by one for each record.

The SS / SU record list is information stored and listed one by one in the order in which the SS records and the SU records arrive in the list. In this case, the SS record includes a record type, a block number, an inode number, and a file block number, as shown in FIG. 4B, and the SU record includes a record type, a segment number, an effective number of blocks in a segment, and a segment recording time, as shown in FIG. 4C. do. That is, the SS record has a structure in which a record type and a block number are added to the SS entry of FIG. 2A, and the SU record has a structure in which a record type and segment number are added to the SU entry of FIG. 3A. The record type is information for distinguishing the SS record and the SU record. Therefore, when both the SS record and the SU record are included in the SS / SU record list field, information about the record type is required. However, if only one of the SS record and the SU record is included, the information about the record type is not necessary.

5 is a flowchart illustrating a process in which a file system records a checkpoint record.

When data to be recorded occurs in response to an input / output (I / O) request of a user application program, a separate process in the operating system requests the file system to record the data in the storage device (step 402).

The filesystem determines a storage location to store the data at the request of the process (step 404). That is, the file system allocates a block number.

If a block number is assigned, the file system generates an SS record as shown in FIG. 4B (step 406) and adds it to the end of the temporary SS / SU record list (step 408).

Next, the file system identifies the segment in which the blocks in which the SS record is generated are located and generates a SU record as shown in FIG. 4C (step 410), and then adds the generated SU record to the end of the temporary SS / SU record list (step 412). ).

The blocks that generate the SS record and the SU record are written to storage.

The next time a user application needs to write a checkpoint, such as by calling the sync () system call (step 414), the filesystem will determine the size of the temporary SS / SU record list and the SS / SU record within the checkpoint record. The size of the space available as a list (space except the checkpoint information in the block size) is checked to determine whether all records in the temporary SS / SU record list can be recorded in the checkpoint record (step 416).

In step 416, if the space available for the SS / SU record list is larger than the size of the temporary SS / SU record list, the filesystem includes all records in the temporary SS / SU record list in the checkpoint record (step 418).

However, in step 416, if the space available for the SS / SU record list is not larger than the size of the temporary SS / SU record list, the file system cannot write the temporary SS / SU by an amount that cannot be included in the checkpoint record. It is removed from the beginning of the record list and directly reflected in the segment summary information SS and the segment usage information SU, and the remaining part is included in the checkpoint record (step 420).

Next, the file system writes the version number or the current time (recording time) in the checkpoint information field of the checkpoint record (step 422).

Next, the file system writes the checkpoint record to the assigned location (step 424) and then initializes the temporary SS / SU record list (step 426).

6 and 7 are diagrams for describing a method of recording a checkpoint record using a plurality of checkpoint segments.

The filesystem can use at least two segments for checkpoint storage. In other words, because checkpoints are very important information for filesystem mounts, the filesystem ensures that checkpoint information is written to two or more NAND flash memory erase blocks so that even if one erase block fails, the other removes it. You can use checkpoints written in blocks.

The segment used to store the checkpoint record is called the checkpoint segment. A checkpoint record, which is a checkpoint record unit, occupies one block. Whenever a checkpoint record is required, the filesystem writes the checkpoint record in order, starting with the first block of the selected checkpoint segment. At this time, each checkpoint record must include a version number (counter that increments by one for each write) or checkpoint write time to distinguish which is the latest record.

However, since the space reserved for the checkpoint segment is limited, the available space may be exhausted when used. Therefore, the filesystem should be used while deleting older versions of checkpoint records. However, if you simply delete the old version of the record, the changes you made to the SS and SU records are lost, so the filesystem will display the contents of the SS and SU records contained in that checkpoint record before deleting them. (SS) and the segment usage information SU of FIG. 3B.

There are two ways that the filesystem deletes (removes) older versions of records.

6 is a diagram for describing a method of deleting an old version of a checkpoint record according to an embodiment of the present invention.

The filesystem starts writing to another segment when the block in the checkpoint segment in use runs out. At this point, the filesystem flushes all previously used segments before the block of the checkpoint segment that has just started recording runs out.

For example, as shown in FIG. 6, when two segments are used to store a checkpoint record and each segment is composed of four blocks, the file system is configured to have a second segment (if the first segment (segment 1) runs out of blocks). Start recording in Segment 2). In this case, the number in the box (block) in FIG. 6 means a version number.

The filesystem empties all of the first segment before all the blocks in the second segment are used up, and then starts writing back to the first segment when the second segment fills up.

Similarly, the filesystem deletes all the second segment again before all the blocks of the first segment are used up.

7 is a diagram for describing a method of deleting an old version of a checkpoint record according to another embodiment of the present invention.

In the embodiment of FIG. 7, as in the embodiment of FIG. 6, the records of the previously used segments are not deleted beforehand, but the old records are sequentially overwritten. In other words, if the filesystem fills up the second segment, it will start overwriting the oldest record in the first segment. In this embodiment, since the overwrite is performed, the method can be used only when there is an FTL under the file system.

FIG. 8 reflects the SS record and the SU record included in the checkpoint record to be deleted when the old version of the checkpoint record is deleted in the segment summary information SS and the segment usage information SU, as shown in FIG. 6 or 7. This is a flowchart to explain the process.

For the checkpoint records to be deleted, the following steps are performed in order from the first recorded based on the version number or the recording time in the record, for example.

First, the file system prepares each checkpoint record (step 802).

To do this, the file system imports a checkpoint record in memory after writing in the above-described checkpoint record writing process, and reads the checkpoint record from storage if it does not.

The file system then adds the SS record and the SU record in the SS / SU record list field of each checkpoint record to the end of the synchronization list (step 804).

The file system then checks the record type and block number or segment number included in the SS record or SU record in order from the beginning of the synchronization list (step 806).

In other words, if the record is an SS record, the file system checks the record type and block number. If the record is an SU record, the file system checks the record type and the segment number. Through this, the file system can know what number of entries the corresponding SS record or SU record is in the table of FIG. 2B or 3B.

Next, the file system overwrites the entry information of the record to be recorded with the entry corresponding to the corresponding block number or segment number in the SS table or the SU table (step 808).

For example, if the record is an SS record, the file system assigns the inode number and file block number of the SS record to the inode number and file corresponding to the corresponding block number (block number identified in step 806) in the SS table of FIG. 2B. Overwrite the block number.

<Example 1>

When the above-described embodiment of the present invention is applied to a log structure file system (LFS) having inode information, checkpoint information, segment summary information, and segment usage information, it will be described based on a simple scenario as follows.

At this time, the structure of the target environment and the virtual LFS is as follows.

Storage: NAND flash memory (no FTL)

File index: inode pointer structure

-Inode Information: Inode Table / Bitmap

-Complete Metadata Configuration: Metadata is included in the file like NILFS2, and metadata file is divided into IFILE and SUFILE as shown in FIG.

The storage space is divided as shown in FIG. 10, and the number in the box means the segment number.

In this case, the superblock stores information about the checkpoint area, information about the SUFILE inode area, and information about the log area (where the log area starts). Is an area that contains important information that is not used. This superblock is allocated one segment.

The checkpoint area is an area used as a checkpoint segment in the present invention. Because the metadata is written to a file, the checkpoint information in the checkpoint record includes the inode for the IFILE. The checkpoint area is allocated two segments.

The SUFILE checkpoint area is an area where a checkpoint for SUFILE is recorded. In this embodiment, since the segment usage information is separated from the IFILE into a separate file, SUFILE also needs a checkpoint. If you include a version number or record time in the SUFILE's inode itself, that's the SUFILE checkpoint record. This area can be operated according to the checkpoint storage method. The SUFILE checkpoint area is allocated two segments.

The log is a space in which the blocks constituting the metadata file and the general file are written, and includes the remaining space except those used in the first three areas (super block, checkpoint area, and SUFILE checkpoint area).

In the following description, for convenience of description, a case in which only the segment usage information SU is included in the checkpoint record will be described. It is assumed that the segment is composed of four blocks. In addition, it is assumed that the file system format is completed and the storage space is allocated as shown in FIG. 10, and the normal files are normally recorded after the metadata file has already been recorded in the log. In this situation, the contents of the existing files are partially changed.

Step 1.

When a request is received to write the change history of the file A to the storage device, this causes a situation in which four data blocks and one index block need to be written as shown in FIG. 11A. In FIG. 11A, a block indicated by a dot among blocks in which A ′ is written represents a data block, and a block indicated by hatching in one direction represents an index block.

As a result, four changes to the segment summary information (SS) and four changes to Inode A occur, but the file system displays them in memory only once.

Step 2.

Next, when a request is received to write the change history for the file B to the storage device, this causes a situation in which two data blocks and one index block need to be written as shown in FIG. 11B. In FIG. 11B, a block indicated by a dot among blocks in which B 'is written represents a data block, and a block indicated by hatching in one direction represents an index block.

This results in two changes to the SSS and two changes to Inode B, but the filesystem likewise only displays them in memory once.

Step 3.

When the entire synchronization request is received to maintain the consistency of the file system, as shown in FIG. 11C, the file system reflects the two inode changes for the files A and B previously generated in the inode table of the IFILE. Use two blocks of IFILE. In addition, one block of the IFILE is used to reflect eight changes in the segment summary information (SS) that occurred earlier in the segment summary information (SS) portion of the IFILE.

In Segment X + 2 of FIG. 11C, the first and second block parts mean an inode table change part, and the third block part means segment use information change part.

Two SU records in the temporary SU record list are inserted into the checkpoint record and stored at checkpoint write. To this end, changes are made to the checkpoint region as shown in FIG. 11D.

In FIG. 11D, the number 5 means the version number, and a version 5 checkpoint record is recorded in the block.

In the above-described embodiment, a total of four blocks are used for metadata synchronization while performing steps 1 to 3. If the present invention is not applied to the change of the segment usage information (SU), one block is consumed to reflect in the SUFILE, and two blocks must be used again in segments 3 and 4 to store the SUFILE inode. You might have written more blocks. Certain applications frequently make these synchronization requests, so the difference between the application of this invention and the case of non-application will be a big difference.

<Example 2>

In Example 1 described above, it is shown what happens when the present invention is applied to a situation of using a NAND flash memory without FTL. In the present embodiment (Example 2), an example in which an FTL is present is applied to another virtual LFS.

Since the FTL can be overwritten, the metadata configuration and recording method is different from the case where the FTL is not made as in the first embodiment. In such a case, it is an object of the present embodiment to show that the present invention can be applied to improve the effect.

The structure of the target environment and the virtual LFS in this embodiment is as follows.

Storage: eMMC or SD card (NAND flash memory based storage with FTL)

File index: inode pointer structure

Inode Information: Inode Map (as used by Sprite LFS)

Full Metadata Configuration: FTLs can be overwritten so metadata is not treated as a file, instead specify a storage location for each metadata item and changes are overwritten there

The storage space is divided as shown in FIG. 12, and the number in the box means the segment number.

In this case, the superblock is an area including important information such as a location where each metadata item (checkpoint, IMAP, SU, SS) is stored. This superblock is allocated one segment.

The checkpoint area is an area used as a checkpoint segment in the present invention. In order to use the checkpoint storage space operating method according to the present invention, since at least two segments are required, the present embodiment allocates two segments.

The IMAP area is an area for storing the inode map. The location of each inode is recorded in a table form.

The SU area is an area in which segment usage information is stored. Since there is one table entry for each segment, the size required to store segment usage information varies in proportion to the size of the entire storage space. However, in the present embodiment, it is assumed that only one segment is needed for convenience.

The SS area is an area in which segment summary information is stored. Like the SU area, the required size varies in proportion to the size of the total storage space, but for convenience, it is assumed that only two segments are required.

The log area is a space where general data, not metadata, is recorded. It is used for metadata and uses the remaining space.

In the following description, as in the first embodiment, a case in which only the segment usage information SU is included in the checkpoint record is described for convenience of explanation, and it is assumed that the segment is composed of four blocks.

Step 1.

When a request is received to write the change history of the file A to the storage device, this causes a situation in which four data blocks and one index block need to be written as shown in FIG. 13A. In FIG. 13A, a block indicated by a dot among blocks in which A ′ is written represents a data block, and a block indicated by hatching in one direction represents an index block.

As a result, four changes to the segment summary information (SS) and four changes to Inode A occur, but the file system displays them in memory only once.

Step 2.

Next, when a request is received to write the change history of the file B to the storage device, this causes a situation in which two data blocks and one index block need to be written as shown in FIG. 13B. In FIG. 13B, a block indicated by a dot among blocks in which B ′ is written represents a data block, and a block indicated by hatching in one direction represents an index block.

This results in two changes to the SSS and two changes to Inode B, but the filesystem likewise only displays them in memory once.

Step 3.

When a full synchronization request is received to maintain the consistency of the filesystem, the filesystem allocates a block to each new inode of the two files (A, B) that were changed in steps 1 and 2 above. It should be recorded. As a result, the log is changed as shown in FIG. 13C. In FIG. 13C, IA 'represents the new inode of file A and IB' represents the new inode of file B. In FIG.

The filesystem then reflects the location of the new inodes (IA ', IB') that have been relocated in the inode map, and records eight changes to the SS that were only displayed in memory in steps 1 and 2. Reflected in the SS region of FIG. To this end, as shown in FIG. 13D, one block of the third segment in which the inode map is located is changed, and one block of the fifth segment in which the SS is located is changed.

Next, the file system inserts the SU records of the temporary SU record list into the checkpoint record and stores them at checkpoint write. For this purpose, one block is recorded in the checkpoint area as shown in FIG. 13E.

In step 3 of the present embodiment, when the present invention is not applied, the file system must additionally record at least one of the blocks located in the segment 4, which is the SU storage area, in order to reflect the SU change. If the location where the SU change for the steps 1 and 2 is to be recorded corresponds to several blocks, recording should be performed for each block.

Briefly summarized the contents of the invention as follows.

When synchronizing metadata in the log structure file system, which consists of four items of metadata: inode information, checkpoint information, segment summary information, and segment usage information, no matter how small each item is modified You must record at least four times, because each of the four must be recorded separately. By the way, the checkpoint information necessary for restoring file system consistency is smaller than the size of a typical block (usually a multiple of the page size of flash memory). Accordingly, in the present invention, the number of recordings required for synchronization is reduced by 'identifying and recording' the segment summary information and the change of the segment usage information in the space left in the checkpoint record.

Preferred embodiments of the present invention described above are intended for purposes of illustration, and those skilled in the art will be able to make various modifications, changes, substitutions and additions through the spirit and scope of the appended claims, and such modifications may be made by the following patents. It should be regarded as belonging to the claims.

Claims (17)

In the way the file system stores data in flash memory,
Allocating a block in which information to be recorded is to be stored;
Generating segment summary information (SS) records for the allocated blocks and writing them to a temporary list;
Generating a segment usage information (SU) record for a segment in which blocks in which the segment summary information record is generated are recorded and recorded in the temporary list;
Including at least one of the segment summary information record and the segment usage information record recorded in the temporary list in a checkpoint record; And
Recording the checkpoint record at an assigned location;
Including in the checkpoint record
Checking the size of the temporary list and the size of the reserved space in the checkpoint record; And
If the size of the pre-booked space is smaller than the temporary list size, the segment summary information (SS) and the segment usage information which are stored in advance by removing an amount not included in the checkpoint record from the beginning of the temporary list. SU) directly reflects and the rest of the file system metadata storage method for including the remaining part in the checkpoint record. The method of claim 1, wherein the segment summary information record is
A method for storing metadata of a file system, comprising an inode number and a file block number. The method of claim 2, wherein the file block number is
A method for storing metadata of a file system, wherein the block is a number indicating which part of the file. The method of claim 1, wherein the segment usage information record is
A method of storing metadata of a file system, comprising information on the number of valid blocks in a segment and the last time recorded in the segment. The method of claim 1,
Before writing the checkpoint record to the assigned location,
And writing checkpoint information to the checkpoint record. The method of claim 5, wherein the checkpoint information is
A method for storing metadata of a file system, including version information or checkpoint write time. delete 2. The method of claim 1, wherein recording the checkpoint record at an assigned location
And storing the checkpoint record sequentially from the first block of the preset checkpoint segment. 9. The method of claim 8, wherein recording the checkpoint record at an assigned location
Sequentially writing the checkpoint record to a first checkpoint segment;
Sequentially recording the checkpoint record in a second checkpoint segment when the first checkpoint segment is exhausted;
Deleting all checkpoint records recorded in the first checkpoint segment before the second checkpoint segment is exhausted; And
And if the second checkpoint segment is exhausted, rewriting the checkpoint record in the first checkpoint segment. The method of claim 9,
Before deleting all the checkpoint records recorded in the first checkpoint segment, the contents of the segment summary information record and the segment usage information record included in the checkpoint record to be deleted are stored in the segment summary information (SS) and the segment usage information. Meta data storage method of the file system, characterized in that reflected in (SU). 9. The method of claim 8, wherein recording the checkpoint record at an assigned location
Sequentially writing the checkpoint record to a first checkpoint segment;
Sequentially recording the checkpoint record in a second checkpoint segment when the first checkpoint segment is exhausted; And
And when the second checkpoint segment is used up, overwriting the oldest checkpoint record in the first checkpoint segment with a checkpoint record to be newly recorded. Storage method. The method of claim 11,
Before the overwriting, the contents of the segment summary information record and the segment usage information record included in the checkpoint record to be deleted are reflected in the previously stored segment summary information (SS) and the segment usage information (SU). How metadata is stored. In the way the file system stores data in flash memory,
Allocating a block in which information to be recorded is to be stored;
Generating a segment summary information (SS) record for the assigned block and a segment usage information (SU) record for the segment in which the blocks where the segment summary information record is generated are located; And
Including at least one of the segment summary information record and the segment usage information record in a checkpoint record to record at a pre-assigned location,
The recording step
Comparing the size of at least one record to be included in the checkpoint record and the size of the pre-allocated position among the segment summary information record and the segment usage information record, and the size of the pre-allocated position is included in the checkpoint record. When smaller than the size of at least one record, the segment summary information (SS) and the segment usage information which are previously stored by removing an amount which cannot be included in the checkpoint record from the front of the at least one record to be included in the checkpoint record. Metadata storage method of the file system to reflect directly to the SU and include the remaining part in the checkpoint record. The method of claim 13, wherein the segment summary information record is
A method for storing metadata of a file system, comprising an inode number and a file block number. The method of claim 13, wherein the segment usage information record is
A method of storing metadata of a file system, comprising information on the number of valid blocks in a segment and the last time recorded in the segment. The method of claim 13,
Before writing the checkpoint record to the assigned location,
And writing checkpoint information to the checkpoint record. The method of claim 16, wherein the checkpoint information is
A method for storing metadata of a file system, including version information or checkpoint write time.

Images