[운영체제] FSCK and Journaling

FSCK and Journaling

만약 write operation 도중 system 에 crash 혹은 power lose 이 발생했을 때, File system inconsistency 혹은 data 손실에 대한 문제점이 발생할 수 있습니다. 이러한 문제에 대한 해결책으로 File system checher , journaling 을 살펴보도록 하겠습니다

Crash Cases

Crash with only a single write succeeds

• data block is written to disk
  • file 을 읽는 것에는 문제가 되지 않습니다.
• just updated inode
  • File-system-inconsistency 발생
• just updated bitmap
  • File-system-inconsistency 발생

Crash with only two write succeeds

• inode and bitmap are written
  • 보기에는 File system 에 문제가 없어보이지만, Data block 이 쓰레기값을 갖습니다.
• inode and data block are written
  • File-system-inconsistency 발생
• bitmap and data block are written
  • File-system-inconsistency 발생

FSCK

file system 의 일부가 아닌, File-system-inconsistency 를 해결하기 위한 도구입니다. data 를 복원하는 등의 모든 문제를 해결할 순 없지만 file system 을 consistent 하게 해주는 정도를 도와주게 됩니다.

• Superblock 이 reasonable 한지 check 합니다.
• Free blocks
  • inodes, indirect blocks 등을 scan 합니다.
  • bitmap 과 비교하고, inconsistency 가 발견된다면 수정합니다.
• inode state
  • inode 의 값들이 valid 한지 확인합니다.
  • 문제점이 발견된다면 해당 inode 와 bitmap 을 삭제합니다.
• inode links
  • reference count 가 맞는지 확인합니다.
• Duplicate
  • 같은 block 을 가리키는 inode pointer 가 발견된다면, bad inode 를 제거하거나 block 을 copy 합니다.
• Bad block pointers
  • 만약 pointer 가 partition 을 벗어나는 datablock 을 가리킨다면 pointer 를 초기화 합니다.
• Directory checks
  • Directory 들을 잘 포함하고 있는지 inode 와 file name 쌍이 잘 존재하는지 확인합니다.

Drawbacks of FSCK

• Too slow
• Works but is wasteful

Journaling

Disk의 내용을 update 하기 전에 일종의 노트(기록)을 남겨두는 작업입니다. 실제로 update 작업인 checkpointing 전에 journaling 을 우선적으로 수행합니다.

On disk structure

• disk 를 block groups 로 나눕니다.
• 각각의 block group 에는 inode bitmap, data bitmap, inodes, data blocks 들을 포함합니다
• journal group 은 TxB(ID) bitmap inode datablock TxE(ID) 를 포함합니다.
• TxB(ID) 와 TxE(ID) 는 jornal group 을 표시하기 위하여 사용되고 고유한 ID 를 갖습니다.

Writing the journal

CPU 자원을 낭비시키거나, journal 을 쓰는 중 crash 가 발생하여 jounal 자체에도 문제가 생길 수 있는 문제점이 있기 때문에, Two steps 을 따라가며 journal 을 write 합니다.

• step 1
  • Data block 부분까지만 write 합니다.
• step 2
  • step 1 이 끝나면 txE(ID) 를 write 합니다.

Recovery

• 만약 journal 에 transaction 이 완전히 쓰이기 전에 crash 가 발생한다면
  • 해당 update 를 무시합니다.
• 만약 journal 이 제대로 쓰이고 checkpointing 이전에 crash 가 발생한다면
  • 해당 journal 을 통하여 복구합니다.
  • 복구는 가능하지만, 이미 checkpointing 한 영역에 대하여도 recovery 가 발생하면서 성능이 저하되는 문제점이 있습니다.

Batching Log Updates

• Problem
  • extra disk traffic 증가의 문제점이 있습니다.
  • ex) 같은 directory 에 대해 inode 가 같은 두개의 file 이 생성될 수 있습니다.
• Solution
  • 해결책으로 Buffering updates 가 있습니다.
  • File system buffer는 동일한 block 에 대해 update 하려는 시도가 연속적으로 발생하면 buffering 하여 한번에 write 합니다.

Making the Log Finite

• Problem
  • journal 영역이 커질수록 recovery 시간이 더 오래 걸리게 됩니다.
  • journal 들의 반영 여부를 알 수 잆기 때문입니다.
  • journal size 를 줄이게 되면 journal 유실이 발생할 수 있습니다.
• Solution
  • circular 한 log 즉 journal 구조를 사용합니다.
  • Journal 안에 journal superblock 을 두어 Transaction 의 반영 시기를 관리합니다.
  • 다 update 된 journal 은 circular 하게 재사용 가능합니다.

Ordered Journaling (= Metadata Journaling)

• Problem (Data journaling)
  • Data block 의 부분이 가장 크므로 해당 부분의 write 횟수를 줄여야 합니다.
• Solution (Metadata journaling)
  • 실제 data 내용이 아닌 inode 와 bitmap 의 정보만 journal 에 포함시킵니다.
  • Data block 을 journaling 하기전에 우선적으로 write 시킵니다.
• Basic Protocol
  • Data write
  • Journal metadata write
  • Journal commit
  • Checkpoint metadata
  • Free