WO2022114898A1 - 다중파일 트랜잭션의 파일 관리 기법 및 장치 - Google Patents

다중파일 트랜잭션의 파일 관리 기법 및 장치 Download PDF

Info

Publication number
WO2022114898A1
WO2022114898A1 PCT/KR2021/017783 KR2021017783W WO2022114898A1 WO 2022114898 A1 WO2022114898 A1 WO 2022114898A1 KR 2021017783 W KR2021017783 W KR 2021017783W WO 2022114898 A1 WO2022114898 A1 WO 2022114898A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
call
filegroup
group
transaction
Prior art date
Application number
PCT/KR2021/017783
Other languages
English (en)
French (fr)
Inventor
원유집
오준택
Original Assignee
한국과학기술원
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 한국과학기술원 filed Critical 한국과학기술원
Publication of WO2022114898A1 publication Critical patent/WO2022114898A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/1865—Transactional file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/11—File system administration, e.g. details of archiving or snapshots
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/185—Hierarchical storage management [HSM] systems, e.g. file migration or policies thereof

Definitions

  • the present invention relates to computing technology, and more particularly, to a technique for managing a plurality of files modified by a transaction when a file system supports a transaction function.
  • a file system supporting a transaction function is defined as a transactional file system.
  • a transaction support file system provides a transaction function to a user application (user) in the form of a system call.
  • the prior art can be classified into a file-oriented transaction management technology and a process-oriented transaction management technology.
  • File-centric transaction management technology stores transaction information in a data structure that represents a set of information related to a file. This data structure is called an inode.
  • Process-oriented transaction management technology stores transaction information in a data structure that represents a set of information related to a process. This data structure is called a process control block. In Linux, the process control block is called task_struct.
  • a representative file-oriented transaction management technology is single file transaction of F2FS.
  • the inode of F2FS has a flag indicating whether the file is in transaction or not, and a list of contents modified by the transaction.
  • the contents modified by the transaction are managed in the unit of page, which is the caching unit of the disk block.
  • the list of contents modified by the transaction is the list of pages modified by the transaction.
  • the user passes the file as an argument when starting or committing a transaction. To be precise, when the user opens a file, the file descriptor assigned to each file is passed as an argument.
  • the flag value indicating transaction progress is changed to 1 in the inode.
  • the changed page is inserted into the page list of the inode.
  • the pages in the page list are written atomically to the storage device.
  • a representative process-oriented transaction management technology is TxFS.
  • the process control block (struct task_struct) of TxFS has a flag indicating whether or not the transaction is in progress and a list of pages modified by the transaction.
  • transaction start and commit do not require any arguments.
  • the value of the flag indicating transaction progress is changed to 1 in the process control block of the process that called the start of the transaction. All pages modified by the process that started the transaction are inserted into the page list in the process control block of the process.
  • the pages in the page list of the process control block are atomically written to the storage device.
  • File-centric transaction management technology does not support multi-file transactions.
  • Inode which is a data structure that stores transaction information in file-oriented transaction management technology, is a data structure that represents one file.
  • the transaction information stored in the inode is limited to one file in the transaction scope.
  • the unit of transaction start and commit is also a file descriptor. The problem is that the transactions that a user can initiate or commit are limited to single-file transactions.
  • process-oriented transaction management technology users cannot specify which files to include in a transaction.
  • File-related information is not stored in the process control block, which is a data structure that process-oriented transaction management technology stores transaction information. It is not possible to store information indicating which files to participate in a transaction. The start and commit of a transaction do not receive any arguments. There is no way to specify which files to participate in the transaction. Therefore, in a process-oriented transaction, all file contents changed by the process that started the transaction participate in the transaction. This has a problem in that unnecessary contents may be included in the transaction.
  • software that requires multi-file transaction function includes server-oriented or embedded database systems, software installers, and web browsers. They implement multi-file transactions either by using proprietary logging mechanisms or by using successive invocations of single-file transactions and writing to global log files.
  • these conventional techniques suffer from severe performance degradation due to write volume amplification and indiscriminate flush calls.
  • An object of the present invention is to provide a file management method of a transaction that does not limit a transaction that a user can start or commit to a single file transaction, and does not include unnecessary contents in the transaction.
  • An object of the present invention is to provide a technology that supports a multi-file transaction function at the operating system level to provide efficient transaction performance while allowing a user to designate a file to participate in a transaction.
  • a method and apparatus for managing files of a multi-file transaction when an operating system supports a transaction function may be provided.
  • a transaction filegroup which is a new data structure for a multi-file transaction, is defined, and the transaction is executed in units of the transactional filegroup.
  • a file management technique for multi-file transaction and an apparatus thereof are defined.
  • the multi-file transaction of the prior art has a limitation that a user cannot specify a file to participate in the transaction.
  • a multi-file transaction is defined in which a user can designate a file to participate in the transaction.
  • the concept of a transaction filegroup is provided.
  • FIG. 11 shows the structure of a transaction filegroup according to the present invention.
  • the transaction file group 110 (TFG) consists of an inode list 111 , a data page list 112 , and a metadata page list 113 .
  • the inode list 111 is a list consisting of inodes of files participating in a transaction.
  • the data page list 112 and the metadata page list 113 are lists of data pages and metadata pages modified by a transaction, respectively.
  • a user may create and delete the transaction filegroup 110 through a system call.
  • the user who has created the transaction filegroup 110 is returned an ID of the transaction filegroup 110 .
  • the user can access the transaction filegroup 110 created by the user with the corresponding ID.
  • a user may add files to participate in a transaction to the transaction filegroup 110 through a system call.
  • a call to create the transaction filegroup 110 and a call to add files to participate in a transaction to the transaction filegroup 110 may be expressed as CALL: Create ( ) and CALL: Add ( ), respectively.
  • the transaction filegroup 110 is used as a basic unit of transaction start and commit.
  • the ID of the transaction filegroup 110 is used as a factor.
  • TFG#1 is the ID of the transaction filegroup of the first transaction.
  • the calls can be regarded as calls related to the selected transaction filegroup. have.
  • a flag value indicating that a transaction is in progress is changed to 1 in the inodes in the inode list 111 of the transaction filegroup 110 .
  • Multiple inodes must be changed atomically.
  • two-step locking is used. First, the locks of the inodes are acquired collectively and the inodes are modified. When the modification is completed, the locks of the inodes are released at once. If a file added to the transaction filegroup 110 is modified while a transaction is in progress, the modified page is inserted into the page list of the transaction filegroup 110 .
  • the ID of the transactional filegroup is passed as an argument.
  • the commit of a multi-transaction filegroup can be made by the commit call CALL: Commit ( ). And at this time, the ID of the transaction filegroup to be committed is included in ( ).
  • Commitment of a multi-transaction filegroup atomically writes the pages in the page list of the transaction filegroup to the storage device.
  • FIG. 12 is a flowchart illustrating an operation of a multi-file transaction defined according to an aspect of the present invention.
  • step S611 the user first creates a transaction filegroup (create_tx_file_group( )).
  • step S612 the user may add files to participate in the transaction to the transaction filegroup (add_tx_file_group( )).
  • step S613 when a transaction is started, a transaction is started for files included in the transaction filegroup.
  • step S614 if the user changes the corresponding files, the changes are added to the transaction.
  • step S618 if the transaction proceeds abnormally due to a file operation failure in the middle, the transaction is aborted (abort_tx_file_group( )).
  • step S616 on the other hand, if the transaction proceeds normally, the transaction is committed (commit_tx_file_group( )).
  • step S617 when the transaction is completed, the transaction filegroup is deleted (delete_tx_file_group( )).
  • the create_tx_file_group( ) may be expressed as CALL: Create ( ).
  • the add_tx_file_group( ) may be expressed as CALL: Add ( ).
  • the abort_tx_file_group( ) may be expressed as CALL: Abort ( ).
  • the commit_tx_file_group( ) may be expressed as CALL: Commit ( ).
  • the commit_tx_file_group( ) may be expressed as CALL: Commit ( ).
  • the file system of the host creates a file group in a group creation step (S711); and a commit step (S117) of committing, when the file system receives a commit call specifying the filegroup, commits a transaction including only operation calls related to files included in the filegroup.
  • the file system adds a file of a group to the filegroup as a member of the filegroup (S712); and executing, by the file system, an operation call on the files included in the filegroup (S713, S714), and executing an operation call on another file not included in the filegroup (S715, S716).
  • S712 a file of a group to the filegroup as a member of the filegroup
  • S713 an operation call on the files included in the filegroup
  • S715, S716 may include more.
  • the file system may further include deleting the filegroup ( S717 ).
  • the group creation step may be executed when the file system receives the file group creation call
  • the file adding step may be executed when the file system receives the file addition call.
  • the file addition call includes information about an identifier for identifying the filegroup and an identifier for identifying a file of the one group
  • the start call includes information about an identifier for identifying the filegroup
  • the commit call may include information about an identifier for identifying the filegroup.
  • a host may be provided.
  • the host may include a processing unit; and a communication unit, wherein the processing unit executes a file system of the host, wherein the file system includes: a group creation step (S711) of creating a file group; and when a commit call designating the filegroup is received, a commit step (S117) of committing a transaction composed of only operation calls related to files included in the filegroup is executed.
  • the file system is configured between the group creation step and the commit step
  • a file adding step of adding a group of files to the file group as a member of the file group (S712); and executing an operation call for files included in the filegroup (S713, S714) and executing an operation call for another file not included in the filegroup (S715, S716).
  • the processing unit is configured to execute an application of the host, and the application includes, before the group creation step, transmitting a filegroup creation call to create the filegroup to the file system (S111); between the group creation step and the file addition step, transmitting a file add call indicating a request to add a file of the one group as a member of the file group to the file system (S112); and transmitting a start call specifying the file group to the file system (S113) between the file adding step and the executing the operation call.
  • the group creation step may be executed when the file system receives the file group creation call
  • the file adding step may be executed when the file system receives the file addition call.
  • a computing device including a host and storage may be provided.
  • the host may be configured to execute a file system.
  • the file system may include: a group creation step of creating a file group (S711); and when a commit call designating the filegroup is received, a commit step (S117) of committing a transaction composed of only operation calls related to files included in the filegroup is executed.
  • the storage may be configured to store, in the storage, a transaction including only operation calls related to files included in the filegroup when the file system executes the commit step.
  • the file system is configured between the group creation step and the commit step
  • a file adding step of adding a group of files to the file group as a member of the file group (S712); and executing an operation call for files included in the filegroup (S713, S714) and executing an operation call for another file not included in the filegroup (S715, S716).
  • the file management method provided according to an aspect of the present invention is applicable to all fields requiring transaction support, including database management systems such as SQLite and MySQL, key value stores such as MongoDB and RocksDB, and file systems such as EXT4 and XFS. can be applied.
  • database management systems such as SQLite and MySQL
  • key value stores such as MongoDB and RocksDB
  • file systems such as EXT4 and XFS.
  • the file management method provided according to one aspect of the present invention is applied to embedded devices such as smart phones and smart cars that use transactions for consistency of all server software or all services and data using the database management system. can be applied.
  • the method provided according to the present invention is applicable to any software requiring multi-file transaction function.
  • the present invention can be applied to data center management software, databases, and embedded applications requiring data consistency.
  • the present invention can be applied not only to the smartphone market and data center market, but also to all fields requiring multi-file transactions.
  • the present invention can be applied to the business of any enterprise that develops software.
  • a web browser In the case of a web browser, it stores website visit history and file download history in multiple files. This applies to both desktop web browsers and mobile web browsers.
  • RocksDB a database system used by many companies for data center management and distributed storage such as Ceph, requires multiple file operations in compaction operations. These are all software that can be optimized for multi-file transactions.
  • the present invention is a technology capable of improving their service quality.
  • the present invention it is possible to provide a file management method of a transaction that does not limit a transaction that a user can start or commit to a single file transaction and does not include unnecessary contents in the transaction.
  • a technology can be provided that supports a multi-file transaction function at the operating system level to provide efficient transaction performance while allowing a user to designate a file to participate in a transaction.
  • FIG. 1 illustrates a concept in which a host records information in storage according to an exemplary embodiment.
  • Figure 2 shows different transactions executed by the host.
  • FIG 3 illustrates one transaction processing method provided according to an embodiment.
  • FIG 4 illustrates two transaction processing methods provided according to an embodiment.
  • FIG. 5 is a diagram illustrating a concept in which a host records information in storage according to an embodiment of the present invention.
  • FIG. 6 is a flowchart illustrating a method of executing a transaction provided according to an embodiment of the present invention.
  • FIG. 7 shows an embodiment modified from FIG. 6 .
  • FIG. 8 is a flowchart illustrating a method of executing a transaction according to a comparative embodiment.
  • FIG. 9 is a flowchart illustrating a transaction execution method provided according to an embodiment of the present invention.
  • FIG. 10 is a flowchart illustrating a transaction execution method provided according to an embodiment of the present invention.
  • FIG. 11 shows the structure of a transaction filegroup according to the present invention.
  • FIG. 12 is a flowchart illustrating an operation of a multi-file transaction defined according to an aspect of the present invention.
  • FIG. 1 illustrates a concept in which a host records information in storage according to an exemplary embodiment.
  • the host 10 and the storage 20 may be computing devices operating by supplying power from a power supply, respectively.
  • the host 10 and the storage 20 may exchange data and commands through one or more transport channels 30 .
  • the transport channels 30 may be a wireless channel or a wired channel.
  • the host 10 and the storage 20 may share power provided from one power supply device, or may receive power from two different power supply devices, respectively.
  • the host 10 may include a CPU, a memory, a power supply, and a communication device.
  • the storage 20 may include a controller 21 , a volatile memory 22 , and a non-volatile memory 23 .
  • the host 10 may transmit various commands and data to the storage 20 through the transmission channels 30 .
  • the command may include a write command.
  • the controller 21 of the storage 20 may store the data received from the transport channels 30 in the volatile memory 22 based on the command received from the transport channels 30 .
  • Data stored in the volatile memory 22 may be stored in the nonvolatile memory 23 according to a rule followed by the controller 21 .
  • the data stored in the volatile memory 22 can be deleted when the power supplied to the storage 20 is cut off, but the data stored in the nonvolatile memory 23 is deleted even when the power supplied to the storage 20 is cut off. doesn't happen
  • the host 10 may execute an application 11 and a file system 12 .
  • the application 11 and the file system 12 may be executed by executing predetermined command codes stored in a memory accessed by the host 10 by the CPU included in the host 10 .
  • the application 11 may be a program that is executed or terminated when a user using the host 10 provides a user input through a user interface provided by the host 10 .
  • the file system 12 may be a program that is automatically executed by the host 10 when power is applied to the host 10 or reset is performed.
  • the application 11 may send various system calls to the file system 12 .
  • the file system 12 may execute a job corresponding to the system call.
  • the host 10 may execute a transaction. It may take a certain amount of time from the start of a specific transaction to the end. At a specific point in time, the host 10 may perform one transaction.
  • the application 11 may control the start and commit of a transaction. In addition, the application 11 may control one or more operations to be executed during the transaction. 1 , the application 11 may transmit system calls including a start call, a set of operation calls, and a commit call to the file system 12 .
  • a specific transaction is started by the start call, instructions to be transferred from the host 10 to the storage 20 are prepared by the set of operation calls, and the prepared instructions are prepared by the commit call It may be transmitted to the storage 20 through the transport channels 30 .
  • Figure 2 shows different transactions executed by the host.
  • a set of a plurality of operations may constitute one transaction.
  • the first transaction 41 is composed of four write operations (WO#1 to WO#4)
  • the second transaction 42 is composed of two write operations (WO#5 to WO#6)
  • the third transaction 43 may be composed of two write operations WO#7 to WO#8.
  • FIG 3 illustrates one transaction processing method provided according to an embodiment.
  • step S11 the application 11 may transmit a start call to the file system 12 .
  • the first transaction can be started.
  • the file system 12 may start a process for the first transaction upon receiving the start call.
  • step S12 the application 11 may call a write operation call WO#1 for the first file to the file system 12 .
  • the application 11 may call a write operation call WO#2 for the second file to the file system 12 .
  • the application 11 may call a write operation call WO#3 for a third file to the file system 12 .
  • the application 11 may call a write operation call WO#4 for the fourth file to the file system 12 .
  • the file system 12 may store a page corresponding to each write operation call in a buffer corresponding to each page.
  • step S16 the application 11 may make a commit call to the file system 12 . It is considered that all operation calls sent by the application 11 to the file system 12 between the start call and the commit call are included in one first transaction.
  • step S17 upon receiving the commit call, the file system 12 may process the first transaction with reference to contents stored in buffers related to the first transaction.
  • step S18 four write commands WC#1 to WC#4 related to the four write operations are sent from the file system 12 to the storage 20 according to the processing of the first transaction. can be transmitted. Then, the file system 12 sends a flush command to the storage 20 , and when the storage 20 receives the flush command, the pages related to the four write commands are stored in the storage 20 . to be stored in the volatile memory 23 .
  • FIG 4 illustrates two transaction processing methods provided according to an embodiment.
  • step S21 the application 11 may transmit a start call to the file system 12 .
  • the second transaction can be started.
  • the file system 12 may start a process for the second transaction upon receiving the start call.
  • step S22 the application 11 may call a write operation call WO#1 for the first file to the file system 12 .
  • the application 11 may call a write operation call WO#2 for the second file to the file system 12 .
  • the file system 12 may store a page corresponding to each write operation call in a buffer corresponding to each page.
  • step S24 the application 11 may make a commit call to the file system 12 . It is considered that all operation calls sent by the application 11 to the file system 12 between the start call and the commit call are included in one second transaction.
  • step S25 upon receiving the commit call, the file system 12 may process the second transaction with reference to contents stored in buffers related to the second transaction.
  • step S26 two write commands (WC#1 to WC#2) and a flush command related to the two write operations are sent from the file system 12 to the storage ( 20) can be transmitted.
  • step S31 the application 11 may transmit a start call to the file system 12 .
  • the third transaction can be started.
  • the file system 12 may start a process for a third transaction upon receiving the start call.
  • step S32 the application 11 may call a write operation call WO#3 for a third file to the file system 12 .
  • the application 11 may call a write operation call WO#4 for the fourth file to the file system 12 .
  • the file system 12 may store a page corresponding to each write operation call in a buffer corresponding to each page.
  • step S34 the application 11 may make a commit call to the file system 12 . It is considered that all operation calls sent by the application 11 to the file system 12 between the start call and the commit call are included in one third transaction.
  • step S35 upon receiving the commit call, the file system 12 may process the third transaction with reference to contents stored in buffers related to the third transaction.
  • step S36 according to the processing of the third transaction, two write commands (WC#3 to WC#4) and a flush command related to the two write operations are sent from the file system 12 to the storage ( 20) can be transmitted.
  • another transaction may be started only after the commit of one transaction is finished. This is because, in the example shown in FIG. 4, all operation calls occurring between the start call and the commit call that occurs first after the start call are considered to be included in one single transaction.
  • FIG. 5 is a diagram illustrating a concept in which a host records information in storage according to an embodiment of the present invention.
  • FIG. 5 The concept shown in FIG. 5 is the same as the concept shown in FIG. 1 . However, the system call transmitted by the application 11 to the file system 12 is different from that shown in FIG. 1 . And at a specific point in time, the host 10 may execute one transaction or a plurality of different transactions together.
  • the application 11 includes a create call (Create( ) Call), an add call (Add( , ) Call), a start call (Start( ) Call), a set of operation calls, and a commit call ( Commit( ) Call) may be transmitted to the file system 12 .
  • the create call (Create( ) Call), the add call (Add( , ) Call), the start call (Start( ) Call), and the commit call (Commit( ) Call) according to an embodiment of the present invention It may be a function supported by the provided file system 12 .
  • a transaction filegroup (TFG) (simply a 'filegroup') can be created and used.
  • the host 10 may create a new filegroup in the Create( ) Call.
  • the Create( ) Call may include an ID indicating the new filegroup as an argument.
  • An ID indicating a specific file group is an argument to the create call (Create( ) Call), the add call (Add( , ) Call), the start call (Start( ) Call), and the commit call (Commit( ) Call) can be included as
  • FIG. 6 is a flowchart illustrating a method of executing a transaction provided according to an embodiment of the present invention.
  • step S111 the application 11 may transmit a create call to the file system 12 .
  • a new filegroup designated by the create call may be created.
  • the file system 12 may create the first file group TFG#1 upon receiving the create call (S711).
  • TFG#1 which is an identifier indicating the first filegroup
  • the file system 12 may return the TFG#1 to the application 11 . From this point on, the application 11 may use the identifier TFG#1 to execute the step related to the first filegroup.
  • step S112 the application 11 may transmit an additional call Add(TFG#1, File#1, File#2) to the file system 12 .
  • files designated by the add call may be added as members to a specific filegroup designated by the add call.
  • the additional call may include IDs representing filegroups and files as arguments.
  • TFG#1 represents a file group to which a file is to be added
  • File#1 and File#2 represent files to be added to TFG#1.
  • the file system 12 receives the add call (Add(TFG#1, File#1, File#2))
  • the first file (File#1) and the second file are added to the first filegroup (TFG#1).
  • 2 files (File #2) can be added (S712).
  • step S113 the application 11 may transmit a start call Start(TFG#1) to the file system 12 .
  • the first transaction can be started.
  • the file system 12 may start a process for the first transaction upon receiving the start call Start(TFG#1).
  • the transaction started by the start call is related only to the filegroup designated by the start call.
  • the start call may include an ID indicating a filegroup to start a new transaction as an argument.
  • TFG#1 is an ID indicating a filegroup to be associated with a transaction to be started.
  • step S114 the application 11 may call the file system 12 a write operation call WO#1 for the first file File#1.
  • the application 11 may call a write operation call WO#2 for the second file File#2 to the file system 12 .
  • steps S114 and S115 respectively, the file system 12 may store the pages transmitted by the operation calls WO#1 and WO#2 in corresponding buffers. These buffers may be considered to be buffers related to the first transaction.
  • the file system 12 may store a page corresponding to each write operation call in a buffer corresponding to each page.
  • step S116 the application 11 may call a commit call Commit(TFG#1) to the file system 12 .
  • a transaction committed by the commit call is related only to a filegroup designated by the commit call.
  • an ID indicating a filegroup associated with a transaction to be committed may be included as an argument in the commit call.
  • TFG#1 is an ID indicating a filegroup associated with a transaction to be committed.
  • step S117 when the file system 12 receives the commit call (Commit(TFG#1)), it refers to the contents stored in the buffers related to the first transaction related to the first filegroup. 1 transaction can be processed.
  • the file system 12 executes an operation call on the files (File#1, File#2) included in the filegroup TFG#1 between steps S113 and S117 (S713, S714). ), an operation call related to other files (File#3, File#4) not included in the filegroup may be executed (S715, S716).
  • step S118 according to the processing of the first transaction, two write commands WC#1 to WC#2 and a flush command related to the two write operations are sent from the file system 12 to the storage ( 20) can be transmitted.
  • the second transaction related to the second filegroup TFG#2 may be executed instead of the first transaction related to the first filegroup TFG#1.
  • the time at which the second transaction is executed does not depend on the time at which the first transaction is executed. That is, the first transaction associated only with the first filegroup TFG#1 and the second transaction associated with only the second filegroup TFG#2 may be executed independently of each other. That is, the second transaction may be being executed at a specific time point when the first transaction is being executed.
  • Steps S121 to S128 in FIG. 6 relate to a second transaction related only to the second file group TFG#2.
  • steps S121 and S122 are executed between steps S112 and S113
  • step S123 is executed between steps S113 and S114
  • steps S124 and S125 are Step S115 is executed between step S116 and step S126
  • step S126 is executed after step S118.
  • step S121 the application 11 may transmit a create call to the file system 12 .
  • the file system 12 may create the second file group TFG#2 upon receiving the create call.
  • TFG#2 which is an identifier indicating the second filegroup
  • the file system 12 may return the TFG#2 to the application 11 . From this point on, the application 11 may use the identifier TFG#2 to execute the step related to the second filegroup.
  • step S122 the application 11 may transmit an additional call Add(TFG#2, File#3, File#4) to the file system 12 .
  • TFG#2 represents a file group to which a file is to be added
  • File#3 and File#4 represent files to be added to TFG#2.
  • the file system 12 receives the add call Add(TFG#2, File#3, File#4)
  • the file system 12 stores the third file (File#3) and the second file in the second file group (TFG#2). 4 files (File#4) can be added.
  • step S123 the application 11 may transmit a start call Start(TFG#2) to the file system 12 .
  • the second transaction can be started.
  • the file system 12 may start a process for the second transaction upon receiving the start call Start(TFG#2).
  • TFG#2 is an ID indicating a filegroup to be associated with the second transaction.
  • step S124 the application 11 may call a write operation call WO#3 for the third file File#3 to the file system 12 .
  • step S125 the application 11 may call a write operation call WO#4 for the fourth file File#4 to the file system 12 .
  • steps S214 and S215 respectively, the file system 12 may store the pages transmitted by the operation calls WO#3 and WO#4 in corresponding buffers. These buffers may be considered to be buffers related to the second transaction.
  • the execution time of the start call, operation call, and commit call specifying the second filegroup is dependent on the execution time of the start call, operation call, and commit call specifying the first filegroup. doesn't happen
  • one start call and one commit call designating the same filegroup may be paired with each other.
  • a start call (Start(TFG#1)) and a commit call (Commit(TFG#1)) designating the first filegroup may be paired with each other.
  • a commit call (Commit(TFG#1)) designating the first filegroup may occur multiple times.
  • the commit call (Commit(TFG#1)) paired with the start call (Start(TFG#1)) is the start call (Start(TFG#) among the plurality of commit calls (Commit(TFG#1)). It may have occurred for the first time since 1)) occurred.
  • a start call (Start(TFG#1)) that specifies the first filegroup occurs at the first time point
  • a commit call (Commit) paired with the start call (Start(TFG#1)) (TFG#1)) may occur at the second time point.
  • the commit call (Commit(TFG#1)) occurs, only the operation calls related to the first filegroup are committed, and the operation calls related to the second filegroup are not committed. That is, the operation calls related to the first filegroup belong to a first transaction, and the operation calls related to the second filegroup belong to a second transaction.
  • This characteristic of the present invention is different from that, in the comparison technique shown in FIGS. 3 and 4, all operation calls occurring between the start call and the commit call are included in one single transaction.
  • step S117 of FIG. 6 the operations on the second file group TFG#2 are not processed.
  • step S126 the application 11 may call a commit call Commit(TFG#2) to the file system 12 .
  • the file system 12 may process the second transaction related to the second filegroup TFG#2.
  • the file system 12 determines that the operation call relates to the first filegroup. For example, since the file (File#1) specified in the operation call (WO#1) received by the file system 12 in step S114 became a member of the first filegroup in step S112, the operation call (WO#1) is determined to be related to the first filegroup.
  • step S127 when the file system 12 receives the commit call (Commit(TFG#2)), it refers to the contents stored in the buffers related to the second transaction related to the second filegroup. 2 transactions can be processed.
  • step S128 according to the processing of the second transaction, two write commands (WC#3 to WC#4) and a flush command related to the two write operations are sent from the file system 12 to the storage ( 20) can be transmitted.
  • FIG. 7 shows an embodiment modified from FIG. 6 .
  • the start call to the first filegroup occurred before the start call to the second filegroup, and the commit call to the first filegroup was also generated before the commit call to the second filegroup.
  • the storage 20 is The sets are all the same in the examples of FIGS. 6 and 7 . However, only the timing at which the storage 20 receives a set of commands is changed. In FIG. 6 , the commands transmitted to step S118 form one set, and the commands transmitted to step S128 form another set.
  • FIG. 8 is a flowchart illustrating a method of executing a transaction according to a comparative embodiment.
  • FIG. 8 is a comparative example in which the same result as that of FIG. 6 is obtained from the viewpoint of the storage 20 by using a conventional technique that does not use the filegroup concept.
  • Steps S213 to S218 shown in FIG. 8 correspond to steps S113 to S118 shown in FIG. 6 .
  • the system call indicated by steps S213 to S217 does not use the above-described filegroup information.
  • steps S223 to S228 shown in FIG. 8 correspond to steps S123 to S128 shown in FIG. 6 .
  • the system call indicated in steps S223 to S227 does not use the above-described file group information.
  • Steps corresponding to steps S111, S112, S121, and S122 shown in FIG. 6 are not provided in FIG.
  • the start call S223 for starting the second transaction must occur after the commit call of the first transaction occurs. That is, the application 11 needs to control the generation time of the start call of the second transaction and the generation of the commit call of the first transaction.
  • the file system 12 is the file group. Information is processed automatically.
  • FIG. 9 is a flowchart illustrating a transaction execution method provided according to an embodiment of the present invention.
  • Each step of FIG. 9 may be executed in the host.
  • an application of the host may transmit a system call for creating a first filegroup to the file system of the host, and the file system may create the first filegroup.
  • step S52 the application transmits to the file system a system call for adding predetermined files to the first filegroup as a member, and adds the predetermined files to the first filegroup as members of the first filegroup. Can be added as a member.
  • step S53 after the application transmits a system call for starting a first transaction related to the first filegroup to the file system, one or more operation system calls for the first filegroup may be transmitted. .
  • step S54 the application transmits to the file system a system call for execution of a commit of a first transaction related to the first filegroup, and the file system processes the first transaction to create a set of Commands can be sent to storage.
  • the file system Among the operation calls received from the application, only operation calls related to the first filegroup may be included.
  • FIG. 10 is a flowchart illustrating a transaction execution method provided according to an embodiment of the present invention. Each step of FIG. 10 may be executed in the host.
  • the file system may create a filegroup having one group of files as members.
  • step S552 when the file system receives a commit call specifying the filegroup from the application, it can commit a transaction including only operation calls related to the filegroup.
  • the present invention was created with the support of the following research project.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

파일그룹을 생성하는 단계, 및 상기 파일그룹을 지정한 커밋 콜이 발생하면 상기 파일그룹에 포함된 파일들에 관한 오퍼레이션 콜들만으로 구성된 트랜잭션을 커밋하는 단계를 포함하는 트랜잭션 처리방법을 공개한다.

Description

다중파일 트랜잭션의 파일 관리 기법 및 장치
본 발명은 컴퓨팅 기술에 관한 것으로서, 특히 파일시스템이 트랜잭션 기능을 지원할 때, 트랜잭션이 수정하는 다수의 파일을 관리하는 기법에 관한 것이다.
원자적으로 실행되는 다수의 쓰기 연산의 트랜잭션이라 정의한다. 종래 기술 중 트랜잭션 기능을 지원하는 파일 시스템을 트랜잭션 지원 파일 시스템 (Transactional file system)이라 정의한다. 트랜잭션 지원 파일 시스템은 시스템 콜 형태로 사용자 어플리케이션(사용자)에게 트랜잭션 기능을 제공한다. 종래 기술은 파일 중심 트랜잭션 관리 기술과 프로세스 중심 트랜잭션 관리 기술로 분류될 수 있다. 파일 중심 트랜잭션 관리 기술은 트랜잭션 정보를 파일에 관련된 일련의 정보를 나타내는 자료구조에 저장한다. 해당 자료구조를 아이노드라고 칭한다. 프로세스 중심 트랜잭션 관리 기술은 트랜잭션 정보를 프로세스에 관련된 일련의 정보를 나타내는 자료구조에 저장한다. 해당 자료구조를 프로세스 컨트롤 블록이라고 칭한다. 리눅스에서는 프로세스 컨트롤 블록을 task_struct라고 칭한다.
대표적인 파일 중심 트랜잭션 관리 기술은 F2FS의 단일 파일 트랜잭션이다. F2FS의 아이노드(Inode)는 해당 파일의 트랜잭션 진행 여부를 나타내는 플래그와 트랜잭션이 수정한 내용들의 리스트를 갖는다. 트랜잭션이 수정한 내용들은 디스크 블록의 캐싱 단위인 페이지 단위로 관리한다. 트랜잭션이 수정한 내용들의 리스트는 트랜잭션이 수정한 페이지들의 리스트다. 사용자는 트랜잭션을 시작(start)하거나 커밋(commit)할 때 파일을 인자로 전달한다. 정확히는 사용자가 파일을 열었을 때 파일마다 할당받는 파일 디스크립터를 인자로 전달한다. 사용자가 해당 파일에 트랜잭션 시작을 요청하면 아이노드에 트랜잭션 진행을 나타내는 플래그 값을 1로 바꾼다. 트랜잭션 수행 중에 파일이 변경되면 변경된 내용의 페이지를 아이노드가 갖고 있는 페이지 리스트에 삽입한다. 사용자가 트랜잭션 커밋을 요청하면 페이지 리스트에 있는 페이지들을 저장장치에 원자적으로 쓴다(write atomically).
대표적인 프로세스 중심 트랜잭션 관리 기술은 TxFS다. TxFS의 프로세스 컨트롤 블록(struct task_struct)은 트랜잭션 진행 여부를 나타내는 플래그와 트랜잭션이 수정한 페이지의 리스트를 갖는다. 프로세스 중심 트랜잭션에서 트랜잭션 시작과 커밋은 인자를 필요로 하지 않는다. 사용자가 트랜잭션을 시작하면 트랜잭션 시작을 호출한 프로세스의 프로세스 컨트롤 블록에 트랜잭션 진행을 나타내는 플래그 값을 1로 바꾼다. 트랜잭션을 시작한 프로세스가 수정하는 모든 페이지들은 해당 프로세스의 프로세스 컨트롤 블록에 있는 페이지 리스트에 삽입된다. 사용자가 트랜잭션 커밋을 요청하면 프로세스 컨트롤 블록의 페이지 리스트에 있는 페이지들을 저장장치에 원자적으로 쓴다.
파일 중심 트랜잭션 관리 기술은 다중 파일 트랜잭션을 지원하지 못한다. 파일 중심 트랜잭션 관리 기술이 트랜잭션 정보를 저장하는 자료구조인 아이노드는 파일 하나를 표현하는 자료구조다. 아이노드에 저장된 트랜잭션 정보는 트랜잭션 범위를 파일 하나로 한정된다. 트랜잭션의 시작과 커밋의 단위도 파일 디스크립터다. 사용자가 시작하거나 커밋할 수 있는 트랜잭션이 단일 파일 트랜잭션으로 제한된다는 문제가 있다.
프로세스 중심 트랜잭션 관리 기술에서는 사용자가 트랜잭션에 포함할 파일을 지정할 수 없다. 프로세스 중심 트랜잭션 관리 기술이 트랜잭션 정보를 저장하는 자료구조인 프로세스 컨트롤 블록에는 파일 관련 정보가 저장되지 않는다. 어떤 파일을 트랜잭션에 참여시킬지를 나타내는 정보를 저장할 수 없다. 트랜잭션의 시작과 커밋도 인자를 전달받지 않는다. 트랜잭션에 참여시킬 파일을 지정할 방법이 없다. 때문에 프로세스 중심 트랜잭션은 트랜잭션을 시작한 프로세스가 변경하는 모든 파일 내용을 트랜잭션에 참여시킨다. 이는 불필요한 내용들을 트랜잭션에 포함시키게 할 수 있다는 문제가 있다.
일반적으로 다중 파일 트랜잭션 기능을 필요로 하는 소프트웨어는 서버향 혹은 임베디드향 데이터베이스 시스템, 소프트웨어 설치 관리자, 웹 브라우저가 포함된다. 이들은 독자적인 로깅 메커니즘을 사용하거나 단일 파일 트랜잭션의 연속 호출과 전역 로그 파일 기록을 이용해서 다중 파일 트랜잭션을 구현한다. 하지만, 이러한 종래기술들은 쓰기량 증폭과 무분별한 플러쉬 호출 때문에 심각한 성능 저하를 겪는다.
본 발명에서는, 사용자가 시작하거나 커밋할 수 있는 트랜잭션을 단일 파일 트랜잭션으로 제한하지 않으며, 그리고 불필요한 내용들을 트랜잭션에 포함시키지 않도록 하는 트랜잭션의 파일 관리 방법을 제공하고자 한다.
본 발명에서는, 운영체제 수준에서 다중 파일 트랜잭션 기능을 지원하여 효율적인 트랜잭션 성능을 제공하는 동시에 사용자가 트랜잭션에 참여시킬 파일을 지정할 수 있도록 하는 기술을 제공하고자 한다.
본 발명의 일 관점에 따라, 운영체제가 트랜잭션 기능을 지원할 때 다중 파일 트랜잭션의 파일들을 관리하는 방법 및 이를 위한 장치가 제공될 수 있다.
본 발명의 일 관점에 따라 제공되는 파일 관리 방법에서는, 다중 파일 트랜잭션을 위한 새로운 자료구조인 트랜잭션 파일그룹이 정의되며, 트랜잭션이 트랜잭션 파일그룹 단위로 실행된다.
본 발명의 일 관점에 따라 제공되는 파일 관리 방법에서는, 다중 파일 트랜잭션을 위한 파일 관리 기법과 그 장치가 정의된다. 종래 기술의 다중 파일 트랜잭션은 사용자가 트랜잭션에 참여시킬 파일을 지정할 수 없다는 한계를 갖는다. 그러나 본 발명에서는 사용자가 트랜잭션에 참여시킬 파일을 지정할 수 있는 다중 파일 트랜잭션이 정의된다. 본 발명에서는 트랜잭션 파일그룹이라는 개념이 제공된다.
도 11은 본 발명에 따른 트랜잭션 파일그룹의 구조를 보여준다.
트랜잭션 파일그룹(110)(TFG)은 아이노드 리스트(Inode list)(111), 데이터 페이지 리스트(dirty data page list)(112), 메타데이터 페이지 리스트(dirty node page list)(113)로 이루어져 있다. 아이노드 리스트(111)는 트랜잭션에 참여한 파일들의 아이노드들로 이루어진 리스트다. 데이터 페이지 리스트(112)와 메타데이터 페이지 리스트(113)는 각각 트랜잭션이 수정한 데이터 페이지들과 메타데이터 페이지들의 리스트다.
사용자는 시스템 콜을 통해 트랜잭션 파일그룹(110)을 생성하고 삭제할 수 있다. 트랜잭션 파일그룹(110)을 생성한 사용자는 트랜잭션 파일그룹(110)의 ID를 반환받는다. 사용자는 해당 ID로 자신이 생성한 트랜잭션 파일그룹(110)에 접근할 수 있다. 사용자는 시스템 콜을 통해 트랜잭션에 참여시킬 파일들을 트랜잭션 파일그룹(110)에 추가할 수 있다.
예컨대 트랜잭션 파일그룹(110)을 생성하는 콜, 및 트랜잭션에 참여시킬 파일들을 트랜잭션 파일그룹(110)에 추가하는 콜은, 각각 CALL: Create ( ), 및 CALL: Add ( )로 표현될 수 있다.
본 발명에서 트랜잭션 파일그룹(110)은 트랜잭션의 시작과 커밋의 기본 단위로 사용된다. 다중 파일 트랜잭션을 시작할 때는 트랜잭션 파일그룹(110)의 ID를 인자로 사용한다. 예컨대 도 5의 단계(S111)에서, TFG#1은 제1트랜잭션의 트랜잭션 파일그룹의 ID이다.
예컨대 CALL: Create ( ), CALL: Delete ( ), 및 CALL: Add ( )의 ( ) 안에 선택된 트랙잰션 파일그룹의 ID를 포함시키면, 상기 콜들은 상기 선택된 트랙잰션 파일그룹에 관한 콜로서 간주될 수 있다.
다중 트랜잭션을 시작하면 트랜잭션 파일그룹(110)의 아이노드 리스트(111)에 있는 아이노드들에 트랜잭션이 진행 중임을 나타내는 플래그 값을 1로 변경한다. 다수의 아이노드들을 원자적으로(atomically) 변경해야 한다. 이를 위해 두 단계 락킹(locking)을 사용한다. 가장 먼저 아이노드들의 락들을 일괄적으로 획득하고 아이노드들을 수정한다. 수정이 완료되면 아이노드들의 락들을 일괄적으로 해제한다. 트랜잭션 진행 중에 트랜잭션 파일그룹(110)에 추가된 파일을 수정하면 수정한 페이지를 트랜잭션 파일그룹(110)이 갖고 있는 페이지 리스트에 삽입한다.
다중 트랜잭션 파일그룹을 커밋할 때 트랜잭션 파일그룹의 ID를 인자로 전달한다.
예컨대, 다중 트랜잭션 파일그룹의 커밋은 커밋 콜 CALL: Commit ( )에 의해 이루어질 수 있다. 그리고 이때 상기 ( ) 안에는 커밋의 대상이 되는 트랙잰션 파일그룹의 ID를 포함시킨다.
다중 트랜잭션 파일그룹의 커밋은 트랜잭션 파일그룹이 갖고 있는 페이지 리스트 내 페이지들을 저장 장치에 원자적으로 쓴다.
도 12는 본 발명의 일 관점에 따라 정의된 다중 파일 트랜잭션의 동작을 순서도로 표현한 것이다.
단계(S611)에서, 사용자는 가장 먼저 트랜잭션 파일그룹을 생성한다(create_tx_file_group( )).
단계(S612)에서, 사용자는 트랜잭션에 참여시킬 파일들을 트랜잭션 파일그룹에는 추가할 수 있다(add_tx_file_group( )).
단계(S613)에서, 트랜잭션을 시작하면 트랜잭션 파일그룹에 포함된 파일들을 대상으로 트랜잭션이 시작된다.
단계(S614)에서, 사용자가 해당 파일들을 변경하면 변경 사항들이 트랜잭션에 추가된다.
단계(S618)에서, 중간에 파일 연산이 실패하는 등의 이유로 트랜잭션이 비정상적으로 진행될 경우 트랜잭션을 abort 한다(abort_tx_file_group( )).
단계(S616)에서, 반면에 트랜잭션이 정상적으로 진행되면 트랜잭션을 커밋한다(commit_tx_file_group( )).
단계(S617)에서, 트랜잭션 진행이 완료되면 트랜잭션 파일그룹을 삭제한다(delete_tx_file_group( )).
본 명세서에서, 상기 create_tx_file_group( )은 CALL: Create ( )로 표기될 수도 있다. 그리고 상기 add_tx_file_group( )은 CALL: Add ( )로 표기될 수도 있다. 그리고 상기 abort_tx_file_group( )은 CALL: Abort ( )로 표기될 수도 있다. 그리고 상기 commit_tx_file_group( )은 CALL: Commit ( )로 표기될 수도 있다. 그리고 상기 commit_tx_file_group( )은 CALL: Commit ( )로 표기될 수도 있다.
본 발명의 일 관점에 따라 호스트의 파일 시스템이, 파일그룹을 생성하는 그룹생성단계(S711); 및 상기 파일 시스템이, 상기 파일그룹을 지정한 커밋 콜을 수신하면, 상기 파일그룹에 포함된 파일들에 관한 오퍼레이션 콜들만으로 구성된 트랜잭션을 커밋하는 커밋단계(S117)를 포함하는, 트랜잭션 처리방법이 제공될 수 있다.
이때, 상기 그룹생성단계와 상기 커밋단계 사이에, 상기 파일 시스템이, 상기 파일그룹에 일 그룹의 파일을 상기 파일그룹의 멤버로서 추가하는 파일추가단계(S712); 및 상기 파일 시스템이, 상기 파일그룹에 포함된 파일들에 관한 오퍼레이션 콜을 실행하고(S713, S714), 상기 파일그룹에 포함되지 않은 다른 파일에 관한 오퍼레이션 콜을 실행(S715, S716)하는 단계를 더 포함할 수 있다.
이때, 상기 커밋단계 이후에, 상기 파일 시스템이, 상기 파일그룹을 삭제하는 단계(S717)를 더 포함할 수 있다.
이때, 상기 그룹생성단계 이전에, 상기 호스트의 어플리케이션이, 상기 파일그룹을 생성하라는 파일그룹 생성 콜을 상기 파일 시스템에게 전송하는 단계(S111); 상기 그룹생성단계와 상기 파일추가단계 사이에, 상기 어플리케이션이, 상기 일 그룹의 파일을 상기 파일그룹의 멤버로서 추가하라는 요청을 나타내는 파일추가 콜을 상기 파일 시스템에게 전송하는 단계(S112); 및 상기 파일추가단계와 상기 오퍼레이션 콜을 실행하는 단계 사이에, 상기 어플리케이션이, 상기 파일그룹을 지정한 시작 콜을 상기 파일 시스템에게 전송하는 단계(S113);를 더 포함할 수 있다. 상기 그룹생성단계는, 상기 파일 시스템이 상기 파일그룹 생성 콜을 수신하면 실행되고, 상기 파일추가단계는, 상기 파일 시스템이 상기 파일추가 콜을 수신하면 실행될 수 있다.
이때, 상기 파일추가 콜은 상기 파일그룹을 식별하는 식별자와 상기 일 그룹의 파일을 식별하는 식별자에 관한 정보를 포함하며, 상기 시작 콜은 상기 파일그룹을 식별하는 식별자에 관한 정보를 포함하며, 그리고 상기 커밋 콜은 상기 파일그룹을 식별하는 식별자에 관한 정보를 포함할 수 있다.
본 발명의 일 관점에 따라 호스트가 제공될 수 있다. 상기 호스트는 처리부; 및 통신부;를 포함하며, 상기 처리부는 상기 호스트의 파일 시스템을 실행하도록 되어 있고, 상기 파일 시스템은, 파일그룹을 생성하는 그룹생성단계(S711); 및 상기 파일그룹을 지정한 커밋 콜을 수신하면, 상기 파일그룹에 포함된 파일들에 관한 오퍼레이션 콜들만으로 구성된 트랜잭션을 커밋하는 커밋단계(S117)를 실행하도록 되어 있는 것을 특징으로 할 수 있다.
이때, 상기 파일 시스템은, 상기 그룹생성단계와 상기 커밋단계 사이에,
상기 파일그룹에 일 그룹의 파일을 상기 파일그룹의 멤버로서 추가하는 파일추가단계(S712); 및 상기 파일그룹에 포함된 파일들에 관한 오퍼레이션 콜을 실행하고(S713, S714), 상기 파일그룹에 포함되지 않은 다른 파일에 관한 오퍼레이션 콜을 실행(S715, S716)하는 단계를 더 실행하도록 되어 있을 수 있다.
이때, 상기 처리부는 상기 호스트의 어플리케이션을 실행하도록 되어 있고, 상기 어플리케이션은, 상기 그룹생성단계 이전에, 상기 파일그룹을 생성하라는 파일그룹 생성 콜을 상기 파일 시스템에게 전송하는 단계(S111); 상기 그룹생성단계와 상기 파일추가단계 사이에, 상기 일 그룹의 파일을 상기 파일그룹의 멤버로서 추가하라는 요청을 나타내는 파일추가 콜을 상기 파일 시스템에게 전송하는 단계(S112); 및 상기 파일추가단계와 상기 오퍼레이션 콜을 실행하는 단계 사이에, 상기 파일그룹을 지정한 시작 콜을 상기 파일 시스템에게 전송하는 단계(S113)를 실행하도록 되어 있을 수 있다. 상기 그룹생성단계는, 상기 파일 시스템이 상기 파일그룹 생성 콜을 수신하면 실행되고, 상기 파일추가단계는, 상기 파일 시스템이 상기 파일추가 콜을 수신하면 실행될 수 있다.
본 발명의 일 관점에 따라 호스트 및 스토리지를 포함하는 컴퓨팅 장치가 제공될 수 있다. 상기 호스트는 파일 시스템을 실행하도록 되어 있을 수 있다. 상기 파일 시스템은, 파일그룹을 생성하는 그룹생성단계(S711); 및 상기 파일그룹을 지정한 커밋 콜을 수신하면, 상기 파일그룹에 포함된 파일들에 관한 오퍼레이션 콜들만으로 구성된 트랜잭션을 커밋하는 커밋단계(S117)를 실행하도록 되어 있을 수 있다. 상기 스토리지는, 상기 파일 시스템이 상기 커밋단계를 실행하면, 상기 파일그룹에 포함된 파일들에 관한 오퍼레이션 콜들만으로 구성된 트랜잭션을 상기 스토리지에 저장하도록 되어 있을 수 있다.
이때, 상기 파일 시스템은, 상기 그룹생성단계와 상기 커밋단계 사이에,
상기 파일그룹에 일 그룹의 파일을 상기 파일그룹의 멤버로서 추가하는 파일추가단계(S712); 및 상기 파일그룹에 포함된 파일들에 관한 오퍼레이션 콜을 실행하고(S713, S714), 상기 파일그룹에 포함되지 않은 다른 파일에 관한 오퍼레이션 콜을 실행(S715, S716)하는 단계를 더 실행하도록 되어 있을 수 있다.
본 발명의 일 관점에 따라 제공되는 파일 관리 방법은, SQLite, MySQL과 같은 데이터베이스 관리 시스템, MongoDB, RocksDB과 같은 키밸류 스토어, EXT4, XFS과 같은 파일 시스템을 포함한 트랜잭션 지원을 필요로 하는 모든 분야에 적용될 수 있다.
또한, 본 발명의 일 관점에 따라 제공되는 파일 관리 방법은, 데이터베이스 관리 시스템을 운용하는 모든 서버용 소프트웨어 혹은 이를 이용하는 모든 서비스와 데이터의 일관성을 위해 트랜잭션을 사용하는 스마트폰, 스마트카 등의 임베디드 기기에 적용될 수 있다.
본 발명에 따라 제공되는 방법은 다중 파일 트랜잭션 기능을 필요로 하는 모든 소프트웨어에 적용 가능하다.
본 발명은 데이터센터 관리용 소프트웨어와 데이터베이스, 그리고 데이터 일관성을 필요로 하는 임베디드 어플리케이션에 적용될 수 있다. 본 발명은 스마트폰 시장과 데이터 센터 시장뿐만 아니라 다중 파일 트랜잭션을 필요로 하는 모든 분야에 적용될 수 있다.
본 발명은 소프트웨어를 개발하는 모든 기업의 사업에 적용될 수 있다. 웹 브라우저의 경우, 다중 파일에 웹 사이트 방문 기록 및 파일 다운로드 기록을 저장한다. 이는 데스크톱용 웹 브라우저와 모바일용 웹 브라우저 전부 해당된다. 많은 기업들은, 데이터센터 관리용으로 사용하고, Ceph 등 분산 스토리지에서 사용하는 데이터베이스 시스템인 RocksDB는 컴팩션 연산에서 다중 파일 연산을 필요로 한다. 이들은 모두 다중 파일 트랜잭션으로 최적화될 수 있는 소프트웨어들이다. 본 발명은 이들의 서비스 품질을 향상시킬 수 있는 기술이다.
본 발명에 따르면, 사용자가 시작하거나 커밋할 수 있는 트랜잭션을 단일 파일 트랜잭션으로 제한하지 않으며, 그리고 불필요한 내용들을 트랜잭션에 포함시키지 않도록 하는 트랜잭션의 파일 관리 방법을 제공할 수 있다.
본 발명에 따르면, 운영체제 수준에서 다중 파일 트랜잭션 기능을 지원하여 효율적인 트랜잭션 성능을 제공하는 동시에 사용자가 트랜잭션에 참여시킬 파일을 지정할 수 있도록 하는 기술이 제공될 수 있다.
도 1은 일 실시예에 따라 호스트가 스토리지에 정보를 기록하는 개념을 나타낸 것이다.
도 2는 호스트가 실행하는 서로 다른 트랜잭션들을 나타낸 것이다.
도 3은 일 실시예에 따라 제공되는 한 개의 트랜잭션 처리 방법을 나타낸 것이다.
도 4는 일 실시예에 따라 제공되는 두 개의 트랜잭션 처리 방법을 나타낸 것이다.
도 5는 본 발명의 일 실시예에 따라, 호스트가 스토리지에 정보를 기록하는 개념을 나타낸 것이다.
도 6은 본 발명의 일 실시예에 따라 제공되는 트랜잭션을 실행하는 방법을 나타낸 순서도이다.
도 7은 도 6으로부터 변형된 실시예를 나타낸다.
도 8은 비교 실시예에 따라 트랜잭션을 실행하는 방법을 나타낸 순서도이다.
도 9는 본 발명의 일 실시예에 따라 제공되는 트랜잭션 실행 방법을 나타낸 순서도이다.
도 10은 본 발명의 일 실시예에 따라 제공되는 트랜잭션 실행 방법을 나타낸 순서도이다.
도 11은 본 발명에 따른 트랜잭션 파일그룹의 구조를 보여준다.
도 12는 본 발명의 일 관점에 따라 정의된 다중 파일 트랜잭션의 동작을 순서도로 표현한 것이다.
이하, 본 발명의 실시예를 첨부한 도면을 참고하여 설명한다. 그러나 본 발명은 본 명세서에서 설명하는 실시예에 한정되지 않으며 여러 가지 다른 형태로 구현될 수 있다. 본 명세서에서 사용되는 용어는 실시예의 이해를 돕기 위한 것이며, 본 발명의 범위를 한정하고자 의도된 것이 아니다. 또한, 이하에서 사용되는 단수 형태들은 문구들이 이와 명백히 반대의 의미를 나타내지 않는 한 복수 형태들도 포함한다.
도 1은 일 실시예에 따라 호스트가 스토리지에 정보를 기록하는 개념을 나타낸 것이다.
호스트(10)와 저장소(20)는 각각 전원장치로부터 전력을 공급하여 동작하는 컴퓨팅 장치일 수 있다. 상기 호스트(10)와 상기 저장소(20)는 한 개 이상의 전송채널들(30)을 통해 데이터 및 명령을 교환할 수 있다. 상기 전송채널들(30)은 무선채널 또는 유선채널일 수 있다. 상기 호스트(10)와 상기 저장소(20)는 한 개의 전원장치로부터 제공되는 전원을 공유할 수도 있고, 또는 서로 다른 두 개의 전원장치들로부터 각각 전력을 공급받을 수도 있다.
상기 호스트(10)는 CPU, 메모리, 전원장치, 및 통신장치를 포함할 수 있다.
상기 저장소(20)는 콘트롤러(21), 휘발성 메모리(22), 및 비휘발성 메모리(23)를 포함할 수 있다.
상기 호스트(10)는 상기 전송채널들(30)을 통해 각종 명령 및 데이터를 상기 저장소(20)에게 전송할 수 있다. 상기 명령에는 쓰기 명령이 포함될 수 있다.
상기 저장소(20)의 상기 콘트롤러(21)는 상기 전송채널들(30)로부터 수신한 명령을 기초로 상기 전송채널들(30)로부터 수신한 데이터를 상기 휘발성 메모리(22)에 저장할 수 있다. 상기 휘발성 메모리(22)에 저장된 데이터는 상기 콘트롤러(21)가 따르는 규칙에 의해 상기 비휘발성 메모리(23)에 저장될 수 있다. 상기 휘발성 메모리(22) 저장된 데이터는 상기 저장소(20)에 공급되는 전원이 차단되면 삭제될 수 있지만, 상기 비휘발성 메모리(23)에 저장된 데이터는 상기 저장소(20)에 공급되는 전원이 차단되더라도 삭제되지 않는다.
상기 호스트(10)는 어플리케이션(11)과 파일 시스템(12)을 실행할 수 있다. 상기 어플리케이션(11)과 상기 파일 시스템(12)은 상기 호스트(10)가 액세스하는 메모리에 저장된 소정의 명령코드들이 상기 호스트(10)에 포함된 CPU에 의해 실행됨으로써 실행되는 것일 수 있다.
일 실시예에서, 상기 어플리케이션(11)은 상기 호스트(10)는 사용하는 사용자가 상기 호스트(10)이 제공하는 사용자 인터페이스를 통해 사용자 입력을 제공함으로써 실행되거나 종료되는 프로그램일 수 있다.
일 실시예에서, 상기 파일 시스템(12)는 상기 호스트(10)에 전원이 인가되거나 리셋이 이루어지면 상기 호스트(10)에 의해 자동으로 실행되는 프로그램일 수 있다.
상기 어플리케이션(11)은 상기 파일 시스템(12)에게 다양한 시스템 콜을 보낼 수 있다. 상기 파일 시스템(12)은 상기 시스템 콜에 대응하는 작업을 실행할 수 있다.
상기 호스트(10)는 트랜잭션을 실행할 수 있다. 특정 트랜잭션이 시작되어 종료될 때까지 소정의 시간이 소요될 수 있다. 특정 시점에, 상기 호스트(10)는 한 개의 트랜잭션을 수행할 수 있다.
트랜잭션의 시작 및 커밋을 상기 어플리케이션(11)가 제어할 수 있다. 그리고 상기 트랜잭션 도중 실행되어야 하는 한 개 이상의 오퍼레이션들을 상기 어플리케이션(11)가 제어할 수 있다. 도 1에 제시하였듯이, 상기 어플리케이션(11)는 스타트 콜, 한 세트의 오퍼레이션 콜, 및 커밋 콜을 포함하는 시스템 콜들을 상기 파일 시스템(12)에 전송할 수 있다.
상기 스타트 콜에 의해 특정 트랜잭션이 시작되고, 상기 한 세트의 오퍼레이션 콜들에 의해 상기 호스트(10)으로부터 상기 저장소(20)에게 전달되어야 하는 명령들이 준비되고, 그리고 상기 커밋 콜에 의해 상기 준비된 명령들이 상기 전송채널들(30)을 통해 상기 저장소(20)에게 전달될 수 있다.
도 2는 호스트가 실행하는 서로 다른 트랜잭션들을 나타낸 것이다.
복수 개의 오퍼레이션들의 집합이 하나의 트랜잭션을 구성할 수 있다.
제1트랜잭션(41)은 4개의 쓰기 오퍼레이션들(WO#1~WO#4)로 구성되고, 제2트랜잭션(42)은 2개의 쓰기 오퍼레이션들(WO#5~WO#6)로 구성되고, 그리고 제3트랜잭션(43)은 2개의 쓰기 오퍼레이션들(WO#7~WO#8)로 구성될 수 있다.
도 2에서는 각 트랙잰션에 쓰기 오퍼레이션들만일 포함된 예를 제시하였지만, 다른 종류의 오퍼레이션들도 포함될 수 있다.
도 3은 일 실시예에 따라 제공되는 한 개의 트랜잭션 처리 방법을 나타낸 것이다.
단계(S11)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 스타트 콜을 송신(transmit)할 수 있다. 이로써 제1트랜잭션일 시작될 수 있다. 상기 파일 시스템(12)은 상기 스타트 콜을 수신하면 제1트랜잭션을 위한 프로세스를 시작할 수 있다.
단계(S12)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 제1파일에 대한 쓰기 오퍼레이션 콜(WO#1)을 호출할 수 있다. 단계(S13)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 제2파일에 대한 쓰기 오퍼레이션 콜(WO#2)을 호출할 수 있다. 단계(S14)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 제3파일에 대한 쓰기 오퍼레이션 콜(WO#3)을 호출할 수 있다. 단계(S15)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 제4파일에 대한 쓰기 오퍼레이션 콜(WO#4)을 호출할 수 있다.
상기 파일 시스템(12)은 상기 쓰기 오퍼레이션 콜들을 수신하면, 각 쓰기 오퍼레이션 콜에 대응하는 페이지를, 각 페이지에 대응하는 버퍼에 저장할 수 있다.
단계(S16)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 커밋 콜을 호출할 수 있다. 상기 스타트 콜과 상기 커밋 콜 사이에 상기 어플리케이션(11)이 상기 파일 시스템(12)에게 보낸 모든 오퍼레이션 콜들을 한 개의 상기 제1트랜잭션에 포함된 것으로 간주된다.
단계(S17)에서, 상기 파일 시스템(12)는 상기 커밋 콜을 수신하면, 상기 제1트랜잭션에 관련된 버퍼들에 저장된 내용을 참조하여 제1트랜잭션을 처리할 수 있다.
단계(S18)에서, 상기 제1트랜잭션의 처리에 따라 상기 4개의 쓰기 오퍼레이션들에 관한 4개의 쓰기 명령들(WC#1~WC#4)이 상기 파일 시스템(12)으로부터 상기 저장소(20)에게 전송될 수 있다. 그 다음, 상기 파일 시스템(12)은 상기 저장소(20)에게 플러시 명령을 전송하고, 상기 저장소(20)는 상기 플러시 명령을 수신하면 상기 4개의 쓰기 명령에 관련된 페이지들이 상기 저장소(20)의 비휘발성 메모리(23)에 저장될 수 있도록 한다.
도 4는 일 실시예에 따라 제공되는 두 개의 트랜잭션 처리 방법을 나타낸 것이다.
단계(S21)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 스타트 콜을 송신할 수 있다. 이로써 제2트랜잭션일 시작될 수 있다. 상기 파일 시스템(12)은 상기 스타트 콜을 수신하면 제2트랜잭션을 위한 프로세스를 시작할 수 있다.
단계(S22)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 제1파일에 대한 쓰기 오퍼레이션 콜(WO#1)을 호출할 수 있다. 단계(S23)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 제2파일에 대한 쓰기 오퍼레이션 콜(WO#2)을 호출할 수 있다.
상기 파일 시스템(12)은 상기 쓰기 오퍼레이션 콜들을 수신하면, 각 쓰기 오퍼레이션 콜에 대응하는 페이지를, 각 페이지에 대응하는 버퍼에 저장할 수 있다.
단계(S24)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 커밋 콜을 호출할 수 있다. 상기 스타트 콜과 상기 커밋 콜 사이에 상기 어플리케이션(11)이 상기 파일 시스템(12)에게 보낸 모든 오퍼레이션 콜들을 한 개의 상기 제2트랜잭션에 포함된 것으로 간주된다.
단계(S25)에서, 상기 파일 시스템(12)는 상기 커밋 콜을 수신하면, 상기 제2트랜잭션에 관련된 버퍼들에 저장된 내용을 참조하여 제2트랜잭션을 처리할 수 있다.
단계(S26)에서, 상기 제2트랜잭션의 처리에 따라 상기 2개의 쓰기 오퍼레이션들에 관한 2개의 쓰기 명령들(WC#1~WC#2) 및 플러시 명령이 상기 파일 시스템(12)으로부터 상기 저장소(20)에게 전송될 수 있다.
단계(S31)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 스타트 콜을 송신할 수 있다. 이로써 제3트랜잭션일 시작될 수 있다. 상기 파일 시스템(12)은 상기 스타트 콜을 수신하면 제3트랜잭션을 위한 프로세스를 시작할 수 있다.
단계(S32)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 제3파일에 대한 쓰기 오퍼레이션 콜(WO#3)을 호출할 수 있다. 단계(S33)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 제4파일에 대한 쓰기 오퍼레이션 콜(WO#4)을 호출할 수 있다.
상기 파일 시스템(12)은 상기 쓰기 오퍼레이션 콜들을 수신하면, 각 쓰기 오퍼레이션 콜에 대응하는 페이지를, 각 페이지에 대응하는 버퍼에 저장할 수 있다.
단계(S34)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 커밋 콜을 호출할 수 있다. 상기 스타트 콜과 상기 커밋 콜 사이에 상기 어플리케이션(11)이 상기 파일 시스템(12)에게 보낸 모든 오퍼레이션 콜들을 한 개의 상기 제3트랜잭션에 포함된 것으로 간주된다.
단계(S35)에서, 상기 파일 시스템(12)는 상기 커밋 콜을 수신하면, 상기 제3트랜잭션에 관련된 버퍼들에 저장된 내용을 참조하여 제3트랜잭션을 처리할 수 있다.
단계(S36)에서, 상기 제3트랜잭션의 처리에 따라 상기 2개의 쓰기 오퍼레이션들에 관한 2개의 쓰기 명령들(WC#3~WC#4) 및 플러시 명령이 상기 파일 시스템(12)으로부터 상기 저장소(20)에게 전송될 수 있다.
도 4에 제시된 예에서, 한 개의 트랜잭션에 대한 커밋이 종료된 이후에야 다른 한 개의 트랜잭션이 시작될 수 있다. 이는 도 4에 제시된 예에서 스타트 콜과, 상기 스타토 콜 이후에 처음으로 발생하는 커밋 콜 사이에 발생한 모든 오퍼레이션 콜들은 한 개의 단일 트랜잭션에 포함된 것으로 간주되기 때문이다.
도 5는 본 발명의 일 실시예에 따라, 호스트가 스토리지에 정보를 기록하는 개념을 나타낸 것이다.
도 5에 나타낸 개념은 도 1에 나타낸 개념과 동일하다. 다만, 상기 어플리케이션(11)이 상기 파일 시스템(12)에게 전송하는 시스템 콜은 도 1에 제시된 것과 다르다. 그리고 특정 시점에, 상기 호스트(10)는 한 개의 트랜잭션을 수행할 수도 있고, 복수 개의 서로 다른 트랜잭션을 함께 실행할 수도 있다.
도 5에 제시하였듯이, 상기 어플리케이션(11)는 생성 콜(Create( ) Call), 추가 콜(Add( , ) Call), 스타트 콜(Start( ) Call), 한 세트의 오퍼레이션 콜, 및 커밋 콜(Commit( ) Call)을 포함하는 시스템 콜들을 상기 파일 시스템(12)에 전송할 수 있다.
상기 생성 콜(Create( ) Call), 상기 추가 콜(Add( , ) Call), 상기 스타트 콜(Start( ) Call), 및 상기 커밋 콜(Commit( ) Call)은 본 발명의 일 실시예에 따라 제공되는 상기 파일 시스템(12)이 지원하는 기능일 수 있다.
본 발명의 일 실시예에서는 트랜잭션 파일그룹(TFG)(간단히 '파일그룹')이라는 것을 생성하여 용할 수 있다.
에 따라, 상기 호스트(10)는 상기 생성 콜(Create( ) Call)에는 새로운 파일그룹을 생성할 수 있다. 상기 생성 콜(Create( ) Call)에는 상기 새로운 파일그룹을 나타내는 ID가 인자로서 포함될 수 있다.
상기 생성 콜(Create( ) Call), 상기 추가 콜(Add( , ) Call), 상기 스타트 콜(Start( ) Call), 및 상기 커밋 콜(Commit( ) Call)에는 특정 파일그룹을 나타내는 ID가 인자로서 포함될 수 있다.
이하 도 6을 참조하여 설명한다.
도 6은 본 발명의 일 실시예에 따라 제공되는 트랜잭션을 실행하는 방법을 나타낸 순서도이다.
단계(S111)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 생성 콜(Create)을 송신할 수 있다.
본 발명의 일 실시예에서, 상기 생성 콜에 의해 지정된 새로운 파일그룹이 생성될 수 있다. 상기 파일 시스템(12)은 상기 생성 콜(Create)을 수신하면 상기 제1파일그룹(TFG#1)을 생성할 수 있다(S711).
여기서 상기 제1파일그룹을 나타내는 식별자인 TFG#1은 상기 파일 시스템(12)이 생성한 것이다. 상기 파일 시스템(12)은 상기 TFG#1을 상기 어플리케이션(11)에 반환할 수 있다. 이때부터, 상기 어플리케이션(11)은 상기 제1파일그룹에 관한 단계를 실행하기 위하여 상기 식별자 TFG#1을 이용할 수 있다.
단계(S112)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 추가 콜(Add(TFG#1, File#1, File#2))을 송신할 수 있다.
본 발명의 일 실시예에서, 상기 추가 콜에 의해 지정된 파일들이 상기 추가 콜에 의해 지정된 특정 파일그룹에 멤버로서 추가될 수 있다. 상기 지정을 위해 상기 추가 콜에는 파일그룹 및 파일들을 나타내는 ID들이 인자로서 포함될 수 있다. 단계(S112)에서 TFG#1은 파일을 추가할 파일그룹을 나타내며, File#1 및 File#2는 TFG#1에 추가할 파일들을 나타낸다. 상기 파일 시스템(12)은 상기 추가 콜(Add(TFG#1, File#1, File#2))을 수신하면 상기 제1파일그룹(TFG#1)에 제1파일(File#1) 및 제2파일(File#2)을 추가할 수 있다(S712).
단계(S113)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 스타트 콜(Start(TFG#1))을 송신할 수 있다. 이로써 제1트랜잭션일 시작될 수 있다. 상기 파일 시스템(12)은 상기 스타트 콜(Start(TFG#1))을 수신하면 제1트랜잭션을 위한 프로세스를 시작할 수 있다.
본 발명의 일 실시예에서, 상기 스타트 콜에 의해 시작되는 트랜잭션은, 상기 스타트 콜에 의해 지정된 파일그룹에만 연관된다. 상기 지정을 위해 상기 스타트 콜에는 새롭게 트랜잭션을 시작할 파일그룹을 나타내는 ID가 인자로서 포함될 수 있다. 단계(S113)에서 TFG#1은 시작할 트랜잭션에 연관지을 파일그룹을 나타내는 ID이다. 상기 파일 시스템(12)은 상기 스타트 콜(Start(TFG#1))을 수신하면 상기 제1파일그룹(TFG#1)에 연관된 상기 제1트랜잭션을 위한 프로세스를 시작할 수 있다.
단계(S114)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 상기 제1파일(File#1)에 대한 쓰기 오퍼레이션 콜(WO#1)을 호출할 수 있다. 단계(S115)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 제2파일(File#2)에 대한 쓰기 오퍼레이션 콜(WO#2)을 호출할 수 있다. 단계(S114) 및 단계(S115)에서 각각, 상기 파일 시스템(12)은 상기 오퍼레이션 콜(WO#1) 및 오퍼레이션 콜(WO#2)이 전달한 페이지를 이에 대응하는 버퍼들에 저장할 수 있다. 이 버퍼들은 상기 제1트랜잭션에 관련된 버퍼인 것으로 간주될 수 있다.
상기 파일 시스템(12)은 상기 쓰기 오퍼레이션 콜들을 수신하면, 각 쓰기 오퍼레이션 콜에 대응하는 페이지를, 각 페이지에 대응하는 버퍼에 저장할 수 있다.
단계(S116)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 커밋 콜(Commit(TFG#1))을 호출할 수 있다.
본 발명의 일 실시예에서, 상기 커밋 콜에 의해 커밋되는 트랜잭션은, 상기 커밋 콜에 의해 지정된 파일그룹에만 연관된다. 상기 지정을 위해 상기 커밋 콜에는 커밋을 실행할 트랜잭션에 연관된 파일그룹을 나타내는 ID가 인자로서 포함될 수 있다. 단계(S116)에서 TFG#1은 커밋을 실행할 트랜잭션에 연관된 파일그룹을 나타내는 ID이다. 상기 파일 시스템(12)은 상기 커밋 콜(Commit(TFG#1))을 수신하면 상기 제1파일그룹(TFG#1)에 연관된 상기 제1트랜잭션을 처리할 수 있다.
단계(S117)에서, 상기 파일 시스템(12)는 상기 커밋 콜(Commit(TFG#1))을 수신하면, 상기 제1파일그룹에 연관된 상기 제1트랜잭션에 관련된 버퍼들에 저장된 내용을 참조하여 제1트랜잭션을 처리할 수 있다.
상기 파일 시스템(12)은, 단계(S113)와 단계(S117) 사이에, 파일그룹 TFG#1에 포함된 파일들(File#1, File#2)에 관한 오퍼레이션 콜을 실행하고(S713, S714), 상기 파일그룹에 포함되지 않은 다른 파일(File#3, File#4)에 관한 오퍼레이션 콜을 실행(S715, S716)할 수 있다.
단계(S118)에서, 상기 제1트랜잭션의 처리에 따라 상기 2개의 쓰기 오퍼레이션들에 관한 2개의 쓰기 명령들(WC#1~WC#2) 및 플러시 명령이 상기 파일 시스템(12)으로부터 상기 저장소(20)에게 전송될 수 있다.
한편, 도 6에 제시한 본 발명의 일 실시예에서, 상기 제1파일그룹(TFG#1)에 연관된 상기 제1트랜잭션이 아닌 제2파일그룹(TFG#2)에 연관된 제2트랜잭션이 실행될 수 있다. 이때, 상기 제2트랜잭션이 실행되는 시각은 상기 제1트랜잭션이 실행되는 시각에 종속되지 않는다. 즉, 상기 제1파일그룹(TFG#1)에만 연관된 상기 제1트랜잭션과 상기 제2파일그룹(TFG#2)에만 연관된 제2트랜잭션은 서로 독립적으로 실행될 수 있다. 즉, 상기 제1트랜잭션이 실행되고 있는 특정 시점에 상기 제2트랜잭션이 실행되고 있을 수 있다.
도 6에서 단계(S121~S128)는 상기 제2파일그룹(TFG#2)에만 연관된 제2트랜잭션에 관한 것이다. 도 6에서 단계(S121, S122)는 단계(S112)와 단계(S113) 사이에 실행되고, 단계(S123)는 단계(S113)와 단계(S114) 사이에 실행되고, 단계(S124, S125)는 단계(S115)와 상기 단계(S116) 사이에 실행되고, 단계(S126)는 단계(S118) 이후에 실행된다.
단계(S121)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 생성 콜(Create)을 송신할 수 있다. 상기 파일 시스템(12)은 상기 생성 콜(Create)을 수신하면 상기 제2파일그룹(TFG#2)을 생성할 수 있다.
여기서 상기 제2파일그룹을 나타내는 식별자인 TFG#2은 상기 파일 시스템(12)이 생성한 것이다. 상기 파일 시스템(12)은 상기 TFG#2을 상기 어플리케이션(11)에 반환할 수 있다. 이때부터, 상기 어플리케이션(11)은 상기 제2파일그룹에 관한 단계를 실행하기 위하여 상기 식별자 TFG#2을 이용할 수 있다.
단계(S122)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 추가 콜(Add(TFG#2, File#3, File#4))을 송신할 수 있다. 이때, TFG#2은 파일을 추가할 파일그룹을 나타내며, File#3 및 File#4는 TFG#2에 추가할 파일들을 나타낸다. 상기 파일 시스템(12)은 상기 추가 콜(Add(TFG#2, File#3, File#4))을 수신하면 상기 제2파일그룹(TFG#2)에 제3파일(File#3) 및 제4파일(File#4)을 추가할 수 있다.
단계(S123)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 스타트 콜(Start(TFG#2))을 송신할 수 있다. 이로써 제2트랜잭션일 시작될 수 있다. 상기 파일 시스템(12)은 상기 스타트 콜(Start(TFG#2))을 수신하면 제2트랜잭션을 위한 프로세스를 시작할 수 있다. 이때, TFG#2은 제2트랜잭션에 연관 지을 파일그룹을 나타내는 ID이다.
단계(S124)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 상기 제3파일(File#3)에 대한 쓰기 오퍼레이션 콜(WO#3)을 호출할 수 있다. 단계(S125)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 제4파일(File#4)에 대한 쓰기 오퍼레이션 콜(WO#4)을 호출할 수 있다. 단계(S214) 및 단계(S215)에서 각각, 상기 파일 시스템(12)은 상기 오퍼레이션 콜(WO#3) 및 오퍼레이션 콜(WO#4)이 전달한 페이지를 이에 대응하는 버퍼들에 저장할 수 있다. 이 버퍼들은 상기 제2트랜잭션에 관련된 버퍼인 것으로 간주될 수 있다.
본 발명의 일 실시예에 있어서, 상기 제2파일그룹을 지정한 스타트 콜, 오퍼레이션 콜, 및 커밋 콜의 실행시점은 상기 제1파일그룹을 지정한 스타트 콜, 오퍼레이션 콜, 및 커밋 콜의 실행시점에 종속되지 않는다.
본 발명의 일 실시예에서, 복수 개의 스타트 콜들과 복수 개의 커밋 콜들 중, 동일한 파일그룹을 지정하고 있는 한 개의 스타트 콜과 한 개의 커밋 콜은 서로 페어링될 수 있다. 예컨대 제1파일그룹을 지정한 스타트 콜(Start(TFG#1))과 커밋 콜(Commit(TFG#1))은 서로 페어링될 수 있다. 상기 호스트가 동작하는 동안, 상기 제1파일그룹을 지정한 커밋 콜(Commit(TFG#1))은 복수 회 발생할 수도 있다. 여기서 상기 스타트 콜(Start(TFG#1))에 페어링되는 커밋 콜(Commit(TFG#1))은, 상기 복수 개의 커밋 콜(Commit(TFG#1))들 중 상기 스타트 콜(Start(TFG#1))이 발생한 이후 처음으로 발생한 것일 수 있다.
본 발명의 일 실시예에서, 제1파일그룹을 지정한 스타트 콜(Start(TFG#1))은 제1시점에 발생하고, 상기 스타트 콜(Start(TFG#1))에 페어링된 커밋 콜(Commit(TFG#1))은 제2시점에 발생할 수 있다. 이때, 상기 제1시점과 상기 제2시점 사이에, 상기 제1파일그룹에 관한 오퍼레이션 콜들뿐만 아니라 제2파일그룹에 관한 오퍼레이션 콜들이 발생할 수 있다. 이때, 상기 커밋 콜(Commit(TFG#1))이 발생하면, 상기 제1파일그룹에 관한 오퍼레이션 콜들만이 커밋 처리되며, 상기 제2파일그룹에 관한 오퍼레이션 콜들은 커밋 처리되지 않는다. 즉, 상기 제1파일그룹에 관한 오퍼레이션 콜들은 제1트랜잭션에 속하고, 상기 제2파일그룹에 관한 오퍼레이션 콜들은 제2트랜잭션에 속한다.
이러한 본 발명의 특징은, 도 3 및 도 4에 제시한 비교 기술에서, 스타트 콜와 커밋 콜 사이에 발생한 모든 오퍼레이션 콜들이 한 개의 단일 트랜잭션에 포함되는 것과는 다르다.
도 6의 단계(S117)에서 상기 제2파일그룹(TFG#2)에 대한 오퍼레이션들은 처리되지 않는다.
단계(S126)에서, 상기 어플리케이션(11)은 상기 파일 시스템(12)에게 커밋 콜(Commit(TFG#2))을 호출할 수 있다. 상기 파일 시스템(12)은 상기 커밋 콜(Commit(TFG#2))을 수신하면 상기 제2파일그룹(TFG#2)에 연관된 상기 제2트랜잭션을 처리할 수 있다.
이때, 스타트 콜(Start(TFG#2))과 커밋 콜(Commit(TFG#2)) 사이에, 상기 제1파일그룹에 관한 오퍼레이션 콜들(WO#1, WO#2)뿐만 아니라 제2파일그룹에 관한 오퍼레이션 콜들(WO#3, WO#4)이 발생하였다.
상기 파일 시스템(12)은, 상기 어플리케이션(11)으로부터 수신한 오퍼레이션 콜에 지정되어 있는 파일이 제1파일그룹에 속한 것이라면 상기 오퍼레이션 콜은 상기 제1파일그룹에 관한 것으로 판단한다. 예컨대, 단계(S114)에서 상기 파일 시스템(12)이 수신한 오퍼레이션 콜(WO#1)에 지정되어 있는 파일(File#1)은 단계(S112)에서 제1파일그룹의 멤버가 되었으므로, 오퍼레이션 콜(WO#1)은 상기 제1파일그룹에 관한 것으로 결정된다.
이때, 상기 커밋 콜(Commit(TFG#2))이 발생하면, 상기 제2파일그룹에 관한 오퍼레이션 콜들만이 커밋 처리되며, 상기 제1파일그룹에 관한 오퍼레이션 콜들은 커밋 처리되지 않는다.
단계(S127)에서, 상기 파일 시스템(12)는 상기 커밋 콜(Commit(TFG#2))을 수신하면, 상기 제2파일그룹에 연관된 상기 제2트랜잭션에 관련된 버퍼들에 저장된 내용을 참조하여 제2트랜잭션을 처리할 수 있다.
단계(S128)에서, 상기 제2트랜잭션의 처리에 따라 상기 2개의 쓰기 오퍼레이션들에 관한 2개의 쓰기 명령들(WC#3~WC#4) 및 플러시 명령이 상기 파일 시스템(12)으로부터 상기 저장소(20)에게 전송될 수 있다.
도 7은 도 6으로부터 변형된 실시예를 나타낸다.
도 6에서는 제1파일그룹에 대한 스타트 콜이 제2파일그룹에 대한 스타트 콜 보다 먼저 발생하였고, 제1파일그룹에 대한 커밋 콜도 제2파일그룹에 대한 커밋 콜 보다 먼저 발생하였다.
이에 비하여, 도 6에서는 제1파일그룹에 대한 스타트 콜이 제2파일그룹에 대한 스타트 콜 보다 먼저 발생하였지만, 제2파일그룹에 대한 커밋 콜이 제1파일그룹에 대한 커밋 콜 보다 먼저 발생한 경우를 나타낸다.
그러나 상술한 바와 같이, 본 발명의 일 실시예에서, 서로 다른 파일그룹에 대한 서로 다른 트랜잭션들을 시간축에서 서로 독립적으로 실행되기 때문에, 상기 저장소(20)가 상기 파일 시스템(12)으로부터 수신하는 명령들의 집합은 도 6 및 도 7의 예에서 모두 동일하다. 다만, 상기 저장소(20)이 각 명령들의 집합을 수신하는 시점이 변경될 뿐이다. 도 6에서 단계(S118)에 전송되는 명령들이 한 개의 집합을 이루고, 단계(S128)에 전송되는 명령들이 또 다른 한 개의 집합을 이룬다.
도 8은 비교 실시예에 따라 트랜잭션을 실행하는 방법을 나타낸 순서도이다.
도 8은, 상기 파일그룹 개념을 이용하지 않는 종래의 기술을 이용하여, 상기 저장소(20)의 입장에서 도 6과 동일한 결과를 얻도록 하는 비교 실시예이다.
도 8에 나타낸 단계(S213~S218)은 도 6에 나타낸 단계(S113~S118)에 대응한다. 다만, 단계(S213~S217)이 나타내는 시스템 콜은 상술한 파일그룹이라는 정보를 이용하지 않는다.
또한, 도 8에 나타낸 단계(S223~S228)은 도 6에 나타낸 단계(S123~S128)에 대응한다. 다만, 단계(S223~S227)이 나타내는 시스템 콜은 상술한 파일그룹이라는 정보를 이용하지 않는다.
도 8에는 도 6에 나타낸 단계(S111, S112, S121, S122)에 대응하는 단계가 제공되지 않는다.
도 8에 나타낸 실시예가 도 6과 동일한 결과를 얻기 위해서, 제2트랜잭션의 시작을 위한 스타트 콜(S223)은 반드시 제1트랜잭션의 커밋 콜이 발생한 이후에 발생해야 한다. 즉, 제2트랜잭션의 스타트 콜 발생시점과 제1트랜잭션의 커밋 콜의 발생시점을 상기 어플리케이션(11)이 제어해야 한다.
이에 비하여, 도 6에 나타낸 방법에서는, 제2트랜잭션의 스타트 콜 발생시점과 제1트랜잭션의 커밋 콜의 발생시점을 상기 어플리케이션(11)이 제어하지 않더라도, 상기 파일 시스템(12)이 상기 파일그룹이라는 정보를 이용하여 자동으로 처리한다.
도 6의 방법에 따르면, 상기 어플리케이션(11)에서 특정 파일그룹에 대한 시작 콜과 추가 콜을 한 번만 발생시키면, 그 이후에 상기 파일그룹에 대한 트랜잭션을 다른 파일그룹에 대한 트랜잭션을 고려하지 않고 임의의 시점에 실행할 수 있다는 큰 효과가 제공된다.
도 9는 본 발명의 일 실시예에 따라 제공되는 트랜잭션 실행 방법을 나타낸 순서도이다.
도 9의 각 단계는 호스트에서 실행될 수 있다.
단계(S51)에서, 호스트의 어플리케이션이 상기 호스트의 파일 시스템에게 제1파일그룹을 생성하는 시스템 콜을 전송하고, 상기 파일 시스템이 상기 제1파일그룹을 생성할 수 있다.
단계(S52)에서, 상기 어플리케이션이 상기 파일 시스템에게 상기 제1파일그룹에 소정의 파일들을 멤버로서 추가하는 시스템 콜을 전송하고, 상기 제1파일그룹에 상기 소정의 파일들을 상기 제1파일그룹의 멤버로서 추가할 수 있다.
단계(S53)에서, 상기 어플리케이션이 상기 파일 시스템에게 상기 제1파일그룹에 관련된 제1트랜잭션을 시작하는 시스템 콜을 전송한 후, 상기 제1파일그룹에 대한 한 개 이상의 오퍼레이션 시스템 콜을 전송할 수 있다.
단계(S54)에서, 상기 어플리케이션이 상기 파일 시스템에게 상기 제1파일그룹에 관련된 제1트랜잭션의 커밋의 실행을 위한 시스템 콜을 전송하고, 상기 파일 시스템이, 상기 제1트랜잭션을 처리하여 한 세트의 명령들을 스토리지에 전송할 수 있다.
이때, 상기 파일 시스템이 처리하는 상기 제1트랜잭션은, 상기 제1트랜잭션을 시작하는 시스템 콜의 발생 시각과 상기 제1트랜잭션의 커밋의 실행을 위한 시스템 콜의 발생 시각 사이에, 상기 파일 시스템이 상기 어플리케이션으로부터 수신한 오퍼레이션 콜들 중에서, 상기 제1파일그룹에 연관된 오퍼레이션 콜들만을 포함할 수 있다.
도 10은 본 발명의 일 실시예에 따라 제공되는 트랜잭션 실행 방법을 나타낸 순서도이다. 도 10의 각 단계는 호스트에서 실행될 수 있다.
단계(S551)에서, 파일 시스템은 일 그룹의 파일들을 멤버로 갖는 파일그룹을 생성할 수 있다.
단계(S552)에서, 상기 파일 시스템이 어플리케이션으로부터 상기 파일그룹을 지정한 커밋 콜을 수신하면, 상기 파일그룹에 연관된 오퍼레이션 콜들만으로 구성된 트랜잭션을 커밋할 수 있다.
상술한 본 발명의 실시예들을 이용하여, 본 발명의 기술 분야에 속하는 자들은 본 발명의 본질적인 특성에서 벗어나지 않는 범위 내에 다양한 변경 및 수정을 용이하게 실시할 수 있을 것이다. 특허청구범위의 각 청구항의 내용은 본 명세서를 통해 이해할 수 있는 범위 내에서 인용관계가 없는 다른 청구항에 결합될 수 있다.
[사사]
본 발명은 다음 연구과제의 지원을 받아 창작된 것이다.
1. 연구과제1
*과제고유번호: 2018900054
*과제번호:20180005490031001
*부처명:과학기술정보통신부
*과제관리(전문)기관명:정보통신기획평가원
*연구사업명:SW컴퓨팅산업원천기술개발사업
*연구과제명:매니코어 초대용량 메모리를 위한 확장형 순서보장 운영체제 개발
*과제수행기관명:한국과학기술원
2. 연구과제2
*과제고유번호: 2020123008
*과제번호: 2020R1A2C300852511
*부처명:과학기술정보통신부
*과제관리(전문)기관명:한국연구재단
*연구사업명:이공분야기초연구사업
*연구과제명:초저지연 저장장치를 위한 무경쟁 확장형 입출력 서브시스템 연구(2020)
*과제수행기관명:한국과학기술원

Claims (15)

  1. 호스트의 파일 시스템이, 파일그룹을 생성하는 그룹생성단계(S711); 및
    상기 파일 시스템이, 상기 파일그룹을 지정한 커밋 콜을 수신하면, 상기 파일그룹에 포함된 파일들에 관한 오퍼레이션 콜들만으로 구성된 트랜잭션을 커밋하는 커밋단계(S117);
    를 포함하는,
    트랜잭션 처리방법.
  2. 제1항에 있어서,
    상기 그룹생성단계와 상기 커밋단계 사이에,
    상기 파일 시스템이, 상기 파일그룹에 일 그룹의 파일을 상기 파일그룹의 멤버로서 추가하는 파일추가단계(S712); 및
    상기 파일 시스템이, 상기 파일그룹에 포함된 파일들에 관한 오퍼레이션 콜을 실행하고(S713, S714), 상기 파일그룹에 포함되지 않은 다른 파일에 관한 오퍼레이션 콜을 실행(S715, S716)하는 단계;
    를 더 포함하는,
    트랜잭션 처리방법.
  3. 제1항에 있어서, 상기 커밋단계 이후에, 상기 파일 시스템이, 상기 파일그룹을 삭제하는 단계(S717)를 더 포함하는, 트랜잭션 처리방법.
  4. 제2항에 있어서,
    상기 그룹생성단계 이전에, 상기 호스트의 어플리케이션이, 상기 파일그룹을 생성하라는 파일그룹 생성 콜을 상기 파일 시스템에게 전송하는 단계(S111);
    상기 그룹생성단계와 상기 파일추가단계 사이에, 상기 어플리케이션이, 상기 일 그룹의 파일을 상기 파일그룹의 멤버로서 추가하라는 요청을 나타내는 파일추가 콜을 상기 파일 시스템에게 전송하는 단계(S112); 및
    상기 파일추가단계와 상기 오퍼레이션 콜을 실행하는 단계 사이에, 상기 어플리케이션이, 상기 파일그룹을 지정한 시작 콜을 상기 파일 시스템에게 전송하는 단계(S113);
    를 더 포함하며,
    상기 그룹생성단계는, 상기 파일 시스템이 상기 파일그룹 생성 콜을 수신하면 실행되고,
    상기 파일추가단계는, 상기 파일 시스템이 상기 파일추가 콜을 수신하면 실행되는,
    트랜잭션 처리방법.
  5. 제4항에 있어서,
    상기 파일추가 콜은 상기 파일그룹을 식별하는 식별자와 상기 일 그룹의 파일을 식별하는 식별자에 관한 정보를 포함하며,
    상기 시작 콜은 상기 파일그룹을 식별하는 식별자에 관한 정보를 포함하며, 그리고
    상기 커밋 콜은 상기 파일그룹을 식별하는 식별자에 관한 정보를 포함하는,
    트랜잭션 처리방법.
  6. 호스트로서,
    처리부; 및 통신부;를 포함하며,
    상기 처리부는 상기 호스트의 파일 시스템을 실행하도록 되어 있고,
    상기 파일 시스템은,
    파일그룹을 생성하는 그룹생성단계(S711); 및
    상기 파일그룹을 지정한 커밋 콜을 수신하면, 상기 파일그룹에 포함된 파일들에 관한 오퍼레이션 콜들만으로 구성된 트랜잭션을 커밋하는 커밋단계(S117);
    를 실행하도록 되어 있는 것을 특징으로 하는,
    호스트.
  7. 제6항에 있어서,
    상기 파일 시스템은,
    상기 그룹생성단계와 상기 커밋단계 사이에,
    상기 파일그룹에 일 그룹의 파일을 상기 파일그룹의 멤버로서 추가하는 파일추가단계(S712); 및
    상기 파일그룹에 포함된 파일들에 관한 오퍼레이션 콜을 실행하고(S713, S714), 상기 파일그룹에 포함되지 않은 다른 파일에 관한 오퍼레이션 콜을 실행(S715, S716)하는 단계;
    를 더 실행하도록 되어 있는,
    호스트.
  8. 제7항에 있어서,
    상기 처리부는 상기 호스트의 어플리케이션을 실행하도록 되어 있고,
    상기 어플리케이션은,
    상기 그룹생성단계 이전에, 상기 파일그룹을 생성하라는 파일그룹 생성 콜을 상기 파일 시스템에게 전송하는 단계(S111);
    상기 그룹생성단계와 상기 파일추가단계 사이에, 상기 일 그룹의 파일을 상기 파일그룹의 멤버로서 추가하라는 요청을 나타내는 파일추가 콜을 상기 파일 시스템에게 전송하는 단계(S112); 및
    상기 파일추가단계와 상기 오퍼레이션 콜을 실행하는 단계 사이에, 상기 파일그룹을 지정한 시작 콜을 상기 파일 시스템에게 전송하는 단계(S113);
    를 실행하도록 되어 있으며,
    상기 그룹생성단계는, 상기 파일 시스템이 상기 파일그룹 생성 콜을 수신하면 실행되고,
    상기 파일추가단계는, 상기 파일 시스템이 상기 파일추가 콜을 수신하면 실행되는,
    호스트.
  9. 제8항에 있어서,
    상기 파일추가 콜은 상기 파일그룹을 식별하는 식별자와 상기 일 그룹의 파일을 식별하는 식별자에 관한 정보를 포함하며,
    상기 시작 콜은 상기 파일그룹을 식별하는 식별자에 관한 정보를 포함하며, 그리고
    상기 커밋 콜은 상기 파일그룹을 식별하는 식별자에 관한 정보를 포함하는,
    호스트.
  10. 제6항에 있어서, 상기 파일 시스템은, 상기 커밋단계 이후에, 상기 파일 시스템이, 상기 파일그룹을 삭제하는 단계(S717)를 더 실행하도록 되어 있는, 호스트.
  11. 호스트 및 스토리지를 포함하는 컴퓨팅 장치로서,
    상기 호스트는 파일 시스템을 실행하도록 되어 있고,
    상기 파일 시스템은,
    파일그룹을 생성하는 그룹생성단계(S711); 및
    상기 파일그룹을 지정한 커밋 콜을 수신하면, 상기 파일그룹에 포함된 파일들에 관한 오퍼레이션 콜들만으로 구성된 트랜잭션을 커밋하는 커밋단계(S117);
    를 실행하도록 되어 있고,
    상기 스토리지는, 상기 파일 시스템이 상기 커밋단계를 실행하면, 상기 파일그룹에 포함된 파일들에 관한 오퍼레이션 콜들만으로 구성된 트랜잭션을 상기 스토리지에 저장하도록 되어 있는,
    컴퓨팅 장치.
  12. 제11항에 있어서,
    상기 파일 시스템은,
    상기 그룹생성단계와 상기 커밋단계 사이에,
    상기 파일그룹에 일 그룹의 파일을 상기 파일그룹의 멤버로서 추가하는 파일추가단계(S712); 및
    상기 파일그룹에 포함된 파일들에 관한 오퍼레이션 콜을 실행하고(S713, S714), 상기 파일그룹에 포함되지 않은 다른 파일에 관한 오퍼레이션 콜을 실행(S715, S716)하는 단계;
    를 더 실행하도록 되어 있는,
    컴퓨팅 장치.
  13. 제12항에 있어서, 상기 파일 시스템은, 상기 커밋단계 이후에, 상기 파일 시스템이, 상기 파일그룹을 삭제하는 단계(S717)를 더 실행하도록 되어 있는, 컴퓨팅 장치.
  14. 제12항에 있어서,
    상기 그룹생성단계 이전에, 상기 호스트의 어플리케이션이, 상기 파일그룹을 생성하라는 파일그룹 생성 콜을 상기 파일 시스템에게 전송하는 단계(S111);
    상기 그룹생성단계와 상기 파일추가단계 사이에, 상기 어플리케이션이, 상기 일 그룹의 파일을 상기 파일그룹의 멤버로서 추가하라는 요청을 나타내는 파일추가 콜을 상기 파일 시스템에게 전송하는 단계(S112); 및
    상기 파일추가단계와 상기 오퍼레이션 콜을 실행하는 단계 사이에, 상기 어플리케이션이, 상기 파일그룹을 지정한 시작 콜을 상기 파일 시스템에게 전송하는 단계(S113);
    를 더 실행하도록 되어 있고,
    상기 그룹생성단계는, 상기 파일 시스템이 상기 파일그룹 생성 콜을 수신하면 실행되고,
    상기 파일추가단계는, 상기 파일 시스템이 상기 파일추가 콜을 수신하면 실행되는,
    컴퓨팅 장치.
  15. 제14항에 있어서,
    상기 파일추가 콜은 상기 파일그룹을 식별하는 식별자와 상기 일 그룹의 파일을 식별하는 식별자에 관한 정보를 포함하며,
    상기 시작 콜은 상기 파일그룹을 식별하는 식별자에 관한 정보를 포함하며, 그리고
    상기 커밋 콜은 상기 파일그룹을 식별하는 식별자에 관한 정보를 포함하는,
    컴퓨팅 장치.
PCT/KR2021/017783 2020-11-27 2021-11-29 다중파일 트랜잭션의 파일 관리 기법 및 장치 WO2022114898A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20200163275 2020-11-27
KR10-2020-0163275 2020-11-27

Publications (1)

Publication Number Publication Date
WO2022114898A1 true WO2022114898A1 (ko) 2022-06-02

Family

ID=81755875

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2021/017783 WO2022114898A1 (ko) 2020-11-27 2021-11-29 다중파일 트랜잭션의 파일 관리 기법 및 장치

Country Status (2)

Country Link
KR (1) KR20220074806A (ko)
WO (1) WO2022114898A1 (ko)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001077908A2 (en) * 2000-03-30 2001-10-18 Microsoft Corporation Transactional file system
US8838534B2 (en) * 2009-08-12 2014-09-16 Cloudtran, Inc. Distributed transaction processing
US10360146B2 (en) * 2016-06-10 2019-07-23 Sap Se Group garbage collection for multi-version concurrency control in database systems
US20190354989A1 (en) * 2018-05-15 2019-11-21 International Business Machines Corporation Automated data projection for smart contract groups on a blockchain

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001077908A2 (en) * 2000-03-30 2001-10-18 Microsoft Corporation Transactional file system
US8838534B2 (en) * 2009-08-12 2014-09-16 Cloudtran, Inc. Distributed transaction processing
US10360146B2 (en) * 2016-06-10 2019-07-23 Sap Se Group garbage collection for multi-version concurrency control in database systems
US20190354989A1 (en) * 2018-05-15 2019-11-21 International Business Machines Corporation Automated data projection for smart contract groups on a blockchain

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
RAHMAN SYEDUR, AHSAN FEROZ A M, KAMRUZZAMAN MD, FARUQUE MEHERUN NESA, LIMITED JAXARA IT, DHAKA, BANGLADESH: "Analyze Database Optimization Techniques", IJCSNS INTERNATIONAL JOURNAL OF COMPUTER SCIENCE AND NETWORK SECURITY, vol. 10, no. 8, 1 August 2010 (2010-08-01), pages 275 - 279, XP055933844 *

Also Published As

Publication number Publication date
KR20220074806A (ko) 2022-06-03

Similar Documents

Publication Publication Date Title
WO2015020471A1 (en) Method and apparatus for distributing data in hybrid cloud environment
WO2020101343A1 (ko) 데이터베이스 관리 시스템에서의 변경 데이터 캡쳐 구현 기법
WO2016171401A1 (ko) 공동 편집 문서를 공유하는 방법 및 장치
WO2010062063A2 (ko) 브라우저 기반 어뷰징 방지 방법 및 시스템
WO2018101640A1 (ko) 데이터베이스 이중화 무중단 정합성 복구 기법
WO2015156596A1 (en) Hardware-based memory management apparatus and memory management method thereof
WO2018076840A1 (zh) 数据分享方法、装置、存储介质及服务器
WO2015137641A2 (ko) 계층적인 룰 구조를 가지고 있는 비즈니스 룰 관리 시스템 및 그 표현 방법
WO2012124985A2 (en) Method and apparatus for synchronizing personal inforamtion
WO2018201774A1 (zh) 数据审批方法、装置、设备和计算机可读存储介质
WO2019088334A1 (ko) 빅 데이터의 실시간 저장 및 검색 시스템
WO2020253125A1 (zh) 日志管理方法、装置、设备及存储介质
WO2020256301A1 (en) Electronic device including storage and method for using the storage
WO2023038220A1 (en) Method and apparatus for performing horizontal federated learning
WO2018076873A1 (zh) 数据分享方法、装置、介质、电子设备及系统
WO2013183944A1 (en) Apparatus and method for transmitting and receiving files in general purpose device
WO2020222347A1 (ko) 가상 머신 배치 방법 및 이를 구현하는 가상 머신 배치 장치
WO2022114898A1 (ko) 다중파일 트랜잭션의 파일 관리 기법 및 장치
WO2017020620A1 (zh) 标签页同步方法、电子设备及存储介质
WO2024112108A1 (ko) 실시간 drm 기반 영상 스트리밍 시스템 및 그의 영상 스트리밍 방법
WO2024043613A1 (ko) 이력서 생성 및 관리 서비스를 제공하기 위한 서버 장치 및 그 동작 방법
WO2021040168A1 (ko) 신구 데이터간의 차분에 대한 데이터 구조화 방법 및 그 디바이스
WO2019245247A1 (en) Method for object management using trace identifier, apparatus for the same, computer program for the same, and recording medium storing computer program thereof
WO2023171973A1 (en) Apparatus and method of managing non-fungible tokens based on blockchain
WO2013125920A1 (ko) 로케이션 기반의 언솔리시티드 다운로드 방법, 장치 및 시스템

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: 21898723

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: 21898723

Country of ref document: EP

Kind code of ref document: A1