WO2017116186A1 - 파일의 메타데이터에 대한 보호 방법 및 보호 장치 - Google Patents

파일의 메타데이터에 대한 보호 방법 및 보호 장치 Download PDF

Info

Publication number
WO2017116186A1
WO2017116186A1 PCT/KR2016/015518 KR2016015518W WO2017116186A1 WO 2017116186 A1 WO2017116186 A1 WO 2017116186A1 KR 2016015518 W KR2016015518 W KR 2016015518W WO 2017116186 A1 WO2017116186 A1 WO 2017116186A1
Authority
WO
WIPO (PCT)
Prior art keywords
storage device
file
metadata
journal file
block
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.)
Ceased
Application number
PCT/KR2016/015518
Other languages
English (en)
French (fr)
Inventor
원유집
남범석
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.)
Industry University Cooperation Foundation IUCF HYU
UNIST Academy Industry Research Corp
Original Assignee
Industry University Cooperation Foundation IUCF HYU
UNIST Academy Industry Research Corp
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 Industry University Cooperation Foundation IUCF HYU, UNIST Academy Industry Research Corp filed Critical Industry University Cooperation Foundation IUCF HYU
Publication of WO2017116186A1 publication Critical patent/WO2017116186A1/ko
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
    • G06F16/1815—Journaling file systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/178—Techniques for file synchronisation in file systems
    • G06F16/1787—Details of non-transparently synchronising file systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Definitions

  • the present invention can be used in the field of storing a lot of data, and in particular, it can be usefully used in the field using a method of recording database recovery information by buffer-based input / output, direct input / output, or input / output using a buffer.
  • data stored in a user buffer is temporarily stored in a page cache, and data stored in the page cache is written to a storage device through a function called fsync () or fdatasync ().
  • fsync a function called fsync () or fdatasync ().
  • DIO direct input / output
  • the file system can journal updated metadata for each file.
  • fdatasync when file blocks are allocated or unallocated, the file system can journal the updated metadata. DIO write itself does not involve any file system journaling.
  • Write operations may be classified into two types (a process of allocating write and a process of not allocating write).
  • the process of allocating writes can update various metadata such as block bitmaps, inode tables, and intermediate node blocks.
  • the process of not allocating a write does not involve allocating file blocks. It only updates the flags initialized in the access time and metadata associated with the field.
  • fsync () can journal the updated metadata.
  • fdatasync () has the same behavior as fsync ().
  • fdatasync () doesn't journal any metadata.
  • direct IO does not involve journaling the file system. In DIO, updated metadata is likely to be lost.
  • file system journaling process occurs, which stores metadata in the page cache and synchronizes the metadata to the storage device through fsync () or fdatasync (). This increases the amount of I / O to the database and shortens the lifetime of the storage device.
  • the present invention provides a protection method and a protection device which can improve the performance of the storage device and extend its life by greatly reducing the amount of input and output substantially generated when synchronizing the contents recorded in the file to the storage device.
  • a protection method includes the steps of: preallocating a predetermined amount of initialized blocks for a journal file to a storage device; And journaling the updated metadata for the journal file to the storage device by calling a data synchronization function.
  • the protection method may further include committing a log, which is recovery information of a database, to the block after the journaling.
  • the log may be recorded in a block previously allocated to a storage device from a database in a direct input / output (DIO) manner or a buffered input / output (Buffered IO) manner.
  • DIO direct input / output
  • Buffered IO buffered input / output
  • the journaling step may be stored in a storage device by synchronizing metadata about the journal file through a data synchronization function.
  • the block may be initialized by zero filling the block allocated to the storage device or by applying a discard command to the storage device.
  • the protection method may further include reallocating a predetermined amount of blocks when all previously allocated blocks are full as the log is committed.
  • the protection method may further include journaling by synchronizing metadata for the journal file when the file size of the journal file changes as the block is reallocated.
  • a protection device includes a processor, the processor comprising: preallocating a predetermined amount of initialized blocks for a journal file to a storage device; And journaling the updated metadata for the journal file to the storage device by calling a data synchronization function.
  • the processor may further perform a step of committing a log, which is recovery information of a database, to the block.
  • the processor may write the log to a block previously allocated to a storage device from a database in a direct input / output (DIO) manner or a buffered input / output (Buffered IO) manner.
  • DIO direct input / output
  • Buffered IO buffered input / output
  • the processor may perform journaling for storing metadata for the journal file in a storage device by synchronizing through a data synchronization function.
  • the block may be initialized by zero filling the block allocated to the storage device or by applying a discard command to the storage device.
  • the processor may further perform the step of reallocating a predetermined amount of blocks when all previously allocated blocks are full as the log is committed.
  • the processor may further perform journaling by synchronizing metadata for the journal file when the file size of the journal file changes as the block is reallocated.
  • the performance of the storage device can be improved and its life can be extended.
  • FIG. 1 is a view showing the overall configuration according to an embodiment of the present invention.
  • FIG. 2 is a flowchart illustrating a method for protecting metadata of a file according to an embodiment of the present invention.
  • FIG. 3 is a diagram illustrating an example of a method for protecting metadata of a file according to an embodiment of the present invention.
  • FIG. 1 is a view showing the overall configuration according to an embodiment of the present invention.
  • the protection device 103 may be composed of a database 101, a storage device 102, and a protection device (103).
  • the protection device 103 performs a protection method for metadata of a file according to an embodiment of the present invention, and may be a processor supporting a file system included in a specific terminal.
  • the protection device 103 may preallocate a predetermined degree of initialized blocks for the file.
  • the protection device 103 may journal the metadata about the generated file by calling fdatasync ().
  • the protection device 103 may pre-allocate the initialized blocks for the journal file to the storage device 102.
  • the protection device 103 may journal the metadata of the journal file by synchronizing the metadata of the journal file to the storage device 102 through fdatasync (). Thereafter, the logs may be committed to a block previously allocated to the journal file through direct IO (DIO) or buffered IO (Buffered IO).
  • DIO direct IO
  • Buffered IO buffered IO
  • the buffered input / output refers to a method in which logs are temporarily written to the page cache through write () and then written to the storage device 102 through a function such as fdatasync () or fsync ().
  • Direct IO is one of the functions of a file system in which a user reads data from or writes data to or from the storage device 102. With direct input and output, data may be written directly to storage 102 without being written to the page cache. That is, data may be written directly to the storage device 102 instead of being temporarily stored in the page cache by bypassing the page cache.
  • the present invention can be applied to journal modes (DELETE, TRUNCATE, PERSIST, WAL, MEMORY and OFF, etc.) supported by a database. What is needed is a way to protect against unexpected system failures of the database.
  • the database uses a journal file that keeps logs. To ensure the transaction, the database either commits the log to the journal file or updates the database 101 and then synchronizes the log file with the database file using fdatasync (). Commit means that the result of the transaction is reflected in the database 101 and remains persistent.
  • Committing the log mentioned in the present invention refers to a process of storing a log, which is recovery information of the database 101 indicating a change of data in the database 101, in a block previously allocated for the journal file.
  • the protection device 103 performs a preallocating process and a journaling process of the initialized block, thereby appropriately protecting the metadata about the file by an unexpected system crash. You can remove journaling.
  • journaling is a technique of storing a change history of data in a log called a journal before storing the change history of data in the storage device 102. Journaling is used to recover from abnormal corruption of data in the event of a system failure while storing a history of changes to the data.
  • FIG. 2 is a flowchart illustrating a method for protecting metadata of a file according to an embodiment of the present invention.
  • the protection device may pre-allocate the initialized blocks for the journal file.
  • pre-allocating means pre-allocating a block before or before generating a journal file for recording a log, which is recovery information of a database.
  • Initialized blocks may be pre-allocated to the storage device.
  • the protection device can journal the updated metadata for the journal file.
  • the protection device may journal the metadata by synchronizing the metadata of the journal file existing in the database to the storage device through a data synchronization function such as fdatasync ().
  • the protection device may commit the log, which is recovery information of the database, from the database to the storage device using direct input / output (DIO) or buffered input / output (Buffered IO).
  • the log can then be stored in a block pre-allocated for the journal file.
  • the protection device may again allocate new blocks of a preset size. As a result, if the file size of the journal file changes, the metadata of the journal file may change. The protection device can then synchronize the changed metadata to the storage device through journaling as step 202.
  • FIG. 3 is a diagram illustrating an example of a method for protecting metadata of a file according to an embodiment of the present invention.
  • a write operation based on a direct IO (DIO) or a write operation based on a buffered IO is proposed to commit the logs 302 to a journal file.
  • the logs 302 may be directly written to the storage device according to the DIO or the logs may be temporarily stored in the page cache according to the buffered IO and then written to the storage device. Committing the log 302 ensures that no updates to the data block 303 or the metadata 301 are involved in the page cache entries.
  • database synchronization such as fdatasync () does not trigger any file system journaling related to IO.
  • the present invention can eliminate the interference of journaling in the committing log 302 and protect the metadata 301 of the journal file.
  • the preallocation with explicitly journaling involves (i) preallocating a certain amount of initialized specific blocks 303 for the journal file, and (ii) calling fdatasync (). By doing so, it is possible to journal the metadata 301 for the generated journal file.
  • this has the problem of suppressing all log 302 commit operations to involve filesystem journaling, but the present invention can be eliminated from this suppression by eliminating such filesystem journaling.
  • initialized blocks 303 for the journal file may be pre-allocated. These blocks are pre-allocated to the storage device.
  • the metadata 301 of the journal file is journaled by synchronizing via fdatasync (). That is, the metadata 301 of the journal file is stored in the storage device.
  • logs 302 are committed to the journal file via the DIO. That is, the logs 302, which are recovery information of the database, may be written to blocks previously allocated to the storage device without going through the page cache through the DIO.
  • the file system may maintain an initialized flag for each block 303. When the flag is set, block 303 can be initialized. Any attempts to read the uninitialized block 303 may return mode 0. The primary reason for this mechanism is to avoid exposing stale data.
  • journal mode in accordance with one embodiment of the present invention protects the database from file system journaling.
  • the journal mode may call fdatasync () to synchronize metadata 301 for the file. If explicit journaling is involved, the journal file can be robust to system errors.
  • the first way is to fill zero for the assigned blocks 303.
  • the second and third methods use the discard (or trim) command on the embedded MultiMediaCard (eMMC) storage device to protect old content from exposure.
  • eMMC is a storage device that integrates NAND flash memory and flash memory controller. It is widely used in mobile devices because it supports fast input / output speed, but the number of write / erase is limited due to the nature of NAND flash storage device.
  • the discard command may take a list of logical block 303 addresses as input, and request that the eMMC storage device remove the mapping table entries for each logical block 303.
  • the second method can modify fallocate () which mounts a discard option to the file system and allocates blocks 303 with an initialized flag set.
  • a discard command may be issued when the file blocks 303 are deallocated.
  • a way to port a NO HIDE STALE patch to a Linux source for a particular smartphone has been proposed.
  • the discard command is embedded in the NO HIDE STALE patch developed for the second method, and a new flag of NO HIDE STALE DISCARD for fallocate () has been proposed.
  • the biggest difference between the second and third methods is the time when block 303 is unmapped.
  • the file blocks 303 when the file blocks 303 are deallocated or allocated, the file blocks 303 may be unmapped.
  • the file system can issue a discard command for all deallocated blocks 303.
  • the file system may discard the file blocks 303 allocated to the journal file. Then, the third method may exhibit less overhead than the second method.
  • the zero-fill process of filling the block 303 with zero involves IO overhead.
  • Using the discard mount option can slow down the file system.
  • Recent smartphones mount the retirement option on the file system.
  • the discard option can be designed to make garbage collection more efficient.
  • the retirement option is not designed to hide old content.
  • the eMMC standard does not define what needs to be read when accessing obsolete blocks 303. Some eMMC storage devices may return all zeros when accessing discarded blocks 303. When using the discard command to hide old content, it is necessary to ensure that a given eMMC storage device does not leak old content. In such a case, it may be guaranteed to return all zeros or all ones when accessing the discarded blocks 303.
  • the trim command may return all zeros or all ones.
  • the discard command from the host cannot be ignored in certain circumstances.
  • Methods according to an embodiment of the present invention can be implemented in the form of program instructions that can be executed by various computer means and recorded in a computer readable medium.
  • the computer readable medium may include program instructions, data files, data structures, etc. alone or in combination.
  • Program instructions recorded on the media may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well-known and available to those having skill in the computer software arts.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)

Abstract

파일의 메타데이터를 위한 보호 방법 및 보호 장치가 개시된다. 보호 방법은 저널 파일을 위한 일정량의 초기화된 블록들을 저장 장치에 미리 할당(preallocation)하는 단계; 및 데이터 동기화 함수를 호출함으로써, 상기 저널 파일에 대한 업데이트된 메타데이터를 저장 장치에 저널링하는 단계를 포함할 수 있다.

Description

파일의 메타데이터에 대한 보호 방법 및 보호 장치
본 발명은 데이터를 많이 저장하는 분야에 사용될 수 있으며, 특히, 버퍼기반 입출력이나 직접 입출력 또는 버퍼를 이용한 입출력으로 데이터베이스 복구정보를 기록하는 방법을 사용하는 분야에서는 유용하게 사용될 수 있다.
종래의 경우, 사용자 버퍼에 저장된 데이터를 페이지 캐시(page cache)에 임시적으로 저장하고, fsync() 또는 fdatasync()라는 함수를 통해 페이지 캐시에 저장된 데이터를 저장 장치에 기록하였다. 또한, 직접 입출력(DIO)를 통해 데이터를 페이지 캐시를 거치지 않고 바로 저장 장치에 기록하였다.
fsync()에서, 파일 시스템은 각각의 파일에 대해 업데이트된 메타데이터를 저널링할 수 있다. fdatasync()에서, 파일 블록들이 할당되거나 또는 할당되지 않을 때, 파일 시스템은 업데이트된 메타데이터를 저널링할 수 있다. DIO write는 그 자체로 어떠한 파일 시스템 저널링을 수반하지 않는다.
기록 동작(write operation)은 2가지 타입들(write를 할당하는 과정, write를 할당하지 않는 과정)로 분류될 수 있다. Write를 할당하는 과정은 블록 비트맵, 아이노드 테이블, 중간 노드 블록 등과 같은 다양한 메타데이터를 업데이트할 수 있다. Write를 할당하지 않는 과정은, 파일 블록들을 할당하는 것을 수반하지 않는다. 그것은 필드와 관련된 액세스 시간과 메타데이터에서 초기화된 플래그를 업데이트할 뿐이다.
write를 할당하는 것과 write를 할당하지 않는 경우 모두에서, fsync()는 업데이트된 메타데이터를 저널링할 수 있다. Write를 할당하는 경우, fdatasync()는 fsync()와 동일한 행동을 나타낸다. 그리고, write를 할당하지 않는 경우, fdatasync()는 어떠한 메타데이터를 저널링하지 않는다. write를 할당하는 것과 write를 할당하지 않는 경우 모두에서, DIO(Direct IO)는 파일 시스템의 저널링을 수반하지 않는다. DIO에서, 업데이트된 메타데이터는 손실되기 쉽다.
종래의 경우, DIO를 사용하지 않으면 메타데이터를 페이지 캐시에 저장하고, 메타데이터를 fsync()나 fdatasync()를 통해 저장 장치에 동기화하는 파일 시스템 저널링 과정이 발생하는데, 이와 같은 불필요한 파일 시스템 저널링으로 인해서 데이터베이스에 대한 입출력 양이 증가하고, 저장 장치의 수명이 단축되는 문제가 있었다.
본 발명은 파일에 기록한 내용을 저장 장치에 동기화할 때 실질적으로 발생하는 입출력의 양을 대폭 감소시킴으로써 저장 장치의 성능을 향상시키고 수명이 연장될 수 있는 보호 방법 및 보호 장치를 제공한다.
본 발명의 일실시예에 따른 보호 방법은 저널 파일을 위한 일정량의 초기화된 블록들을 저장 장치에 미리 할당(preallocation)하는 단계; 및 데이터 동기화 함수를 호출함으로써, 상기 저널 파일에 대한 업데이트된 메타데이터를 저장 장치에 저널링하는 단계를 포함할 수 있다.
상기 보호 방법은 상기 저널링하는 단계 이후에, 데이터베이스의 복구 정보인 로그를 상기 블록에 커밋하는 단계를 더 포함할 수 있다.
상기 커밋하는 단계는, 상기 로그를 데이터베이스로부터 저장 장치에 미리 할당된 블록에 직접 입출력 (DIO) 방식 또는 버퍼링된 입출력(Buffered IO) 방식으로 기록할 수 있다.
상기 저널링하는 단계는, 상기 저널 파일에 대한 메타데이터를 데이터 동기화 함수를 통해 동기화함으로써 저장 장치에 저장할 수 있다.
상기 블록은, 상기 저장 장치에 할당된 블록을 제로로 채우거나, 상기 저장 장치에 폐기 명령(discard command)을 적용함으로써 초기화될 수 있다.
상기 보호 방법은 상기 로그를 커밋함에 따라 미리 할당된 블록 전부가 차면(full), 미리 설정된 양의 블록을 재할당하는 단계를 더 포함할 수 있다.
상기 보호 방법은 상기 블록이 재할당됨에 따라 저널 파일의 파일 크기가 변경되는 경우, 저널 파일에 대한 메타데이터를 동기화함으로써 저널링하는 단계를 더 포함할 수 있다.
본 발명의 일실시예에 따른 보호 장치는 프로세서를 포함하고, 상기 프로세서는, 저널 파일을 위한 일정량의 초기화된 블록들을 저장 장치에 미리 할당(preallocation)하는 단계; 및 데이터 동기화 함수를 호출함으로써, 상기 저널 파일에 대한 업데이트된 메타데이터를 저장 장치에 저널링하는 단계를 수행할 수 있다.
상기 프로세서는, 상기 저널링하는 단계 이후에, 데이터베이스의 복구 정보인 로그를 상기 블록에 커밋하는 단계를 더 수행할 수 있다.
상기 프로세서는, 상기 로그를 데이터베이스로부터 저장 장치에 미리 할당된 블록에 직접 입출력 (DIO) 방식 또는 버퍼링된 입출력(Buffered IO) 방식으로 기록할 수 있다.
상기 프로세서는, 상기 저널 파일에 대한 메타데이터를 데이터 동기화 함수를 통해 동기화함으로써 저장 장치에 저장하는 저널링을 수행할 수 있다.
상기 블록은, 상기 저장 장치에 할당된 블록을 제로로 채우거나, 상기 저장 장치에 폐기 명령(discard command)을 적용함으로써 초기화될 수 있다.
상기 프로세서는, 상기 로그를 커밋함에 따라 미리 할당된 블록 전부가 차면(full), 미리 설정된 양의 블록을 재할당하는 단계를 더 수행할 수 있다.
상기 프로세서는, 상기 블록이 재할당됨에 따라 저널 파일의 파일 크기가 변경되는 경우, 저널 파일에 대한 메타데이터를 동기화함으로써 저널링하는 단계를 더 수행할 수 있다.
본 발명의 일실시예에 따르면, 파일에 기록한 내용을 저장 장치에 동기화할 때 실질적으로 발생하는 입출력의 양을 대폭 감소시킴으로써 저장 장치의 성능을 향상시키고 수명이 연장될 수 있다.
도 1은 본 발명의 일실시예에 따른 전체 구성을 도시한 도면이다.
도 2는 본 발명의 일실시예에 따른 파일의 메타데이터에 대한 보호 방법을 도시한 플로우차트이다.
도 3은 본 발명의 일실시예에 따른 파일의 메타데이터에 대한 보호 방법에 대한 예시를 도시한 도면이다.
이하, 본 발명의 실시예를 첨부된 도면을 참조하여 상세하게 설명한다.
도 1은 본 발명의 일실시예에 따른 전체 구성을 도시한 도면이다.
본 발명의 일실시예에 따르면, 데이터베이스(101), 저장 장치(102), 및 보호 장치(103)로 구성될 수 있다. 보호 장치(103)는 본 발명의 일실시예에 따른 파일의 메타데이터를 위한 보호 방법을 수행하며, 특정 단말에 포함된 파일 시스템을 지원하는 프로세서가 될 수 있다.
본 발명의 일실시예에 따르면, 보호 장치(103)는 파일을 위해 미리 설정된 정도의 초기화된 블록들을 미리 할당(preallocation)할 수 있다. 그리고, 보호 장치(103)는 fdatasync()를 호출함으로써, 생성된 파일에 대한 메타데이터를 저널링할 수 있다.
구체적으로, 보호 장치(103)는 저널 파일을 위한 초기화된 블록들은 저장 장치(102)에의 미리 할당될 수 있다. 그리고, 보호 장치(103)는 저널 파일의 메타데이터를 fdatasync()를 통해 저장 장치(102)에 동기화함으로써, 저널 파일의 메타데이터를 저널링할 수 있다. 이 후, 로그들은 직접 입출력(DIO: Direct IO) 또는 버퍼링된 입출력(Buffered IO)를 통해 저널 파일에 미리 할당된 블록에 커밋될 수 있다. 저널 파일의 메타데이터는, 저널 파일의 사이즈와 같은 속성을 의미한다.
여기서, 버퍼링된 입출력은 로그들이 페이지 캐쉬에 write()를 통해 임시적으로 기록된 후, fdatasync()나 fsync()와 같은 함수를 통해 저장 장치(102)에 기록하는 방식을 의미한다. 그리고, 직접 입출력(Direct IO)은 사용자가 데이터를 저장 장치(102)(storage device)로부터 데이터를 읽거나 또는 저장 장치(102)로 데이터를 기록하는 파일 시스템의 기능 중 하나이다. 직접 입출력에 의하면, 데이터는 페이지 캐시에 기록되지 않고 저장 장치(102)에 바로 기록될 수 있다. 즉, 데이터는 페이지 캐시를 바이패스하여 페이지 캐시에 임시적으로 저장되지 않고, 바로 저장 장치(102)에 기록될 수 있다.
본 발명은 데이터베이스에서 지원하는 저널 모드(DELETE, TRUNCATE, PERSIST, WAL, MEMORY 및 OFF 등)에 적용될 수 있다. 데이터베이스에 대해 예상하지 못한 시스템 실패(failure)를 보호하기 위한 방법이 요구된다. 이 때, 크래시로부터 회복하기 위해 데이터베이스는 로그를 유지하는 저널 파일을 사용한다. 트랜잭션의 보장을 위해, 데이터베이스는 로그를 저널 파일에 커밋(commit)하거나 또는 데이터베이스(101)를 업데이트한 후, fdatasync()를 이용하여 로그 파일과 데이터베이스 파일을 동기화한다. 커밋은 트랜잭션의 수행 결과가 데이터베이스(101)에 반영되어 영속적으로 남아 있는 것을 의미한다.
본 발명에서 언급하는 로그를 커밋하는 것은, 데이터베이스(101)에서 데이터의 변경 사항을 나타내는 데이터베이스(101)의 복구 정보인 로그를 저널 파일을 위해 미리 할당된 블록에 저장하는 과정을 의미한다.
본 발명의 일실시예에 따른 보호 장치(103)는 초기화된 블록을 미리 할당(preallocating) 과정과 저널링 과정을 수행함으로써, 예상되지 않은 시스템 크래시에 의해 파일에 대한 메타데이터를 적절히 보호하기 위해 파일 시스템 저널링을 제거할 수 있다. 여기서, 저널링은 저장 장치(102)에 데이터의 변경 이력을 저장하기 전에 저널이라는 로그 안에 데이터의 변경 이력을 저장하는 기법이다. 저널링은 데이터의 변경 이력을 저장하는 도중에 시스템 장애가 발생하는 경우 데이터가 비정상적으로 손상되는 것을 회복하기 위해 사용된다.
도 2는 본 발명의 일실시예에 따른 파일의 메타데이터에 대한 보호 방법을 도시한 플로우차트이다.
단계(201)에서, 보호 장치는 저널 파일을 위한 초기화된 블록들을 미리 할당할 수 있다. 이 때, 미리 할당한다는 의미는, 데이터베이스의 복구 정보인 로그를 기록하기 위한 저널 파일을 생성할 때 또는 생성하기 전에 블록을 미리 할당한다는 것을 의미한다. 초기화된 블록들은 저장 장치에 미리 할당될 수 있다.
단계(202)에서, 보호 장치는 저널 파일에 대해 업데이트된 메타데이터를 저널링할 수 있다. 이 때, 보호 장치는 fdatasync()와 같은 데이터 동기화 함수를 통해 데이터베이스에 존재하는 저널 파일의 메타데이터를 저장 장치에 동기화함으로써, 메타데이터를 저널링할 수 있다.
단계(203)에서, 보호 장치는 직접 입출력(DIO) 또는 버퍼링된 입출력(Buffered IO)를 이용하여 데이터베이스의 복구 정보인 로그를 데이터베이스에서 저장 장치로 커밋할 수 있다. 그러면, 로그는 저널 파일을 위해 미리 할당된 블록에 저장될 수 있다.
단계(203)을 통해 로그가 커밋됨으로써 미리 할당된 블록 전부에 로그가 기록되면, 보호 장치는 다시 미리 설정된 크기의 새로운 블록들을 할당할 수 있다. 이를 통해 저널 파일의 파일 크기가 변경되면, 저널 파일의 메타데이터가 변경될 수 있다. 그러면, 보호 장치는 단계(202)와 같이 변경된 메타데이터를 저널링을 통해 저장 장치에 동기화할 수 있다.
도 3은 본 발명의 일실시예에 따른 파일의 메타데이터에 대한 보호 방법에 대한 예시를 도시한 도면이다.
본 발명의 일실시예에 따르면, 로그(302)들을 저널 파일에 커밋하기 위해 DIO(Direct IO) 기반의 쓰기 연산 또는 Buffered IO 기반의 쓰기 연산을 제안한다. 본 발명의 일실시예에 따르면, 저장 장치에 로그(302)들을 DIO에 따라 직접적으로 기록하거나 또는 Buffered IO에 따라 로그를 페이지 캐시에 임시로 저장한 후에 저장 장치에 기록할 수 있다. 로그(302)를 커밋하는 행위가 데이터 블록(303)이나 메타데이터(301)에 대해 어떠한 업데이트들이 페이지 캐시 엔트리들에서 수반되지 않도록 한다. 이러한 접근을 위해, fdatasync()와 같은 데이터베이스의 동기화 과정은 IO와 관련된 어떠한 파일 시스템 저널링을 트리거링하지 않는다.
본 발명은 로그(302)를 커밋하는 동작에서 저널링의 간섭을 제거하고, 저널 파일의 메타데이터(301)를 보호할 수 있다. 본 발명과 같이, 명백한 저널링을 수반하는 미리 할당 과정(preallocation with explicitly journaling)은 (i) 저널 파일을 위해 일정 량의 초기화된 특정 블록(303)들을 미리 할당하고, (ii) fdatasync()를 호출함으로써, 생성된 저널 파일을 위한 메타데이터(301)를 저널링할 수 있다. 종래의 경우, 데이터베이스 저널 파일의 메타데이터(301)를 보호하기 위해, 파일 시스템 저널링에 의존할 필요가 있다. 그러나, 이는 파일시스템 저널링을 수반하기 위한 모든 로그(302) 커밋 동작을 억압할 수 있는 문제가 있으나, 본 발명은 이러한 파일 시스템 저널링을 제거함으로써 이러한 억압에서 해소될 수 있다.
도 3에 의하면, (i) 저널 파일을 위한 초기화된 블록(303)들이 미리 할당될 수 있다. 이러한 블록들은 저장 장치에 미리 할당된다. (ii) 저널 파일의 메타데이터(301)는 fdatasync()를 통해 동기화됨으로써 저널링된다. 즉, 저널 파일의 메타데이터(301)는 저장 장치에 저장된다. 그리고, (iii) 로그(302)들은 DIO를 통해 저널 파일에 커밋된다. 즉, 데이터베이스의 복구 정보인 로그(302)들은 DIO를 통해 페이지 캐시를 거치지 않고 바로 저장 장치에 미리 할당된 블록에 기록될 수 있다.
파일 시스템은 각각의 블록(303)에 대해 초기화된 플래그를 유지할 수 있다. 플래그가 설정될 때, 블록(303)은 초기화될 수 있다. 초기화되지 않은 블록(303)을 읽기 위한 어떠한 시도들은 모드 0을 리턴할 수 있다. 이러한 매커니즘에 대한 가장 우선적인 이유는 오래된 데이터(stale data)를 노출하는 것을 피하기 위함이다.
저널 파일을 위한 블록(303)들을 미리 할당할 때, 로그(302)의 커밋 동작 기반의 Direct IO는 write를 할당하지 않을 수 있다. 그러면, 페이지 캐쉬 엔트리들과 저널 파일의 메타데이터(301)는 온전하게 유지된다. 본 발명의 일실시예에 따른 저널 모드에서 로그(302)의 커밋 동작은 간섭을 일으키는 파일 시스템 저널링 모듈을 위한 어떠한 공간도 남기지 않는다. 본 발명의 일실시예에 따른 저널 모드는 파일 시스템 저널링으로부터 데이터베이스를 보호한다. 저널 파일이 생성되거나 또는 확장될 때, 본 발명의 일실시예에 따른 저널 모드는 파일에 대한 메타데이터(301)를 동기화하기 위해 fdatasync()를 호출할 수 있다. 명백한 저널링이 수반되는 경우, 저널 파일은 시스템 오류에 강건할 수 있다.
블록들을 미리 할당할 때, 할당된 블록(303)들을 초기화하기 위해 특별한 보호가 요구된다. 이와는 달리, 예상되지 않은 시스템 실패 이후에, 본 발명의 일실시예에 따른 저널 모드에서 기록된 로그(302)들은 읽을 수 없다. 파일 시스템의 fallocate() 시스템 호출은 초기화되지 않은 블록(303)들을 리턴한다. 처음에 블록(303)들이 기록될 때, 초기화된다. 블록(303)이 DIO로 기록될 때, 블록(303)들이 아직 초기화되지 않은 경우, 파일 시스템은 초기화된 플래그를 설정할 수 있다. 그러나, DIO 기록은 파일 시스템을 저널링하는 것을 수반하지 않기 때문에, 업데이트된 플래그는 예상되지 않은 시스템 실패에 손실되기 쉽다.
할당된 블록(303)들을 초기화하는 것은 3가지 방법 있다. 첫번째 방법으로, 할당된 블록(303)들에 대해 제로(0)를 채우는 것이다. 두번째 방법과 세번째 방법은, 노출로부터 오래된 컨텐츠를 보호하기 위해 저장 장치인 eMMC(embedded MultiMediaCard)에 폐기 (또는 트림) 명령을 사용하는 것이다. eMMC는 낸드 플래시 메모리와 플래시 메모리 컨트롤러가 패키지로 통합된 저장장치다. 빠른 입/출력 속도를 지원하기 때문에 모바일 기기에 많이 사용되지만 낸드 플래시 저장장치의 특성상 쓰기/지우기 횟수에 제한이 있다. 폐기 명령은 입력으로서 논리적인 블록(303) 주소들의 리스트를 취할 수 있고, eMMC 저장 장치가 각각의 논리적인 블록(303)을 위한 맵핑 테이블 엔트리들을 제거하도록 요청할 수 있다.
두 번째 방법은 파일 시스템에 폐기 옵션(discard option)을 마운트하고, 초기화된 플래그 셋트를 가지는 블록(303)들을 할당하는 fallocate()를 수정할 수 있다. 파일 시스템이 폐기 마운트 옵션을 이용할 때, 파일 블록(303)들이 할당 해제될 때 폐기 명령이 발행될 수 있다. 초기화된 플래그 셋트를 가지는 블록(303)들을 리턴하는 fallocate()를 강제하기 위해, 특정 스마트폰을 위해 리눅스 소스에 NO HIDE STALE patch를 포트하는 방안이 제안되었다.
세번째 방법은 초기화된 플래그 셋트를 가지는 블록(303)들을 할당하고, 할당된 블록(303)들을 폐기하는 fallocate()를 수정하는 방안이 제안되었다. 본 발명의 일실시예에 따르면, 폐기 명령은 두번째 방법을 위해 개발된 NO HIDE STALE patch에 임베드되고, fallocate()를 위한 NO HIDE STALE DISCARD의 신규 플래그가 제안되었다.
두번째 방법과 세번째 방법 간의 가장 큰 차이는 블록(303)이 언맵핑되는 시간이다. 두번째 방법과 세번째 방법에 의하면, 파일 블록(303)들이 할당 해제되거나, 할당될 때, 파일 블록(303)들은 언매핑(unmapped)될 수 있다. 두번째 방법에서, 파일 시스템은 모든 할당해제된 블록(303)들을 위해 폐기 명령을 발행할 수 있다. 하지만, 세번째 방법에 의하면, 파일 시스템은 저널 파일에 할당되는 파일 블록(303)들을 폐기할 수 있다. 그러면, 세번째 방법은 두번째 방법보다 좀더 작은 오버헤드를 나타낼 수 있다.
첫번째 방법에 따라 블록(303)에 제로를 채우는 zero-fill 과정은 IO 오버헤드를 수반한다. 폐기 마운트 옵션을 이용하는 것은, 파일 시스템의 속도를 늦출 수 있다. 최근 스마트폰들은 파일 시스템에 폐기 옵션을 마운트한다. 폐기 옵션은 가비지 컬렉션을 좀더 효율적으로 만들도록 디자인될 수 있다. 하지만, 폐기 옵션은 오래된 컨텐츠를 숨기도록 디자인되지 않는다.
eMMC 표준은 폐기된 블록(303)들에 접근할 때 무엇을 읽을 필요가 있는지에 대해 정의하지 않는다. 어떤 eMMC 저장 장치는 폐기된 블록(303)들에 접근할 때 모두 0을 리턴할 수 있다. 오래된 컨텐츠를 숨기기 위한 폐기 명령을 사용할 때, 주어진 eMMC 저장 장치가 오래된 컨텐츠를 유출하지 않는 것을 보장하는 것이 필요하다. 이러한 경우, 폐기된 블록(303)들에 접근할 때 모두 0을 리턴하거나 또는 모두 1을 리턴하는 것이 보장될 수 있다.
반면에, 본 발명의 일실시예에 따르면, 좀더 많은 오버헤드가 발생될 수 있다고 하더라도 트림 명령(trim command)를 이용하는 것을 의존할 필요가 있다. 트림된 블록(303)들에 접근할 때, 트림 명령은 모두 0을 리턴하거나 또는 모두 1을 리턴할 수 있다. 뿐만 아니라, 주어진 eMMC 저장 장치를 보장하기 위해 eMMC 저장 장치가 백그라운드에서 가비지 컬랙션을 수행하더라도, 특정 환경에서 호스트로부터의 폐기 명령을 무시할 수 없다.
본 발명의 실시 예에 따른 방법들은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다.
이상과 같이 본 발명은 비록 한정된 실시예와 도면에 의해 설명되었으나, 본 발명은 상기의 실시예에 한정되는 것은 아니며, 본 발명이 속하는 분야에서 통상의 지식을 가진 자라면 이러한 기재로부터 다양한 수정 및 변형이 가능하다.
그러므로, 본 발명의 범위는 설명된 실시예에 국한되어 정해져서는 아니 되며, 후술하는 특허청구범위뿐 아니라 이 특허청구범위와 균등한 것들에 의해 정해져야 한다.

Claims (14)

  1. 저널 파일을 위한 일정량의 초기화된 블록들을 저장 장치에 미리 할당(preallocation)하는 단계; 및
    데이터 동기화 함수를 호출함으로써, 상기 저널 파일에 대한 업데이트된 메타데이터를 저장 장치에 저널링하는 단계
    를 포함하는 보호 방법.
  2. 제1항에 있어서,
    상기 저널링하는 단계 이후에, 데이터베이스의 복구 정보인 로그를 상기 블록에 커밋하는 단계
    를 더 포함하는 보호 방법.
  3. 제2항에 있어서,
    상기 커밋하는 단계는,
    상기 로그를 데이터베이스로부터 저장 장치에 미리 할당된 블록에 직접 입출력 (DIO) 방식 또는 버퍼링된 입출력(Buffered IO) 방식으로 기록하는 보호 방법.
  4. 제1항에 있어서,
    상기 저널링하는 단계는,
    상기 저널 파일에 대한 메타데이터를 데이터 동기화 함수를 통해 동기화함으로써 저장 장치에 저장하는 보호 방법.
  5. 제1항에 있어서,
    상기 블록은,
    상기 저장 장치에 할당된 블록을 제로로 채우거나, 상기 저장 장치에 폐기 명령(discard command)을 적용함으로써 초기화되는 보호 방법.
  6. 제1항에 있어서,
    상기 로그를 커밋함에 따라 미리 할당된 블록 전부가 차면(full), 미리 설정된 양의 블록을 재할당하는 단계
    를 더 포함하는 보호 방법.
  7. 제6항에 있어서,
    상기 블록이 재할당됨에 따라 저널 파일의 파일 크기가 변경되는 경우, 저널 파일에 대한 메타데이터를 동기화함으로써 저널링하는 단계
    를 더 포함하는 보호 방법.
  8. 파일의 메타데이터를 위한 보호 방법을 수행하는 보호 장치는,
    프로세서를 포함하고,
    상기 프로세서는,
    저널 파일을 위한 일정량의 초기화된 블록들을 저장 장치에 미리 할당(preallocation)하는 단계; 및
    데이터 동기화 함수를 호출함으로써, 상기 저널 파일에 대한 업데이트된 메타데이터를 저장 장치에 저널링하는 단계
    를 수행하는 보호 장치.
  9. 제8항에 있어서,
    상기 프로세서는,4
    상기 저널링하는 단계 이후에, 데이터베이스의 복구 정보인 로그를 상기 블록에 커밋하는 단계
    를 더 수행하는 보호 장치.
  10. 제9항에 있어서,
    상기 프로세서는,
    상기 로그를 데이터베이스로부터 저장 장치에 미리 할당된 블록에 직접 입출력 (DIO) 방식 또는 버퍼링된 입출력(Buffered IO) 방식으로 기록하는 보호 장치.
  11. 제8항에 있어서,
    상기 프로세서는,
    상기 저널 파일에 대한 메타데이터를 데이터 동기화 함수를 통해 동기화함으로써 저장 장치에 저장하는 저널링을 수행하는 보호 장치.
  12. 제8항에 있어서,
    상기 블록은,
    상기 저장 장치에 할당된 블록을 제로로 채우거나, 상기 저장 장치에 폐기 명령(discard command)을 적용함으로써 초기화되는 보호 장치.
  13. 제8항에 있어서,
    상기 프로세서는,
    상기 로그를 커밋함에 따라 미리 할당된 블록 전부가 차면(full), 미리 설정된 양의 블록을 재할당하는 단계
    를 더 수행하는 보호 장치.
  14. 제13항에 있어서,
    상기 프로세서는,
    상기 블록이 재할당됨에 따라 저널 파일의 파일 크기가 변경되는 경우, 저널 파일에 대한 메타데이터를 동기화함으로써 저널링하는 단계
    를 더 수행하는 보호 장치.
PCT/KR2016/015518 2015-12-31 2016-12-29 파일의 메타데이터에 대한 보호 방법 및 보호 장치 Ceased WO2017116186A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2015-0191670 2015-12-31
KR1020150191670A KR101744685B1 (ko) 2015-12-31 2015-12-31 파일의 메타데이터에 대한 보호 방법 및 보호 장치

Publications (1)

Publication Number Publication Date
WO2017116186A1 true WO2017116186A1 (ko) 2017-07-06

Family

ID=59220057

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/015518 Ceased WO2017116186A1 (ko) 2015-12-31 2016-12-29 파일의 메타데이터에 대한 보호 방법 및 보호 장치

Country Status (3)

Country Link
US (1) US20170193005A1 (ko)
KR (1) KR101744685B1 (ko)
WO (1) WO2017116186A1 (ko)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102132387B1 (ko) * 2018-10-19 2020-07-09 한양대학교 산학협력단 배리어 기반 로깅 방법 및 장치
US11847333B2 (en) * 2019-07-31 2023-12-19 EMC IP Holding Company, LLC System and method for sub-block deduplication with search for identical sectors inside a candidate block
KR102838560B1 (ko) * 2019-08-06 2025-07-28 삼성전자 주식회사 데이터베이스의 데이터 유실을 방지하기 위한 전자 장치 및 전자 장치의 동작 방법
US12346223B2 (en) * 2020-11-27 2025-07-01 Korea Advanced Institute Of Science And Technology Commit block structure and device, for multiple file transaction
KR102835855B1 (ko) * 2021-11-30 2025-07-18 한국전자통신연구원 비휘발성 메모리에 고속 영구적 쓰기 장치 및 방법
KR102777675B1 (ko) * 2021-12-28 2025-03-10 오토아이티(주) 스트리밍용 대용량 데이터의 단편화 방지 방법 및 장치

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6606651B1 (en) * 2000-05-03 2003-08-12 Datacore Software Corporation Apparatus and method for providing direct local access to file level data in client disk images within storage area networks
JP2007199889A (ja) * 2006-01-25 2007-08-09 Hitachi Ltd ストレージシステム、記憶制御装置及び記憶制御装置のリカバリポイント検出方法
KR20080058834A (ko) * 2006-12-22 2008-06-26 삼성전자주식회사 파일 시스템 관리 장치 및 방법
KR20090009300A (ko) * 2006-05-03 2009-01-22 데이터 로보틱스 인코포레이티드 파일 시스템 인식 블록 저장 시스템, 장치 및 방법

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100906454B1 (ko) 2009-03-18 2009-07-08 주식회사 신시웨이 데이터베이스 로그 정보 관리 장치 및 방법

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6606651B1 (en) * 2000-05-03 2003-08-12 Datacore Software Corporation Apparatus and method for providing direct local access to file level data in client disk images within storage area networks
JP2007199889A (ja) * 2006-01-25 2007-08-09 Hitachi Ltd ストレージシステム、記憶制御装置及び記憶制御装置のリカバリポイント検出方法
KR20090009300A (ko) * 2006-05-03 2009-01-22 데이터 로보틱스 인코포레이티드 파일 시스템 인식 블록 저장 시스템, 장치 및 방법
KR20080058834A (ko) * 2006-12-22 2008-06-26 삼성전자주식회사 파일 시스템 관리 장치 및 방법

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
WONGUN LEE ET AL.: "WALDIO: Eliminating the Filesystem Journaling in Resolving the Journaling of Journal Anomaly", PROCEEDINGS OF THE 2015 USENIX ANNUAL TECHNICAL CONFERENCE- USENIX, 27 June 2015 (2015-06-27) - 8 July 2015 (2015-07-08), pages 242 - 254, XP061024783 *

Also Published As

Publication number Publication date
US20170193005A1 (en) 2017-07-06
KR101744685B1 (ko) 2017-06-09

Similar Documents

Publication Publication Date Title
WO2017116186A1 (ko) 파일의 메타데이터에 대한 보호 방법 및 보호 장치
US10175894B1 (en) Method for populating a cache index on a deduplicated storage system
US9152349B2 (en) Automated information life-cycle management with thin provisioning
US8924664B2 (en) Logical object deletion
US10983955B2 (en) Data unit cloning in memory-based file systems
EP3115903B1 (en) File accessing method and related device
US9946477B2 (en) Information processing apparatus, information processing method, and computer program product
US8176294B2 (en) Reducing storage expansion of a virtual machine operating system
US9501421B1 (en) Memory sharing and page deduplication using indirect lines
US20170097909A1 (en) Storage controller cache memory operations that forego region locking
WO2013069859A1 (ko) 소거 대상 블록의 매핑 테이블을 저장하는 플래시 메모리 제어장치 및 방법
WO2012008732A2 (ko) 페이지 단위 매핑 기법을 이용한 플래시 메모리 관리 장치 및 방법
EP4375836A1 (en) Memory paging method and system, and storage medium
CN118819871B (zh) 内存管理方法、宿主机、电子设备、存储介质和程序产品
US10452267B2 (en) Storage scheme for a distributed storage system
WO2021047425A1 (zh) 一种持久性内存的虚拟化方法及系统
WO2012008731A2 (ko) 블록 단위 매핑 기법을 이용한 플래시 메모리 관리 장치 및 방법
US8892838B2 (en) Point-in-time copying of virtual storage and point-in-time dumping
US10204002B1 (en) Method for maintaining a cache index on a deduplicated storage system
US9798793B1 (en) Method for recovering an index on a deduplicated storage system
US12259793B2 (en) Allocating system RDP metadata space with IO performance priority
US8990541B2 (en) Compacting Memory utilization of sparse pages
US10430105B2 (en) Storage scheme for a distributed storage system
CN119493519A (zh) 数据管理方法及其装置
US10289307B1 (en) Method for handling block errors on a deduplicated storage system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16882138

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16882138

Country of ref document: EP

Kind code of ref document: A1