[OS] 파일시스템의 consistency(일관성)를 위한 FSCK, Journaling - OS 공부 30

안녕하세요 Pingu입니다!🐧

 

지난 글에서는 FFS(Fast File System)에 대해 알아보며 파일 시스템의 성능을 어떻게 좋게 만들지에 대해 알아봤었는데요, 이번 글에서는 파일 시스템의 신뢰성을 위한 FSCK(File System ChecK)와 journaling에 대해 알아보려고 합니다. 제가 공부할 때 참고하고 있는 책인 OSTEP에서는 Chapter 42 - FSCK And Journaling 부분입니다!

Crash Consistency: FSCK and Journaling

지금까지 알아본 파일 시스템은 추상화를 지원하기 위해 파일, 디렉터리, 이들의 정보를 담은 메타 데이터로 구성된다고 배웠습니다. 메모리와는 다르게 디스크나 SSD와 같은 저장 장치는 전원이 차단된 상태에서도 데이터를 유지할 수 있어야 하는데요, 만약 파일 시스템의 데이터가 정전이나 오류로 인해 손상된다면 어떻게 될까요? 아마도 데이터가 날아가서 마음이 아플 수도 있고 중요한 데이터라면 큰 문제가 발생할 수도 있습니다. 또한 consistency (일관성) 문제로 알려진 문제가 발생한다면 이는 큰 문제가 될 수 있습니다.

 

일관성 문제를 잠깐 짚고 넘어가자면, 두 개의 디스크(A, B 디스크)가 있고 두 개의 디스크에 쓰기 작업을 해야하는 작업이 있다고 가정해보겠습니다. A 디스크에 쓰기 작업을 하고 B에 하려는데 정전이 된다면 B 디스크에는 올바른 정보가 존재하지 않게 되고 이러한 문제를 일관성 문제라고 합니다. 이번 글에서는 이러한 문제들을 해결하기 위한 FSCK, Journaling에 대해 알아보려고 합니다.

A Detailed Example

그럼 해결해야되는 문제인 일관성 문제에 대한 좀 더 자세한 예를 보며 어떤 문제가 발생하는지 살펴보도록 하겠습니다. 하나의 데이터 블록을 기존 파일에 추가하는 작업을 한다고 가정해보겠습니다. 이를 위해서는 lseek()로 파일의 끝으로 이동한 뒤 거기서부터 데이터 블록의 크기만큼 쓰기 작업을 해주면 됩니다. 여기서는 데이터 블록의 크기를 4KB라고 가정하겠습니다. 또한 지난 글들에서 알아본 대로 inode bitmap, data bitmap, inode, 데이터 블록으로 구성된 디스크에 이러한 쓰기 작업을 한다고 해보겠습니다.

그럼 처음에는 위와 같이 파일이 존재하고 있을거에요. 하나의 데이터 블록이 사용 중이고 이를 위한 inode, 그리고 사용 중인 inode, data 블록을 나타내는 bitmap이 있는 것을 볼 수 있습니다. inode [V1]을 자세히 살펴보면 아래와 같습니다.

위의 구조에서 size는 데이터 블록의 크기를 뜻합니다. 그리고 pointer는 direct pointer로 보이네요. 어쨌든 위와 같이 존재하는 파일에 데이터 블록 하나만큼 쓰기 작업을 해줘야 할 때 어떤 것들을 해줘야 할까요? 일단 파일의 정보가 달라질 것이므로 inode를 수정해야 됩니다. 당연하게도 데이터 블록도 하나 써줘야겠죠? 그리고 새로운 데이터 블록의 사용 정보를 bitmap에도 적용해줘야 합니다. 즉 3개의 부분을 수정해줘야 하는 것이죠. 일단 비트맵부터 수정해보겠습니다.

모든 작업을 성공적으로 하게 되면 위와 같이 디스크가 수정될거에요. 이러한 디스크로 수정되기 위해서는 3번의 쓰기 작업이 수행되어야 합니다. 그리고 이전에 알아본 대로 저희는 이러한 쓰기 작업은 디스크가 너무 느리기 때문에 쓰기 작업이 발생할 때마다 쓰는 것이 아닌 어느 정도 쓰기 작업을 모은 뒤 수행한다는 것을 알고 있습니다. 그런데 이렇게 쓰기 작업을 바로바로 하지 않기 때문에 뭔가 시스템적으로나 정전과 같은 문제가 발생하게 된다면 파일 시스템은 이상한 상태가 될 수 있습니다.

Crash Scenarios

그럼 문제가 발생할 수 있는 경우의 수를 한 번 살펴보겠습니다.

• 데이터 블록에만 작업이 완료된 경우가 있을 수 있습니다. 이러한 경우엔 inode에 새로운 파일에 대한 정보도 없고 비트맵에도 없기 때문에 헛수고를 한 것이라고 할 수 있습니다. 즉 쓰기는 했지만 그러한 사실을 아무도 모르는 것이죠. 이러한 상태는 파일 시스템의 일관성을 해치지는 않습니다.
• inode에만 작업이 완료된 경우가 있을 수 있습니다. 이 경우 inode에는 새로운 파일에 대한 정보, 즉 pointer를 통해 새로운 디스크 블록을 가리키지만 해당 위치에 존재하는 디스크 블록에는 원하는 데이터가 없는 garbage data를 읽게 됩니다. 또한 쓰지도 않는 디스크 블록을 쓰고 있다고 inode에는 저장되어있기 때문에 데이터 비트맵과 정보가 inconsistency(불일치)하게 됩니다. 
• Bitmap에만 작업이 완료된 경우도 있을 수 있겠죠? 이 경우에는 bitmap에서는 데이터 블록을 할당했다고 되어있는데 이를 가리키는 inode가 없게 되며 이는 또다시 파일 시스템의 일관성을 해치게 됩니다. 이렇게 되면 사용하지도 않는 블록을 사용중이라고 표현하기 때문에 space leak(공간 낭비)를 발생합니다.

이렇게 하나의 작업만 완료될 수도 있지만 두 개의 작업만 완료되는 경우의 수도 있습니다.

• Inode, bitmap에만 작업이 완료된 경우를 살펴보겠습니다. 이 경우 메타 데이터는 일관성을 유지합니다. 하지만 data 블록에 원하는 데이터가 존재하지 않고 garbage data가 존재하게 됩니다.
• inode, 데이터 블록에만 작업이 완료된 경우는 어떨까요? 이젠 어떤 문제가 발생하는지 짐작할 수 있을거에요. 이 때는 bitmap과 inode의 정보가 불일치하는 문제가 발생하게 됩니다.
• bitmap, 데이터 블록에만 작업이 완료되는 경우에도 bitmap, inode의 정보가 불일치 하며 inode가 파일을 가리키지 않기 때문에 어떤 파일인지 알 수도 없습니다.

The Crash Consistency Problem

위와 같이 6개의 경우에서 문제가 발생할 수 있고 발생한 문제는 space leak, inconsistency, garbage data 였습니다. 이를 해결하기 위해서는 파일에 어떤 작업을 할 때 모든 필요한 작업을 원자적으로 수행해야 합니다. 하지만 디스크는 한 번에 하나의 쓰기만 수행하고 여러 개의 쓰기 사이에 문제가 발생할 수 있기 때문에 해결이 쉽진 않습니다. 그리고 지금 발생하는 이러한 문제를 crash consistency problem(충돌 일관성 문제)이라고 합니다.

Solution #1: The File System Checker

초창기 파일 시스템은 충돌 일관성 문제를 해결하기 위해 간단한 방법을 사용했습니다. 기본적으로 불일치가 발생하더라도 일단 고치지 않고 나중에 수정하는 것이죠. 이러한 방법을 FSCK라고 합니다. FSCK는 디스크에서 불일치가 발생한 부분을 찾고 이를 고치는 UNIX 도구인데요, FSCK로는 모든 문제를 해결할 수는 없습니다. 예를 들어 파일 시스템이 정상으로 보이지만 inode가 garbage data를 가리키는 경우를 아까 본 적이 있습니다. 즉 FSCK는 메타 데이터의 일관성만을 고칠 수 있는 것이죠. 그럼 FSCK가 어떻게 일관성을 유지하는지 순서대로 살펴보도록 하겠습니다.

• Superblock : FSCK는 슈퍼블록이 정상인지 부터 확인합니다. 파일 시스템의 크기가 할당된 블록 수 보다 큰지 확인하고 만약 뭔가 문제가 있다면 슈퍼 블록의 사본으로 교체합니다.
• Free Blocks : 슈퍼 블록을 본 뒤 FSCK는 inode, indirect block, direct block 들을 스캔하여 현재 파일 시스템에 할당된 블록을 파악합니다. 이 정보를 사용하여 알맞은 비트맵도 생성하게 되며 이를 통해 비트맵과 inode의 불일치를 inode의 정보를 기반으로 해결하게 됩니다. 
• node state : 각각의 inode 마다 손상이 있는지 확인합니다. 예를 들어 FSCK는 할당된 inode에 유효한 필드가 있는지 확인합니다. inode 필드에 뭔가 문제가 있다면 fsck는 이를 삭제해버립니다. 또한 삭제되었다는 정보를 inode 비트맵에도 업데이트합니다.
• inode link : FSCK는 할당된 inode의 링크 수를 확인합니다. 링크수는 특정 파일에 대한 참조를 포함하는 다른 디렉터리의 수를 나타낸다고 예전에 알아봤었는데요 이러한 링크 수를 확인하기 위해 FSCK는 루트 디렉터리부터 시작하여 모든 디렉터리를 검색하고 모든 파일, 디렉터리에 대한 링크수를 만듭니다. 이렇게 만든 링크수와 기존에 존재하던 링크수가 다르다면 수정해주는 방식으로 일관성을 유지합니다.
• Duplicate (중복) : FSCK는 중복 포인터를 검사합니다. 서로 다른 inode가 동일한 블록을 참조하는 경우 둘 중 하나를 삭제하거나 사본을 만들어 각각의 inode에게 고유한 데이터 블록을 할당해줍니다.
• Bad Block : 모든 포인터 블록을 검색하는 동안 불량 포인터 블록이 있는지도 확인합니다. 포인터가 이상한 곳을 가리킨다면 이상하다고 간주하여 inode의 포인터를 그냥 삭제해버립니다. 
• Directory Check : FSCK는 파일의 내용은 이해하지 못하지만 디렉토리의 정보는 이해할 수 있습니다. 이를 사용해 FSCK는 디렉터리의 내용에 대한 무결성 검사를 하고 하나의 디렉터리에 대해 두 번 이상 링크되지 않도록 만듭니다.

위와 같이 FSCK는 여러 작업을 통해 일관성 문제를 해결하는데요, 진행하는 일 중에 루트 디렉토리부터 시작하여 모든 디렉터리를 탐색하는 작업과 같이 한눈에 봐도 오래 걸리는 작업이 여럿 존재합니다. 즉 너무 느리다는 문제가 존재하는 것이죠. 또한 하나의 파일만 비정상인데 이를 수정하기 위해서 파일 시스템에 존재하는 모든 파일을 봐야 하는 배보다 배꼽이 더 큰 문제가 발생할 수 도 있습니다. 따라서 이러한 FSCK보다는 다른 방법을 찾아야만 했고 그중 하나가 Journaling입니다.

Solution #2: Journaling (or Write-Ahead Logging)

Journaling은 데이터 베이스 관리 시스템에서 아이디어를 가지고 온 것으로 write ahead logging으로 알려진 방법에서 가져온 아이디어로   일관성 문제를 해결할 수 있습니다. Journaling의 아이디어는 간단합니다. 디스크를 업데이트할 때 디스크의 구조를 변경하기 전에 수행할 작업을 잘 알려진 위치에 써두는 것입니다. 이러한 정보를 쓰는 것이 write ahead 부분이며 이를 log로 구성된 구조에 작성합니다. 따라서 저널링을 Write-Ahead Logging 방법이라고 할 수 있는 것이죠.

 

수행할 작업을 잘 알려진 공간에 써두었기 때문에 디스크에 실제 작업을 하다가 충돌이 발생하여 중단되더라도 수행할 작업을 적어둔 곳에 가서 다시 뭘 할지 본 뒤 수행할 수 있습니다. 그럼 실제 Linux EXT3 파일 시스템에서 저널링을 사용하는 예를 보며 저널링을 살펴보겠습니다. EXT3는 EXT2에서 저널링 기능만 추가된 파일 시스템인데요, EXT2의 경우엔 지금까지 알아본 파일 시스템의 구조처럼 디스크를 그룹으로 나누고 각 그룹에는 비트맵, inode, 데이터 블록으로 구성됩니다. 또한 파일 시스템에 대한 정보인 슈퍼 블록도 가지고 있죠. 이를 다시 보면 아래와 같습니다.

근데 이제 저널링을 사용할 것이고 아까 말했듯이 수행할 작업을 잘 알려진 공간에 써둔다고 했으니 디스크에 저널링을 위한 잘 알려진 공간을 하나 만들면 EXT3 파일시스템의 구조를 만들 수 있습니다.

그럼 지금부터 저널링의 동작 방식을 살펴보도록 하겠습니다.

Data Journaling

먼저 디스크 업데이트에 필요한 모든 정보를 저널 공간에 기록하는 Data Journaling부터 살펴보도록 하겠습니다. 데이터 저널링의 동작 방식을 알아보기 위해 간단한 예를 살펴볼게요.

아까 잘 알려진 저널 공간은 위와 같은 구조의 데이터가 쓰이게 됩니다. TxB는 수행할 작업 정보가 시작된다는 의미를 가지며 수행할 작업 정보에는 inode, bitmap, 데이터 블록에 대한 업데이트 정보가 포함됩니다. 이렇게 모든 정보가 포함된 뒤에는 TxE가 있고 이는 수행할 작업 정보의 끝을 나타내게 됩니다. 이렇게 5개의 정보가 모두 있어야 파일 시스템에 작업을 수행할 준비가 된 것이라고 간주하며 이러한 과정을 checkpoint(체크 포인트)라고 합니다. 위의 과정을 정리하면 아래와 같아요.

1. Journal write : 트랜잭션 시작 블록(TxB), 업데이트할 데이터 정보 (inode, bitmap, datablock), 트랜잭션 종료 블록(TxE)을 저널 공간에 기록합니다.
2. Checkpoint : 저널 공간에 있는 정보로 디스크를 업데이트합니다. 

즉 먼저 저널 공간에 수행해야 될 작업에 대한 정보를 쓰고 실제 디스크 위치로 이동하여 이를 수행하는 것이죠. 결과적으로는 동일한 일을 2번 한다고 볼 수 있습니다. 이러한 과정 중에 오류가 발생해도 별 일 없이 넘어가려면 어떻게 해줘야 할까요? 일단 간단한 방법으로 저널 공간에 수행할 작업에 대한 정보를 쓸 때 TxB, Inode, Bitmap, Datablock, TxE에 대한 정보를 하나씩 써주는 방법이 있습니다. 하나씩 완료될 때까지 기다리는 방법인데 너무 느리다는 단점이 있습니다. 따라서 5개의 블록을 한 번에 써주는 것이 빠를 것 같은데요, 5개를 한 번에 쓰려다 보면 쓰는 도중 문제가 발생하여 아래와 같이 디스크가 구성될 수도 있습니다.

위와 같이 데이터 블록에 대한 정보가 없는 채로 디스크에 저장이 될 수도 있는 것이죠. 위와 같이 저장된다면 garbage data 문제가 발생하게 됩니다. 따라서 속도도 챙기고 이러한 문제를 해결하기 위해서 끝을 나타내는 TxE 블록을 제외한 블록을 한 번에 쓰고 그 뒤에 TxE 블록을 써서 트랜잭션을 완성하는 방법을 사용합니다.

즉 위와 같이 TxB, inode, bitmap, datablock을 모두 쓴 뒤

TxE 블록을 써줘서 트랜잭션을 완성하게 됩니다.

 

이러한 방법으로 트랜잭션을 저널 공간에 작성하게 되면 원자성을 보장할 수 있게 됩니다. 지금까지 알아본 방법을 순서대로 정리하면 아래와 같아집니다.

1. Journal Write : 저널 공간에 트랜잭션 내용을 작성하는 과정
2. Journal Commit : 트랜잭션 내용을 다 작성한 뒤 TxE 블록을 추가하는 과정
3. Checkpoing : 저널 공간의 정보로 실제 디스크를 업데이트하는 과정

Recovery

그럼 이번엔 방금 알아본 대로 3단계에 걸쳐서 디스크를 업데이트하는 과정 중에 문제가 발생했을 때 이를 복구하는 방법을 알아보도록 하겠습니다. 저널 공간에 트랜잭션이 모두 쓰이기 전에 충돌이 발생한다면 그냥 그 작업을 안 하면 됩니다.(undo) 혹은 트랜잭션을 저널 공간에 쓰는 것을 완료하고 checkpoint 단계를 수행하다가 문제가 발생하면 저널 공간에 기록된 정보로 작업을 다시 시도하면 됩니다. (redo) 여기서 생길 수 있는 의문은 이런 식으로 자꾸 작업을 재시도하게 되면 성능 저하가 발생할 수 있지 않느냐? 는 것인데 실제로 문제는 거의 발생하지 않기 때문에 성능에는 큰 영향을 주지 않습니다.

Batching Log Updates

이러한 저널링 방법은 디스크에 바로 작업을 하는 것보다 저널 공간에 추가로 작업을 해줘야 하기 때문에 성능이 나빠지는 것을 알 수 있습니다. 예를 들어 file1, file2라는 2개의 파일을 동일한 디렉터리에 연속적으로 생성하는 작업을 수행할 때 두 파일에 대해 각각 저널링을 처리해줘야합니다. 이 때 두 파일은 동일한 디렉토리에 생성하기 때문에 같은 inode 블록을 수정하게 되고 이는 동일한 블록을 여러 번 수정하게 되는 문제를 발생하게 됩니다.

 

이러한 문제를 해결하기 위해 어떤 파일 시스템은 업데이트를 한 번에 하나씩 디스크에 커밋하는 것이 아니라 모든 업데이트를 전역 트랜잭션으로 버퍼링 할 수 있습니다. 즉 업데이트 내용을 어느 정도 모았다가 한 번에 처리하는 방법인데요, 이는 동일한 블록을 한 번만 업데이트하도록 만들어 쓰기 작업의 수를 줄일 수 있습니다.

Making The Log Finite

지금까지 알아본 방법을 사용하여 디스크 업데이트를 할 수 있는데요, 업데이트가 끝난 뒤 해당 업데이트에 대한 정보를 저널 공간에 계속 유지해야 할까요? 저널 공간도 디스크에 존재하는 유한한 공간이기 때문에 업데이트가 성공했다면 저널 공간에서 해당 트랜잭션을 제거해줘야 합니다.

 

만약 트랜잭션을 제거하지 않는다면 디스크 업데이트 도중 문제가 발생하여 복구작업을 수행할 때 시간도 더 오래 걸릴 뿐만 아니라 저널 공간이 가득 차서 더 이상 업데이트를 하지 못하는 상황이 발생할 수 있습니다. 따라서 저널링을 사용하는 파일 시스템은 이를 재사용해야 하고 이러한 이유 때문에 저널링을 cirular log라고도 합니다. 파일 시스템은 checkpoint가 된 후 해당 트랜잭션을 저널 공간에서 제거합니다. 어떤 트랜잭션을 제거할지에 대한 정보를 journal superblock에 저장하는데요 따라서 저널 공간이 아래와 같아집니다.

위와 같이 journal super block을 만들어 어떤 트랜잭션이 가장 오래되었는지, checkpoint 되지 않은 트랜잭션이 무엇인지를 나타낼 수 있습니다. 이러한 과정을 추가하게 되면 프로토콜의 단계가 아래와 같이 하나 추가됩니다.

1. Journal Write : 저널 공간에 트랜잭션 내용을 작성하는 과정
2. Journal Commit : 트랜잭션 내용을 다 작성한 뒤 TxE 블록을 추가하는 과정
3. Checkpoing : 저널 공간의 정보로 실제 디스크를 업데이트하는 과정
4. Free : 완료된 트랜잭션을 저널 공간에서 제거합니다.

지금까지 알아본 저널링은 결과적으로 모든 데이터를 두 번씩 쓰는 비효율적인 작업입니다. 데이터를 두 번 쓰지 않고 저널링을 사용하여 일관성을 유지하는 방법에는 어떤 방법이 있을까요?

Metadata Journling

지금까지 알아본 데이터 저널링은 안전하긴 하지만 같은 작업을 2번 해야 하기 때문에 성능이 나쁜데요, 성능을 높이기 위한 방법으로 메타 데이터만 저널링하는 방법이 있습니다. 이러한 것을 ordered journaling(혹은 metadata journaling)이라고 하며 데이터 블록을 저널 공간에 쓰지 않는다는 점만 빼면 지금까지 알아본 데이터 저널링과 동일합니다.

즉 위와 같이 트랜잭션을 쓸 때 데이터 블록을 제외하고 작성하게 되는 것이죠. 이렇게 하면 빨라질 거 같긴 한데... 그럼 데이터 블록은 언제 디스크에 써야 할까요? 글의 초반에 inode, bitmap, 데이터 블록 중 하나라도 안 썼을 때 발생하는 문제를 알아봤었는데 기억하시나요? 여러 경우의 수 중에 데이터 블록만 쓰인 경우는 디스크 일관성에 영향을 주지 않고 디스크에 쓰기 한 시간이 아까운 상황만 발생했었습니다. 저널링을 사용하는 이유가 디스크의 일관성을 유지하기 위함이기 때문에 데이터 일관성에 영향을 주는 inode, bitmap를 항상 데이터 블록보다 나중에 처리해주면 데이터 일관성에 문제가 발생하는 일은 없게 되는 것이죠.

 

즉 항상 데이터 블록을 디스크에 먼저 쓴 뒤 inode, bitmap을 디스크에 쓰게 되면 데이터 블록만 쓰이더라도 문제가 발생하지 않고 데이터 블록이 쓰인 뒤 inode, bitmap을 쓰다가 문제가 발생해도 해당 정보는 저널 공간에 저장되어 있으므로 복구를 할 수 있게 됩니다. 이렇게 데이터를 쓰는 순서를 지켜주는 방법이기 때문에 ordered journaling이라고 하는 것입니다.

 

따라서 ordered journaling 방법으로 디스크를 업데이트하는 과정은 아래와 같습니다.

1. 데이터 블록 쓰기 : 디스크에 데이터 블록을 씁니다
2. journal metadata write : 저널 공간에 메타 데이터 정보를 씁니다.
3. journal commit : 트랜잭션에 TxE를 추가합니다.
4. checkpoint metadata : 메타데이터를 디스크에 씁니다.
5. free : 트랜잭션을 디스크에서 제거합니다.

Wrapping Up Journaling: A Timeline

그럼 지금까지 알아본 저널링을 타임라인으로 정리해보도록 하겠습니다. 데이터 저널링과 메타 데이터 저널링이라는 두 가지 방법을 알아봤으니 타임 라인도 두 가지를 보도록 할게요!

위의 그림은 데이터 저널링 타임라인입니다. 알아본 대로 journaling -> commit -> checkpoint 순서로 수행되며 다한 뒤에 저널 공간에서 트랜잭션을 제거하는 작업도 있지만 위에는 생략되어있네요.

위의 그림은 메타데이터 저널링 타임라인입니다. ordered journaling이라고도 했었죠? 알아본 대로 데이터 블록을 디스크에 쓰고 메타 데이터를 저널링 한 뒤 commit을 하고 메타 데이터 checkpoint 순서로 진행하게 됩니다.

Solution #3: Other Approaches

이렇게 journaling과 FSCK를 통해 파일 시스템의 메타 데이터 일관성을 유지하는 방법을 살펴봤습니다. 물론 이 두 개의 방법이 일관성 문제를 해결하는 유일한 방법은 아닙니다. Soft Updates로 알려진 방법은 디스크 구조가 불일치 상태로 남아있지 않도록 모든 시스템에 대한 쓰기를 신중하게 지시합니다. 예를 들어 어떤 데이터 블록에 대한 inode를 업데이트하기 전에 해당 데이터 블록을 반드시 먼저 써줘서 garbage data 문제가 발생하지 않도록 할 수 있습니다. 하지만 soft update는 파일 시스템 데이터 구조에 대한 지식이 필요하고 이는 시스템에 복잡성을 주기 때문에 쉽게 구현하기 어렵습니다.

 

또 다른 방법은 copy-on-write(COW)입니다. COW는 파일이나 디렉터리를 절대 덮어쓰지 않으며 디스크에서 이전에 사용되지 않은 위치에 새 업데이트를 배치합니다. 여러 업데이트가 끝난 뒤 COW 파일 시스템은 새로 업데이트된 구조에 대한 포인터를 포함하도록 파일 시스템의 루트 구조를 뒤집습니다. 이렇게 하면 파일 시스템의 일관성을 간단하게 유지할 수 있다고 합니다. 다음 글에서 알아볼 log-structruced file system(LFS)에서 COW에 대해 자세히 알아보도록 하겠습니다.

 

또 다른 방법은 backpointer based consistency입니다. 이 방법은 일관성을 유지하기 위해 모든 블록에 백 포인터가 추가됩니다. 예를 들어 각 데이터 블록에 inode에 대한 참조가 있는 것이죠. 지금까지는 inode에서만 파일을 찾아갈 수 있었는데 이 방법을 사용하면 파일에서도 inode를 찾아갈 수 있게 됩니다. 이를 통해 일관성을 유지할 수 있습니다. 

Summary

이번 글에서는 디스크 업데이트 중에 발생하는 crash consistency 문제를 해결하기 위한 방법인 FSCK, Journaling, 그리고 그 외의 몇 가지 방법들에 대해 알아봤습니다. FSCK는 너무 느리기 때문에 journaling을 주로 사용하게 되었고 저널링에는 데이터 저널링, 메타 데이터 저널링이 있었습니다. 이러한 방법을 사용하여 디스크 일관성을 지켜줄 수 있었습니다. 다음 글에서는 Log Structured File System(LFS)에 대해 알아보도록 하겠습니다.

 

감사합니다!