US20070226219A1 - Method of managing data of file system using database management - Google Patents

Method of managing data of file system using database management Download PDF

Info

Publication number
US20070226219A1
US20070226219A1 US11/717,061 US71706107A US2007226219A1 US 20070226219 A1 US20070226219 A1 US 20070226219A1 US 71706107 A US71706107 A US 71706107A US 2007226219 A1 US2007226219 A1 US 2007226219A1
Authority
US
United States
Prior art keywords
data
dbms
file
file system
disk
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/717,061
Inventor
Joo-young Hwang
Min-sung Jang
Jae-Kyoung Bae
Ha-young Kim
Alexander Kirnasov
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Priority to US11/717,061 priority Critical patent/US20070226219A1/en
Assigned to SAMSUNG ELECTRONICS CO., LTD. reassignment SAMSUNG ELECTRONICS CO., LTD. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BAE, JAE-KYOUNG, HWANG, JOO-YOUNG, JANG, MIN-SUNG, KIM, HA-YOUNG, KIRNASOV, ALEXANDER
Assigned to SAMSUNG ELECTRONICS CO., LTD. reassignment SAMSUNG ELECTRONICS CO., LTD. A CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE ADDRESS ON REEL 019057 FRAME 0483 Assignors: BAE, JAE-KYOUNG, HWANG, JOO-YOUNG, JANG, MIN-SUNG, KIM, HA-YOUNG, KIRNASOV, ALEXANDER
Publication of US20070226219A1 publication Critical patent/US20070226219A1/en
Priority to US13/904,493 priority patent/US9384201B2/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/13File access structures, e.g. distributed indices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/16File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • G06F16/164File meta data generation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/17Details of further file system functions
    • G06F16/1727Details of free space management performed by the file system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/1865Transactional file systems

Definitions

  • the present invention relates to a file system, and more particularly, to a method of managing data of a file system using a database management system.
  • Consistency of a file system can be divided into consistency of metadata and consistency of data.
  • the metadata of a file system includes information about an inode, a directory, a free space of a disk, and a free inode. If operations related to these metadata items are performed as a transaction, the consistency of the metadata can be maintained.
  • the consistency of data can be maintained through a data transaction, and if a data transaction for updating part of a file is aborted in the middle of the update operation, the data transaction is completed or discarded as if the transaction had never been performed to begin with.
  • DBMS database management system
  • FIG. 1 is a block diagram illustrating a structure of a related art file system employing a database.
  • the metadata and file data of a file system are managed by using a kernel Berkeley database (KBDB), and the database is stored in a traditional file system (e.g., Ext2).
  • KBDB kernel Berkeley database
  • Ext2 traditional file system
  • the DBMS when a predetermined file is read, the DBMS is accessed, and file data stored in block.db is copied into a buffer cache, and when data is written in a file, data stored in the buffer cache is stored in a record corresponding to the data in block.db. Operations other than file input and/or output operations are also performed by using the DBMS, and thus the consistency of the file system can be guaranteed.
  • this KBDB file system (KBDBFS) cannot be optimized with respect to a variety of environments. That is, the DBMS (KBDB) provides only transactional operations, and the size of a file system, disk allocation, and the like are determined by a file system storing databases. For example, when data is stored on a disk in this file system, the file system (KBDBFS) inputs data into the DBMS (KBDB) and the DBMS (KBDB) stores the data on the disk by using the traditional file system Ext2 and thus the file system (KBDBFS) cannot participate in the layout of the actual disk.
  • the present invention provides a method by which metadata of a file system is managed using a database management system (DBMS) while file data is directly input to or output from a disk without involvement of the DBMS.
  • DBMS database management system
  • a method of managing data in a file system including: searching for a free disk space by using a predetermined database management system (DBMS) managing metadata of the file system, when a data write request is received from an application; writing the data in the free disk space without involvement of the DBMS, by referring to the search result; and updating a part of the metadata changing with the data being written, by using the DBMS.
  • DBMS database management system
  • All operations from the searching operation to the updating operation may be managed by the DBMS as one transaction.
  • the file system may operate at a user level.
  • a disk on which the data is stored may be different from a disk on which the metadata is stored.
  • the updating of the part of the metadata may include requesting the DBMS to update at least one of a database table containing information about a free space, a database table containing information about a non-free space, and a database table containing information about an inode.
  • a computer readable recording medium storing a computer program for performing the methods.
  • FIG. 1 is a block diagram illustrating a structure of a related art file system for managing metadata using a database
  • FIG. 2 is a flowchart illustrating a process of storing data on a disk in a file system according to an exemplary embodiment of the present invention
  • FIG. 3 illustrates a schema of a database storing metadata of a file system according to an exemplary embodiment of the present invention
  • FIG. 4 is a block diagram illustrating a file system according to an exemplary embodiment of the present invention.
  • FIG. 5 is a diagram illustrating a process of creating a file in a file system according to an exemplary embodiment of the present invention
  • FIG. 6 is a diagram illustrating a process of writing a file in a file system according to an exemplary embodiment of the present invention.
  • FIG. 7 is a diagram illustrating a process of reading a file in a file system according to an exemplary embodiment of the present invention.
  • FIG. 2 is a flowchart illustrating a process of storing data on a disk in a file system according to an exemplary embodiment of the present invention.
  • a file system receives a request to write file data on a disk from a user application.
  • the file system should provide an application layer with an application programming interface (API) at a user level corresponding to a system call.
  • API application programming interface
  • the file system requests a database management system (DBMS) for managing metadata to begin transactions. Accordingly, operations that are to be performed in relation to the metadal:a after operation 220 are regarded as one transaction and protected.
  • DBMS database management system
  • free disk space is searched for in order to write the file data requested by the application.
  • the free disk space is searched for referring to a database table including information about the free disk space. Details of a database schema for managing the DBMS will be explained later with reference to FIG. 3 .
  • the file data is written in the free disk space.
  • many free blocks may be found in operation 230 .
  • a disk allocation algorithm defined by the user may be used to determine in which block among the free blocks the requested file data is to be stored. This is because, in the file system according to the current embodiment, metadata is managed by a traditional file system, such as ext2, or DBMS but writing file data to or reading file data from a disk is performed directly by the file system and not through the DBMS or other file systems (raw I/O).
  • the file system of an exemplary embodiment of the present invention does not participate in disk layout in relation to the metadata, since the metadata of the file system is processed through the API provided by the DBMS.
  • the file system in relation to the file data, directly controls the disk layout and thus a disk allocation algorithm optimized with respect to a multimedia environment can be used. Also, since the DBMS neither manages file data nor generates a log on the file data, even though the size of the file increases, degradation of the performance of the file system does not occur.
  • the DBMS is requested to update metadata that should be changed as the file data is written on the disk.
  • metadata For example, database tables related to information about an inode, and free disk spaces and non-free disk spaces, may be updated.
  • the DBMS is requested to terminate the transaction. Accordingly, since the DBMS regards the operations 230 through 250 as one transaction, the metadata consistency of the file system is secured. For example, if, in operation 250 , a database table including information about a non-free space is updated and then a power supply is cut off due to power failure before a database table including information about a free space is updated, the DBMS treats the updating of the database table including information about the non-free space as though no updating has occured, and thus does not apply related data to the metadata.
  • operation 250 is performed only when operation 240 is finished. That is, operation 250 is performed only after writing of the file data is finished. Accordingly, operation 240 is performed between operations 220 and 260 , and thus the consistency of data can be secured. However, in order to improve the performance of the file system, operation 250 may be performed irrespective of whether or not operation 240 is finished.
  • a disk storing metadata may be disposed separately from a disk storing file data.
  • FIG. 3 illustrates a schema of databases storing metadata of a file system according to an exemplary embodiment of the present invention.
  • a super block database stores information about the status of the file system and an inode bitmap. Information about the entire file system may be stored as one record.
  • the inode bitmap also requires only a small number of records and thus this database has a record-number (RECNO)-based data structure and does not require a 2 -dimensional index.
  • RECNO record-number
  • a directory database maps directory and file names and inode numbers.
  • An inode database maps an inode number and file information of a corresponding file, such as the size of the file and a last modified time. If a new file is created, a new inode record is added to this database and if a file is deleted, the record related to the file is deleted from this database.
  • a free space database manages free spaces of a partition.
  • information about free spaces in the database table may be expressed in the form of an extent, which is a continuous area of storage in a file system.
  • the reason for expressing it in the form of an extent is that it can reduce the size of information more than when expressing it in the form of a bitmap.
  • the extent format may be expressed with a block number specifying the start position of a free space and the number of blocks corresponding to the size of the free space, or may be expressed with a byte offset specifying the start position of the free space and a byte unit indicating the size of the free space.
  • a free disk space is searched for by referring to the free space database.
  • An extent database maps an offset of a file and a block address of an extent including the file data.
  • FIG. 4 is a block diagram illustrating a file system according to an exemplary embodiment of the present invention.
  • the file system is composed of a Syscall module 402 , a Namei module 403 , a Super module 404 , a Dir module 405 , an Inode module 406 , a File module 407 , an Alloc module 408 , a DB abstract layer (DBAL) module 410 and an OS abstract layer (OSAL) module 409 .
  • DBAL DB abstract layer
  • OSAL OS abstract layer
  • a Berkeley DB 411 is used as a DBMS, and it is assumed that metadata of the file system is input to and/or output from a disk by ext3 412 .
  • the Syscall module 402 provides an API in order to allow an application 401 to use a system call and requests the DBMS 411 to start and stop a transaction.
  • the Namei module 403 analyzes an API function called by the application 401 and determines a database that is to be updated.
  • the Super module 404 requests the DBMS 411 to search and update super.db.
  • the Dir module 405 requests the DBMS 411 to search and update dir.db.
  • the Inode module 406 manages free inodes by using inode.db.
  • the Alloc module 408 obtains information about a free disk space, and determines blocks in which file data is to be written, by using a disk allocation algorithm optimized with respect to a multimedia environment or other environments.
  • the File module 407 inputs file data to or outputs file data from a disk through an OS module (not shown) operating at a kernel level.
  • the file data input and output can be performed in such a manner that data is written to a block device file or data is read from a block device file.
  • the DBAL module 410 is an interface to ensure compatibility with the Syscall module 402 and the DBMS 411 .
  • the OSAL module 409 is an interface enabling processing of a block device that may vary with respect to an OS.
  • the file system according to the current embodiment as illustrated in FIG. 4 operates at a user level, and thus the source code of the file system does not rely on an OS. Accordingly, compared to a file system operating at a kernel level, the file system according to the current embodiment can be easily ported to other OSs, and also maintenance of the file system is easier.
  • FIG. 5 is a diagram illustrating a process of creating a file in the file system illustrated in FIG. 4 according to an exemplary embodiment of the present invention.
  • the DBAL module 410 and the OSAL module 409 are not used.
  • the application 401 provides a file name to the Syscall module 402 and requests the Syscall module 402 to create a file.
  • the Syscall module 402 requests the DBMS 411 to begin a transaction.
  • the DBMS 411 begins the transaction.
  • the Syscall module 402 requests the Namei module 403 to create a file.
  • the Namei module 403 requests the Super module 404 to provide an inode to be allocated to a new file.
  • the Super module 404 that was requested to provide an inode from the Namei module 403 requests the DBMS 411 to search and modify super.db. After receiving the request, the DBMS 411 allocates a free inode to the new file by referring to the inode bitmap and updates super.db (not shown).
  • the Namei module 403 requests the Dir module 405 to register the new file in a directory. Accordingly, in operation 508 , the Dir module 405 requests the DBMS 411 to search and modify dir.db. After receiving this request, the DBMS 411 maps the name of the new file and an inode corresponding to the file, and stores it in dir.db (not shown).
  • the Namei module 403 requests the Inode module 406 to perform initialization of the new inode.
  • the Inode module 406 requests the DBMS 411 to register information about the new inode in inode.db. After receiving this request, the DBMS 411 stores information related to the new file in an inode corresponding to the new file (not shown).
  • the Namei module 403 informs the Syscall module 402 , in operation 511 , that the file generation is completed.
  • the Syscall module 402 requests the DBMS 411 to finish the transaction.
  • the DBMS 411 finishes the transaction which started in operation 503 .
  • FIG. 6 is a diagram illustrating a process of writing a file in the file system illustrated in FIG. 4 according to an exemplary embodiment of the present invention.
  • the DBAL module 410 and the OSAL module 409 are not used.
  • the application 401 requests the Syscall module 402 to write data to a file. At this time, the name of the file, the data, the size of the data, and offset information in the file are transferred to the Syscall module 402 .
  • the Syscall module 402 requests the DBMS 411 to begin a transaction.
  • the DBMS 411 begins the transaction.
  • the Syscall module 402 requests the File module 407 to perform a write operation.
  • the File module 407 requests the Alloc module 408 to provide information about a free block of a partition.
  • the Alloc module 408 requests the DBMS 411 to search and modify freespace.db in operation 606 .
  • the DBMS 411 finds free spaces by searching freespace.db and transfers information about free spaces to the Alloc module 408 in operation 607 .
  • the Alloc module 408 transfers information about blocks in which data is to be written among free spaces of the partition, to the File module 407 .
  • the transferred information about the blocks may be different from the information about the free spaces transferred by the DBMS 411 in operation 607 . That is, while, in operation 607 , the DBMS 411 transfers information about all free blocks of the partition, the Alloc module 408 determines blocks in which data is to be written, by using a predetermined disk allocation algorithm, and then transfers the information about the determined blocks. Accordingly, the user can freely design a disk allocation algorithm in the Alloc module 408 and can thus establish a file system optimized with respect to a multimedia environment, without using the fixed disk allocation method according to traditional file systems.
  • the File module 407 provides the OS module operating in a kernel mode with the name of the partition, offset information in the partition, data, and the size of the data (raw input), requesting write operation.
  • the OS module writes data on the disk based on the received information.
  • the OS module notifies the File module 407 that the write operation is completed.
  • the File module 407 informs the Inode module 406 that the write operation is completed.
  • the Inode module 406 requests the DBMS 411 to update inode.db by applying the changes that occurred in the corresponding file. According to the request, the DBMS 411 changes information about the last modified time and the size of the file (not shown).
  • the File module 407 requests the DBMS 411 to modify extents.db. After receiving the request, the DBMS 411 updates extents.db, by applying information about the block in which the data is newly written (not shown).
  • the File module 407 notifies the Syscall module 402 that the write operation is completed.
  • the Syscall module 402 requests the DBMS 411 to finish the transaction.
  • the DBMS 411 finishes the transaction which started in operation 603 .
  • FIG. 7 is a diagram illustrating a process of reading a file in the file system illustrated in FIG. 4 according to an exemplary embodiment of the present invention.
  • the DBAL module 410 and the OSAL module 409 are not used.
  • the application 401 requests the Syscall module 402 to read data from a file, by providing the name of the file, offset information in the file and the size of the data.
  • the Syscall module 402 requests the File module 407 to read the data, and in operation 703 , the File module 407 requests the Inode module 406 for information about corresponding blocks.
  • the Inode module 406 After receiving the request, the Inode module 406 requests the DBMS 411 to search extents.db in operation 704 .
  • the DBMS 411 searches extents.db, extracts information about blocks in which the data is stored, and then transfers the extracted information to the Inode module 406 in operation 705 .
  • the Inode module transfers the block information to the File module 407 .
  • the File module 407 requests the OS module to read the data by providing the name of the partition, offset information in the partition and the size of the data (raw output).
  • the OS module reads the data on the disk and transfers the read data to the File module 407 in operation 709 .
  • the File module 407 transfers the data to the Syscall module 402 .
  • the Syscall module 402 transfers the data to the application 401 . In this way, the read operation is completed.
  • the present invention can also be embodied as computer readable codes on a computer readable recording medium.
  • the computer readable recording medium is any data storage device that can store data which can be thereafter read by a computer system. Examples of the computer readable recording medium include read-only memory (ROM), random-access memory (RAM), CD-ROMs, magnetic tapes, floppy disks, optical data storage devices, and carrier waves (such as data transmission through the Internet).
  • metadata of the file system is processed through an API provided by a DBMS and thus transactions can be stably guaranteed.
  • the file system does not participate in a disk layout, the file system directly controls the disk layout in relation to file data. Accordingly, a disk allocation algorithm optimized with respect to a multimedia environment can be designed and used.
  • the DBMS manages only the metadata, and not file data, and does not generate a log on the file data. Accordingly, even though the size of the file increases, degradation of the performance does not occur.
  • the file system of an exemplary embodiment of the present invention operates at a user level, not at a kernel level, and thus the source code of the file system does not rely on an OS. Accordingly, it is easy to port the file system to other OSs, and maintenance of the file system is easier.
  • metadata and file data are stored in separate disks, and thus inputting a file to or outputting a file from the disk can be performed more efficiently than in the related art file systems.

Abstract

A method of managing data of a file system using a database management system is provided. According to the method, the metadata of the file system is managed using a database management system (DBMS), but writing data to or reading data from a disk is directly performed by the file system according to the method directly performed not through other file systems or DBMSs. In this way, stable transactions are guaranteed for a user, and the user can design a disk allocation algorithm optimized with respect to a multimedia environment.

Description

    CROSS-REFERENCE TO RELATED PATENT APPLICATIONS
  • This application claims priority from Korean Patent Application No. 10-2006-0053116 filed on Jun. 13, 2006, in the Korean Intellectual Property Office and U.S. Provisional Application No. 60/784,481 filed on Mar. 22, 2006, in the United States Patent and Trademark Office, the disclosures of which are incorporated herein in their entirety by reference.
  • BACKGROUND OF THE INVENTION
  • 1. Field of the Invention
  • The present invention relates to a file system, and more particularly, to a method of managing data of a file system using a database management system.
  • 2. Description of the Related Art
  • Unlike in the past, the recent development of multimedia technologies has enabled many consumer electronics products, such as personal video recorders, camcorders, and mobile phones, to be offered with embedded hard disks, and thus research projects on a technology for efficiently managing data using disks are being actively carried out.
  • In a file system determining a variety of policies related to input and output of data to and from a disk, consistency is a very important issue. Consistency of a file system can be divided into consistency of metadata and consistency of data. The metadata of a file system includes information about an inode, a directory, a free space of a disk, and a free inode. If operations related to these metadata items are performed as a transaction, the consistency of the metadata can be maintained.
  • Likewise, the consistency of data can be maintained through a data transaction, and if a data transaction for updating part of a file is aborted in the middle of the update operation, the data transaction is completed or discarded as if the transaction had never been performed to begin with.
  • Meanwhile, a database management system (DBMS) reliably stores data by using a fast and effective data structure and guarantees transactions. In the past, there have been attempts to secure consistency of a file system by applying this DBMS solution to an operating system (OS).
  • FIG. 1 is a block diagram illustrating a structure of a related art file system employing a database.
  • In the file system illustrated in FIG. 1, the metadata and file data of a file system are managed by using a kernel Berkeley database (KBDB), and the database is stored in a traditional file system (e.g., Ext2). In this structure, all operations of the file system are performed through a DBMS.
  • For example, when a predetermined file is read, the DBMS is accessed, and file data stored in block.db is copied into a buffer cache, and when data is written in a file, data stored in the buffer cache is stored in a record corresponding to the data in block.db. Operations other than file input and/or output operations are also performed by using the DBMS, and thus the consistency of the file system can be guaranteed.
  • However, due to its dependency on the traditional file system (Ext2) storing the databases, this KBDB file system (KBDBFS) cannot be optimized with respect to a variety of environments. That is, the DBMS (KBDB) provides only transactional operations, and the size of a file system, disk allocation, and the like are determined by a file system storing databases. For example, when data is stored on a disk in this file system, the file system (KBDBFS) inputs data into the DBMS (KBDB) and the DBMS (KBDB) stores the data on the disk by using the traditional file system Ext2 and thus the file system (KBDBFS) cannot participate in the layout of the actual disk. Accordingly, according to this file system, even though an algorithm optimized for an environment is designed, it is impossible to apply the optimized algorithm to the allocation of blocks on a disk. Also, in a multimedia environment where the file size is generally large, the size of a log generated by the DBMS increases and thus the performance of the file system is deteriorated.
  • SUMMARY OF THE INVENTION
  • The present invention provides a method by which metadata of a file system is managed using a database management system (DBMS) while file data is directly input to or output from a disk without involvement of the DBMS.
  • According to an aspect of the present invention, there is provided a method of managing data in a file system including: searching for a free disk space by using a predetermined database management system (DBMS) managing metadata of the file system, when a data write request is received from an application; writing the data in the free disk space without involvement of the DBMS, by referring to the search result; and updating a part of the metadata changing with the data being written, by using the DBMS.
  • All operations from the searching operation to the updating operation may be managed by the DBMS as one transaction.
  • The file system may operate at a user level.
  • A disk on which the data is stored may be different from a disk on which the metadata is stored.
  • The updating of the part of the metadata may include requesting the DBMS to update at least one of a database table containing information about a free space, a database table containing information about a non-free space, and a database table containing information about an inode.
  • According to another aspect of the present invention, there is provided a computer readable recording medium storing a computer program for performing the methods.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The above and other aspects of the present invention will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings in which:
  • FIG. 1 is a block diagram illustrating a structure of a related art file system for managing metadata using a database;
  • FIG. 2 is a flowchart illustrating a process of storing data on a disk in a file system according to an exemplary embodiment of the present invention;
  • FIG. 3 illustrates a schema of a database storing metadata of a file system according to an exemplary embodiment of the present invention;
  • FIG. 4 is a block diagram illustrating a file system according to an exemplary embodiment of the present invention;
  • FIG. 5 is a diagram illustrating a process of creating a file in a file system according to an exemplary embodiment of the present invention;
  • FIG. 6 is a diagram illustrating a process of writing a file in a file system according to an exemplary embodiment of the present invention; and
  • FIG. 7 is a diagram illustrating a process of reading a file in a file system according to an exemplary embodiment of the present invention.
  • DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS OF THE INVENTION
  • The present invention will now be described more fully with reference to the accompanying drawings, in which exemplary embodiments of the invention are shown.
  • FIG. 2 is a flowchart illustrating a process of storing data on a disk in a file system according to an exemplary embodiment of the present invention.
  • In operation 210, a file system according to the current embodiment receives a request to write file data on a disk from a user application. For this, the file system should provide an application layer with an application programming interface (API) at a user level corresponding to a system call.
  • In operation 220, the file system requests a database management system (DBMS) for managing metadata to begin transactions. Accordingly, operations that are to be performed in relation to the metadal:a after operation 220 are regarded as one transaction and protected.
  • In operation 230, free disk space is searched for in order to write the file data requested by the application. At this time, the free disk space is searched for referring to a database table including information about the free disk space. Details of a database schema for managing the DBMS will be explained later with reference to FIG. 3.
  • In operation 240, the file data is written in the free disk space. Depending on the situation, many free blocks may be found in operation 230. A disk allocation algorithm defined by the user may be used to determine in which block among the free blocks the requested file data is to be stored. This is because, in the file system according to the current embodiment, metadata is managed by a traditional file system, such as ext2, or DBMS but writing file data to or reading file data from a disk is performed directly by the file system and not through the DBMS or other file systems (raw I/O). In other words, the file system of an exemplary embodiment of the present invention does not participate in disk layout in relation to the metadata, since the metadata of the file system is processed through the API provided by the DBMS. However, in relation to the file data, the file system according to an exemplary embodiment of the present invention directly controls the disk layout and thus a disk allocation algorithm optimized with respect to a multimedia environment can be used. Also, since the DBMS neither manages file data nor generates a log on the file data, even though the size of the file increases, degradation of the performance of the file system does not occur.
  • In operation 250, the DBMS is requested to update metadata that should be changed as the file data is written on the disk. For example, database tables related to information about an inode, and free disk spaces and non-free disk spaces, may be updated.
  • In operation 260, the DBMS is requested to terminate the transaction. Accordingly, since the DBMS regards the operations 230 through 250 as one transaction, the metadata consistency of the file system is secured. For example, if, in operation 250, a database table including information about a non-free space is updated and then a power supply is cut off due to power failure before a database table including information about a free space is updated, the DBMS treats the updating of the database table including information about the non-free space as though no updating has occured, and thus does not apply related data to the metadata.
  • Also, operation 250 is performed only when operation 240 is finished. That is, operation 250 is performed only after writing of the file data is finished. Accordingly, operation 240 is performed between operations 220 and 260, and thus the consistency of data can be secured. However, in order to improve the performance of the file system, operation 250 may be performed irrespective of whether or not operation 240 is finished.
  • Meanwhile, in order to improve the performance of the file system, a disk storing metadata may be disposed separately from a disk storing file data.
  • FIG. 3 illustrates a schema of databases storing metadata of a file system according to an exemplary embodiment of the present invention.
  • A super block database (super.db) stores information about the status of the file system and an inode bitmap. Information about the entire file system may be stored as one record. The inode bitmap also requires only a small number of records and thus this database has a record-number (RECNO)-based data structure and does not require a 2-dimensional index.
  • A directory database (directory.db) maps directory and file names and inode numbers.
  • An inode database (inode.db) maps an inode number and file information of a corresponding file, such as the size of the file and a last modified time. If a new file is created, a new inode record is added to this database and if a file is deleted, the record related to the file is deleted from this database.
  • A free space database (freespace.db) manages free spaces of a partition. At this time, information about free spaces in the database table may be expressed in the form of an extent, which is a continuous area of storage in a file system. The reason for expressing it in the form of an extent is that it can reduce the size of information more than when expressing it in the form of a bitmap. The extent format may be expressed with a block number specifying the start position of a free space and the number of blocks corresponding to the size of the free space, or may be expressed with a byte offset specifying the start position of the free space and a byte unit indicating the size of the free space. In the file system according to the current embodiment, in order to write data to a file, a free disk space is searched for by referring to the free space database.
  • An extent database (extents.db) maps an offset of a file and a block address of an extent including the file data.
  • FIG. 4 is a block diagram illustrating a file system according to an exemplary embodiment of the present invention.
  • As illustrated in FIG. 4, the file system according to the current embodiment is composed of a Syscall module 402, a Namei module 403, a Super module 404, a Dir module 405, an Inode module 406, a File module 407, an Alloc module 408, a DB abstract layer (DBAL) module 410 and an OS abstract layer (OSAL) module 409. Also, in the current embodiment, a Berkeley DB 411 is used as a DBMS, and it is assumed that metadata of the file system is input to and/or output from a disk by ext3 412.
  • The Syscall module 402 provides an API in order to allow an application 401 to use a system call and requests the DBMS 411 to start and stop a transaction.
  • The Namei module 403 analyzes an API function called by the application 401 and determines a database that is to be updated. The Super module 404 requests the DBMS 411 to search and update super.db. The Dir module 405 requests the DBMS 411 to search and update dir.db. The Inode module 406 manages free inodes by using inode.db.
  • The Alloc module 408 obtains information about a free disk space, and determines blocks in which file data is to be written, by using a disk allocation algorithm optimized with respect to a multimedia environment or other environments.
  • The File module 407 inputs file data to or outputs file data from a disk through an OS module (not shown) operating at a kernel level. For example, the file data input and output can be performed in such a manner that data is written to a block device file or data is read from a block device file.
  • The DBAL module 410 is an interface to ensure compatibility with the Syscall module 402 and the DBMS 411. The OSAL module 409 is an interface enabling processing of a block device that may vary with respect to an OS.
  • Meanwhile, the file system according to the current embodiment as illustrated in FIG. 4 operates at a user level, and thus the source code of the file system does not rely on an OS. Accordingly, compared to a file system operating at a kernel level, the file system according to the current embodiment can be easily ported to other OSs, and also maintenance of the file system is easier.
  • FIG. 5 is a diagram illustrating a process of creating a file in the file system illustrated in FIG. 4 according to an exemplary embodiment of the present invention. In the current embodiment, it is assumed that the DBAL module 410 and the OSAL module 409 are not used.
  • In operation 501, the application 401 provides a file name to the Syscall module 402 and requests the Syscall module 402 to create a file. In operation 502, the Syscall module 402 requests the DBMS 411 to begin a transaction. In operation 503, the DBMS 411 begins the transaction.
  • In operation 504, the Syscall module 402 requests the Namei module 403 to create a file. In operation 505, the Namei module 403 requests the Super module 404 to provide an inode to be allocated to a new file. In operation 506, the Super module 404 that was requested to provide an inode from the Namei module 403 requests the DBMS 411 to search and modify super.db. After receiving the request, the DBMS 411 allocates a free inode to the new file by referring to the inode bitmap and updates super.db (not shown).
  • In operation 507, the Namei module 403 requests the Dir module 405 to register the new file in a directory. Accordingly, in operation 508, the Dir module 405 requests the DBMS 411 to search and modify dir.db. After receiving this request, the DBMS 411 maps the name of the new file and an inode corresponding to the file, and stores it in dir.db (not shown).
  • In operation 509, the Namei module 403 requests the Inode module 406 to perform initialization of the new inode. In operation 510, the Inode module 406 requests the DBMS 411 to register information about the new inode in inode.db. After receiving this request, the DBMS 411 stores information related to the new file in an inode corresponding to the new file (not shown).
  • If operation 510 is completed, the Namei module 403 informs the Syscall module 402, in operation 511, that the file generation is completed. In operation 512, the Syscall module 402 requests the DBMS 411 to finish the transaction. In operation 513, the DBMS 411 finishes the transaction which started in operation 503.
  • FIG. 6 is a diagram illustrating a process of writing a file in the file system illustrated in FIG. 4 according to an exemplary embodiment of the present invention. In the current embodiment, it is assumed that the DBAL module 410 and the OSAL module 409 are not used.
  • In operation 601, the application 401 requests the Syscall module 402 to write data to a file. At this time, the name of the file, the data, the size of the data, and offset information in the file are transferred to the Syscall module 402. In operation 602, the Syscall module 402 requests the DBMS 411 to begin a transaction. In operation 603, the DBMS 411 begins the transaction.
  • In operation 604, the Syscall module 402 requests the File module 407 to perform a write operation. In operation 605, the File module 407 requests the Alloc module 408 to provide information about a free block of a partition. After receiving this request, the Alloc module 408 requests the DBMS 411 to search and modify freespace.db in operation 606. After receiving this request, the DBMS 411 finds free spaces by searching freespace.db and transfers information about free spaces to the Alloc module 408 in operation 607.
  • In operation 608, the Alloc module 408 transfers information about blocks in which data is to be written among free spaces of the partition, to the File module 407. At this time, the transferred information about the blocks may be different from the information about the free spaces transferred by the DBMS 411 in operation 607. That is, while, in operation 607, the DBMS 411 transfers information about all free blocks of the partition, the Alloc module 408 determines blocks in which data is to be written, by using a predetermined disk allocation algorithm, and then transfers the information about the determined blocks. Accordingly, the user can freely design a disk allocation algorithm in the Alloc module 408 and can thus establish a file system optimized with respect to a multimedia environment, without using the fixed disk allocation method according to traditional file systems.
  • In operation 609, the File module 407 provides the OS module operating in a kernel mode with the name of the partition, offset information in the partition, data, and the size of the data (raw input), requesting write operation. In operation 610, the OS module writes data on the disk based on the received information.
  • In operation 611, the OS module notifies the File module 407 that the write operation is completed. In operation 612, the File module 407 informs the Inode module 406 that the write operation is completed. In operation 613, the Inode module 406 requests the DBMS 411 to update inode.db by applying the changes that occurred in the corresponding file. According to the request, the DBMS 411 changes information about the last modified time and the size of the file (not shown). Also, in operation 614, the File module 407 requests the DBMS 411 to modify extents.db. After receiving the request, the DBMS 411 updates extents.db, by applying information about the block in which the data is newly written (not shown).
  • In operation 615, the File module 407 notifies the Syscall module 402 that the write operation is completed. In operation 616, the Syscall module 402 requests the DBMS 411 to finish the transaction. In operation 617, the DBMS 411 finishes the transaction which started in operation 603.
  • FIG. 7 is a diagram illustrating a process of reading a file in the file system illustrated in FIG. 4 according to an exemplary embodiment of the present invention. In the current embodiment, it is assumed that the DBAL module 410 and the OSAL module 409 are not used.
  • In operation 701, the application 401 requests the Syscall module 402 to read data from a file, by providing the name of the file, offset information in the file and the size of the data.
  • In operation 702, the Syscall module 402 requests the File module 407 to read the data, and in operation 703, the File module 407 requests the Inode module 406 for information about corresponding blocks.
  • After receiving the request, the Inode module 406 requests the DBMS 411 to search extents.db in operation 704. The DBMS 411 searches extents.db, extracts information about blocks in which the data is stored, and then transfers the extracted information to the Inode module 406 in operation 705.
  • In operation 706, the Inode module transfers the block information to the File module 407.
  • In operation 707, the File module 407 requests the OS module to read the data by providing the name of the partition, offset information in the partition and the size of the data (raw output).
  • In operation 708, the OS module reads the data on the disk and transfers the read data to the File module 407 in operation 709.
  • In operation 710, the File module 407 transfers the data to the Syscall module 402. In operation 711, the Syscall module 402 transfers the data to the application 401. In this way, the read operation is completed.
  • The present invention can also be embodied as computer readable codes on a computer readable recording medium. The computer readable recording medium is any data storage device that can store data which can be thereafter read by a computer system. Examples of the computer readable recording medium include read-only memory (ROM), random-access memory (RAM), CD-ROMs, magnetic tapes, floppy disks, optical data storage devices, and carrier waves (such as data transmission through the Internet).
  • According to a file system of an exemplary embodiment of the present invention, metadata of the file system is processed through an API provided by a DBMS and thus transactions can be stably guaranteed.
  • Though the file system does not participate in a disk layout, the file system directly controls the disk layout in relation to file data. Accordingly, a disk allocation algorithm optimized with respect to a multimedia environment can be designed and used.
  • Furthermore, in the file system of an exemplary embodiment of the present invention, the DBMS manages only the metadata, and not file data, and does not generate a log on the file data. Accordingly, even though the size of the file increases, degradation of the performance does not occur.
  • Also, the file system of an exemplary embodiment of the present invention operates at a user level, not at a kernel level, and thus the source code of the file system does not rely on an OS. Accordingly, it is easy to port the file system to other OSs, and maintenance of the file system is easier.
  • In addition, in the file system of an exemplary embodiment of the present invention, metadata and file data are stored in separate disks, and thus inputting a file to or outputting a file from the disk can be performed more efficiently than in the related art file systems.
  • While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present invention as defined by the following claims. The exemplary embodiments should be considered in descriptive sense only and not for purposes of limitation. Therefore, the scope of the invention is defined not by the detailed description of the invention but by the appended claims, and all differences within the scope will be construed as being included in the present invention.

Claims (10)

1. A method of managing data in a file system comprising:
searching for a free disk space by using a database management system (DBMS) managing metadata of the file system, when a data write request is received from an application;
writing the data in the free disk space without involvement of the DBMS, by referring to the search result; and
updating a part of the metadata changing with the data being written, by using the DBMS.
2. The method of claim 1, wherein all operations from the searching operation to the updating operation are managed by the DBMS as one transaction.
3. The method of claim 1, wherein the file system operates at a user level.
4. The method of claim 1, wherein a disk on which the data is stored is different from a disk on which the metadata is stored.
5. The method of claim 1, wherein the updating of the part of the metadata comprises requesting the DBMS to update at least one of a database table containing information about a free space, a database table containing information about a non-free space, and a database table containing information about an inode.
6. The method of claim 1, wherein the metadata expresses information about a free space of a disk in the form of an extent.
7. The method of claim 6, wherein the extent form is expressed with a block number indicating a start position of the free space and the number of blocks corresponding to the size of the free space.
8. The method of claim 6, wherein the extent form is expressed with a byte offset indicating a start position of the free space and a byte unit indicating the size of the free space.
9. The method of claim 1, further comprising:
obtaining metadata related to the data through the DBMS, when a read request of the data is received from an arbitrary application;
reading data of at least one block determined by the obtained metadata from a disk not through the DBMS; and
transferring the read data to the arbitrary application.
10. A computer readable recording medium storing a computer program for performing a method of managing data in a file system comprising:
searching for a free disk space by using a database management system (DBMS) managing metadata of the file system, when a data write request is received from an application;
writing the data in the free disk space without involvement of the DBMS, by referring to the search result; and
updating a part of the metadata changing with the data being written, by using the DBMS.
US11/717,061 2006-03-22 2007-03-13 Method of managing data of file system using database management Abandoned US20070226219A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/717,061 US20070226219A1 (en) 2006-03-22 2007-03-13 Method of managing data of file system using database management
US13/904,493 US9384201B2 (en) 2006-03-22 2013-05-29 Method of managing data of file system using database management system

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US78448106P 2006-03-22 2006-03-22
KR10-2006-0053116 2006-06-13
KR1020060053116A KR100790991B1 (en) 2006-03-22 2006-06-13 Method for managing metadata of file system using DBMS
US11/717,061 US20070226219A1 (en) 2006-03-22 2007-03-13 Method of managing data of file system using database management

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/904,493 Continuation US9384201B2 (en) 2006-03-22 2013-05-29 Method of managing data of file system using database management system

Publications (1)

Publication Number Publication Date
US20070226219A1 true US20070226219A1 (en) 2007-09-27

Family

ID=38802908

Family Applications (2)

Application Number Title Priority Date Filing Date
US11/717,061 Abandoned US20070226219A1 (en) 2006-03-22 2007-03-13 Method of managing data of file system using database management
US13/904,493 Active 2027-11-12 US9384201B2 (en) 2006-03-22 2013-05-29 Method of managing data of file system using database management system

Family Applications After (1)

Application Number Title Priority Date Filing Date
US13/904,493 Active 2027-11-12 US9384201B2 (en) 2006-03-22 2013-05-29 Method of managing data of file system using database management system

Country Status (4)

Country Link
US (2) US20070226219A1 (en)
EP (1) EP1837783A1 (en)
KR (1) KR100790991B1 (en)
CN (1) CN100585595C (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070294274A1 (en) * 2006-06-19 2007-12-20 Hitachi, Ltd. System and method for managing a consistency among volumes in a continuous data protection environment
US20080183748A1 (en) * 2007-01-31 2008-07-31 Maruti Haridas Kamat Data Processing System And Method
US20120239634A1 (en) * 2010-02-12 2012-09-20 Huawei Technologies Co., Ltd. Method and apparatus for accessing database and database application system
US9459969B1 (en) * 2012-09-28 2016-10-04 Emc Corporation Method and system for enhanced backup database indexing
US9645893B1 (en) * 2012-09-28 2017-05-09 EMC IP Holding Company LLP Method and system for file recovery using enhanced backup database indexing

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101667178B (en) * 2008-09-01 2012-08-22 北京数码大方科技有限公司 Transaction processing method used for C/S architecture file management system
CN102201005A (en) * 2011-05-20 2011-09-28 苏州安源汇信软件有限公司 Method for distributing streaming media enhanced file of file system
KR102225618B1 (en) * 2014-09-30 2021-03-12 한화테크윈 주식회사 Space-Efficient Recovery of Time-Related Metadata Of Recorded Data From Failure Scenarios
US10372607B2 (en) * 2015-09-29 2019-08-06 Veritas Technologies Llc Systems and methods for improving the efficiency of point-in-time representations of databases
US10976946B2 (en) * 2015-11-27 2021-04-13 Hitachi, Ltd. Method and computer system for managing blocks
KR102214697B1 (en) 2019-04-17 2021-02-10 주식회사 티맥스티베로 A computer program for providing space managrment for data storage in a database management system
KR20210013747A (en) 2021-01-25 2021-02-05 주식회사 티맥스티베로 A computer program for providing space managrment for data storage in a database management system
WO2023146802A1 (en) * 2022-01-26 2023-08-03 Diebold Nixdorf Incorporated Dynamic sizing of system and method for processing financial transactions

Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020065792A1 (en) * 1998-09-24 2002-05-30 Charles Roy Bonner Technique to avoid processing well clustered lob's during reorganization of a lob table space
US20020174189A1 (en) * 2001-04-23 2002-11-21 Luosheng Peng Apparatus and methods for intelligently caching applications and data on a mobile device
US20030056082A1 (en) * 2001-09-19 2003-03-20 Maxfield John D. System and method for controlling free space distribution by key range within a database
US20040111250A1 (en) * 2002-12-10 2004-06-10 Hensley John Alan Emulated read-write disk drive using a protected medium
US20050114291A1 (en) * 2003-11-25 2005-05-26 International Business Machines Corporation System, method, and service for federating and optionally migrating a local file system into a distributed file system while preserving local access to existing data
US6922708B1 (en) * 1999-02-18 2005-07-26 Oracle International Corporation File system that supports transactions
US20050182911A1 (en) * 2003-09-11 2005-08-18 Kaiser Scott D. Data storage analysis mechanism
US20050193132A1 (en) * 1999-11-04 2005-09-01 O'brien Brett Shared internet storage resource, user interface system, and method
US20060053476A1 (en) * 2004-09-03 2006-03-09 Bezilla Daniel B Data structure for policy-based remediation selection
US20060053475A1 (en) * 2004-09-03 2006-03-09 Bezilla Daniel B Policy-based selection of remediation
US20070168640A1 (en) * 2006-01-09 2007-07-19 International Business Machines Corporation Method for searching a data page for inserting a data record
US20070198591A1 (en) * 2006-02-17 2007-08-23 International Business Machines Corporation Partition by growth table space
US20080162485A1 (en) * 2000-05-12 2008-07-03 Long David J Transaction-Aware Caching for Access Control Metadata
US7418435B1 (en) * 1999-08-05 2008-08-26 Oracle International Corporation Multi-model access to data
US20080229047A1 (en) * 2004-05-21 2008-09-18 International Business Machines Corporation Disk Space Allocation
US20080263089A1 (en) * 2004-05-13 2008-10-23 Cousins Robert E Transaction-Based Storage System and Method That Uses Variable Sized Objects to Store Data
US7467163B1 (en) * 2006-02-10 2008-12-16 Unisys Corporation System and method to manipulate large objects on enterprise server data management system
US7539706B1 (en) * 2004-03-30 2009-05-26 Emc Corporation Methods and apparatus for collecting and processing file system data
US7580950B2 (en) * 2004-02-11 2009-08-25 Storage Technology Corporation Clustered hierarchical file system

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3999446B2 (en) 2000-06-30 2007-10-31 株式会社東芝 Disk device and computer system having a plurality of the same
KR100452631B1 (en) * 2002-02-28 2004-10-14 한국전자통신연구원 Management method of dynamic bitmap in huge file system by using huge file storing system
AU2003216671A1 (en) * 2002-05-17 2003-12-02 Koninklijke Philips Electronics N.V. Device and method for storing information
US7469306B2 (en) * 2002-06-28 2008-12-23 Nxp B.V. Method for communicating with first and second device that includes reference to metadata wherein third device modifies the metadata based on specific operations by first device
CN100504854C (en) 2003-01-14 2009-06-24 联想(北京)有限公司 Document management method
JP4393920B2 (en) 2004-05-13 2010-01-06 日本電信電話株式会社 Information access management apparatus, method, program, and recording medium recording the program
US7644107B2 (en) * 2004-09-30 2010-01-05 Microsoft Corporation System and method for batched indexing of network documents
US20070022148A1 (en) * 2005-07-20 2007-01-25 Akers David G Reserving an area of a storage medium for a file

Patent Citations (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020065792A1 (en) * 1998-09-24 2002-05-30 Charles Roy Bonner Technique to avoid processing well clustered lob's during reorganization of a lob table space
US6922708B1 (en) * 1999-02-18 2005-07-26 Oracle International Corporation File system that supports transactions
US7418435B1 (en) * 1999-08-05 2008-08-26 Oracle International Corporation Multi-model access to data
US20050193132A1 (en) * 1999-11-04 2005-09-01 O'brien Brett Shared internet storage resource, user interface system, and method
US20070073840A1 (en) * 1999-11-04 2007-03-29 O'brien Brett Network personal digital video recorder system (NPDVR)
US20080162485A1 (en) * 2000-05-12 2008-07-03 Long David J Transaction-Aware Caching for Access Control Metadata
US20020174189A1 (en) * 2001-04-23 2002-11-21 Luosheng Peng Apparatus and methods for intelligently caching applications and data on a mobile device
US20080040406A1 (en) * 2001-09-19 2008-02-14 Bmc Software, Inc. System and method for controlling free space distribution by key range within a database
US20030056082A1 (en) * 2001-09-19 2003-03-20 Maxfield John D. System and method for controlling free space distribution by key range within a database
US20040111250A1 (en) * 2002-12-10 2004-06-10 Hensley John Alan Emulated read-write disk drive using a protected medium
US20050182911A1 (en) * 2003-09-11 2005-08-18 Kaiser Scott D. Data storage analysis mechanism
US20050114291A1 (en) * 2003-11-25 2005-05-26 International Business Machines Corporation System, method, and service for federating and optionally migrating a local file system into a distributed file system while preserving local access to existing data
US7580950B2 (en) * 2004-02-11 2009-08-25 Storage Technology Corporation Clustered hierarchical file system
US7539706B1 (en) * 2004-03-30 2009-05-26 Emc Corporation Methods and apparatus for collecting and processing file system data
US20080263089A1 (en) * 2004-05-13 2008-10-23 Cousins Robert E Transaction-Based Storage System and Method That Uses Variable Sized Objects to Store Data
US20080229047A1 (en) * 2004-05-21 2008-09-18 International Business Machines Corporation Disk Space Allocation
US20060053476A1 (en) * 2004-09-03 2006-03-09 Bezilla Daniel B Data structure for policy-based remediation selection
US20060053475A1 (en) * 2004-09-03 2006-03-09 Bezilla Daniel B Policy-based selection of remediation
US20070168640A1 (en) * 2006-01-09 2007-07-19 International Business Machines Corporation Method for searching a data page for inserting a data record
US7467163B1 (en) * 2006-02-10 2008-12-16 Unisys Corporation System and method to manipulate large objects on enterprise server data management system
US20070198591A1 (en) * 2006-02-17 2007-08-23 International Business Machines Corporation Partition by growth table space

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070294274A1 (en) * 2006-06-19 2007-12-20 Hitachi, Ltd. System and method for managing a consistency among volumes in a continuous data protection environment
US7647360B2 (en) * 2006-06-19 2010-01-12 Hitachi, Ltd. System and method for managing a consistency among volumes in a continuous data protection environment
US20080183748A1 (en) * 2007-01-31 2008-07-31 Maruti Haridas Kamat Data Processing System And Method
US20120239634A1 (en) * 2010-02-12 2012-09-20 Huawei Technologies Co., Ltd. Method and apparatus for accessing database and database application system
US20130262426A1 (en) * 2010-02-12 2013-10-03 Huawei Technologies Co., Ltd. Method and apparatus for accessing database and database application system
US9459969B1 (en) * 2012-09-28 2016-10-04 Emc Corporation Method and system for enhanced backup database indexing
US9645893B1 (en) * 2012-09-28 2017-05-09 EMC IP Holding Company LLP Method and system for file recovery using enhanced backup database indexing
US10997037B1 (en) 2012-09-28 2021-05-04 EMC IP Holding Company LLC Method and system for enhanced backup database indexing

Also Published As

Publication number Publication date
KR20070095737A (en) 2007-10-01
US20130262535A1 (en) 2013-10-03
CN100585595C (en) 2010-01-27
CN101042703A (en) 2007-09-26
KR100790991B1 (en) 2008-01-03
EP1837783A1 (en) 2007-09-26
US9384201B2 (en) 2016-07-05

Similar Documents

Publication Publication Date Title
US9384201B2 (en) Method of managing data of file system using database management system
CN110062925B (en) Snapshot metadata placement for cloud integration
CN106575297B (en) High throughput data modification using blind update operations
US8868624B2 (en) Blob manipulation in an integrated structured storage system
US6934822B2 (en) Organization of multiple snapshot copies in a data storage system
US8306950B2 (en) Managing data access requests after persistent snapshots
US6957362B2 (en) Instantaneous restoration of a production copy from a snapshot copy in a data storage system
US8620884B2 (en) Scalable blob storage integrated with scalable structured storage
US8983911B2 (en) Storage media abstraction for uniform data storage
US9542409B2 (en) Deduplicated file system
US9075754B1 (en) Managing cache backup and restore
US10423499B2 (en) Cataloging metadata for replication management and recovery
US20040030846A1 (en) Data storage system having meta bit maps for indicating whether data blocks are invalid in snapshot copies
US9021222B1 (en) Managing incremental cache backup and restore
US20130311493A1 (en) Systems and methods for arbitrary data transformations
US11886401B2 (en) Database key compression
CN111007990B (en) Positioning method for quickly positioning data block references in snapshot system
US11210319B2 (en) Replication progress for UPIT snapshots
KR102595120B1 (en) Systems and methods for continuously available network file system (NFS) state data
US10915246B2 (en) Cloud storage format to enable space reclamation while minimizing data transfer
US20070192273A1 (en) Online data volume deletion
US20050246385A1 (en) Database-rearranging program, database-rearranging method, and database-rearranging apparatus
KR100912126B1 (en) Method for providing snapshot of fileset of object based file system
KR20210156682A (en) How to manage meta-data of a file system using a database management system
US11748259B2 (en) System and method to conserve device lifetime for snapshot generation

Legal Events

Date Code Title Description
AS Assignment

Owner name: SAMSUNG ELECTRONICS CO., LTD., KOREA, REPUBLIC OF

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HWANG, JOO-YOUNG;JANG, MIN-SUNG;BAE, JAE-KYOUNG;AND OTHERS;REEL/FRAME:019057/0483

Effective date: 20070302

AS Assignment

Owner name: SAMSUNG ELECTRONICS CO., LTD., KOREA, REPUBLIC OF

Free format text: A CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE ADDRESS ON REEL 019057 FRAME 0483;ASSIGNORS:HWANG, JOO-YOUNG;JANG, MIN-SUNG;BAE, JAE-KYOUNG;AND OTHERS;REEL/FRAME:019680/0004

Effective date: 20070302

STCB Information on status: application discontinuation

Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION