FSCK and Journaling

FSCK와 Journaling은 모두 Crash Consistency문제를 해결하기 위한 방법입니다.

Crash Consistency 문제란 뭘까요?

 

• 많은 Data Structure과는 다르게, File system의 Data Structure은 무조건 안정되어야합니다.
• File System을 crash-consistency problem을 피하면서 안정시키는 것입니다.
• 즉 그러니 쓰다가 전원이 나가거나 해도 File System이 보존되어야 하는것이죠.

Crash Consistency Problem이 어떻게 발생할지 어떤 경우에 발생할지 한번 볼까요?

저희가 파일을 쓰게 되면 Data Bitmap, Inode, Data Block에 정보를 써 주어야 합니다.

 

하지만 이것은 동시에 일어나는 동작이 아니라 Page Cache나 Buffer Cache에 저장되어 있다가 동작합니다.

그러니 file system이 inconsistent한 state에 자주 놓인다는 의미이죠.

 

그럼 여기서 Crash Scenario를 한번 보도록 할까요?

 

• 한개를 쓰다가 Crash가 날 경우
  • Case 1a: Db만 썼을 경우
    • inode도 없고 아무것도 없는 dummy data가 됩니다.
    • 한번도 쓰지 않았던 것과 같은 상태이기에, consistency의 문제가 없습니다.
  • Case 1b: inode만 썼을 경우
    • inode에 주소는 업데이트 했는데 거기에 있는 데이터는 garbage data가 됩니다. 고로 File system Incosistency가 일어납니다.
  • Case 1c: bitmap만 썼을 경우
    • Space leak이 일어납니다. 즉, point해 줄 inode가 없어 free도 되지 않고 access도 되지 않지만 그 누구도 data를 그곳에 쓸 수 없습니다. 고로 이 경우도 file system inconsistency 입니다.
• 두개를 쓰다가 Crash가 날 경우
  • Case 2a: inode와 bitmap만 썼을 경우
    • 문제가 없습니다.
  • Case 2b: inode와 datablock만 썼을경우
    • bitmap이 없기 때문에 언제던지 그 위치에 다른 file이 덮어써질 수 있습니다. 즉 Inconsistency가 발생합니다.
  • Case 2c: bitmap과 datablock만 썼을 경우
    • bitmap만 쓴 경우와 같습니다. = case 1c.

왜 이런 문제가 일어날까요? file system을 atomically하게 작성하지 않기 때문입니다. 하지만 우리는 atomically하게 작성을 할 수 없죠. Disk가 한번에 한 번만 write하는 것을 허용하기 때문입니다.

 

그래서 이것을 해결하기 위해 fsck를 사용합니다. fsck는 언제 실행되냐면, file system이 Mount 될때 실행됩니다. 

fsck는 file system checker로 모든 free block, inode , bitmap을 check합니다.

• Inode state
  • 각 inode는 corruption 되어 있거나 다른 문제가 있는지 Check됩니다.
    • 예를들어 type Check 등이 있습니다.
  • 만약 문제가 있으면 고치기 어렵기 때문에 그냥 suspect로 지정하여 clear시켜 줍니다.
• Free blocks
  • fsck가 inode를 scan하여 map된 block을 전부 조회하고 만약 bitmap과 inode와 consistency가 없을경우 고쳐줍니다. inode를 믿는 방향으로 고치기 때문에 Case 1c와 2b만 고칠 수 있습니다.
• Directory checks
  • Directory는 특정한 file system에 의해 특정한 foramt으로 만들어집니다.
    • fsck는 user file에 어떤 content를 집어 넣을지는 모릅니다.
  • 고로 file system content와 directory간의 integerity check만 합니다.
    • 예를 들어, Directory안에 .과 ..이 올바르게 들어가 있는지. 각 directory entry안에 있는 inode가 allocate되어 있는지.

다만, file system checker는 모든 문제를 고치는 만능 도구는 아닙니다. 예를 들어 case 2a의 경우 metadata는 일치하기 때문에 internally consistent 합니다.

 

fsck를 빌드하려면 파일 시스템에 대한 많은 지식이 필요합니다.

그리고 또, fsck는 크고 중요한 문제가 있습니다, 일단 너무 느리고 전체 디스크를 Scan하는것은 많은 minute과 hour를 필요로 합니다. 이 말은 fsck의 performance는 어마어마하게 비싸 Overhead를 심각하게 일으킨다는 뜻입니다.

 

그래서 fsck 대신 Journaling (WAL: Write Ahead Logging)이라는 방법을 대신 사용합니다.

 

• Structure를 쓰기전에 내가 무엇을 쓰는건지 알려주는 little note를 먼저 씁니다.
• 이 Note를 write하는 것은 "write ahead" part라고 부르고, structure를 쓰는건 "log"라고 부릅니다.
• 만약 crash가 발생하면 note로 돌아가서 확인할 수 있습니다.
• 즉 무엇을 고칠지를 전체 데이터를 스캔하는것보다 훨씬 효율적으로 알 수 있다는 의미입니다.

Journaling 은 Ext2에서는 지원되지 않고 Ext3에서는 Journaling을 지원합니다.

 

구체적으로는 다음과 같습니다.

 

• Journal Write
  • Journal즉 Log를 먼저 남깁니다. 이 Log에는 pending될 Data와 Txb, TIB가 포함됩니다.
• Journal Commit
  • Journal 을 write했으면 transaction commit block을 써서 제대로 써져있는지 확인시켜줍니다. (TxE)
• Checkpoint
  • 이 Transaction을 쓰는 Journal write이 끝나면 이제 Structure를 업데이트 해 줍니다. 
• Free
  • Transaction을 free해 줍니다. (Journal Superblock을 사용)