KR20220088274A - Computing System including Per-core journal structure - Google Patents

Abstract

A computing system having a plurality of cores according to an aspect of the technical concept of the present disclosure includes a memory configured to include a journal stack allocated to each of the plurality of cores, and a storage device configured to include a journal area allocated to each of the plurality of cores. a first core among the plurality of cores merges the blocks changed by the first core in units of transactions and stores them in a journal stack corresponding to the first core, and stores the blocks in a journal stack corresponding to the first core in a journal area corresponding to the first core It is characterized by performing a commit with

Description

Computing System including Per-core journal structure

The technical idea of the present disclosure relates to a computing system, and more particularly, to a computing system including a journal structure for each core.

When an abnormal power problem or a system crash occurs during the operation of the computing system, data stored in the buffer memory is lost and the consistency of the file system is broken. A file system included in the computing system may include a journaling layer in preparation for such a situation. Recently, while the number of cores mounted in a computing system increases, the journaling layer has a problem in that scalability is limited due to accessing one journal area in the storage device.

An object of the technical spirit of the present disclosure is to provide a journal structure for each core that guarantees file system consistency, and a computing system including the same.

In order to achieve the above object, a computing system having a plurality of cores according to an aspect of the technical idea of the present disclosure includes a memory configured to include a journal stack allocated to each of the plurality of cores, and a memory allocated to each of the plurality of cores. a storage device configured to include a journal area, wherein a first core among a plurality of cores merges a block changed by the first core in a transaction unit and stores the merged block in a journal stack corresponding to the first core, and the first core It is characterized in that the commit is performed in the journal area corresponding to the transaction unit.

The computing system according to the exemplary embodiment of the present disclosure may improve the scalability of the journal layer by allowing the kernel thread of each core to independently commit to the journal area allocated to each core. In addition, storage input/output (I/O) performance and arithmetic throughput may be improved because the kernel thread of each core writes file system changes to the journal area in parallel.

A computing system according to an exemplary embodiment of the present disclosure may provide a method for ensuring file system consistency with a small overhead in a computing system having a plurality of cores.

1 illustrates a computing system according to an exemplary embodiment of the present disclosure.
2 illustrates a computing system according to an exemplary embodiment of the present disclosure.
3 illustrates a first journal stack corresponding to a zeroth core according to an exemplary embodiment of the present disclosure.
4A illustrates a processing sequence in a plurality of cores in an exemplary embodiment of the present disclosure. 4B illustrates a journal stack corresponding to the plurality of cores of FIG. 4A according to an exemplary embodiment of the present disclosure.
5 shows a list of transactions included in the journal stack of FIG. 4B according to an exemplary embodiment of the present disclosure.
6 illustrates a journal area stored in a storage device according to an exemplary embodiment of the present disclosure.
7 illustrates a data recovery method in case of a system crash according to an exemplary embodiment of the present disclosure.
8 illustrates a checkpoint method according to an exemplary embodiment of the present disclosure.

Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

1 illustrates a computing system 10 according to an exemplary embodiment of the present disclosure.

Referring to FIG. 1 , a computing system 10 may include a host 100 , a file system 140 , and a storage device 160 . The file system 140 may provide an interface between the host 100 and hardware (eg, the storage device 160 ).

For example, the computing system 10 may correspond to various types of electronic devices. The computing system 10 is a mobile device, a laptop computer, a mobile phone, a smartphone, a tablet PC, a personal digital assistant (PDA), an enterprise digital assistant (EDA), a digital still camera, a digital video camera. camera), PMP (portable multimedia player), PND (personal navigation device or portable navigation device), handheld game console, mobile internet device (MID), wearable computer, internet of things (IoT) device, internet of everything (IoE) device, or e-book.

The host 100 may include a processor 102 and a memory 104 . The memory 104 space allocated by the processor 102 to a process may be divided into a user space and a kernel space. The user space is an area in which a user application is executed, and the kernel space may be an area that is limitedly guaranteed for kernel use. The user application may send a request to the operating system to write data to the storage device 160 or to read data from the storage device 160 . In response to a request of a user application, the operating system may switch to the kernel space using a system call and access the storage device 160 .

The operating system may further include a file system 140 that is a software module for managing files stored in the storage device 160 . The file system 140 may divide the storage space of the storage device 160 into a set of logical blocks, and one block may have an arbitrary size. The file system 140 may write data to or read data from the storage device 160 in block units.

For example, the file system 140 may have various forms according to the operating system of the host 100 . For example, the file system 140 includes a File Allocation Table (FAT), FAT32, NT File System (NTFS), Hierarchical File System (HFS), Journaled File System2 (JSF2), XFS, and On-Disk Structure (ODS-5). -5), UDF, ZFS, UFS (Unix File System), ext2, ext3, ext4, ReiserFS, Reiser5, ISO 9660, Gnome VFS, BFS, or WinFS.

In some embodiments, file system 140 may include a journaling layer 142 . The journaling layer 142 may represent a layer used to maintain data consistency in a file system. For example, when the buffer memory is implemented as a volatile memory, data stored in the buffer memory may be lost before being written into the data area 164 when a system crashes. When power is applied again, metadata and actual data in the file system 140 do not match, and consistency of the file system 140 may be broken.

The journaling layer 142 may ensure the consistency of the file system 140 by executing a kernel thread. The storage space of the storage device 160 may be divided into a journal area 162 and a data area 164 . The kernel thread records changes in the file system 140 to the journal area 162 before writing them to the data area 164 of the storage device 160, and writes them to the journal area 162 when a system crash occurs. The consistency of the file system 140 can be guaranteed by reading the changed changes and writing them to the data area 164 .

Although not shown in FIG. 1 , the computing system 10 may further include a Virtual File System (VFS). The virtual file system may be an abstraction layer as an upper layer of the file system 140 . The virtual file system may support a standardized system call so that the host 100 can consistently access various file systems 140 .

The storage device 160 may be divided into a journal area 162 and a data area 164 . Changes in the file system are recorded in the journal area 162 in transaction units, so that atomicity and persistence can be guaranteed. The journal area 162 may include a commit block, and the commit block may indicate that a corresponding transaction has been effectively written to the journal area 162 .

For example, the storage device 160 may include a NAND flash memory (NAND Flash Memory), a vertical NAND flash memory (VNAND), a NOR flash memory (NOR Flash Memory), and a resistive random access memory (RRAM). , Phase-Change Random Access Memory (PRAM), Magnetoresistive Random Access Memory (MRAM), Ferroelectric Random Access Memory (FRAM), Spin Transfer Torque Random Access Memory ; STT-RAM).

2 illustrates a computing system 20 according to an exemplary embodiment of the present disclosure. FIG. 2 will be described later with reference to FIG. 1 .

Referring to FIG. 2 , the computing system 20 may include a plurality of cores CORE_0 to CORE_N, and journal stacks 120_0 to 120_N allocated to each of the plurality of cores CORE_0 to CORE_N. The file system 140 may allocate a specific address space to the journal stacks 120_0 to 120_N in the memory 104 included in the host 100 . The storage device 160 may include journal areas 162_0 to 162_N allocated to each of the plurality of cores CORE_0 to CORE_N. The storage device 160 may further include a data area (not shown).

In some embodiments, the zeroth core CORE_0 may change at least one block included in the storage device 160 , and the file system 140 may change. The block changed by the 0th core CORE_0 may be stored in the first journal stack 120_0 in units of a transaction TX. The zeroth core CORE_0 may write the transaction TX stored in the first journal stack 120_0 to the first journal area 162_0 before writing it to the data area 164 . This recording process may be referred to as a commit.

Thereafter, the zeroth core CORE_0 may record committed transactions in the data area 164 every predetermined time period defined in the computing system 20 or when the capacity of the first journal area 162_0 is insufficient. . This recording process may be referred to as a checkpoint. Commits and checkpoints of the file system 140 may be performed by a kernel thread. For example, the zeroth core CORE_0 may record changes in the file system by executing the first kernel thread THREAD_0.

The first journal stack 120_0 and the first journal area 162_0 of the 0th core CORE_0 described above may be applied to the first core CORE_1 to the Nth core CORE_N. Each of the plurality of cores CORE_0 to CORE_N executes kernel threads THREAD_0 to THREAD_N independent from each other, so that changes in the file system 140 may be committed for each core.

The computing system according to the exemplary embodiment of the present disclosure may improve the scalability of the journal layer by allowing the kernel thread of each core to independently commit to the journal area allocated to each core. In addition, storage input/output (I/O) performance and arithmetic throughput may be improved because the kernel thread of each core writes file system changes to the journal area in parallel.

In addition, the computing system according to an exemplary embodiment of the present disclosure may provide a method of ensuring file system consistency with a small overhead in a computing system having a plurality of cores.

3 illustrates a first journal stack 120_0 corresponding to a zeroth core CORE_0 according to an exemplary embodiment of the present disclosure. FIG. 3 will be described later with reference to FIG. 2 .

Referring to FIG. 3 , the computing system 20 may include a first journal stack 120_0 corresponding to a zero-th core CORE_0. The first journal stack 120_0 may store blocks changed by the 0th core CORE_0 by merging them in transaction units. The structure of the first journal stack 120_0 of FIG. 3 may be applied to the journal stacks 120_0 to 120_N of FIG. 2 .

The first journal stack 120_0 is a structure for managing a changed block, and may include a journal head JH, a block head BH, and at least one block BL changed by the first core CORE_1. . For example, block 0 and block 1 changed by the 0th core CORE_0 may be written in one transaction TX. The journal head JH may be connected to the block head BH in both directions. For example, the journal head JH may be connected to the block head BH through a double linked list. The block head BH is connected to the changed block BL, and may include information on the block BL. For example, the block head BH may include the number of the block BL in the file system.

The first journal stack 120_0 may further include a structure representing the transaction TX. The structure representing the transaction TX may indicate the number of the transaction and the status of the transaction. A transaction stored in the first journal stack 120_0 may be in a running or committing state. The transaction in the running state may be a state in which blocks changed by the 0th core CORE_0 are merged. The transaction in the commit state may indicate a state in which a transaction included in the first journal stack 120_0 is being written into the first journal area 162_0. The transaction in the commit state may be in the commit completion state when blocks included in the transaction are written to the first journal area 162_0. A transaction in a commit completion state may be identified based on a commit block in the journal area.

In some embodiments, the first journal stack 120_0 may further include a transaction list 130 . The transaction list 130 may include information on transactions of different cores that must be committed together in a journal area of a storage device to ensure file system consistency. The transaction list 130 will be described later in detail with reference to FIG. 5 .

4A illustrates a processing sequence in a plurality of cores in an exemplary embodiment of the present disclosure. 4B illustrates a journal stack corresponding to the plurality of cores of FIG. 4A according to an exemplary embodiment of the present disclosure.

4A and 4B together, in step S100 , the second core CORE_2 may change blocks 4 and 5 . The changed blocks 4 and 5 may be included in the second transaction TX_2. The second transaction TX_2 may correspond to a transaction in a running state, and the second core CORE_2 may store the second transaction TX_2 in the third journal stack 120_2 .

In step S120 , the second core CORE_2 may perform a commit. For example, the second core CORE_2 may commit the second transaction TX_2 to the journal area. The second core CORE_2 may copy the original block included in the second transaction TX_2 and write the copied block to the journal area corresponding to the second core CORE_2 . For example, the second core CORE_2 copies the original block 4 and the original block 5 included in the second transaction TX_2, and applies the copied block 4 and the copied block 5 to the second core CORE_2. You can write to the journal area. Accordingly, the original block 4 and the original block 5 may be accessed and changed by other cores. When the second core CORE_2 completes the commit, the second transaction TX_2 may be changed to a transaction in a commit completion state.

In operation S140 , the first core CORE_1 may change blocks 2 , 3 , and 4 . The changed blocks 2 and 3 may be included in the seventh transaction TX_7. The seventh transaction TX_7 may correspond to a transaction in a running state. In addition, since the second core CORE_2 commits the copied block 4 , the original block 4 may be modified by the first core CORE_1 . The first core CORE_1 may keep the copied block 4 in the second transaction TX_2 of the second core CORE_2 , and may bring the original block 4 and insert it into the seventh transaction TX_7 .

In operation S160 , the zeroth core CORE_0 may change block 0 , block 1 , and block 3 . The changed blocks 0 and 1 may be included in the fourth transaction TX_4. Meanwhile, block 3 may be included in the seventh transaction TX_7 of the first core CORE_1 in step S140 . Accordingly, the zeroth core CORE_0 may access the seventh transaction TX_7 of the first core CORE_1 to modify block 3 .

In step S180 , the first core CORE_1 may change block 0 . Block 0 may be included in the fourth transaction TX_4 of the 0th core CORE_0 in step S160 . Accordingly, the first core CORE_1 may access the fourth transaction TX_4 of the zeroth core CORE_0 to modify block 0 .

5 illustrates a list of transactions included in journal stacks 120_0 to 120_2 of FIG. 4B according to an exemplary embodiment of the present disclosure. 5 will be described later with reference to FIGS. 4A and 4B.

Referring to FIG. 5 , journal stacks 120_0 to 120_2 may include transaction lists 130_0 to 130_2 , respectively. Due to the independent journal stack for each core, there may be a problem in that blocks to be committed together in the journal area of the storage device are distributed in different transactions. For example, in step S100 , block 4 may be changed by the first core CORE_1 and the second core CORE_2 . In order to ensure the consistency of the data included in block 4, it is required that the seventh transaction TX_7 of the first core CORE_1 and the second transaction TX_2 of the second core CORE_2 are recorded together in the storage device. can

The computing system according to an exemplary embodiment of the present disclosure may include transaction lists 130_0 to 130_2 to ensure file system consistency. Each of the transaction lists 130_0 to 130_2 may include a plurality of lists corresponding to the number of the plurality of cores CORE_0 to CORE_2 . For example, each of the transaction lists 130_0 to 130_2 may include three lists. Each of the transaction lists 130_0 to 130_2 may include information on a transaction to be committed together in a journal area of the storage device. For example, the transaction information may include the number of transactions of different cores, and may be referred to as a transaction mark.

In operation S140 , the first core CORE_1 may write data representing the second transaction TX_2 of the second core CORE_2 in the transaction list 130_1 . For example, the first core CORE_1 may write (2,2) in the transaction list 130_1. When a system crash occurs, the first core (CORE_1) checks the commit status of the second transaction (TX_2) of the second core (CORE_2), and restores block 4 when the commit is completed to file the changes in block 4 can be reflected in the system.

In operation S160 , the zeroth core CORE_0 may write (1,7) indicating the seventh transaction TX_7 of the first core CORE_1 in the transaction list 130_0. The first core CORE_1 may write (0,4) indicating the fourth transaction TX_4 of the zeroth core CORE_0 in the transaction list 130_1 . When a system crash occurs, the 0th core (CORE_0) checks the commit status of the 7th transaction (TX_7) of the 1st core (CORE_1), and reflects the changes in block 3 by restoring block 3 when the commit is completed can do. Meanwhile, the first core CORE_1 may reflect the change in block 3 by checking the commit state of the fourth transaction TX_4 of the 0th core CORE_0 and restoring the block 3 when the commit is completed.

In operation S180 , the zeroth core CORE_0 may write (1,7) indicating the first core CORE_1 and the seventh transaction TX_7 in the transaction list 130_0. The first core CORE_1 may write (0,4) indicating the zeroth core CORE_0 and the fourth transaction TX_4 in the transaction list 130_1 . When a system crash occurs, the 0th core (CORE_0) checks the commit status of the 7th transaction (TX_7) of the 1st core (CORE_1), and reflects the changes in block 3 by restoring block 3 when the commit is completed can do. Meanwhile, the first core CORE_1 may reflect the change in block 3 by checking the commit state of the fourth transaction TX_4 of the 0th core CORE_0 and restoring the block 3 when the commit is completed.

6 illustrates a journal area stored in a storage device according to an exemplary embodiment of the present disclosure.

Referring to FIG. 6 , when a system crash occurs, the file system may restore blocks recorded in the journal areas 162_0 to 162_2 to the data area. The storage device may further include a commit block CM in the journal areas 162_0 to 162_2. Each of the plurality of cores CORE_0 to CORE_2 may store a transaction mark (eg, (2,7)) and a timestamp (eg, TS_1 or TS_2) in the commit block CM when commit is performed. For example, the timestamp TS may be information indicating a commit time of a transaction.

In some embodiments, when a system crash occurs, the file system may identify a transaction in which a commit block (CM) is written as a target for recovery. For example, the commit block CM included in the eighth transaction TX_8 of the first core CORE_1 may include transaction marks 2 and 7 . The transaction marks 2 and 7 may indicate that the eighth transaction TX_8 of the first core CORE_1 and the seventh transaction TX_7 of the second core CORE_2 should be committed together in the data area. In the file system, as the commit block CM of the seventh transaction TX_7 of the second core CORE_2 is not recorded in the journal area 162_2 of the second core CORE_2, the first core CORE_1 8 The transaction (TX_8) may not be recovered.

In some embodiments, when a system crash occurs, the file system may identify a transaction to be restored based on a commit time of the transaction written in the timestamp. For example, block 1 (BH_1) may be overlapped in the journal area 162_1 of the first core CORE_1 and the journal area 162_2 of the second core CORE_2. After comparing the timestamp TS_1 corresponding to the seventh transaction TX_7 of the first core CORE_1 and the timestamp TS_2 corresponding to the sixth transaction TX_6 of the second core CORE_2, the file system compares , a transaction with a later commit time can be recovered as the last changed data.

7 illustrates a data recovery method in case of a system crash according to an exemplary embodiment of the present disclosure.

Referring to FIG. 7 , in step S200 , a system crash may occur in the computing system. For example, the journal area of the first core may include a transaction that has not yet been written to the data area due to a system crash. For example, the first transaction may be included in the journal area of the first core, and the first transaction may not be written to the data area due to a system crash.

In step S220, the first core may determine whether the commit block of the first transaction is written in the journal area. The first core may identify a transaction in which a commit block is written as a recovery target. In step S240, if the commit block of the first transaction is not written (S220-N), the first core may not write the first transaction to the data area.

In step S260, when the commit block of the first transaction is written in the journal area (S220-Y), the first core may identify the first transaction as a target of recovery and check the transaction mark in the commit block of the first transaction. . For example, the transaction mark in the commit block of the first transaction may include the second transaction (eg, (2,2)) of the second core.

In step S280, the first core may check whether the commit block of the second transaction included in the transaction mark is written in the journal area of the second core. In step S300, when the second transaction is not written to the data area (S280-N), the first core does not write the first transaction to the data area, thereby ensuring file system consistency.

In step S320, when the second transaction is written to the data area (S280-Y), the first core writes the first transaction to the data area, thereby ensuring file system consistency.

8 illustrates a checkpoint method according to an exemplary embodiment of the present disclosure.

Referring to FIG. 8 , in step S400 , a first core among a plurality of cores included in the computing system may complete a commit. For example, the first core may complete the commit of the first transaction. The first core may checkpoint the commit-completed transaction into the data area every predetermined time period defined in the computing system or when the capacity of the journal area of the first core is insufficient.

In step S420, the first core may check whether the commit block of the first transaction is written in the journal area in the journal area. The first core may identify a transaction in which a commit block is written as a target of a checkpoint. In step S440, when the commit block of the first transaction is not written (S420-N), the first core may not checkpoint the first transaction.

In step S460, when the commit block of the first transaction is written in the journal area (S420-Y), the first core may identify the first transaction as a target of recovery and check the transaction mark in the commit block of the first transaction . For example, the transaction mark in the commit block of the first transaction may include the second transaction (eg, (2,2)) of the second core.

In step S480 , the first core may check whether the commit block of the second transaction included in the transaction mark is written in the journal area of the second core. In step S500, when the second transaction is not written to the data area (S480-N), the first core does not checkpoint the first transaction, thereby ensuring file system consistency.

In step S520, when the second transaction is written in the data area (S480-Y), the first core may checkpoint the first transaction to ensure file system consistency. Accordingly, the computing system can guarantee the consistency of the file system with little overhead based on the transaction mark.

Exemplary embodiments have been disclosed in the drawings and specification as described above. Although the embodiments have been described using specific terms in the present specification, these are used only for the purpose of explaining the technical spirit of the present disclosure, and are not used to limit the meaning or the scope of the present disclosure described in the claims. . Therefore, it will be understood by those skilled in the art that various modifications and equivalent other embodiments are possible therefrom. The true technical protection scope of the present disclosure should be defined by the technical spirit of the appended claims.

Claims (10)

A computing system having a plurality of cores, comprising:
a memory configured to include a journal stack allocated to each of the plurality of cores; and
a storage device configured to include a journal area allocated to each of the plurality of cores;
A first core among the plurality of cores,
The block changed by the first core is merged in units of transactions, stored in a journal stack corresponding to the first core, and a commit is performed in a journal area corresponding to the first core in units of transactions. computing system with According to claim 1,
Each of the journal stacks allocated to the plurality of cores includes a plurality of lists respectively corresponding to the plurality of cores. According to claim 1,
The journal stack corresponding to the first core includes a first transaction in a running state,
When a second transaction of a second core among the plurality of cores changes a block included in the first transaction, the first core lists information on the second transaction of the second core in a list corresponding to the second core , and the second core stores the information of the first transaction of the first core in a list corresponding to the first core. According to claim 1,
The journal stack corresponding to the first core includes a first transaction composed of an original block,
The first core copies the original block included in the first transaction, and commits the copied block to the journal area. 5. The method of claim 4,
When a second transaction of a second core among the plurality of cores changes an original block included in the first transaction, the second core adds the first transaction information of the first core to a list corresponding to the first core Computing system characterized in that it stores. 6. The method of claim 5,
The second core is
and maintaining the copied block in the first transaction, and inserting the original block changed by the second core into the second transaction. According to claim 1,
The first core includes a commit block in the journal area,
Computing system, characterized in that when the commit is performed, a transaction mark including transaction information of a second core that changes the changed block is recorded. 8. The method of claim 7,
The commit block is
Computing system, characterized in that it further includes information indicating when the commit is performed by the first core. 8. The method of claim 7,
The first core is
and performing data recovery based on the transaction mark when a crash occurs in the computing system. 8. The method of claim 7,
The storage device further comprises a data area,
The first core is
and when a commit is completed, checkpointing is performed on the data area of the storage device based on the transaction mark.

Images