KR20210156682A - How to manage meta-data of a file system using a database management system - Google Patents

Abstract

The present invention relates to a method for managing metadata of a file system using a database solution. According to the present invention, metadata of a file system is managed using a database management system. Writing or reading data to disk does not go through any other file system or database management system. As the file system according to the present invention is directly performed, while a user is guaranteed stable transactions, an optimized disk allocation algorithm is designed and used according to the multimedia environment.

Description

How to manage meta-data of a file system using a database management system

The present invention relates to a file system, and more particularly, to a method for managing metadata of a file system using a database solution.

Unlike the past, with the recent development of multimedia technology, many home appliances such as PVR (Personal Video Recorder), camcorder, and mobile phone are being released with hard disk installed. is being actively pursued.

Consistency is a very important issue in a file system that determines various policies related to disk data input/output. File system consistency can be divided into metadata consistency and data consistency. Metadata of the file system includes information about I-nodes, directories, and free disk space, and information about free inodes. When performed as a transaction, the consistency of metadata can be maintained. Similarly, data consistency can be ensured by data transactions, and if a data transaction that updates a part of a file is aborted during the update, the data transaction is either complete or discarded as if it never happened in the first place. .

On the other hand, a database management system (hereinafter referred to as DBMS) reliably stores data using a fast and effective data structure and guarantees transactions. Conventionally, there has been an attempt to secure file system consistency by applying such a DBMS solution to an operating system (hereinafter referred to as an operating system).

1 is a diagram showing the configuration of a file system in which a database is introduced.

In the file system shown in FIG. 1, metadata and file data of the file system are managed by using the kernel Berkeley database (KBDM) as a DBMS, and the database is stored in the existing file system (Ext2). According to this configuration, all operations of the file system are performed through the DBMS.

For example, when reading a specific file, it accesses the DBMS and copies the file data stored in block.db to the buffer cache. When writing data to a file, the data stored in the buffer cache is copied to the corresponding record in block.db. ) is stored in In addition, since operations other than file I/O are also performed through the related database, the consistency of the file system can be guaranteed.

However, this file system (KBDBFS) is dependent on the file system (Ext2) in which the database is stored, and thus cannot be optimized for various environments. That is, DBMS (KBDB) merely provides transactional operations, and the size of the file system, disk allocation, etc. are determined by the file system in which the database is stored. For example, when these file systems store data to disk, the file system (KBDBFS) puts the data into DBMS (KBDB), and the DBMS (KBDB) stores data to disk via Ext2, so the file system (KBDBFS) cannot participate in the layout of the actual disk. Therefore, according to such a file system, even if an algorithm optimized for the environment is designed, there is a problem that blocks of the disk cannot be allocated by reflecting this. In addition, in a multimedia environment where the file size is large, the size of the log generated by the DBMS increases, so that the performance of the file system is deteriorated.

An object of the present invention is to provide a method in which metadata of a file system is managed using a DBMS and file data is directly input/output from/to a disk without going through the DBMS.

In order to achieve this object, the present invention provides a method for managing data in a file system, (a) a predetermined database management system (DataBase Management) that manages metadata of the file system as a data write request is received from an application System) to search for free space on the disk; (b) writing the data to an empty space of the disk without going through the database management system with reference to the search result; and (c) updating a part of the metadata that is changed as the data is written through the database management system.

Here, the steps (a) to (c) are preferably managed as one transaction by the database management system.

In addition, it is preferable that the file system operates at a user-level.

In addition, it is preferable that the disk on which the data is stored is separate from the disk on which the metadata is stored.

In step (c), among the metadata, a database table including information on empty space, a database table including information on space that is already in use, and a database including information on i-nodes It may include requesting the database management system to update at least one of the tables.

In addition, the present invention provides a computer-readable recording medium for executing the data management method in a computer.

Since the file system according to the present invention processes metadata of the file system through the API provided by the DBMS, it can ensure a stable transaction, and does not participate in the disk layout related to metadata, but is directly related to the file data. Because it controls the layout, it is possible to design and use an optimized disk allocation algorithm according to the multimedia environment.

In addition, in the file system according to the present invention, the DBMS only manages metadata and does not create a log related to the file data because the DBMS does not manage the file data, so that even if the file size increases, the performance of the file system does not deteriorate.

In addition, since the file system according to the present invention operates at the user level rather than the kernel level, the source code of the file system does not depend on the OS, so it is easy to port to other OSs and easy to maintain and maintain.

In addition, since the file system according to the present invention stores metadata and file data on separate disks, it is more efficient than the existing file system when inputting and outputting file data to the disk.

1 is a diagram showing the configuration of a conventional <1> file system for managing metadata using a database;
2 is a flowchart illustrating a process of storing data on a disk in a file system according to an embodiment of the present invention;
3 is a diagram illustrating a schema of a database storing metadata of a file system according to an embodiment of the present invention;
4 is a block diagram showing a file system according to an embodiment of the present invention;
5 is a flowchart illustrating a process of creating a file in a file system according to an embodiment of the present invention;
6 is a flowchart illustrating a process of writing a file in a file system according to an embodiment of the present invention;
7 is a flowchart illustrating a process of reading a file in a file system according to an embodiment of the present invention.

Hereinafter, with reference to the accompanying drawings, a preferred embodiment of the present invention will be described in detail.

2 is a flowchart illustrating a process of storing data on a disk in the file system according to the present invention.

In step 210, the file system according to the present invention is requested to write file data to the disk from the user's application. To this end, the file system according to the present invention must provide an application programming interface (API) of a user level corresponding to a system call to the application layer.

In step 220, the file system according to the present invention requests the DBMS managing metadata to start a transaction. Accordingly, operations on metadata performed after step 220 are considered as one transaction and protected.

In step 230, an empty space on the disk is searched for writing the file data requested by the application. At this time, the free space of the disk is searched through the DBMS by referring to the database table including information about the free space of the disk. A detailed description of the database schema managed by the DBMS will be described later with reference to FIG. 3 .

In step 240, the file data is written to an empty space of the disk. Depending on the situation, the number of empty blocks found in step 230 may be very large. In which block among the blocks the requested file data is stored may be determined by a disk allocation algorithm defined by a user. This is because, in the file system according to the present invention, metadata is managed by a conventional file system such as ext2 or DBMS, but reading or writing file data to the disk does not go through the DBMS or other file systems, but according to the present invention. This is because the file system does it directly (raw I/O). In other words, since the file system according to the present invention processes the metadata of the file system through the API provided by the DBMS, it does not participate in the disk layout related to the metadata, but directly controls the disk layout in relation to the file data, so it is suitable for the multimedia environment. Therefore, an optimized disk allocation algorithm can be used. In addition, since the DBMS does not manage the file data and does not create a log related to the file data, the performance of the file system does not deteriorate even if the size of the file increases.

In step 250, the DBMS is requested to update metadata that needs to be changed as file data is written to the disk in step 240. For example, database tables related to inodes, information on free space on the disk, information on used space on the disk, etc. will be updated.

In step 260, the DBMS requests the end of the transaction. Accordingly, since the DBMS regards the operations performed in steps 230 to 250 as one transaction, the file system metadata consistency is secured. For example, in step 250, if the database table including information on the used space is updated and the power is cut off due to a power failure before updating the database table including information on the free space on the disk, the DBMS will The update of the database table containing the information is treated as missing, and accordingly, the related data is not reflected in the metadata.

In addition, if step 250 is performed only when step 240 is completed, that is, when writing of file data is completed before proceeding to step 250, step 240 is also placed between step 220 and step 260 to ensure data consistency. can However, in order to improve file system performance, step 250 may be performed regardless of whether step 240 is completed.

On the other hand, in order to improve the performance of the file system, it may be desirable to separate the disk where the metadata is stored and the disk where the file data is stored.

3 is a table showing types of databases storing metadata of a file system according to an embodiment of the present invention.

The superblock database (super.db) stores information about the status of the file system and an inode bitmap.

Since the information of the entire file system can be stored in one record, and the inode bitmap also requires only a few records, this database has a data structure based on the record number (RECNO) and has a secondary index will not be needed

The directory database (directory.db) maps directory and file names to inode numbers.

The inode database (inode.db) maps the inode number to the file information of the file, such as the size of the file and the last modification time. When a new file is created, a new inode record is added to this database, and when a file is deleted, the related inode record is deleted from this database.

The freespace database (freespace.db) manages the free space of a partition. In this case, it is preferable that information about empty spaces in the database table is expressed in the form of an extent. This is because the size of information can be reduced when represented in a section format compared to represented in a bitmap format. The section format may be expressed as a block number designating the position where the blank space starts and the number of blocks corresponding to the size of the blank space. It can also be expressed in units. The file system according to the present invention searches the free space of the disk by referring to the free space database in order to write data to the file.

The span database (extents.db) maps the offset of the file to the block address of the section containing the file data.

4 is a block diagram illustrating a file system according to an embodiment of the present invention.

4, the file system according to the present invention is a Syscall module 402, a Namei module 403, a Super module 404, a Dir module 405, an Inode module 406, and a File module 407. , an Alloc module 408, a DBAL module 410 and an OSAL 409 module.

Also, in this embodiment, it is assumed that a Berkeley DB 411 is used as the DBMS, and the file system metadata is input/output to/from the disk by the ext3 412.

The Syscall module 402 provides an API that enables the application 401 to make a system call, and requests the DBMS 411 to start and end a transaction.

The Namei module 403 determines the database to be updated by analyzing the API function called by the application 401 . Super module 404 requests DBMS 411 to search and update super.db, Dir module 405 requests search and update dir.db, and Inode module 406 uses inode.db to Manage free inodes. The Alloc module 408 obtains information on the free space of the disk through the DBMS 411, and determines blocks to which file data is to be written using a disk allocation algorithm optimized for a multimedia environment or other environment. .

The File module 407 inputs/outputs file data to/from the disk through an OS module (not shown) operating at the kernel level, for example, writes data to a block device file or reads data from a block device file. method can be used to perform file data input/output.

DBAL (DB Abstract Layer) module 410 is an interface for compatibility with Syscall 402 and DBMS 411, and OSAL (OSAbstract Layer) is an interface that enables processing of block device files that may be different for each OS. .

Meanwhile, as shown in FIG. 4 , since the file system according to the present invention operates at the user level, the source code of the file system does not depend on the OS. Accordingly, compared to the file system operating at the kernel level, the file system according to the present invention is easy to port to other OSs, and it is also easy to maintain and maintain.

5 is a flowchart illustrating a process of creating a file in the file system shown in FIG. 4 . In this embodiment, it is assumed that the DBAL module and the OSAL module are not used.

In step 501, the application provides a file name to the Syscall module and requests to create a file, and in step 502, the Syscall module requests the DBMS to start a transaction. In step 503, the DBMS starts a transaction.

In step 504, the Syscall module requests the Namei module to create a file, and in step 505, the Namei module requests an inode to be assigned to a new file from the Super module. The Super module that has received the inode request from the Namei module requests the DBMS to search for and modify super.db in step 506 . Upon receiving this request, the DBMS refers to the inode bitmap, allocates an empty inode to a new file, and updates super.db (not shown).

In step 507, the Namei module requests the Dir module to register a new file in the directory, and in step 508, the Dir module requests the DBMS to search and modify dir.db. The DBMS receiving this request maps the name of the new file and the corresponding inode and stores it in dir.db (not shown).

In step 509, the Namei module requests the Inode module to initialize a new inode, and in step 510, the Inode module requests the DBMS to register information about the new inode in inode.db. Upon receiving this request, the DBMS stores information related to the new file in the inode corresponding to the new file (not shown).

When the execution of step 510 is completed, in step 511, the Namei module notifies the Syscall module that the file creation has been completed, and in step 512, the Syscall module requests the DBMS to terminate the transaction. In step 513, the DBMS ends the transaction started in step 503.

6 is a flowchart illustrating a process of writing data to a file in the file system shown in FIG. 4 . In this embodiment, it is assumed that the DBAL module and the OSAL module are not used.

In step 601, the application requests the Syscall module to write data to the file. At this time, the file name, data, data size, and offset information in the file are transmitted. In step 602, the Syscall module requests the DBMS to start a transaction, and the DBMS starts the transaction in step 603.

In step 604, the Syscall module requests a write operation from the File module, and in step 605, the File module requests information about an empty block of the partition from the Alloc module. Upon receiving this request, the Alloc module requests the DBMS to search for and modify freespace.db (606). Upon receiving this request, the DBMS searches freespace.db to find free blocks, and in step 607 delivers information about the empty blocks to the Alloc module.

In step 608, the Alloc module delivers information on blocks to which data is to be written among empty blocks of the partition to the File module. At this time, the information on the blocks delivered may be different from the information on the empty blocks delivered by the DBMS in step 607 .

That is, in step 607, the DBMS notifies all empty blocks of the partition, but the Alloc module uses a predetermined disk allocation algorithm to determine the blocks to which data is to be written, and then delivers them to the File module. Therefore, the user can freely design the disk allocation algorithm and implement it in the Alloc module to create a file system optimized for the multimedia environment, breaking away from the fixed disk allocation method by the existing file system.

In step 609, the File module sends a partition name, offset information within the partition, data and size of data to the OS module operating in kernel mode and makes a write request (raw input), and in step 610, the OS module receives the received information Writes data to disk based on

In step 611, the OS module notifies the File module that writing has been completed, and in step 612, the File module notifies the Inode module that writing is complete. In step 613, the Inode module requests the DBMS to update inode.db to reflect the changes that have occurred in the file. Accordingly, the DBMS will change information on the last change time of the corresponding file, the file size, and the like (not shown). Also, in step 614, the File module requests the DBMS to modify extents.db. Upon receiving this request, the DBMS updates extents.db to reflect the information on the newly written block (not shown).

In step 615, the File module notifies the Syscall module that writing has been completed, and in step 616, the Syscall module requests the DBMS to end the transaction. In step 615, the DBMS ends the transaction started in step 603.

7 is a flowchart illustrating a process of reading data from the file system shown in FIG. 4 . In this embodiment, it is assumed that the DBAL module and the OSAL module are not used.

In step 701, the application informs the Syscall module of the file name, offset information in the file, and the size of the data, and requests to read the data. In step 702, the Syscall module requests the File module to read the data, and in step 703, the File module requests the Inode module for information about the relevant block.

Upon receiving this request, the Inode module requests the DBMS to search for extents.db in step 704, and the DBMS searches extents.db to extract information about the block in which the data is located, and then returns the information extracted in step 705 to the Inode module. pass it on to In step 706, the Inode module transmits block information to the File module, and in step 707, the File module informs the OS module of the partition name, offset information within the partition, and the size of data, and requests to read the data (rawoutput). In step 708, the OS module reads the corresponding data from the disk, and transmits the data read in step 709 to the File module. In step 710, the File module delivers data to the Syscall module, and in step 711, the Syscall module delivers data to the application, thereby completing the read process.

Meanwhile, the above-described embodiments of the present invention can be written as a program that can be executed on a computer, and can be implemented in a general-purpose digital computer that operates the program using a computer-readable recording medium.

The computer-readable recording medium includes a magnetic storage medium (eg, ROM, floppy disk, hard disk, etc.), an optically readable medium (eg, CD-ROM, DVD, etc.) and a carrier wave (eg, Internet storage media such as transmission).

So far, the present invention has been looked at with respect to preferred embodiments thereof. Those of ordinary skill in the art to which the present invention pertains will understand that the present invention can be implemented in a modified form without departing from the essential characteristics of the present invention. Therefore, the disclosed embodiments are to be considered in an illustrative rather than a restrictive sense. The scope of the present invention is indicated in the claims rather than the foregoing description, and all differences within the scope equivalent thereto should be construed as being included in the present invention.

Claims (5)

A method for managing data in a file system, the method comprising:
(a) searching for an empty space on the disk through a database management system that manages metadata of the file system as a data write request is received from an application;
(b) writing the data to an empty space of the disk without going through the database management system with reference to the search result; and
(c) updating a part of the metadata that is changed as the data is written through the database management system. The method of claim 1,
Steps (a) to (c) are managed as one transaction by the database management system. The method of claim 1,
The method according to claim 1, wherein the file system operates at a user-level. The method of claim 1,
The method of claim 1, wherein the disk on which the data is stored is separate from the disk on which the metadata is stored. The method of claim 1,
In step (c), among the metadata, a database table including information on empty space, a database table including information on space already in use, and a database table including information on i-nodes Method comprising the step of requesting the database management system to update at least one of the.

Images